| Message ID | 20110831094306.GA25125@adacore.com |
|---|---|
| State | New |
| Headers | show |
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. > >
> 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
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.
> >> +===========================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
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).
> (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
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
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
> 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
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
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
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
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.
> 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
> 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
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. >
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
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
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.