[Bug ada/116498] New: gnat enters busy wait trying to compile for msp430-none-elf with -mlarge flag

[Bug ada/116498] New: gnat enters busy wait trying to compile for msp430-none-elf with -mlarge flag

[alancf0 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116498

            Bug ID: 116498
           Summary: gnat enters busy wait trying to compile for
                    msp430-none-elf with -mlarge flag
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ada
          Assignee: unassigned at gcc dot gnu.org
          Reporter: alancf0 at gmail dot com
                CC: dkm at gcc dot gnu.org
  Target Milestone: ---
            Target: msp430-none-elf

Created attachment 59009
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59009&action=edit
source files for compiler command

Hello,

First some platform information:
Host: x86_64-linux-gnu (Debian bookworm)
Host complier: gcc 12.2.0

The gcc / gnat at issue is also gcc 12.2.0, configured as:
../configure --prefix=/home/acf/msp430tools --target=msp430-none-elf
--with-newlib --disable-libada --disable-libstdcxx-pch --without-headers
--with-include=../../newlib-4.4.0.20231231/include/ --disable-nls
target_alias=msp430-none-elf --enable-languages=c,ada,c++,lto

This is used with binutils 2.43.1
../configure --prefix=/home/acf/msp430tools --target=msp430-none-elf

And newlib 4.4.0.20231231
../configure --prefix=/home/acf/msp430tools --target=msp430-none-elf
--disable-newlib-supplied-syscalls --enable-newlib-reent-small
--disable-newlib-fseek-optimization --disable-newlib-wide-orient
--enable-newlib-nano-formatted-io --disable-newlib-io-float
--enable-newlib-nano-malloc --disable-newlib-unbuf-stream-opt
--enable-lite-exit --enable-newlib-global-atexit --disable-nls


binutils and newlib build and install as usual; I build gcc with:
make all-gcc
make all-target-libgcc
make install-gcc
make install-target-libgcc
make -C gcc cross-gnattools ada.all.cross
make install-gcc


Once gcc is installed, I try to build a file (note the -msmall , selecting
16-bit pointers):
$ /home/acf/msp430tools/bin/msp430-none-elf-gcc -c -x ada -gnatA -gnat2005 -g
-gnatg -gnatec=../gnat.adc -O0 --RTS=../rts/boards/arm -msmall
/home/acf/ada_test/rts/boards/arm/adainclude/system.ads
$
... gcc / gnat compiles file and exits quickly ...

I try to build the same file again with -mlarge (selecting 20-bit pointers)
$ /home/acf/msp430tools/bin/msp430-none-elf-gcc -c -x ada -gnatA -gnat2005 -g
-gnatg -gnatec=../gnat.adc -O0 --RTS=../rts/boards/arm -mlarge
/home/acf/ada_test/rts/boards/arm/adainclude/system.ads
... gcc / gnat hangs forever ...
^C
$

Running under gdb and breaking after a couple of seconds quickly reveals the
problem:
$ gdb /home/acf/msp430tools/bin/msp430-none-elf-gcc
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
[...deleted...]
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/acf/msp430tools/bin/msp430-none-elf-gcc...
(gdb) set follow-fork-mode child
(gdb) run -c -x ada -gnatA -gnat2005 -g -gnatg -gnatec=../gnat.adc -O0
--RTS=../rts/boards/arm -mlarge
/home/acf/ada_test/rts/boards/arm/adainclude/system.ads
Starting program: /home/acf/msp430tools/bin/msp430-none-elf-gcc -c -x ada
-gnatA -gnat2005 -g -gnatg -gnatec=../gnat.adc -O0 --RTS=../rts/boards/arm
-mlarge /home/acf/ada_test/rts/boards/arm/adainclude/system.ads
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Attaching after Thread 0x7ffff7db2740 (LWP 1825980) vfork to child process
1825983]
[New inferior 2 (process 1825983)]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching vfork parent process 1825980 after child exec]
[Inferior 1 (process 1825980) detached]
process 1825983 is executing new program:
/home/acf/msp430tools/libexec/gcc/msp430-none-elf/12.2.0/gnat1
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
^C
Thread 2.1 "gnat1" received signal SIGINT, Interrupt.
[Switching to Thread 0x7ffff7c17ac0 (LWP 1825983)]
default_valid_pointer_mode (mode=...) at ../../gcc/machmode.h:421
421       ALWAYS_INLINE CONSTEXPR operator machine_mode () const { return
m_mode; }
(gdb) next
1553      return (mode == ptr_mode || mode == Pmode);
(gdb) 
validate_size (uint_size=<optimized out>, gnu_type=<optimized out>,
gnat_object=gnat_object@entry=526, kind=<optimized out>, component_p=<optimized
out>, zero_ok=<optimized out>, 
    s1=0x18ed708 "size for %s too small{, minimum allowed is ^}", s2=0x194371e
"&") at ../../gcc/ada/gcc-interface/decl.cc:9299
9299            p_mode = GET_MODE_WIDER_MODE (p_mode).require ();
(gdb) 
9298          while (!targetm.valid_pointer_mode (p_mode))
(gdb) 
9299            p_mode = GET_MODE_WIDER_MODE (p_mode).require ();
(gdb) 
9298          while (!targetm.valid_pointer_mode (p_mode))
(gdb) 
9299            p_mode = GET_MODE_WIDER_MODE (p_mode).require ();
(gdb) 
9298          while (!targetm.valid_pointer_mode (p_mode))
(gdb) 
9299            p_mode = GET_MODE_WIDER_MODE (p_mode).require ();
(gdb) 
9298          while (!targetm.valid_pointer_mode (p_mode))
(gdb) 
9299            p_mode = GET_MODE_WIDER_MODE (p_mode).require ();
(gdb)

