[Bug bootstrap/45612] [4.6 regression] Reference to undefined label building libada on Solaris 2/SPARC

["hainque at adacore dot com" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45612

--- Comment #21 from hainque at adacore dot com <hainque at adacore dot com> 2010-10-01 22:11:52 UTC ---
hubicka at gcc dot gnu.org wrote:
> We might be missing some code in inliner that passes the fact that
> the label is user label...

 I don't yet have a clear track here, but can provide a pretty easy
 way to reproduce with a cross and get starters for further analysis:

 $ configure --target=sparc-sun-solaris2.10 --enable-languages=c,ada
             --disable-libada --disable-bootstrap

 $ make CFLAGS="-O0 -g"
 ...
 let it fail when it gets to C parts of runtime libraries.
 you should have gnat1 at this stage. then ...

 $ cd gcc
 $ make -C ada ../stamp-gnatlib1-rts

 this prepares the runtime library source symlinks in ada/rts. now:

 $ ./gnat1 -Iada/rts ada/rts/g-debpoo.adb -O2 -fdump-tree-all -da

 the anomaly is visible in the output, in particular in one call 
 to debug_pools__put_line from the code for 'Dereference'

  gnat__debug_pools__dereference__2:
     ...
     ld   [%g1+%lo(gnat__debug_pools__code_address_for_dereference_end)], %o4
     ...
     sethi   %hi(.LL544), %o3
     ...
     call    gnat__debug_pools__put_line, 0
     or     %o3, %lo(.LL544), %o3

 LL544 is nowhere for me.

 From a quick glance, this one of the calls to Put_Line in

     <<Dereference_Label>>

      if not Valid then
         if Pool.Raise_Exceptions then
            raise Accessing_Not_Allocated_Storage;
         else
            Put (Output_File (Pool),
                 "error: Accessing not allocated storage, at ");
            Put_Line (Output_File (Pool), Pool.Stack_Trace_Depth, null,
                      Dereference_Label'Address,
                      Code_Address_For_Dereference_End);
         end if;

      else
         Header := Header_Of (Storage_Address);

         if Header.Block_Size < 0 then
            if Pool.Raise_Exceptions then
               raise Accessing_Deallocated_Storage;
            else
               Put (Output_File (Pool),
                    "error: Accessing deallocated storage, at ");
               Put_Line
                 (Output_File (Pool), Pool.Stack_Trace_Depth, null,
                  Dereference_Label'Address,
                  Code_Address_For_Dereference_End);


 which indeed passe the address of the <<Dereference_Label>> code
 label.

 Compiling -da then grep suggests that the label disappears as of

  ada/rts/g-debpoo.adb.153r.vregs:
   (code_label/s 12 11 13 4 538 ("dereference_label") [4 uses])

  ada/rts/g-debpoo.adb.154r.into_cfglayout:
   (note/s 12 11 14 2 ("dereference_label") NOTE_INSN_DELETED_LABEL 538)

 This is still very rough and obviously needs further investigation, but
 yields starters.