Patchwork [Ada] Implementation of aspects within generic units

login
register
mail settings
Submitter Arnaud Charlet
Date Aug. 31, 2011, 9:43 a.m.
Message ID <20110831094306.GA25125@adacore.com>
Download mbox | patch
Permalink /patch/112491/
State New
Headers show

Comments

Arnaud Charlet - Aug. 31, 2011, 9:43 a.m.
If a declaration within a generic unit has aspects, the capture of references
within the aspect expressions has to be done in a separate step because the
aspect specificatios are not directly attached to the tree for the declaration.

The following must compile quietly:

   gcc -c -gnat12 -gnata ml.ads

with Ml_Type;
with Generic_Matrix;
package Ml is

   subtype T_Int32 is Ml_Type.T_Int32;
   subtype T_Float32 is Ml_Type.T_Float32;

   package M32 is new Generic_Matrix(G_Float => T_Float32);
   type T_Matrix32 is new M32.G_Matrix;

   subtype Range2 is T_Int32 range 0 .. 1;
   subtype Range3 is T_Int32 range 0 .. 2;
end Ml;
---
package Ml_Type is
   type T_Int32 is range (-2 ** 31) .. (2 ** 31 - 1);

   type T_Float32 is digits 6  range -3.40282E+38 .. 3.40282E+38;
end Ml_Type;
---
with Ml_Type;

generic
     type G_Float is digits <>;
package Generic_Matrix is
   type G_Matrix is array (Ml_Type.T_Int32 range <>,
                           Ml_Type.T_Int32 range <>) of G_Float;

   function "+" (Left,
                 Right : G_Matrix)
                 return G_Matrix;

   function "-" (Left,
                 Right : G_Matrix)
                 return G_Matrix
     with Pre => (Left'Length (1) = Right'Length (1) and then
     Left'Length (2) = Right'Length (2) );
end Generic_Matrix;
---
package body Generic_Matrix is
   function "+" (Left,
                 Right : G_Matrix)
                 return G_Matrix is
      Res : G_Matrix(Left'Range(1), Left'Range(2));
   begin

      if Left'Length (1) /= Right'Length (1)
        or else Left'Length (2) /= Right'Length (2)
      then
         raise Constraint_Error with
           "matrices are of different dimension in elementwise operation";
      end if;

      for I in Res'Range(1) loop
         for J in Res'Range(2) loop
            Res(I,J) := Left(I,J) + Right(I,J);
         end loop;
      end loop;

      return Res;
   end "+";

   function "-" (Left,
                 Right : G_Matrix)
                 return G_Matrix is
      Res : G_Matrix(Left'Range(1), Left'Range(2));
   begin

      for I in Res'Range(1) loop
         for J in Res'Range(2) loop
            Res(I,J) := Left(I,J) - Right(I,J);
         end loop;
      end loop;

      return Res;
   end "-";
end Generic_Matrix;

Tested on x86_64-pc-linux-gnu, committed on trunk

2011-08-31  Ed Schonberg  <schonberg@adacore.com>

	* sem_ch12.adb (Save_References): If the node has aspects, save
	references within the corresponding expressions in a separate step,
	because the aspects are not directly in the tree for the declaration
	to which they belong.
Richard Guenther - Aug. 31, 2011, 10:24 a.m.
On Wed, Aug 31, 2011 at 11:43 AM, Arnaud Charlet <charlet@adacore.com> wrote:
> If a declaration within a generic unit has aspects, the capture of references
> within the aspect expressions has to be done in a separate step because the
> aspect specificatios are not directly attached to the tree for the declaration.

Just replying to a random mail of this mega-series.

Bootstrap with Ada included was broken at random revisions throughout
the last days which made testing any patch quite painful (well, as someone
who includes Ada in bootstrap and testing by default).