The context from the source around decl.cc:9299
  /* If this is an access type or a fat pointer, the minimum size is that given
     by the smallest integral mode that's valid for pointers.  */
  if (TREE_CODE (gnu_type) == POINTER_TYPE || TYPE_IS_FAT_POINTER_P (gnu_type))
    {
      scalar_int_mode p_mode = NARROWEST_INT_MODE;
      while (!targetm.valid_pointer_mode (p_mode))
        p_mode = GET_MODE_WIDER_MODE (p_mode).require ();
      old_size = bitsize_int (GET_MODE_BITSIZE (p_mode));
    }


It appears we start at "NARROWEST_INT_MODE" and select a wider mode until we
find one which is a valid pointer mode. Checking the 'mode_wider' table, it
appears that when -mlarge is used, the pointer mode cannot be reached using
this algorithm. Instead the sequence shown below is taken, ending with the VOID
mode being visited repeatedly

const unsigned char mode_wider[NUM_MACHINE_MODES] =
{
  E_VOIDmode,              /* VOID */        <--------|
  E_VOIDmode,              /* BLK */                  |
  E_VOIDmode,              /* CC */                   |
  E_QImode,                /* BI */                   |
  E_HImode,                /* QI */  >---|            | <- NARROWEST_INT_MODE
  E_SImode,                /* HI */  <---|   >---|    |
  E_DImode,                /* SI */  >---|   <---|    |
  E_TImode,                /* DI */  <---|   >--------|
  E_VOIDmode,              /* TI */                     <- Pmode (pointer)
  E_SImode,                /* PSI */
  E_HQmode,                /* QQ */
...


Changing
      scalar_int_mode p_mode = NARROWEST_INT_MODE;
to
      scalar_int_mode p_mode = Pmode;
results in gcc / gnat exiting with an error. Disabling several more checks
further down in validate_size() results in gcc finishing without error and
generating a binary. Of course I have no idea if the generated code is correct;
probably not.

Many of these checks / errors seem to indicate a lack of support in gnat for
pointer sizes which are not a multiple of 8 bits, such as "size for ... must be
multiple of Storage_Unit". This will obviously not be the case on platforms
like msp430x with -mlarge where void* is 20 bits, and Storage_Unit is 8 bits.
Are such platforms simply unsupported by gnat? In which case I suppose an error
should be introduced earlier to avoid the busywait. It is also oddly asymmetric
that the compiler can build binaries on the same platform with the -msmall
memory model (with a 16-bit pointer) but not with -mlarge (with a 20-bit
pointer).

NB: I have no experience with gcc internals so maybe be careful when reading my
analysis ;)

