Unexpected case sensitivity in port names

[nipo]

I use ghdl plugin for parsing VHDL code to be synthesized with Yosys to iCE40.

GHDL 2.0.0-dev (1.0.0.r73.g691be6df) Yosys 0.9+4008 (git sha1 396ad17e, gcc 10.2.0-13ubuntu1 -fPIC -Os)

My library contains the following (trivial) adapter entity:

library ieee;
use ieee.std_logic_1164.all;

entity clock_buffer is
  port(
    clock_i      : in std_ulogic;
    clock_o      : out std_ulogic
    );
end entity;

architecture ice of clock_buffer is

  component SB_GB
    port (
      user_signal_to_global_buffer:in std_logic;
      global_buffer_output:out std_logic
      );
  end component;

begin

  gb: sb_gb
    port map(
      user_signal_to_global_buffer => clock_i,
      global_buffer_output => clock_o
      );

end architecture;

If used in a design, elaboration works, but when mapping to library, process fails with the following error:

ERROR: Module `SB_GB' referenced in module `clock_buffer' in cell `gb' does not have a port named 'global_buffer_output'.

If I change architecture in my VHDL code to (i.e. replace both port declaration and mapping to upper-case), it works.

architecture ice of clock_buffer is

  component SB_GB
    port (
      USER_SIGNAL_TO_GLOBAL_BUFFER:in std_logic;
      GLOBAL_BUFFER_OUTPUT:out std_logic
      );
  end component;

begin

  gb: sb_gb
    port map(
      USER_SIGNAL_TO_GLOBAL_BUFFER => clock_i,
      GLOBAL_BUFFER_OUTPUT => clock_o
      );

end architecture;

Alternatively, if I change forward declaration to the following (note case change for component name):

  component sb_gb
    port (
      user_signal_to_global_buffer:in std_logic;
      global_buffer_output:out std_logic
      );
  end component;

it works as well.

There must be some unwanted case-sensitive matching somewhere.

Attached a test case: case-mapping.zip

[nipo]

And I just noticed nextpnr-ice40 only takes the upper-case version as valid, else it fails with:

ERROR: cell type 'sb_gb' is unsupported (instantiated as 'gb16.gb')

[whitequark]

We discussed this in a meeting today, and concluded that a reasonable approach here would be to add a new module attribute that GHDL could use. When this attribute is used, the hierarchy pass would use case-insensitive comparisons for the referenced module names and ports.