When I tried a C + Ada only bootstrap of current mainline on alpha-dec-osf5.1b, most of the bootstrap and building libada went along fine. The bootstrap stopped only when trying to build gnatchop (or any other of gnattools): make -C tools -f ../Makefile "CC=../../xgcc -B../../" "CFLAGS=-O2 -g -O2 -mieee" "LDFLAGS=" "ADAFLAGS=-gnatpg -gnata" "INCLUDES=-I. -I.. -I../.. -I/vol/gnu/src/gcc/gcc-dist/gcc/ada -I/vol/gnu/src/gcc/gcc-dist/gcc/ada/../config -I/vol/gnu/src/gcc/gcc-dist/gcc/ada/../../include -I/vol/gnu/src/gcc/gcc-dist/gcc/ada/.." "ADA_INCLUDES=-I../rts -I. -I/vol/gnu/src/gcc/gcc-dist/gcc/ada" "libsubdir=/vol/gcc/lib/gcc/alpha-dec-osf5.1b/4.0.0" "exeext=" "fsrcdir=/vol/gnu/src/gcc/gcc-dist/gcc/ada" "srcdir=/vol/gnu/src/gcc/gcc-dist/gcc/ada" "TOOLS_LIBS=../rts/libgnat.a ../../prefix.o ../../version.o link.o ../../../libiberty/libiberty.a -lexc " "GNATMAKE=../../gnatmake" "GNATLINK=../../gnatlink" "GNATBIND=../../gnatbind" \ TOOLSCASE=native \ ../../gnatchop ../../gnat ../../gnatkr \ ../../gnatls ../../gnatprep \ ../../gnatxref \ ../../gnatfind ../../gnatname \ ../../gnatclean ../../gprmake \ ../../gprcmd ../../gpr2make make[4]: Entering directory `/amnt/figaro/volumes/obj-gcc/gcc/obj.alpha/gcc-4.0.0-20041110/10-gcc-ada/gcc/ada/tools' ../../gnatmake -c -I../rts -I. -I/vol/gnu/src/gcc/gcc-dist/gcc/ada gnatchop --GCC="../../xgcc -B../../ -O2 -g -O2 -mieee -gnatpg -gnata" gnatmake: "gnatchop" not found make[4]: *** [../../gnatchop] Error 4 Running the newly built gnatmake under truss reveals that it looks for gnatchop in $srcdir, not gnatchop.adb (as expected and happens e.g. on Solaris 10). So this might be a code generation bug on alpha. Environment: System: OSF1 bartok V5.1 2650 alpha Machine: alpha host: alpha-dec-osf5.1b build: alpha-dec-osf5.1b target: alpha-dec-osf5.1b configured with: /vol/gnu/src/gcc/gcc-dist/configure --host alpha-dec-osf5.1b --build alpha-dec-osf5.1b --target alpha-dec-osf5.1b --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls --enable-languages=c,ada How-To-Repeat: Try bootstrapping on alpha-dec-osf5.1b as above.
I thought we declared that Ada building on alpha-dec-osf was broken and should have been turned off. This was because when Geoff fixed a PCH bug, alpha-dec-osf could not bootstrap Ada anymore.
Subject: Re: Cannot build gnattools on Tru64 UNIX V5.1B pinskia at gcc dot gnu dot org writes: > I thought we declared that Ada building on alpha-dec-osf was broken and should have been turned off. > This was because when Geoff fixed a PCH bug, alpha-dec-osf could not bootstrap Ada anymore. But this error manifested itself as a comparison failure (cf. PR ada/13750), which didn't happen at all during this bootstrap: the compiler proper bootstrapped without problems and libgnat built fine; only the Ada tools cannot be built right now. So this is a regression from gcc 3.4. Rainer
It would be useful to isolate this bug to a simpler test case, in particular if this is indeed a codegen problem as it looks like. Arno
Does this work now or something else is wrong?
Tru64 is not a primary or secondary platform; removing target milestone.
This happens on Linux as well.
*** Bug 20089 has been marked as a duplicate of this bug. ***
Subject: Re: [4.0/4.1 Regression] Cannot build gnattools on Tru64 UNIX V5.1B I've done some further debugging and found what's going on: running the failing gnatmake invokation % ../../gnatmake -c -I../rts -I. -I/vol/gnu/src/gcc/gcc-dist/gcc/ada gnatchop --GCC="../../xgcc -B../../ -O2 -g -O2 -mieee -gnatpg -gnata" gnatmake: "gnatchop" not found under truss reveals that with gnatmake from the 3.4 branch, there are several calls to stat() for gnatchop.adb in different directories. With the 4.0 gnatmake, the stat() calls only look for gnatchop (which of course doesn't exist yet). Those calls ultimately come from Osint.Next_Main_File. Running gnatmake under a debugger, I find that in 4.0, neither the case Running_Program is entered nor the if Running_Program = Make then block that does the adding of .adb and .ads. It turns out that Osint.Running_Program = 4 at that point (debugging seems considerably broken on 4.0: with the 3.4 binaries and current CVS gdb, I get symbolic values here, while the 4.0 binaries only give numeric ones), i.e. Unspecified. Running gnatmake again under gdb with a watchpoint on Osint.Running_Program, I find that * for the 3.4 binary, the variable is set only once via Osint.Set_Program (to Osint.Make, as expected) and never touched afterwards, whereas * for the 4.0 binary, the variable is set once in the same place, and later overwritten in osint___elabb (obviously the Osint initialization code), where it is set to 4 (Unspecified) as observed above. So maybe this is an Ada bug after all, not really target specific. Rainer
Given your last comment (a variable set to 4), it still looks very much like a codegen issue to me, and likely target dependent. I guess a next step could be to either look at the ssa transformations performed, and/or at the assembly code generated for the elab routine. Arno
Subject: Re: [4.0/4.1 Regression] Cannot build gnattools on Tru64 UNIX V5.1B charlet at gcc dot gnu dot org writes: > Given your last comment (a variable set to 4), it still looks very much like > a codegen issue to me, and likely target dependent. > > I guess a next step could be to either look at the ssa transformations performed, > and/or at the assembly code generated for the elab routine. I've approached this a bit differently: * I tried to bootstrap mainline with -O0, but it failed as before and even an almost current CVS gdb just SEGVs on the gnatmake binary ;-( * On the 4.0 branch, a bootstrap with -O0 also failed as before, but at least I can debug the gnatmake binary: osint__running_programs starts as 0, is later initialized to 2 (osint__make) in osint__set_program and again overwritten to 4 (osint__unspecified) in osint___elabb: Breakpoint 4, osint.set_program (p=16) at /vol/gnu/src/gcc/gcc-4.0-branch-dist/gcc/ada/osint.adb:2274 (gdb) p osint__running_program $6 = 0 (gdb) where #0 osint.set_program (p=16) at /vol/gnu/src/gcc/gcc-4.0-branch-dist/gcc/ada/osint.adb:2274 #1 0x00000001201fbf10 in <osint__m___elabb> () at /vol/gnu/src/gcc/gcc-4.0-branch-dist/gcc/ada/osint-m.adb:49 #2 0x00000001200b7750 in adainit () at b_gnatm.c:562 #3 0x00000001200b8aec in main (argc=536854608, argv=0x0, envp=0x0) at b_gnatm.c:733 #4 0x00000001200b617c in __start () (gdb) cont Continuing. Watchpoint 6: {<data variable, no debug info>} 5369590752 Old value = 0 New value = 2 osint.set_program (p=16) at /vol/gnu/src/gcc/gcc-4.0-branch-dist/gcc/ada/osint.adb:2280 (gdb) cont Continuing. Breakpoint 3, <osint___elabb> () at /vol/gnu/src/gcc/gcc-4.0-branch-dist/gcc/ada/osint.adb:45 (gdb) cont Continuing. Watchpoint 6: {<data variable, no debug info>} 5369590752 Old value = 2 New value = 4 <osint___elabb> () at /vol/gnu/src/gcc/gcc-4.0-branch-dist/gcc/ada/osint.adb:48 (gdb) where #0 <osint___elabb> () at /vol/gnu/src/gcc/gcc-4.0-branch-dist/gcc/ada/osint.adb:48 #1 0x00000001200b7cc0 in adainit () at b_gnatm.c:610 #2 0x00000001200b8aec in main (argc=536854608, argv=0x0, envp=0x0) at b_gnatm.c:733 #3 0x00000001200b617c in __start () * On the 3.4 branch, osint__running_program is statically initialized to osint__unspecified in osint.adb, later reset to osint__make in osint__set_program: Old value = {F = osint__unspecified} New value = {F = osint__make} osint__set_program (p=osint__make) at /vol/gnu/src/gcc/gcc-3.4-branch-dist/gcc/ada/osint.adb:2253 Breakpoint 3, osint.set_program (p=osint__make) at /vol/gnu/src/gcc/gcc-3.4-branch-dist/gcc/ada/osint.adb:2247 (gdb) where #0 osint.set_program (p=osint__make) at /vol/gnu/src/gcc/gcc-3.4-branch-dist/gcc/ada/osint.adb:2247 #1 0x000000012019efe8 in <osint__m___elabb> () at /vol/gnu/src/gcc/gcc-3.4-branch-dist/gcc/ada/osint-m.adb:49 #2 0x00000001200a046c in adainit () at b_gnatm.c:267 #3 0x00000001200a11c0 in main (argc=6, argv=0x11fffc018, envp=0x11fffc050) at b_gnatm.c:389 #4 0x000000012009fc3c in __start () $1 = {F = osint__unspecified} (gdb) cont Continuing. Watchpoint 5: osint.running_program Old value = {F = osint__unspecified} New value = {F = osint__make} osint.set_program (p=osint__make) at /vol/gnu/src/gcc/gcc-3.4-branch-dist/gcc/ada/osint.adb:2253 Thus, the way/order of initialization changed between 3.4 and 4.0, causing the observed failure: * from osint.adb: package body Osint is Running_Program : Program_Type := Unspecified; -- comment required here ??? * from osint-m.adb: package body Osint.M is [...] begin Set_Program (Make); end Osint.M; * in 3.4: osint__running_program = osint__unspecified (4) statically (osint.o) osint__running_program = osint__make (2) in osint.set_program, called from osint__m___elabb (osint_m.o) * in 4.0: osint__running_program = 0 statically (osint.o) osint__running_program = osint__make (2) in osint.set_program, called from osint__m___elabb (osint_m.o) osint__running_program = osint__unspecified (4) in osint___elabb (osint.o) Hope this helps to narrow down the root cause. Rainer
Ada is not a primary language and alpha is not a primary or secondary platform; removing target milestone.
Workaround patch here: http://gcc.gnu.org/ml/gcc/2005-09/msg00930.html Rest of discussion here: http://gcc.gnu.org/ml/gcc/2005-10/msg00016.html Seems to be a gnatbind bug present on 4.0 and 4.1.
(In reply to comment #12) > Workaround patch here: > http://gcc.gnu.org/ml/gcc/2005-09/msg00930.html > > Rest of discussion here: > http://gcc.gnu.org/ml/gcc/2005-10/msg00016.html > > Seems to be a gnatbind bug present on 4.0 and 4.1. Just confirmed that the suggested workaround works on tru64 5.1B with gcc-4.0.2
(In reply to comment #13) > (In reply to comment #12) > > Workaround patch here: > > http://gcc.gnu.org/ml/gcc/2005-09/msg00930.html > > > > Rest of discussion here: > > http://gcc.gnu.org/ml/gcc/2005-10/msg00016.html > > > > Seems to be a gnatbind bug present on 4.0 and 4.1. > > Just confirmed that the suggested workaround works on tru64 5.1B with gcc-4.0.2 > Works on Tru64 UNIX 4.0D and 5.1 with gcc-4.0.2 as well.
workaround works with 4.0.3 on alpha-linux as well, 4.1 build currently fails in stage3 Matthias
Arnaud has a patch for this issue on trunk and a better workaround patch for 4.0. Could you post your stage3 failure?
(In reply to comment #16) > Arnaud has a patch for this issue on trunk and a better workaround patch for > 4.0. > > Could you post your stage3 failure? actually, it's a stage2 failure, files as PR24821 Matthias
Subject: Bug 18434 Author: charlet Date: Mon Nov 14 13:05:58 2005 New Revision: 106886 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106886 Log: 2005-11-14 Robert Dewar <dewar@adacore.com> PR ada/18434 * osint-m.adb: Add pragma Elaborate_All for Osint Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/osint-m.adb
Subject: Bug 18434 Author: guerby Date: Mon Nov 14 21:34:34 2005 New Revision: 106906 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106906 Log: 2005-11-14 Robert Dewar <dewar@adacore.com> PR ada/18434 * osint-m.adb: Add pragma Elaborate_All for Osint Modified: branches/gcc-4_0-branch/gcc/ada/ChangeLog branches/gcc-4_0-branch/gcc/ada/osint-m.adb
Could people check if the problem was indeed fixed where reported?
(In reply to comment #20) > Could people check if the problem was indeed fixed where reported? bootstrap ok on alpha-linux Matthias
Subject: Bug 18434 Author: charlet Date: Tue Nov 15 13:51:09 2005 New Revision: 106950 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106950 Log: 2005-11-14 Robert Dewar <dewar@adacore.com> Ed Schonberg <schonberg@adacore.com> PR ada/18434 * types.ads: Include All_Checks in Suppress_Array * checks.adb (Check_Needed): Remove kludge for a/=b rewritten as not(a=b), since we no longer do this rewriting, and hence it is not needed. (Elaboration_Checks_Suppressed): Add special casing to deal with different cases of static and dynamic elaboration checks (all checks does not count in the first case, but does in the second). (Expr_Known_Valid): Do not assume that the result of any arbitrary function call is valid, since this is not the case. (Ensure_Valid): Do not apply validity check to a real literal in a universal or fixed context * exp_ch4.adb (Expand_N_Op_Ne): Don't expand a/=b to not(a=b) for elementary types using the operator in standard. It is cleaner not to modify the programmers intent, especially in the case of floating-point. (Rewrite_Comparison): Fix handling of /= (this was always wrong, but it did not matter because we always rewrote a/=b to not(a=b). (Expand_Allocator_Expression): For an allocator expression whose nominal subtype is an unconstrained packed type, convert the expression to its actual constrained subtype. Implement warning for <= or >= where < or > not possible Fix to Vax_Float tests (too early in many routines, causing premature Vax_Float expansions. * sem_prag.adb (Analyze_Pragma, case Obsolescent): Allow this pragma to be used with packages and generic packages as well as with subprograms. (Suppress): Set All_Checks, but not Elaboration_Check, for case of pragma Suppress (All_Checks) (Analyze_Pragma, case Warnings): Implement first argument allowed to be a string literal for precise control over warnings. Avoid raise of pragma in case of unrecognized pragma and just return instead. * sem_prag.ads: Minor reformatting * switch-c.adb (Scan_Front_End_Switches): Replace "raise Bad_Switch;" with call to new procedure Bad_Switch. Call Scan_Pos with new parameter Switch. Do not handle any exception. Include -gnatwx as part of -gnatg (warn on redundant parens) Allow optional = after -gnatm (Scan_Front_End_Switches): The -gnatp switch sets All_Checks, but no longer sets Elaboration_Checks. Code to set warning mode moved to Sem_Warn so that it can be shared by pragma processing. * s-mastop-tru64.adb (Pop_Frame): Remove redundant parentheses in if statement. * s-taprop-solaris.adb: Change some <= to =, to avoid new warning * a-exexda.adb, prj-proc.adb: Fix obvious typo (Num_Tracebacks compared <= 0 instead of < 0) Fix obvious typo (Total_Errors_Detected <= 0 should be = 0) Modified: trunk/gcc/ada/a-exexda.adb trunk/gcc/ada/checks.adb trunk/gcc/ada/exp_ch4.adb trunk/gcc/ada/prj-proc.adb trunk/gcc/ada/s-mastop-tru64.adb trunk/gcc/ada/s-taprop-solaris.adb trunk/gcc/ada/sem_prag.adb trunk/gcc/ada/sem_prag.ads trunk/gcc/ada/switch-c.adb trunk/gcc/ada/types.ads
Fixed. Arno
(In reply to comment #20) > Could people check if the problem was indeed fixed where reported? I did try the new suggested fix on tru64 5.1B on an Alpha. It gets past the previous error pointb ut it fails later on while linking Somehow an extra "-L" is generated that disables the default library search paths. configured with ../gcc-4.0.2/configure alpha-dec-osf5.1 --enable-languages=c,ada exactly the same config bootstrapped OK with the preliminary fix below is an excerpt of the output from make bootstrap make[4]: Entering directory `/usr/users/olle/xyz/objdir/gcc/ada/tools' rm -f tools/* rm -rf tools mkdir -p tools (cd tools; ln -s ../sdefault.adb .) rm -f tools/mlib-tgt.adb; ln -s /usr/users/olle/xyz/gcc-4.0.2/gcc/ada/mlib-tgt-tru64.adb tools/mlib-tgt.adb; touch ../stamp-tools ../../gnatmake -c -I../rts -I. -I/usr/users/olle/xyz/gcc-4.0.2/gcc/ada gnatchop --GCC="../../xgcc -B../../ -O2 -g -O2 -mieee -gnatpg -gnata" ../../xgcc -c -I./ -I../rts -I. -I/usr/users/olle/xyz/gcc-4.0.2/gcc/ada -B../../ -O2 -g -O2 -mieee -gnatpg -gnata -I- /usr/users/olle/xyz/gcc-4.0.2/gcc/ada/gnatchop.adb ../../gnatbind -I../rts -I. -I/usr/users/olle/xyz/gcc-4.0.2/gcc/ada -static -x gnatchop ../../gnatlink -v gnatchop -o ../../gnatchop --GCC="../../xgcc -B../../ -static-libgcc -I../rts -I. -I/usr/users/olle/xyz/gcc-4.0.2/gcc/ada" ../rts/libgnat.a ../../prefix.o ../../version.o link.o ../../../libiberty/libiberty.a -lexc GNATLINK 4.0.2 Copyright 1995-2005 Free Software Foundation, Inc xgcc -c -gnatA -gnatWb -gnatiw -B../../ -static-libgcc -I../rts -I. -I/usr/users/olle/xyz/gcc-4.0.2/gcc/ada -gnatws b~gnatchop.adb ../../xgcc b~gnatchop.o ../../prefix.o ../../version.o link.o ../rts/ada.o ../rts/a-charac.o ../rts/a-chlat1.o ../rts/gnat.o ../rts/g-string.o interfac.o system.o ../rts/s-addope.o s-casuti.o ../rts/g-casuti.o s-htable.o ../rts/s-parame.o ../rts/s-crtl.o ../rts/i-cstrea.o s-purexc.o ../rts/s-restri.o s-stoele.o ../rts/s-carun8.o ../rts/s-imgint.o ../rts/a-comlin.o ../rts/s-stache.o ../rts/s-strops.o ../rts/s-sopco3.o ../rts/s-sopco4.o ../rts/s-sopco5.o ../rts/s-traent.o ../rts/a-elchha.o ../rts/s-except.o ../rts/s-traceb.o ../rts/s-soflin.o s-secsta.o s-exctab.o ../rts/a-ioexce.o ../rts/a-string.o ../rts/a-tags.o ../rts/a-stream.o ../rts/g-os_lib.o ../rts/s-assert.o ../rts/s-finroo.o ../rts/s-memory.o ../rts/s-mastop.o s-stalib.o ../rts/s-unstyp.o a-except.o ../rts/s-bitops.o ../rts/a-strmap.o ../rts/a-stmaco.o ../rts/a-chahan.o ../rts/a-strsea.o ../rts/a-strfix.o ../rts/s-stratt.o ../rts/s-finimp.o ../rts/a-finali.o ../rts/a-filico.o ../rts/g-dirope.o ../rts/g-regexp.o ../rts/g-comlin.o ../rts/s-ficobl.o ../rts/s-fileio.o ../rts/a-textio.o ../rts/s-valuti.o ../rts/s-valuns.o ../rts/s-valint.o gnatvsn.o hostparm.o gnatchop.o -o ../../gnatchop ../rts/libgnat.a ../../../libiberty/libiberty.a -lexc -L -L../rts/ -L./ -L/usr/users/olle/xyz/gcc-4.0.2/gcc/ada/ -L/usr/local/lib/gcc/alpha-dec-osf5.1/4.0.2/adalib/ ../rts/libgnat.a -lexc -B../../ -static-libgcc -I../rts -I. -I/usr/users/olle/xyz/gcc-4.0.2/gcc/ada /bin/ld: Can't locate file for: -lc collect2: ld returned 1 exit status gnatlink: cannot call ../../xgcc make[4]: *** [../../gnatchop] Error 4 make[4]: Leaving directory `/usr/users/olle/xyz/objdir/gcc/ada/tools' make[3]: *** [gnattools2] Error 2 make[3]: Leaving directory `/usr/users/olle/xyz/objdir/gcc/ada' make[2]: *** [gnattools-native] Error 2 make[2]: Leaving directory `/usr/users/olle/xyz/objdir/alpha-dec-osf5.1/libada' make[1]: *** [all-target-libada] Error 2 make[1]: Leaving directory `/usr/users/olle/xyz/objdir' make: *** [bootstrap] Error 2
(In reply to comment #24) Seems that the basic difference between the working case (the preliminary work around) and the final fix is that in the working case there are two occasions of "-L./" in the linking command in the nonworking case there are one "-L" and one "-L./"