Can you please ensure that you don't break bootstrap all the time?  I'm
now simply testing patches w/o Ada for the time being (having wasted
another hour for verifying it wasn't my patch causing the last bootstrap
error I ran into, loads of

+===========================GNAT BUG DETECTED==============================+
| 4.7.0 20110831 (experimental) [trunk revision 161655]
(x86_64-unknown-linux-gnu) |
| Storage_Error stack overflow or erroneous memory access                  |
| Error detected at a-elchha.adb:41:25                                     |

Thanks,
Richard.

> The following must compile quietly:
>
>   gcc -c -gnat12 -gnata ml.ads
>
> with Ml_Type;
> with Generic_Matrix;
> package Ml is
>
>   subtype T_Int32 is Ml_Type.T_Int32;
>   subtype T_Float32 is Ml_Type.T_Float32;
>
>   package M32 is new Generic_Matrix(G_Float => T_Float32);
>   type T_Matrix32 is new M32.G_Matrix;
>
>   subtype Range2 is T_Int32 range 0 .. 1;
>   subtype Range3 is T_Int32 range 0 .. 2;
> end Ml;
> ---
> package Ml_Type is
>   type T_Int32 is range (-2 ** 31) .. (2 ** 31 - 1);
>
>   type T_Float32 is digits 6  range -3.40282E+38 .. 3.40282E+38;
> end Ml_Type;
> ---
> with Ml_Type;
>
> generic
>     type G_Float is digits <>;
> package Generic_Matrix is
>   type G_Matrix is array (Ml_Type.T_Int32 range <>,
>                           Ml_Type.T_Int32 range <>) of G_Float;
>
>   function "+" (Left,
>                 Right : G_Matrix)
>                 return G_Matrix;
>
>   function "-" (Left,
>                 Right : G_Matrix)
>                 return G_Matrix
>     with Pre => (Left'Length (1) = Right'Length (1) and then
>     Left'Length (2) = Right'Length (2) );
> end Generic_Matrix;
> ---
> package body Generic_Matrix is
>   function "+" (Left,
>                 Right : G_Matrix)
>                 return G_Matrix is
>      Res : G_Matrix(Left'Range(1), Left'Range(2));
>   begin
>
>      if Left'Length (1) /= Right'Length (1)
>        or else Left'Length (2) /= Right'Length (2)
>      then
>         raise Constraint_Error with
>           "matrices are of different dimension in elementwise operation";
>      end if;
>
>      for I in Res'Range(1) loop
>         for J in Res'Range(2) loop
>            Res(I,J) := Left(I,J) + Right(I,J);
>         end loop;
>      end loop;
>
>      return Res;
>   end "+";
>
>   function "-" (Left,
>                 Right : G_Matrix)
>                 return G_Matrix is
>      Res : G_Matrix(Left'Range(1), Left'Range(2));
>   begin
>
>      for I in Res'Range(1) loop
>         for J in Res'Range(2) loop
>            Res(I,J) := Left(I,J) - Right(I,J);
>         end loop;
>      end loop;
>
>      return Res;
>   end "-";
> end Generic_Matrix;
>
> Tested on x86_64-pc-linux-gnu, committed on trunk
>
> 2011-08-31  Ed Schonberg  <schonberg@adacore.com>
>
>        * sem_ch12.adb (Save_References): If the node has aspects, save
>        references within the corresponding expressions in a separate step,
>        because the aspects are not directly in the tree for the declaration
>        to which they belong.
>
>
Arnaud Charlet - Aug. 31, 2011, 11:16 a.m.
> Bootstrap with Ada included was broken at random revisions throughout
> the last days which made testing any patch quite painful (well, as someone
> who includes Ada in bootstrap and testing by default).
> 
> Can you please ensure that you don't break bootstrap all the time?  I'm
> now simply testing patches w/o Ada for the time being (having wasted
> another hour for verifying it wasn't my patch causing the last bootstrap
> error I ran into, loads of

Sorry about the pain. Yes, I'm trying hard to not break bootstrap, and when
I do, I fix it as soon as possible.

> +===========================GNAT BUG DETECTED==============================+
> | 4.7.0 20110831 (experimental) [trunk revision 161655]
> (x86_64-unknown-linux-gnu) |
> | Storage_Error stack overflow or erroneous memory access                  |
> | Error detected at a-elchha.adb:41:25                                     |

This one was fixed very rapidly (like within 15 minutes AFAIK).

The other issue reported was wrt rts vs $(RTS) which wasn't detected by
my build and which was fixed later, so perhaps it's the one that caused you
more troubles.

In any case, I'll try to avoid these as much as possible.

Arno
Richard Guenther - Aug. 31, 2011, 2:33 p.m.
On Wed, Aug 31, 2011 at 1:16 PM, Arnaud Charlet <charlet@adacore.com> wrote:
>> Bootstrap with Ada included was broken at random revisions throughout
>> the last days which made testing any patch quite painful (well, as someone
>> who includes Ada in bootstrap and testing by default).
>>
>> Can you please ensure that you don't break bootstrap all the time?  I'm
>> now simply testing patches w/o Ada for the time being (having wasted
>> another hour for verifying it wasn't my patch causing the last bootstrap
>> error I ran into, loads of
>
> Sorry about the pain. Yes, I'm trying hard to not break bootstrap, and when
> I do, I fix it as soon as possible.
>
>> +===========================GNAT BUG DETECTED==============================+
>> | 4.7.0 20110831 (experimental) [trunk revision 161655]
>> (x86_64-unknown-linux-gnu) |
>> | Storage_Error stack overflow or erroneous memory access                  |
>> | Error detected at a-elchha.adb:41:25                                     |
>
> This one was fixed very rapidly (like within 15 minutes AFAIK).

It seems not.  Still broken with rev. 178380.

Richard.
Arnaud Charlet - Aug. 31, 2011, 3:07 p.m.
> >> +===========================GNAT BUG
> >> DETECTED==============================+
> >> | 4.7.0 20110831 (experimental) [trunk revision 161655]
> >> (x86_64-unknown-linux-gnu) |
> >> | Storage_Error stack overflow or erroneous memory access                  |
> >> | Error detected at a-elchha.adb:41:25                                     |
> >
> > This one was fixed very rapidly (like within 15 minutes AFAIK).
> 
> It seems not.  Still broken with rev. 178380.

Hmm, then it's not the issue I had in mind, and not something I'm aware of
(didn't get this error on my end on any build I've done).

Which bootstrap compiler are you using, and at which stage is the above
error occurring? Which options are you using to build?

Did you restart a build from scratch after this error first occurred?

I just retried another complete bootstrap from scratch and still don't
get any error.

Arno
Joseph S. Myers - Aug. 31, 2011, 3:53 p.m.
On Wed, 31 Aug 2011, Arnaud Charlet wrote:

> > >> +===========================GNAT BUG
> > >> DETECTED==============================+
> > >> | 4.7.0 20110831 (experimental) [trunk revision 161655]
> > >> (x86_64-unknown-linux-gnu) |
> > >> | Storage_Error stack overflow or erroneous memory access                  |
> > >> | Error detected at a-elchha.adb:41:25                                     |
> > >
> > > This one was fixed very rapidly (like within 15 minutes AFAIK).
> > 
> > It seems not.  Still broken with rev. 178380.
> 
> Hmm, then it's not the issue I had in mind, and not something I'm aware of
> (didn't get this error on my end on any build I've done).
> 
> Which bootstrap compiler are you using, and at which stage is the above
> error occurring? Which options are you using to build?
> 
> Did you restart a build from scratch after this error first occurred?
> 
> I just retried another complete bootstrap from scratch and still don't
> get any error.

I also see a bootstrap failure on x86_64-unknown-linux-gnu, r178381.

+===========================GNAT BUG DETECTED==============================+
| 4.7.0 20110831 (experimental) [trunk revision 178381] (x86_64-unknown-linux-gnu) |
| Storage_Error stack overflow or erroneous memory access                  |
| Error detected at system.ads:175:5                                       |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.            |
| Use a subject line meaningful to you and us to track the bug.            |
| Include the entire contents of this bug box in the report.               |
| Include the exact gcc or gnatmake command that you entered.              |
| Also include sources listed below in gnatchop format                     |
| (concatenated together with no headers between files).                   |
+==========================================================================+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

/scratch/jmyers/fsf/gcc-mainline/gcc/ada/system.ads
/scratch/jmyers/fsf/gcc-mainline/gcc/ada/a-charac.ads
/scratch/jmyers/fsf/gcc-mainline/gcc/ada/ada.ads

compilation abandoned
make[3]: *** [ada/a-charac.o] Error 1
make[3]: *** Waiting for unfinished jobs....
[...]
make[3]: Leaving directory `/scratch/jmyers/fsf/build/gcc'
make[2]: *** [all-stage3-gcc] Error 2
make[2]: Leaving directory `/scratch/jmyers/fsf/build'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/scratch/jmyers/fsf/build'
make: *** [all] Error 2

The bootstrap compiler is 4.6.2 20110816 (prerelease).
Arnaud Charlet - Aug. 31, 2011, 3:57 p.m.
> (x86_64-unknown-linux-gnu) |
> | Storage_Error stack overflow or erroneous memory access                  |
> | Error detected at system.ads:175:5                                       |
> +==========================================================================+
> 
> 
> 
> Please include these source files with error report
> Note that list may not be accurate in some cases,
> so please double check that the problem can still
> be reproduced with the set of files listed.
> Consider also -gnatd.n switch (see debug.adb).
> 
> /scratch/jmyers/fsf/gcc-mainline/gcc/ada/system.ads
> /scratch/jmyers/fsf/gcc-mainline/gcc/ada/a-charac.ads
> /scratch/jmyers/fsf/gcc-mainline/gcc/ada/ada.ads
> 
> compilation abandoned
> make[3]: *** [ada/a-charac.o] Error 1
> make[3]: *** Waiting for unfinished jobs....
> [...]
> make[3]: Leaving directory `/scratch/jmyers/fsf/build/gcc'
> make[2]: *** [all-stage3-gcc] Error 2
> make[2]: Leaving directory `/scratch/jmyers/fsf/build'
> make[1]: *** [stage3-bubble] Error 2
> make[1]: Leaving directory `/scratch/jmyers/fsf/build'
> make: *** [all] Error 2
> 
> The bootstrap compiler is 4.6.2 20110816 (prerelease).

OK. Can you get a backtrace from gnat1 on this crash so that
we get a bit more info about where gnat1 is crashing? As I said, I can't
reproduce it and the above info unfortunately isn't enough to understand
what is going on.

Arno
IainS - Aug. 31, 2011, 4 p.m.
On 31 Aug 2011, at 16:53, Joseph S. Myers wrote:

> On Wed, 31 Aug 2011, Arnaud Charlet wrote:
>
>>>>> +===========================GNAT BUG
>>>>> DETECTED==============================+
>>>>> | 4.7.0 20110831 (experimental) [trunk revision 161655]
>>>>> (x86_64-unknown-linux-gnu) |
>>>>> | Storage_Error stack overflow or erroneous memory  
>>>>> access                  |
>>>>> | Error detected at a-elchha.adb: 
>>>>> 41:25                                     |
>>>>
>>>> This one was fixed very rapidly (like within 15 minutes AFAIK).
>>>
>>> It seems not.  Still broken with rev. 178380.
>>
>> Hmm, then it's not the issue I had in mind, and not something I'm  
>> aware of
>> (didn't get this error on my end on any build I've done).
>>
>> Which bootstrap compiler are you using, and at which stage is the  
>> above
>> error occurring? Which options are you using to build?
>>
>> Did you restart a build from scratch after this error first occurred?
>>
>> I just retried another complete bootstrap from scratch and still  
>> don't
>> get any error.
>
> I also see a bootstrap failure on x86_64-unknown-linux-gnu, r178381.
>
> +===========================GNAT BUG  
> DETECTED==============================+
> | 4.7.0 20110831 (experimental) [trunk revision 178381] (x86_64- 
> unknown-linux-gnu) |
> | Storage_Error stack overflow or erroneous memory  
> access                  |
> | Error detected at system.ads: 
> 175:5                                       |
> | Please submit a bug report; see http://gcc.gnu.org/ 
> bugs.html.            |
> | Use a subject line meaningful to you and us to track the  
> bug.            |
> | Include the entire contents of this bug box in the  
> report.               |
> | Include the exact gcc or gnatmake command that you  
> entered.              |
> | Also include sources listed below in gnatchop  
> format                     |
> | (concatenated together with no headers between  
> files).                   |
> + 
> = 
> = 
> = 
> = 
> = 
> =====================================================================+
>
> Please include these source files with error report
> Note that list may not be accurate in some cases,
> so please double check that the problem can still
> be reproduced with the set of files listed.
> Consider also -gnatd.n switch (see debug.adb).
>
> /scratch/jmyers/fsf/gcc-mainline/gcc/ada/system.ads
> /scratch/jmyers/fsf/gcc-mainline/gcc/ada/a-charac.ads
> /scratch/jmyers/fsf/gcc-mainline/gcc/ada/ada.ads
>
> compilation abandoned
> make[3]: *** [ada/a-charac.o] Error 1
> make[3]: *** Waiting for unfinished jobs....
> [...]
> make[3]: Leaving directory `/scratch/jmyers/fsf/build/gcc'
> make[2]: *** [all-stage3-gcc] Error 2
> make[2]: Leaving directory `/scratch/jmyers/fsf/build'
> make[1]: *** [stage3-bubble] Error 2
> make[1]: Leaving directory `/scratch/jmyers/fsf/build'
> make: *** [all] Error 2
>
> The bootstrap compiler is 4.6.2 20110816 (prerelease).

same on i686-darwin9 @ 178381
(Bootstrap compiler = 4.7.0 r178116, last successful bootstrap 178261)

>

>
> -- 
> Joseph S. Myers
> joseph@codesourcery.com
IainS - Aug. 31, 2011, 4:13 p.m.
On 31 Aug 2011, at 16:57, Arnaud Charlet wrote:

>> (x86_64-unknown-linux-gnu) |
>> | Storage_Error stack overflow or erroneous memory  
>> access                  |
>> | Error detected at system.ads: 
>> 175:5                                       |
>> + 
>> = 
>> = 
>> = 
>> = 
>> = 
>> = 
>> ====================================================================+
>>
>>
>>
>> Please include these source files with error report
>> Note that list may not be accurate in some cases,
>> so please double check that the problem can still
>> be reproduced with the set of files listed.
>> Consider also -gnatd.n switch (see debug.adb).
>>
>> /scratch/jmyers/fsf/gcc-mainline/gcc/ada/system.ads
>> /scratch/jmyers/fsf/gcc-mainline/gcc/ada/a-charac.ads
>> /scratch/jmyers/fsf/gcc-mainline/gcc/ada/ada.ads
>>
>> compilation abandoned
>> make[3]: *** [ada/a-charac.o] Error 1
>> make[3]: *** Waiting for unfinished jobs....
>> [...]
>> make[3]: Leaving directory `/scratch/jmyers/fsf/build/gcc'
>> make[2]: *** [all-stage3-gcc] Error 2
>> make[2]: Leaving directory `/scratch/jmyers/fsf/build'
>> make[1]: *** [stage3-bubble] Error 2
>> make[1]: Leaving directory `/scratch/jmyers/fsf/build'
>> make: *** [all] Error 2
>>
>> The bootstrap compiler is 4.6.2 20110816 (prerelease).
>
> OK. Can you get a backtrace from gnat1 on this crash so that
> we get a bit more info about where gnat1 is crashing? As I said, I  
> can't
> reproduce it and the above info unfortunately isn't enough to  
> understand
> what is going on.

on i686-darwin9:

(gdb) run
Starting program: /Volumes/ScratchCS/gcc-4-7-trunk-build/prev-gcc/ 
gnat1 -I - -I . -I ada -I /GCC/gcc-live-trunk/gcc/ada -I /GCC/gcc-live- 
trunk/gcc/ada/gcc-interface -quiet -nostdinc -dumpbase a-charac.ads - 
auxbase-strip ada/a-charac.o -O2 -fexceptions -mmacosx-version- 
min=10.5.8 -g -gnatpg -gnata -gnatwns -mtune=core2 -fPIC -feliminate- 
unused-debug-symbols -gnatO ada/a-charac.o /GCC/gcc-live-trunk/gcc/ada/ 
a-charac.ads -o /var/folders/OW/OW-PGOtgHbKakssxFpJpkU++-0E/-Tmp-// 
ccKUPx8T.s
Reading symbols for shared libraries +++.. done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x001c4fa0 in lib__writ__write_ali ()
(gdb) bt
#0  0x001c4fa0 in lib__writ__write_ali ()
#1  0x0036799a in _ada_gnat1drv ()
#2  0x000305f5 in gnat_parse_file ()

cheers,
Iain
Arnaud Charlet - Aug. 31, 2011, 4:34 p.m.
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
> 0x001c4fa0 in lib__writ__write_ali ()
> (gdb) bt
> #0  0x001c4fa0 in lib__writ__write_ali ()
> #1  0x0036799a in _ada_gnat1drv ()
> #2  0x000305f5 in gnat_parse_file ()

I just triple checked, and revision 178381 is OK for me on
x86_64-unknown-linux-gnu.

Unfortunately without debug info, the above traceback isn't
giving much info.

Just a shot in the dark, can you try to pinpoint at which revision
things started to break? That'd be useful.

In particular I'd be curious to know if revision 178376 has the failure or not.

Same for revision 178311
IainS - Aug. 31, 2011, 7:07 p.m.
On 31 Aug 2011, at 17:34, Arnaud Charlet wrote:

>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
>> 0x001c4fa0 in lib__writ__write_ali ()
>> (gdb) bt
>> #0  0x001c4fa0 in lib__writ__write_ali ()
>> #1  0x0036799a in _ada_gnat1drv ()
>> #2  0x000305f5 in gnat_parse_file ()
>
> I just triple checked, and revision 178381 is OK for me on
> x86_64-unknown-linux-gnu.
>
> Unfortunately without debug info, the above traceback isn't
> giving much info.
>
> Just a shot in the dark, can you try to pinpoint at which revision
> things started to break? That'd be useful.
>
> In particular I'd be curious to know if revision 178376 has the  
> failure or not.

different failure;
built with BOOT_CFLAGS="-O0 -g" ..
.. it fails debug-compare (ada/exp_ch6.o).
There are a lot of seemingly innocuous code differences (nop  
insertions) masking whatever the real problem is (difficult to compare  
because  of the number of trivial differences).

If I touch compare and continue the bootstrap if fails building the  
native tools with a gnatmake internal error  
(SYSTEM_ASSERTIONS.ASSERT_FAILURE) namet.adb line 675 -- but that's a  
target-specific file, right?

===

... FWIW, I find debugging ada bootstrap problems especially  
intractable (any hints/advice on good techniques would be most  
welcome) ....
.... I've yet to succeed in getting powerpc-darwin9 (trunk) to  
bootstrap .. :-(
(although with some jiggery-pokery it is possible to bootstrap 4.6 on  
it.)

> Same for revision 178311

will set this going .. prob. tomorrow before a report.

----

Also - I don't know that Darwin is the best platform for test here --  
it's probably the least exercised ... so other people might wish to  
chime in....

cheers
Iain
IainS - Aug. 31, 2011, 7:56 p.m.
On 31 Aug 2011, at 20:07, Iain Sandoe wrote:
>
>> Same for revision 178311
>
> will set this going .. prob. tomorrow before a report.

fails with:
  "exp_light.ali" not found "exp_light.adb" must be compiled

.... (that issue was already reported by Richi).

so .. not much progress ... will try bisecting from 311 -> 261 which  
did bootstrap for me..

cheers
Iain
IainS - Sept. 1, 2011, 6:53 a.m.
On 31 Aug 2011, at 20:07, Iain Sandoe wrote:

> On 31 Aug 2011, at 17:34, Arnaud Charlet wrote:
>
>>>
>>
>> In particular I'd be curious to know if revision 178376 has the  
>> failure or not.
>
> different failure;
> built with BOOT_CFLAGS="-O0 -g" ..
> .. it fails debug-compare (ada/exp_ch6.o).
> There are a lot of seemingly innocuous code differences (nop  
> insertions) masking whatever the real problem is (difficult to  
> compare because  of the number of trivial differences).
>
> If I touch compare and continue the bootstrap if fails building the  
> native tools with a gnatmake internal error  
> (SYSTEM_ASSERTIONS.ASSERT_FAILURE) namet.adb line 675 -- but that's  
> a target-specific file, right?

Sorry, misleading datum...

The failure above is the result of building with "-O0 -g"

If I build with default BOOT_CFLAGS, 178376 fails in the same wayt as  
178381.

Iain
Richard Guenther - Sept. 1, 2011, 7:06 a.m.
On Wed, Aug 31, 2011 at 6:34 PM, Arnaud Charlet <charlet@adacore.com> wrote:
>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
>> 0x001c4fa0 in lib__writ__write_ali ()
>> (gdb) bt
>> #0  0x001c4fa0 in lib__writ__write_ali ()
>> #1  0x0036799a in _ada_gnat1drv ()
>> #2  0x000305f5 in gnat_parse_file ()
>
> I just triple checked, and revision 178381 is OK for me on
> x86_64-unknown-linux-gnu.
>
> Unfortunately without debug info, the above traceback isn't
> giving much info.
>
> Just a shot in the dark, can you try to pinpoint at which revision
> things started to break? That'd be useful.
>
> In particular I'd be curious to know if revision 178376 has the failure or not.
>
> Same for revision 178311

My bootstrap compiler is GCC 4.3.4, the error occurs in stage3 (well, when
building the RTS).  It will take some time to check the revs you quoted.

Richard.
Arnaud Charlet - Sept. 1, 2011, 7:14 a.m.
> My bootstrap compiler is GCC 4.3.4, the error occurs in stage3 (well, when
> building the RTS).  It will take some time to check the revs you quoted.

OK. Still trying to reproduce here and trying to figure out blindly what could
be the cause of this behavior for now.

Olivier is also trying to reproduce. Perhaps he or Eric will have an idea
on what could be going wrong.

Just in case, here are the versions of gmp and co I'm using:

gmp-4.3.2
mpc-0.8.1
mpfr-2.4.2

I also have other pending changes to merge. Perhaps one of these changes may
"fix" or make this problem go away, although that's also a shot in the dark,
since a quick review of the changes didn't shed any light/candidate.

Arno
Arnaud Charlet - Sept. 1, 2011, 7:53 a.m.
> OK. Still trying to reproduce here and trying to figure out blindly what
> could be the cause of this behavior for now.

I could finally reproduce on another machine (i686-linux), so I am now
doing a binary search to find out precisely what change caused this
failure, so no need for other people to do it.

I'll send more info ASAP (pending bootstrap/cpu time).

Arno
Richard Guenther - Sept. 1, 2011, 8:01 a.m.
On Thu, Sep 1, 2011 at 9:06 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Wed, Aug 31, 2011 at 6:34 PM, Arnaud Charlet <charlet@adacore.com> wrote:
>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
>>> 0x001c4fa0 in lib__writ__write_ali ()
>>> (gdb) bt
>>> #0  0x001c4fa0 in lib__writ__write_ali ()
>>> #1  0x0036799a in _ada_gnat1drv ()
>>> #2  0x000305f5 in gnat_parse_file ()
>>
>> I just triple checked, and revision 178381 is OK for me on
>> x86_64-unknown-linux-gnu.
>>
>> Unfortunately without debug info, the above traceback isn't
>> giving much info.
>>
>> Just a shot in the dark, can you try to pinpoint at which revision
>> things started to break? That'd be useful.
>>
>> In particular I'd be curious to know if revision 178376 has the failure or not.
>>
>> Same for revision 178311
>
> My bootstrap compiler is GCC 4.3.4, the error occurs in stage3 (well, when
> building the RTS).  It will take some time to check the revs you quoted.

glibc 2.11.1, on SLE11 SP1, binutils from what will be SP2, 2.21.1.

r178311, no-go:

error: "exp_light.ali" not found, "exp_light.adb" must be compiled
make[3]: *** [ada/b_gnat1.adb] Error 5
make[3]: *** Waiting for unfinished jobs....

r178376, broken.

r178316, which maybe fixed the r178311 issue: ok.
Richard.

> Richard.
>
Arnaud Charlet - Sept. 1, 2011, 9:34 a.m.
After doing a binary search, the first revision which breaks bootstrap on
my environment with Ada enabled is the following:

r178353 | vries | 2011-08-31 09:04:25 +0200 (Wed, 31 Aug 2011) | 8 lines

2011-08-31  Tom de Vries  <tom@codesourcery.com>

        PR middle-end/43513
        * Makefile.in (tree-ssa-ccp.o): Add $(PARAMS_H) to rule.
        * tree-ssa-ccp.c (params.h): Include.
        (fold_builtin_alloca_for_var): New function.
        (ccp_fold_stmt): Use fold_builtin_alloca_for_var.

Which makes sense, since Ada uses alloca a lot, much more than other languages.

In other words, none of the changes in the Ada repository is reponsible for
this regression.

So Tom and/or Richard, could you please have a look at this regression? TIA.

Arno

Patch

Index: sem_ch12.adb
===================================================================
--- sem_ch12.adb	(revision 178372)
+++ sem_ch12.adb	(working copy)
@@ -12737,6 +12737,23 @@ 
                end if;
             end;
          end if;
+
+         --  If a node has aspects, references within their expressions must
+         --  be saved separately, given that they are not directly in the
+         --  tree.
+
+         if Has_Aspects (N) then
+            declare
+               Aspect : Node_Id;
+
+            begin
+               Aspect := First (Aspect_Specifications (N));
+               while Present (Aspect) loop
+                  Save_Global_References (Expression (Aspect));
+                  Next (Aspect);
+               end loop;
+            end;
+         end if;
       end Save_References;
 
    --  Start of processing for Save_Global_References