Thanks for reading!

All the best,
Alan

[Bug ada/116498] gnat enters busy wait trying to compile for msp430-none-elf with -mlarge flag

[alancf0 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116498

--- Comment #1 from Alan Fisher <alancf0 at gmail dot com> ---
Correction to the above diagram:

const unsigned char mode_wider[NUM_MACHINE_MODES] =
{
  E_VOIDmode,              /* VOID */              <--|
  E_VOIDmode,              /* BLK */                  |
  E_VOIDmode,              /* CC */                   |
  E_QImode,                /* BI */                   |
  E_HImode,                /* QI */  >---|            | <- NARROWEST_INT_MODE
  E_SImode,                /* HI */  <---|   >---|    |
  E_DImode,                /* SI */  >---|   <---|    |
  E_TImode,                /* DI */  <---|   >---|    |
  E_VOIDmode,              /* TI */          <---| >--|
  E_SImode,                /* PSI */                    <- Pmode (pointer)
  E_HQmode,                /* QQ */
...

[Bug ada/116498] gnat enters busy wait trying to compile for msp430-none-elf with -mlarge flag

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116498

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed on trunk,

      while (!targetm.valid_pointer_mode (p_mode))
        p_mode = GET_MODE_WIDER_MODE (p_mode).require ();

is broken, but I think the code expects it will find a valid_pointer_mode
and this expectation is wrong in this case.

It seems odd that neither Pmode nor ptr_mode is in the set of integer modes
though.  Eventually because

/* 20-bit address */
PARTIAL_INT_MODE (SI, 20, PSI);

INT_N (PSI, 20);

it seems PSImode is not found via the above iteration.

[Bug ada/116498] gnat enters busy wait trying to compile for msp430-none-elf with -mlarge flag

[alancf0 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116498

--- Comment #3 from Alan Fisher <alancf0 at gmail dot com> ---
> It seems odd that neither Pmode nor ptr_mode is in the set of integer modes though.

This does seem odd... One would think PSI should sit between HI and SI as here:
https://gcc.gnu.org/onlinedocs/gccint/Machine-Modes.html . Again, as someone
who knows little about gcc internals maybe this is not that useful but...

Upon investigation this appears to be a result of how calc_wider_mode() in
genmodes.cc works. From what I can see,
  - Each mode is iterated through
  - The objects in each mode are sorted according to some set of criteria (see
below) -
    but the sorting is done only within the mode, not between modes
  - Following the sorting process of a mode in calc_wider_mode, the 'wider'
member of
    the mode structure is set to the next member in the sorted list
  - The algorithm for emitting the mode_wider array involves iterating over
each mode,
    printing out each object within, and its 'wider' member.
  - This means that all of the integer modes are sorted together within their
    category (2); the single partial integer mode is "sorted" within its
category (3);
    and the latter is emitted in the mode_wider text output below the former
  - The comparison used to sort the objects within modes involves the
'bytesize' and
    'precision' fields, the latter of which is used for partial integers to
indicate their
    bit length. A number of other fields are also used.

Most of this code / design seems to have been around untouched for a long time.
Perhaps someone else can comment on whether this is correct output for
genmodes.

All the best,
Alan

[Bug ada/116498] gnat enters busy wait trying to compile for msp430-none-elf with -mlarge flag

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116498

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-09-09
             Status|UNCONFIRMED                 |NEW

--- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
The loop can be fixed, but that will probably not be the end of the road.

[Bug ada/116498] infinite loop on MSP430 with -mlarge flag

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116498

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |ebotcazou at gcc dot gnu.org