[Bug middle-end/20933] [4.1 Regression] gcc can no longer bootstrap itself
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 06:00 --- Most likely libiberty (the pex* functions) is being miscompiled. -- What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20933
[Bug tree-optimization/20926] [4.1 Regressopm] ICE: tree check, in recent builds
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 06:03 --- I almost want to say this was caused by: 2005-04-05 Andrew MacLeod [EMAIL PROTECTED] * lambda-code.c (lambda_loopnest_to_gcc_loopnest): Use update_stmt. Use immediate use iterator. Somehow an virtual OP is being added which means someone forgot an update_stmt somewhere. -- What|Removed |Added CC||amacleod at redhat dot com Summary|ICE: tree check, in recent |[4.1 Regressopm] ICE: tree |builds |check, in recent builds Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20926
[Bug libfortran/19014] [4.0 only] print *,maxloc(array) segfaults
-- What|Removed |Added Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19014
[Bug libfortran/19106] [4.0 only] segfault in executable for print *,sum(a,dim=2,mask=a0)
-- What|Removed |Added Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19106
[Bug tree-optimization/19347] Invariant load not moved out of loop
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Last reconfirmed|2005-01-09 15:55:15 |2005-04-11 06:09:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19347
[Bug fortran/20833] LEN of a null slice and temporaries don't mix up well
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 06:30 --- Confirmed, looks like someone is forgetting to call fold somewhere: int4 C.465 = 1 - 1; int4 C.464 = 2; -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-04-11 06:30:36 date|| Version|unknown |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20833
[Bug c/20940] New: Option -ggdb3 stopped working
The option -ggdb3 has stopped working recently. The following example does not
compile any more
[/Users/fca] cat junk.c
#include stdio.h
main () {
float a=0;
printf(%f\n,a);
}
[/Users/fca] /opt/gcc-4_0/bin/gcc -ggdb3 junk.c -o junk.o
junk.c:5: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
Summary: Option -ggdb3 stopped working
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: federico dot carminati at cern dot ch
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: powerpc-apple-darwin7.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20940
[Bug debug/20940] Option -ggdb3 stopped working
-- What|Removed |Added Component|c |debug Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20940
[Bug debug/20940] [4.1 Regression] Option -ggdb3 stopped working
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 06:34 --- Confirmed, this just started to happen in the last three days too. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-11 06:34:09 date|| Summary|Option -ggdb3 stopped |[4.1 Regression] Option - |working |ggdb3 stopped working Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20940
[Bug debug/20940] [4.1 Regression] Option -ggdb3 stopped working
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 06:38 --- This was caused by: 2005-04-09 Caroline Tice [EMAIL PROTECTED] * dwarf2out.c (COLD_TEXT_SECTION_LABEL): New macro. .. (output_line_info): Get cold section label from function struct. .. -- What|Removed |Added CC||ctice at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20940
[Bug tree-optimization/20913] copy-prop does not fold conditionals
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 06:40 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-11 06:40:52 date|| Version|unknown |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20913
[Bug c++/19317] [4.1 Regression] removing a temporary return value when we cannot
--- Additional Comments From jason at redhat dot com 2005-04-11 07:49 --- Subject: Re: [4.1 Regression] removing a temporary return value when we cannot Have you tested the 4.0 branch with the temporary fix I applied? Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19317
[Bug target/20799] [4.0/4.1 Regression] bad relocs for new/delete overrides
--- Additional Comments From federico dot carminati at cern dot ch 2005-04-11 07:49 --- This fix has not yet been merged to the head. Any news? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20799
[Bug fortran/20777] [4.0 only] Arithmetic IF not flagged obsolete
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-11 07:51 --- Patch from: http://gcc.gnu.org/ml/fortran/2005-04/msg00283.html applied to mainline. Waiting for 4.0 to reopen. -- What|Removed |Added Last reconfirmed|2005-04-05 23:34:37 |2005-04-11 07:51:40 date|| Summary|Arithmetic if not flagged |[4.0 only] Arithmetic IF not |obsolete|flagged obsolete http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20777
[Bug middle-end/20937] BLK ptr's losing original ptr's static-constant readonly attribute.
-- What|Removed |Added Summary|BLK ptr's loosing original |BLK ptr's losing original |ptr's static-constant |ptr's static-constant |readonly attribute. |readonly attribute. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20937
[Bug libfortran/17992] [4.0 only] reading empty line does not return 0
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-11 08:01 --- Can you try with a later build and tell us what your exact source and output is? $ cat psfres.dat $ cat pr17992.f integer n,m open(unit=8,file='psfres.dat',status='unknown') read(8,'(/2i2)')n,m write(*,*)n,m end $ gfortran -v Using built-in specs. Target: i386-linux Configured with: ../gcc/configure --prefix=/tmp/gfortran-20050411/irun --enable-languages=c,f95 --host=i386-linux Thread model: posix gcc version 4.1.0 20050411 (experimental) $ gfortran pr17992.f ./a.out 0 0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17992
[Bug java/20941] New: Incorrect case for META-INF with fastjar
This case came to light making service provider property files for GNU JAXP: org.xml.sax.driver etc. These should be created in the META-INF/services path of the JAR. Reproduce this error by creating a META-INF/services directory at the root of your compiled class hierarchy and adding one or more property files (attached) and call fastjar without the M argument. Compiled classes in /build with the service provider at: /build/META-INF/services/org.xml.sax.driver cd /build jar cvf /lib/gnu-jaxp.jar . GNU fastjar takes the file system directory name META-INF and correctly creates the service provider directory in the JAR, but it also creates a default manifest file at meta-inf/Manifest.mf. When I run my JAXP application with gij, it seems to read meta-inf by default, ignore the META-INF path and cannot resolve a SAX driver to instantiate. If I suppress the default manifest with the fastjar M argument, no lowercase meta-inf path is created, the uppercase META-INF path is processed and the SAX driver is loaded. jar cvfM /lib/gnu-jaxp.jar . The Sun JAR specification [1] does not say META-INF must be uppercase, but all the examples are in upper case and broader reading suggests that uppercase path is expected. The attached test case confirms the Sun JVM expects an uppercase META-INF, so it seems gij is not at fault. gij --classpath .:$CLASSPATH:/lib/gnu-jaxp.jar XMLReaderTest java -classpath g:\lib\gnu-jaxp.jar XMLReaderTest XMLReader created with hard-coded value. [1] http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html -- Summary: Incorrect case for META-INF with fastjar Product: gcc Version: 3.4.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: phil at mkdoc dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20941
[Bug java/20941] Incorrect case for META-INF with fastjar
--- Additional Comments From phil at mkdoc dot com 2005-04-11 08:11 --- Created an attachment (id=8583) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8583action=view) SAX driver service provider file Driver class: gnu.xml.aelfred2.SAXDriver -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20941
[Bug bootstrap/20942] New: jc1 segfault causes mainline bootstrap failure
Have not seen this reported yet... Bootstrap of mainline 4.1 compiler failed at ia32/IPF/x86_64 Linux due to jc1 segmentation fault in 'in_unlikely_text_section'. /bootstrap/bld/./gcc/gcj -B/bootstrap/bld/./gcc/ -B/bootstrap/usr/i586-suse- linux/bin/ -B/bootstrap/usr/i586-suse-linux/lib/ -isystem /bootstrap/usr/i586- suse-linux/include -isystem /bootstrap/usr/i586-suse-linux/sys-include - findirect-dispatch -B../.. -ffloat-store -fno-omit-frame-pointer -fclasspath= - fbootclasspath=/bootstrap/bld/i586-suse- linux/libjava:../../../../../src/libjava/external/sax:../../../../../src/libjava :../.. --encoding=UTF-8 -Wno-deprecated -g -O2 -MT libsax_gcj_la-sax.lo -MD - MP -MF .deps/libsax_gcj_la-sax.Tpo -c sax.jar -fPIC -o .libs/libsax_gcj_la-sax.o org/xml/sax/helpers/XMLReaderFactory.java: In class 'org.xml.sax.helpers.XMLReaderFactory': org/xml/sax/helpers/XMLReaderFactory.java: In method 'org.xml.sax.helpers.XMLReaderFactory.createXMLReader()': org/xml/sax/helpers/XMLReaderFactory.java:111: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[5]: *** [libsax_gcj_la-sax.lo] Error 1 make[5]: Leaving directory `/bootstrap/bld/i586-suse-linux/libjava/external/sax' .. Program received signal SIGSEGV, Segmentation fault. in_unlikely_text_section () at varasm.c:309 309 ret_val = ((in_section == in_unlikely_executed_text) (gdb) bt #0 in_unlikely_text_section () at varasm.c:309 #1 0xbfffd69c in ?? () #2 0x08384f4a in named_section_real (name=0x0, flags=131104, decl=0x1) at varasm.c:444 #3 0x0020 in ?? () #4 0x0808498d in build_utf8_ref (name=0x1) at class.c:906 #5 0x080a61cc in prepare_eh_table_type (type=0x4017ac3c) at except.c:362 #6 0x080a683c in expand_end_java_handler (range=0x8610f88) at except.c:447 #7 0x in ?? () #8 0x08096c74 in poplevel (keep=1, reverse=0, functionbody=0) at decl.c:1546 #9 0x080973b1 in maybe_poplevels (pc=12) at decl.c:1766 #10 0x0860fdf4 in ?? () #11 0x0860fdf4 in ?? () #12 0x080a11fc in expand_byte_code (jcf=0x40018bc0, method=0x403740d8) at expr.c:3021 #13 0x080b2a06 in parse_class_file () at jcf-parse.c:933 #14 0x080b61cc in java_parse_file (set_yydebug=0) at jcf-parse.c:1432 #15 0x08370395 in toplev_main (argc=32, argv=0xbfffd8f4) at toplev.c:1000 #16 0x40062b10 in __libc_start_main () from /lib/tls/libc.so.6 #17 0x08049ed1 in _start () at start.S:119 -- Summary: jc1 segfault causes mainline bootstrap failure Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: grigory dot zagorodnev at intel dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20942
[Bug java/20941] Incorrect case for META-INF with fastjar
--- Additional Comments From phil at mkdoc dot com 2005-04-11 08:56 --- Created an attachment (id=8584) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8584action=view) Test case for org.xml.sax.driver service provider property First checks any service provider configuration using XMLReaderFactory.createXMLReader(), then with a system property or a hard coded value to confirm the class can be loaded one way or another. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20941
[Bug c++/19317] [4.1 Regression] removing a temporary return value when we cannot
--- Additional Comments From pluto at pld-linux dot org 2005-04-11 08:59 --- (In reply to comment #26) Subject: Re: [4.1 Regression] removing a temporary return value when we cannot Have you tested the 4.0 branch with the temporary fix I applied? Jason I applied a temporary fix and Dirk's hack to get konqueror working but misscompilation still exists. I see it on artsd crash and buggy openoffice behaviour (STLport is misscompiled now). Several gcc-snaps ago artsd/stl/openoffice worked fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19317
[Bug java/20941] Incorrect case for META-INF with fastjar
--- Additional Comments From phil at mkdoc dot com 2005-04-11 09:13 --- Created an attachment (id=8585) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8585action=view) GNU JAXP pure Java source, no natives GNU JAXP source classes, compile using the attached script. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20941
[Bug java/20941] Incorrect case for META-INF with fastjar
--- Additional Comments From phil at mkdoc dot com 2005-04-11 09:18 --- Created an attachment (id=8586) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8586action=view) GCJ compile script for GNU JAXP Compiles GNU JAXP source to classes. Requires environment variables $mk_home, a path in which the source is at $mk_home/lib-src/jaxp, and $mk_build, which is a temporary build directory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20941
[Bug java/20941] Incorrect case for META-INF with fastjar
--- Additional Comments From phil at mkdoc dot com 2005-04-11 09:21 --- Created an attachment (id=8587) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8587action=view) Fastjar archive script for GNU JAXP Creates a JAR of the compiled GNU JAXP classes. Requires environment variables $mk_home, a path in which the source is at $mk_home/lib-src/jaxp, and $mk_build, which is a temporary build directory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20941
[Bug java/20941] Incorrect case for META-INF with fastjar
--- Additional Comments From phil at mkdoc dot com 2005-04-11 09:23 --- Created an attachment (id=8588) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8588action=view) Check you have the necessary environment variables Checks the $mk_home and $mk_build environment variables are set. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20941
[Bug fortran/20943] New: Valid option produces warning
The following command line produces a warning even if it behaves correctly [/Users/fca] cat bug.F subroutine bug_bug end [/Users/fca] /opt/gcc-4_0/bin/gfortran -c bug.F ; nm bug.o T _bug_bug__ [/Users/fca] /opt/gcc-4_0/bin/gfortran -fno-second-underscore -c bug.F ; nm bug.o cc1: warning: command line option -fno-second-underscore is valid for F95 but not for C T _bug_bug_ -- Summary: Valid option produces warning Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: federico dot carminati at cern dot ch CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: powerpc-apple-darwin7.8.0 GCC target triplet: powerpc-apple-darwin7.8.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20943
[Bug java/20941] Incorrect case for META-INF with fastjar
--- Additional Comments From phil at mkdoc dot com 2005-04-11 09:47 --- Lots of attachments, but it's simple really: 1. Set two environment variables: $mk_home, a path in which the source is at $mk_home/lib-src/jaxp, and $mk_build, which is a temporary build directory 2. Put all the bash scripts in the same directory, say $mk_home/bin (chmod +x) 3. Extract the GNU JAXP source to $mk_home/lib-src/jaxp 4. Run $mk_home/bin/jar-jaxp.sh to compile and archive the classes: the JAR is created at $mk_home/lib/gnu-jaxp.jar 5. Compile XMLReaderTest.java with $mk_home/lib/gnu-jaxp.jar in the classpath. 6. Run XMLReaderTest with with $mk_home/lib/gnu-jaxp.jar in the classpath, default package, no arguments. The source JAR does not include the service provider directory. To test with the service provider: 7. Save the service provider file at $mk_home/lib-src/META-INF/services/org.xml. sax.driver 8. Re-run $mk_home/bin/jar-jaxp.sh 9. Re-run XMLReaderTest with with $mk_home/lib/gnu-jaxp.jar in the classpath. To test fastjar with the M argument, add it to $mk_home/jar-jaxp.sh and repeat 7 and 8 above. Correction to my original report: the Sun JVM is case insensitive to META-INF, gij is case sensitive. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20941
[Bug rtl-optimization/17428] internal compiler error: in spill_failure, at reload1.c:1880 (-fspeculative-prefetching)
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-04-11 09:47 --- Zdenek, the ICE with the testcase from comment #12 reappeared on mainline. Could you please have a look? -- What|Removed |Added Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17428
[Bug rtl-optimization/17428] internal compiler error: in spill_failure, at reload1.c:1880 (-fspeculative-prefetching)
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-04-11 10:32 --- The new failure (which is a segfault, btw) was caused by http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg01363.html -- What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17428
[Bug rtl-optimization/17428] internal compiler error: in spill_failure, at reload1.c:1880 (-fspeculative-prefetching)
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni dot cz 2005-04-11 10:41 --- Subject: Re: internal compiler error: in spill_failure, at reload1.c:1880 (-fspeculative-prefetching) Hello, the ICE with the testcase from comment #12 reappeared on mainline. Could you please have a look? it is because the patch you identified (http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg01363.html) reverted the patch that fixed the problem (http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/value-prof.c.diff?cvsroot=gccr1=1.16r2=1.17). Honza, could you please fix that? Zdenek -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17428
[Bug tree-optimization/20944] New: ICE: SSA corruption compiling ACE542 with gcc41
When I compile ACE 5.4.2 with the actual snapshot of gcc41 (gcc-4.1-20050410) I get an ICE: g++41 -O2 -c -o .shobj/Synch_Invocation.o Synch_Invocation.ii Conflict s_4 and s_78 across an abnormal edge from BB40-BB43 Synch_Invocation.cpp: In member function 'TAO::Invocation_Status TAO::Synch_Twoway_Invocation::remote_twoway(ACE_Time_Value*)': Synch_Invocation.cpp:49: internal compiler error: SSA corruption Please submit a full bug report, with preprocessed source if appropriate. g++41 -v: Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.1-20050410/configure --prefix=/usr/local/gcc41g --program-suffix=41g --with-arch=opteron --enable-languages=c,c++ --enable-checking Thread model: posix gcc version 4.1.0 20050410 (experimental) This ICE doesn't occur at -O1 or with snapshot gcc-4.1-20050403. Michael Cieslinski -- Summary: ICE: SSA corruption compiling ACE542 with gcc41 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: micis at gmx dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20944
[Bug fortran/18452] -fno-second-underscore induces warning for fortran that needs preprocessing
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-11 11:33 --- This one is certainly going to annoy lots of people (when 4.0 is released, I think we will get bug-reports by the ton). This should be easy to solve for someone who knows the interactions between GCC components. How can we ask some help? -- What|Removed |Added CC||federico dot carminati at ||cern dot ch Last reconfirmed|2005-02-11 14:21:27 |2005-04-11 11:33:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18452
[Bug tree-optimization/20944] ICE: SSA corruption compiling ACE542 with gcc41
--- Additional Comments From micis at gmx dot de 2005-04-11 11:37 --- Created an attachment (id=8589) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8589action=view) preprocessd source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20944
[Bug fortran/18452] -fno-second-underscore induces warning for fortran that needs preprocessing
--- Additional Comments From tobi at gcc dot gnu dot org 2005-04-11 12:05 --- It is annoying enough that the preprocessor is invoked via cc1. Is there a reason for this, besides that it is the example given in the specfiles? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18452
Re: Fix tree-optimization/20920
On Sun, Apr 10, 2005 at 09:53:00PM -0400, Andrew Pinski wrote: Could you try the patch in PR 20934 and see if it fixed the bootstrap problem on i686-linux? It does. What's the status of that patch? It almost looks obvious to me. Diego.
[Bug middle-end/20396] TRULY_NOOP_TRUNCATION ignored
--- Additional Comments From joern dot rennecke at st dot com 2005-04-11 12:36 --- Subject: Re: TRULY_NOOP_TRUNCATION ignored echristo at redhat dot com wrote: --- Additional Comments From echristo at redhat dot com 2005-04-10 19:02 --- I think I'm ok with this, but I'd like a bit more info. What changes to the backend do you forsee this needing? The one patch that you applied to the 4.1 sh branch was too big to just get that particular set of changes. [assuming you are talking about generating TRUNCATE in gen_lowpart_common] First. some source operands will have a TRUNCATE, and if your expander tries to make all operands fit, or thinks it knows all the codes that can occur in some position, it will have to be updated to cope with the TRUNCATE. This is unfortunately also true for destination operands. Also, when you use gen_lowpart for a non-TRULY_NOOP_TRUNCATION mode pair, in a splitter or a peephole, for a destination, or for an operand where due to the nature of the operation or the register class being used a SUBREG is desired, you will still get a TRUNCATE; you have to use simplyfy_gen_subreg to explicitly get a SUBREG. The splitter with the for_each_rtx application of shmedia_cleanup_truncate cleans up such stuff after reload. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20396
[Bug ada/20822] makeinfo cannot process gnat_ugn_unw.texi
--- Additional Comments From rolf dot ebert dot gcc at gmx dot de 2005-04-11 12:37 --- Created an attachment (id=8590) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8590action=view) patch to fix PR20822 in 4.0.0-RC1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20822
[Bug bootstrap/20942] jc1 segfault causes mainline bootstrap failure
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 12:44 --- *** This bug has been marked as a duplicate of 20934 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20942
[Bug middle-end/20934] [4.1 Regression] Segmentation fault in gnat1
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 12:44 --- *** Bug 20942 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||grigory dot zagorodnev at ||intel dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20934
[Bug fortran/20943] Valid option produces warning
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 12:47 --- *** This bug has been marked as a duplicate of 18452 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20943
[Bug fortran/18452] -fno-second-underscore induces warning for fortran that needs preprocessing
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 12:47 --- *** Bug 20943 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18452
[Bug fortran/18452] -fno-second-underscore induces warning for fortran that needs preprocessing
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 12:48 --- (In reply to comment #5) It is annoying enough that the preprocessor is invoked via cc1. Is there a reason for this, besides that it is the example given in the specfiles? Besides that is the only preprocessor any more, there is not a seperate one anymore, it is integrated into cc1 now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18452
[Bug rtl-optimization/20413] VOIDmode LABEL_REFs are generated
--- Additional Comments From giovannibajo at libero dot it 2005-04-11 12:48 --- I have a very naive question: if LABEL_REFS should always be generated with Pmode, can't we add an assert if gen_rtx_LABEL_REF is called with a different mode? Or better, remove the mode argument altogether? -- What|Removed |Added CC||giovannibajo at libero dot ||it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20413
[Bug c++/19317] [4.1 Regression] removing a temporary return value when we cannot
--- Additional Comments From jason at redhat dot com 2005-04-11 12:48 --- Subject: Re: [4.1 Regression] removing a temporary return value when we cannot On 11 Apr 2005 08:59:58 -, pluto at pld-linux dot org [EMAIL PROTECTED] wrote: Have you tested the 4.0 branch with the temporary fix I applied? I applied a temporary fix and Dirk's hack to get konqueror working but misscompilation still exists. My patch fixes all the reduced testcases in this PR. If KDE is still broken, I think that's a separate bug and needs testcases. Can you submit another PR? Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19317
[Bug tree-optimization/20944] ICE: SSA corruption compiling ACE542 with gcc41
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 12:50 --- I want to say this is a dup of bug 20920 which has a patch referenced, could you try with that patch applied? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20944
[Bug fortran/20777] [4.0 only] Arithmetic IF not flagged obsolete
-- What|Removed |Added Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20777
[Bug libgcj/20941] Incorrect case for META-INF with fastjar
-- What|Removed |Added Component|java|libgcj http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20941
[Bug tree-optimization/20944] ICE: SSA corruption compiling ACE542 with gcc41
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-04-11 13:01 --- *** This bug has been marked as a duplicate of 20920 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20944
[Bug tree-optimization/20920] [4.1 Regression] ICE with eh and VRP
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-04-11 13:01 --- *** Bug 20944 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||micis at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20920
[Bug rtl-optimization/20586] bootstrap comparision fails with -funroll-loops.
--- Additional Comments From pluto at pld-linux dot org 2005-04-11 13:08 --- Problem still exists in 4.0.0-20050409 snap. I've checked the i386.o and caller-save.o from stage2/3. They have the same size but diff. instructions in several places. --- stage2-i386.o.txt 2005-04-11 14:42:40.0 +0200 +++ stage3-i386.o.txt 2005-04-11 14:42:46.0 +0200 @@ -1,5 +1,5 @@ -stage2-i386.o: file format elf32-i386 +stage3-i386.o: file format elf32-i386 Disassembly of section .text: // split_di function @@ -4948,7 +4948,7 @@ 4461: 89 42 fcmov%eax,0xfffc(%edx) 4464: 8b 44 24 20 mov0x20(%esp),%eax 4468: 83 c0 01add$0x1,%eax -446b: 89 44 24 1c mov%eax,0x1c(%esp) +446b: 89 44 24 18 mov%eax,0x18(%esp) 446f: 8b 7c 24 24 mov0x24(%esp),%edi 4473: 83 ef 04sub$0x4,%edi 4476: 89 7c 24 24 mov%edi,0x24(%esp) @@ -4956,7 +4956,7 @@ 447d: 89 f5 mov%esi,%ebp 447f: 8b 54 24 28 mov0x28(%esp),%edx 4483: 83 ea 04sub$0x4,%edx -4486: 89 54 24 18 mov%edx,0x18(%esp) +4486: 89 54 24 1c mov%edx,0x1c(%esp) 448a: 8b 5a fcmov0xfffc(%edx),%ebx 448d: 66 83 3b 27 cmpw $0x27,(%ebx) 4491: 0f 84 fe 00 00 00 je 4595 split_di+0x25b @@ -4984,13 +4984,13 @@ 44e8: c7 04 24 0c 00 00 00movl $0xc,(%esp) 44ef: e8 fc ff ff ff call 44f0 split_di+0x1b6 44f4: 89 47 fcmov%eax,0xfffc(%edi) -44f7: 8b 54 24 1c mov0x1c(%esp),%edx +44f7: 8b 54 24 18 mov0x18(%esp),%edx 44fb: 83 c2 01add$0x1,%edx 44fe: 89 54 24 20 mov%edx,0x20(%esp) 4502: 83 ef 04sub$0x4,%edi 4505: 89 7c 24 24 mov%edi,0x24(%esp) 4509: 8d 6e fclea0xfffc(%esi),%ebp -450c: 8b 44 24 18 mov0x18(%esp),%eax +450c: 8b 44 24 1c mov0x1c(%esp),%eax 4510: 83 e8 04sub$0x4,%eax 4513: 89 44 24 28 mov%eax,0x28(%esp) 4517: 8b 44 24 44 mov0x44(%esp),%eax // split_ti function @@ -5144,7 +5144,7 @@ 474e: 89 42 fcmov%eax,0xfffc(%edx) 4751: 8b 44 24 20 mov0x20(%esp),%eax 4755: 83 c0 01add$0x1,%eax -4758: 89 44 24 1c mov%eax,0x1c(%esp) +4758: 89 44 24 18 mov%eax,0x18(%esp) 475c: 8d 7d fclea0xfffc(%ebp),%edi 475f: 89 fd mov%edi,%ebp 4761: 8b 74 24 24 mov0x24(%esp),%esi @@ -5152,7 +5152,7 @@ 4768: 89 74 24 24 mov%esi,0x24(%esp) 476c: 8b 54 24 28 mov0x28(%esp),%edx 4770: 83 ea 04sub$0x4,%edx -4773: 89 54 24 18 mov%edx,0x18(%esp) +4773: 89 54 24 1c mov%edx,0x1c(%esp) 4777: 8b 5a fcmov0xfffc(%edx),%ebx 477a: 66 83 3b 27 cmpw $0x27,(%ebx) 477e: 0f 84 e4 00 00 00 je 4868 split_ti+0x20d @@ -5172,13 +5172,13 @@ 47bb: c7 04 24 0d 00 00 00movl $0xd,(%esp) 47c2: e8 fc ff ff ff call 47c3 split_ti+0x168 47c7: 89 46 fcmov%eax,0xfffc(%esi) -47ca: 8b 54 24 1c mov0x1c(%esp),%edx +47ca: 8b 54 24 18 mov0x18(%esp),%edx 47ce: 83 c2 01add$0x1,%edx 47d1: 89 54 24 20 mov%edx,0x20(%esp) 47d5: 8d 6f fclea0xfffc(%edi),%ebp 47d8: 83 ee 04sub$0x4,%esi 47db: 89 74 24 24 mov%esi,0x24(%esp) -47df: 8b 44 24 18 mov0x18(%esp),%eax +47df: 8b 44 24 1c mov0x1c(%esp),%eax 47e3: 83 e8 04sub$0x4,%eax 47e6: 89 44 24 28 mov%eax,0x28(%esp) 47ea: 8b 44 24 44 mov0x44(%esp),%eax -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20586
[Bug rtl-optimization/20413] VOIDmode LABEL_REFs are generated
--- Additional Comments From joern dot rennecke at st dot com 2005-04-11 13:16 --- Subject: Re: VOIDmode LABEL_REFs are generated giovannibajo at libero dot it wrote: --- Additional Comments From giovannibajo at libero dot it 2005-04-11 12:48 --- I have a very naive question: if LABEL_REFS should always be generated with Pmode, can't we add an assert if gen_rtx_LABEL_REF is called with a different mode? Or better, remove the mode argument altogether? Well, striclty speaking, there are some special cases where LABEL_REF is generated in ptr_mode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20413
[Bug fortran/20945] New: about 2x perfomance regression in comparision with 3.4.2
fortran 4.0 shows perfomance regression (with -O2 option) in comparison with g77 from 3.4.2 on IA32 with attached test. This test is obtained from cpu2000/mgrid test. It consists of calling of two functions: PSINV and RESID. Instrumental control (gprof) shows that most part of time spends in RESID function. There is one strange thing for me. If I remove call of PSINV function test (compiled by g77) became more slowly then it was before (with this call). gfortran from gcc4.0 behave more predictable. It looks like g77 from gcc 3.4.2 does interprocedure optimization for better cache using which can't do gfortran from gcc4.0 You can reproduce my results with attached test. Timing results: With PSINV call g77 sample.f -O2 -static 0m0.693s 0m0.685s 0m0.008s 0m0.694s 0m0.685s 0m0.009s 0m0.690s 0m0.683s 0m0.007s With PSINV call gfortran sample.f -O2 -static 0m1.293s 0m1.279s 0m0.015s 0m1.320s 0m1.306s 0m0.014s 0m1.303s 0m1.294s 0m0.008s Without PSINV call: g77 sample1.f -O2 -static -o z342s time ./z342s 0m0.902s 0m0.893s 0m0.007s 0m0.930s 0m0.923s 0m0.008s 0m0.894s 0m0.889s 0m0.005s Without PSINV call gfortran sample1.f -O2 -static -o z40s time ./z40s 0m0.758s 0m0.752s 0m0.006s 0m0.762s 0m0.758s 0m0.004s 0m0.759s 0m0.757s 0m0.004s cat /proc/cpuinfo: processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Xeon(TM) CPU 2.40GHz stepping: 7 cpu MHz : 2400.858 cache size : 512 KB -- Summary: about 2x perfomance regression in comparision with 3.4.2 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: denis dot nagorny at intel dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i586-suse-linux GCC host triplet: i586-suse-linux GCC target triplet: i586-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20945
[Bug middle-end/20946] New: --enable-checking=yes,fold fails on the mainline
--enable-checking=yes,fold fails on the mainline because when we get a SSA_NAME, we checksum the whole use-def chain which is wrong. -- Summary: --enable-checking=yes,fold fails on the mainline Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, build Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20946
[Bug middle-end/20946] --enable-checking=yes,fold fails on the mainline
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 13:20 --- I am testing a fix right now, this is blocking my patch for PR 20931. -- What|Removed |Added OtherBugsDependingO||20931 nThis|| AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-11 13:20:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20946
[Bug fortran/20945] about 2x perfomance regression in comparision with 3.4.2
--- Additional Comments From denis dot nagorny at intel dot com 2005-04-11 13:20 --- Created an attachment (id=8591) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8591action=view) Test for results reproducing -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20945
[Bug rtl-optimization/20413] VOIDmode LABEL_REFs are generated
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-04-11 13:21 --- The patch has been posted here: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01157.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20413
[Bug fortran/20945] about 2x perfomance regression in comparision with 3.4.2
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 13:28 --- I know that gfortran has some issue with inlining. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20945
[Bug middle-end/20946] --enable-checking=yes,fold fails on the mainline
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 13:30 --- And TREE_LIST too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20946
[Bug middle-end/20946] --enable-checking=yes,fold fails on the mainline
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 14:05 --- (In reply to comment #2) And TREE_LIST too. Actually it related to how TREE_LIST is handle, I change the recusiveness of fold_checksum_tree for TREE_LIST is that we no longer use recusion but a loop instead. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20946
[Bug tree-optimization/20947] New: ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:394
When I compile GSL 1.5 with the actual snapshot of gcc41 (gcc-4.1-20050410) I get an ICE: gcc41 -O2 -fpeel-loops -ftree-vectorize -c permute.i -o permute.o permute_source.c: In function 'gsl_permute_complex_inverse': permute_source.c:87: internal compiler error: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:394 Please submit a full bug report, with preprocessed source if appropriate. gcc41 -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.1-20050410/configure --prefix=/usr/local/gcc41g -- program-suffix=41g --with-arch=opteron --enable-languages=c,c++ --enable- checking Thread model: posix gcc version 4.1.0 20050410 (experimental) This ICE doesn't occur at -O1 or with snapshot gcc-4.1-20050403. Michael Cieslinski -- Summary: ICE in check_loop_closed_ssa_use, at tree-ssa-loop- manip.c:394 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: micis at gmx dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20947
[Bug tree-optimization/20947] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:394
--- Additional Comments From micis at gmx dot de 2005-04-11 14:30 --- Created an attachment (id=8592) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8592action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20947
[Bug tree-optimization/20947] [4.1 Regression] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:394
-- What|Removed |Added Keywords||ice-on-valid-code Summary|ICE in |[4.1 Regression] ICE in |check_loop_closed_ssa_use, |check_loop_closed_ssa_use, |at tree-ssa-loop-manip.c:394|at tree-ssa-loop-manip.c:394 Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20947
[Bug tree-optimization/20947] [4.1 Regression] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:394
--- Additional Comments From micis at gmx dot de 2005-04-11 14:33 --- My gcc is patched with the patch for bug20920 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20947
[Bug bootstrap/20948] New: bootstrap of gcc-4.0.0-20050410 fails on i386-pc-solaris2.10
This is what I get during a gmake bootstrap: mv 'libgcc/./tmp-libgcc.map' libgcc/./libgcc.map ./xgcc -B./ -B/opt/gcc-4.0/i386-pc-solaris2.10/bin/ -isystem /opt/gcc-4.0/i386-pc-solaris2.10/include -isystem /opt/gcc-4.0/i386-pc-solaris2.10/sys-include -L/var/tmp/gcc-4.0.0-20050410/obj/gcc/../ld -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc/./libgcc.map -o ./libgcc_s.so.1.tmp libgcc/./_muldi3_s.o libgcc/./_negdi2_s.o libgcc/./_lshrdi3_s.o libgcc/./_ashldi3_s.o libgcc/./_ashrdi3_s.o libgcc/./_cmpdi2_s.o libgcc/./_ucmpdi2_s.o libgcc/./_floatdidf_s.o libgcc/./_floatdisf_s.o libgcc/./_fixunsdfsi_s.o libgcc/./_fixunssfsi_s.o libgcc/./_fixunsdfdi_s.o libgcc/./_fixdfdi_s.o libgcc/./_fixunssfdi_s.o libgcc/./_fixsfdi_s.o libgcc/./_fixxfdi_s.o libgcc/./_fixunsxfdi_s.o libgcc/./_floatdixf_s.o libgcc/./_fixunsxfsi_s.o libgcc/./_fixtfdi_s.o libgcc/./_fixunstfdi_s.o libgcc/./_floatditf_s.o libgcc/./_clear_cache_s.o libgcc/./_enable_execute_stack_s.o libgcc/./_trampoline_s.o libgcc/./__main_s.o libgcc/./_absvsi2_s.o libgcc/./_absvdi2_s.o libgcc/./_addvsi3_s.o libgcc/./_addvdi3_s.o libgcc/./_subvsi3_s.o libgcc/./_subvdi3_s.o libgcc/./_mulvsi3_s.o libgcc/./_mulvdi3_s.o libgcc/./_negvsi2_s.o libgcc/./_negvdi2_s.o libgcc/./_ctors_s.o libgcc/./_ffssi2_s.o libgcc/./_ffsdi2_s.o libgcc/./_clz_s.o libgcc/./_clzsi2_s.o libgcc/./_clzdi2_s.o libgcc/./_ctzsi2_s.o libgcc/./_ctzdi2_s.o libgcc/./_popcount_tab_s.o libgcc/./_popcountsi2_s.o libgcc/./_popcountdi2_s.o libgcc/./_paritysi2_s.o libgcc/./_paritydi2_s.o libgcc/./_powisf2_s.o libgcc/./_powidf2_s.o libgcc/./_powixf2_s.o libgcc/./_powitf2_s.o libgcc/./_mulsc3_s.o libgcc/./_muldc3_s.o libgcc/./_mulxc3_s.o libgcc/./_multc3_s.o libgcc/./_divsc3_s.o libgcc/./_divdc3_s.o libgcc/./_divxc3_s.o libgcc/./_divtc3_s.o libgcc/./_divdi3_s.o libgcc/./_moddi3_s.o libgcc/./_udivdi3_s.o libgcc/./_umoddi3_s.o libgcc/./_udiv_w_sdiv_s.o libgcc/./_udivmoddi4_s.o libgcc/./unwind-dw2_s.o libgcc/./unwind-dw2-fde_s.o libgcc/./unwind-sjlj_s.o libgcc/./gthr-gnat_s.o libgcc/./unwind-c_s.o -lc rm -f ./libgcc_s.so if [ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 ln -s libgcc_s.so.1 ./libgcc_s.so /usr/sfw/bin/gld: cannot open linker script file ldscripts/elf_i386.xsc: No such file or directory collect2: ld returned 1 exit status gmake[3]: *** [libgcc_s.so] Error 1 gmake[3]: Leaving directory `/var/tmp/gcc-4.0.0-20050410/obj/gcc' gmake[2]: *** [stmp-multilib] Error 2 gmake[2]: Leaving directory `/var/tmp/gcc-4.0.0-20050410/obj/gcc' gmake[1]: *** [stage1_build] Error 2 gmake[1]: Leaving directory `/var/tmp/gcc-4.0.0-20050410/obj/gcc' gmake: *** [bootstrap] Error 2 I am building gcc-4.0.0-20050410 on Solaris 10 x86 workstation with AMD64 CPU's. The isainfo -v command gives: 64-bit amd64 applications sse2 sse fxsr amd_3dnowx amd_3dnow amd_mmx mmx cmov amd_sysc cx8 tsc fpu 32-bit i386 applications sse2 sse fxsr amd_3dnowx amd_3dnow amd_mmx mmx cmov amd_sysc cx8 tsc fpu I am bootstrapping with a previous build of gcc 4.0 (gcc-4.0-20050402). My build options were: /var/tmp/gcc-4.0.0-20050410/configure --prefix=/opt/gcc-4.0 --with-gnu-as --with-as=/usr/sfw/bin/gas --with-gnu-ld -with-ld=/usr/sfw/bin/gld --disable-nls --with-system-zlib --enable-languages=c,c++ As can be seen above I am using the bundled GNU AS and GNU LD that come by default with Solaris 10 x86. Brett -- Summary: bootstrap of gcc-4.0.0-20050410 fails on i386-pc- solaris2.10 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brett dot albertson at stratech dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i386-pc-solaris2.10 GCC host triplet: i386-pc-solaris2.10 GCC target triplet: i386-pc-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20948
[Bug bootstrap/20948] bootstrap of gcc-4.0.0-20050410 fails on i386-pc-solaris2.10
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 14:37 --- This means you installation of binutils is wrong: /usr/sfw/bin/gld: cannot open linker script file ldscripts/elf_i386.xsc: No such file or directory Can you compile binutils and try again since this is not a gcc bug really. -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20948
[Bug c++/20949] New: misscompilation of konqueror, artsd, STLport, libstdc++, ...
**
[1] konqueror (kdebase-3.4.0).
(gdb) bt
#0 ~QIconSet (this=0x8209614) at qshared.h:50
~QIconSet (this=0x8209614) at qshared.h:50
50 bool deref(){ return !--count; }
(gdb) print this
$1 = (QIconSet * const) 0x8209614
(gdb) print *this
$2 = {_vptr.QIconSet = 0x41048ba8, d = 0x5}
It looks as if d pointer was corrupted in toplevel.
#1 0x4068cc51 in ~KGuiItem (this=0xbfffdbe4) at kguiitem.cpp:109
#2 0x400a1ce5 in ~QPair (this=0xbfffdbe4) at konq_mainwindow.cc:3683
#3 0x400727ea in KonqMainWindow::initActions (this=0x812af98)
at konq_mainwindow.cc:3922
#4 0x4008b330 in KonqMainWindow (this=0x812af98, [EMAIL PROTECTED],
openInitialURL=false, name=0x29 Address 0x29 out of bounds,
[EMAIL PROTECTED]) at konq_mainwindow.cc:217
(...)
Known workaround:
http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/kdebase-gcc4-konq_mainwindow.patch?rev=1.3
**
[2] arts-1.4.0
Program received signal SIGSEGV, Segmentation fault.
0x404f7405 in __gnu_cxx::__pooltrue::_M_reclaim_block ()
from /usr/lib/libstdc++.so.6
(gdb) bt
#0 0x404f7405 in __gnu_cxx::__pooltrue::_M_reclaim_block () from
/usr/lib/libstdc++.so.6
#1 0x08104928 in ?? ()
#2 0x0810492c in ?? ()
#3 0x in ?? ()
#4 0xb4d4 in ?? ()
#5 0xb4c8 in ?? ()
#6 0x in ?? ()
#7 0xb580 in ?? ()
#8 0x4006c8a0 in virtual thunk to Arts::GSLPlayObject_base::_defaultPortsOut()
const () from /usr/lib/libsoundserver_idl.so.1
#9 0x4008ae60 in Arts::SampleStorageEntry_base::_IID ()
from /usr/lib/libsoundserver_idl.so.1
#10 0x08104928 in ?? ()
#11 0x0004 in ?? ()
#12 0x080ff100 in ?? ()
#13 0x081618ac in ?? ()
#14 0x081070bd in ?? ()
#15 0x081070f0 in ?? ()
#16 0xb4c8 in ?? ()
#17 0xb4b0 in ?? ()
#18 0xb4c8 in ?? ()
#19 0xb4b0 in ?? ()
#20 0x40061d49 in Arts::SoundServerStartup_base::_fromString ()
from /usr/lib/libsoundserver_idl.so.1
#21 0x0001 in ?? ()
#22 0x08073240 in vtable for Arts::ObjectReference ()
#23 0x080b902c in ?? ()
#24 0x001c in ?? ()
#25 0x081048d8 in ?? ()
#26 0x081048dc in ?? ()
#27 0x081048dc in ?? ()
#28 0x08073240 in vtable for Arts::ObjectReference ()
#29 0x0811634c in ?? ()
#30 0x001c in ?? ()
#31 0x08104928 in ?? ()
#32 0x0810492c in ?? ()
#33 0x0810492c in ?? ()
#34 0xb520 in ?? ()
#35 0x in ?? ()
#36 0xb508 in ?? ()
#37 0x0805e5e8 in Arts::SoundServerStartup_impl::cleanReference (this=0x8163ee0)
at soundserver.h:1376
#38 0x0805ebda in Arts::SoundServerStartup_impl::lock (this=0x8163ee0)
at soundserverstartup_impl.cc:78
#39 0x0805d51c in main (argc=1, argv=0xb784) at soundserver.h:2082
It may be related to PR19265
**
[3] STLport-4.6.2 (used by openoffice-1.1.3)
OpenOffice's open-file dialog closes immediately after it was launched.
This behavior came with rebuilded STLport.
It works fine with gcc-3.4, 3.3 and some earlier 4.0-snaps.
I will do a bsearch in free time.
**
--
Summary: misscompilation of konqueror, artsd, STLport, libstdc++,
...
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at pld-linux dot org
CC: gcc-bugs at gcc dot gnu dot org,jason at redhat dot com
GCC build triplet: i686-pld-linux
GCC host triplet: i686-pld-linux
GCC target triplet: i686-pld-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20949
[Bug middle-end/20933] [4.1 Regression] gcc can no longer bootstrap itself
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 14:43 --- I think this was caused by: 2005-04-08 Diego Novillo [EMAIL PROTECTED] Merge from tree-cleanup-branch: VRP, store CCP, store copy-prop, incremental SSA updating of FUD chains and newly exposed symbols. -- What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20933
[Bug c++/19317] [4.1 Regression] removing a temporary return value when we cannot
--- Additional Comments From pluto at pld-linux dot org 2005-04-11 14:43 --- (In reply to comment #28) Subject: Re: [4.1 Regression] removing a temporary return value when we cannot On 11 Apr 2005 08:59:58 -, pluto at pld-linux dot org [EMAIL PROTECTED] wrote: Have you tested the 4.0 branch with the temporary fix I applied? I applied a temporary fix and Dirk's hack to get konqueror working but misscompilation still exists. My patch fixes all the reduced testcases in this PR. If KDE is still broken, I think that's a separate bug and needs testcases. Can you submit another PR? I've opened the PR20949 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19317
[Bug c++/20949] [4.0 Regression] misscompilation of konqueror, artsd, STLport, libstdc++, ...
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 14:44 --- Well without a test, there is still nothing we can do anyways because they could be invoking undefined behavior :). Also do they fail when compiled with -O0? -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |critical Keywords||wrong-code Summary|misscompilation of |[4.0 Regression] |konqueror, artsd, STLport, |misscompilation of |libstdc++, ... |konqueror, artsd, STLport, ||libstdc++, ... Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20949
[Bug middle-end/20933] [4.1 Regression] gcc can no longer bootstrap itself
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 14:50 --- Actually if anything is miscompile it would be make_temp_file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20933
[Bug bootstrap/20948] bootstrap of gcc-4.0.0-20050410 fails on i386-pc-solaris2.10
--- Additional Comments From brett dot albertson at stratech dot com 2005-04-11 14:57 --- (In reply to comment #1) This means you installation of binutils is wrong: /usr/sfw/bin/gld: cannot open linker script file ldscripts/elf_i386.xsc: No such file or directory Can you compile binutils and try again since this is not a gcc bug really. I'm restarting the bootstrap now using Sun's linker (/usr/ccs/bin/ld). I'll reply when it is finished. Brett -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20948
[Bug tree-optimization/20920] [4.1 Regression] ICE with eh and VRP
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-11 15:06 --- Subject: Bug 20920 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-11 15:05:50 Modified files: gcc: ChangeLog tree-pretty-print.c tree-vrp.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/tree-ssa: pr20920.C Log message: PR tree-optimization/20920 * tree-pretty-print.c (dump_generic_node): Show '(ab)' if an SSA_NAME flows through an abnormal edge. * tree-vrp.c (infer_value_range): Ignore SSA names that flow through abnormal edges. (maybe_add_assert_expr): Likewise. PR tree-optimization/20920 * g++.dg/tree-ssa/pr20920.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8227r2=2.8228 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-pretty-print.c.diff?cvsroot=gccr1=2.56r2=2.57 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-vrp.c.diff?cvsroot=gccr1=2.2r2=2.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5324r2=1.5325 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/tree-ssa/pr20920.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20920
[Bug middle-end/20933] [4.1 Regression] gcc can no longer bootstrap itself
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-11 15:07:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20933
[Bug tree-optimization/20920] [4.1 Regression] ICE with eh and VRP
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-04-11 15:09 --- Fixed. http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01050.html -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20920
Re: Fix tree-optimization/20920
On Sun, Apr 10, 2005 at 09:47:25PM -0400, Diego Novillo wrote: On Sun, Apr 10, 2005 at 05:38:31PM -0400, Andrew Pinski wrote: This fixes the bootstrap problem for me on powerpc-darwin. Thanks. I will commit as soon as I get a clean bootstrap. Got a clean bootstrap and test run using the additional patch for PR 20934. Fix for 20920 comitted to mainline. Diego.
[Bug tree-optimization/20926] [4.1 Regressopm] ICE: tree check, in recent builds
--- Additional Comments From amacleod at redhat dot com 2005-04-11 15:13 --- Why would you say that? I get the same failure with a build from April 1 before immuses was checked in. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20926
[Bug bootstrap/20948] bootstrap of gcc-4.0.0-20050410 fails on i386-pc-solaris2.10
--- Additional Comments From brett dot albertson at stratech dot com 2005-04-11 15:21 --- (In reply to comment #2) I'm restarting the bootstrap now using Sun's linker (/usr/ccs/bin/ld). I'll reply when it is finished. It successfully bootstrapped using Sun's ld and Gnu's as, as supplied with Solaris 10 x86. Brett -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20948
[Bug tree-optimization/20926] [4.1 Regressopm] ICE: tree check, in recent builds
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-04-11 15:26 --- I believe ivopts is doing funky things with copying vops and whatnot without taking into account subvars that is screwing us up. The error existed before 04/01, AFAICT -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20926
[Bug libfortran/20950] New: segfault in INQUIRE asking for SEQUENTIAL status
$ cat fc112.f character*20 c inquire (33, sequential = c) print *, c end $ ./bin/gfortran -static fc112.f ./a.out zsh: segmentation fault ./a.out With gdb: Program received signal SIGSEGV, Segmentation fault. inquire_via_unit (u=0x0) at ../../../gcc/libgfortran/io/inquire.c:92 92else Patch will follow soon. -- Summary: segfault in INQUIRE asking for SEQUENTIAL status Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20950
[Bug libfortran/20950] segfault in INQUIRE asking for SEQUENTIAL status
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-11 15:41:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20950
[Bug tree-optimization/20944] ICE: SSA corruption compiling ACE542 with gcc41
--- Additional Comments From micis at gmx dot de 2005-04-11 15:49 --- The patch for bug20920 solves this problem. Michael Cieslinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20944
[Bug c++/20949] [4.0 Regression] misscompilation of konqueror, artsd, STLport, libstdc++, ...
--- Additional Comments From pluto at pld-linux dot org 2005-04-11 15:58 --- (In reply to comment #1) Well without a test, there is still nothing we can do anyways because they could be invoking undefined behavior :). Also do they fail when compiled with -O0? arts crashes with -O0. Program received signal SIGSEGV, Segmentation fault. 0x406fc405 in __gnu_cxx::__pooltrue::_M_reclaim_block () from /usr/lib/libstdc++.so.6 (gdb) bt #0 0x406fc405 in __gnu_cxx::__pooltrue::_M_reclaim_block () from /usr/lib/libstdc++.so.6 #1 0xb538 in ?? () #2 0x40014280 in _dl_runtime_resolve () from /lib/ld-linux.so.2 #3 0x40063efd in __gnu_cxx::__mt_allocstd::string, __gnu_cxx::__common_pool_policy__gnu_cxx::__pool, true ::deallocate (this=0xb2ac, __p=0x81058d8, __n=1) at mt_allocator.h:746 #4 0x40063f36 in std::_Vector_basestd::string, std::allocatorstd::string ::_M_deallocate (this=0xb2ac, __p=0x81058d8, __n=1) at stl_vector.h:123 #5 0x40063f71 in ~_Vector_base (this=0xb2ac) at stl_vector.h:109 #6 0x40063fe1 in ~vector (this=0xb2ac) at stl_vector.h:273 #7 0x40064013 in ~ObjectReference (this=0xb2a0) at reference.h:48 #8 0x40055244 in Arts::SoundServerStartup_base::_fromString ([EMAIL PROTECTED]) at soundserver.cc:2545 #9 0x080644d4 in SoundServerStartup (this=0xb314, [EMAIL PROTECTED]) at soundserver.h:1376 #10 0x0805585b in Arts::SoundServerStartup_impl::cleanReference (this=0x8164cf0) at soundserverstartup_impl.cc:54 #11 0x080559a1 in Arts::SoundServerStartup_impl::lock (this=0x8164cf0) at soundserverstartup_impl.cc:78 #12 0x0805e080 in Arts::SoundServerStartup::lock (this=0xb4a8) at soundserver.h:2082 #13 0x080561d2 in main (argc=65, argv=0x8614c381) at artsd.cc:293 kdebase and stlport not recompiled yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20949
[Bug c++/20949] [4.0 Regression] misscompilation of konqueror, artsd, STLport, libstdc++, ...
-- What|Removed |Added CC||mmazur at kernel dot pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20949
[Bug c/20951] New: bogus error passing va_list to va_list*
The program below fails to compile with gcc on EM64T. I believe the program is
well-formed based on 7.15.1.1 of C99, Footnote 212 (I am aware that footnotes
are not normative).
The second program below uses va_copy to get around the compilation error in the
first case fails to compile with the -ansi option (I am aware of gcc-specific
__builtin_va_copy). Even if the program did compile the solution seems
unreasonably complicated.
Can you confirm whether you agree that this is a conformance bug or not and if
not explain why not?
$ cat t.cpp g++ --version g++ -c t.cpp
#include stdarg.h
void foo (int, va_list*);
void bar (int i, va_list va)
{
foo (i, va);
}
g++ (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-47)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
t.cpp: In function `void bar(int, __va_list_tag*)':
t.cpp:7: cannot convert `__va_list_tag**' to `__va_list_tag (*)[1]' for
argument `2' to `void foo(int, __va_list_tag (*)[1])'
$ cat t.cpp g++ --version g++ -ansi t.cpp
#include assert.h
#include stdarg.h
#include stdio.h
int a [3];
int foo (int i, va_list *pva)
{
a [i++] = va_arg (*pva, int);
return i;
}
void bar (int i, va_list va)
{
a [i++] = va_arg (va, int);
#ifdef va_copy
va_list cpy;
va_copy (cpy, va);
va_end (va);
i = foo (i, cpy);
va_copy (va, cpy);
va_end (cpy);
#else
i = foo (i, va);
#endif
a [i++] = va_arg (va, int);
}
void baz (int i, ...)
{
va_list va;
va_start (va, i);
bar (i, va);
va_end (va);
}
int main ()
{
baz (0, 1, 2, 3);
printf (%d, %d, %d\n, a [0], a [1], a [2]);
assert (1 == a [0]);
assert (2 == a [1]);
assert (3 == a [2]);
}
g++ (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-47)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
t.cpp: In function `void bar(int, __va_list_tag*)':
t.cpp:25: cannot convert `__va_list_tag**' to `__va_list_tag (*)[1]' for
argument `2' to `int foo(int, __va_list_tag (*)[1])'
--
Summary: bogus error passing va_list to va_list*
Product: gcc
Version: 3.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: x86_64-redhat-linux
GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20951
[Bug tree-optimization/20926] [4.1 Regressopm] ICE: tree check, in recent builds
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-04-11 16:55 --- Mine -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-11 16:55:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20926
[Bug target/20951] bogus error passing va_list to va_list*
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 17:07 --- Nope this is invalid, see PR 14557 for more discussion about this issue. va is equivalent to va[0] on x86_64 since va_list is defined as an array on x86_64. *** This bug has been marked as a duplicate of 14557 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |target Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20951
[Bug target/14557] va_list is automatically taken address-of when passed as argument
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 17:07 --- *** Bug 20951 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||sebor at roguewave dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14557
[Bug c++/20949] [4.0/4.1 Regression] misscompilation of konqueror, artsd, STLport, libstdc++, ...
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 17:12 --- http://gcc.gnu.org/ml/gcc/2005-04/msg00514.html -- What|Removed |Added CC||jakub at gcc dot gnu dot org Summary|[4.0 Regression]|[4.0/4.1 Regression] |misscompilation of |misscompilation of |konqueror, artsd, STLport, |konqueror, artsd, STLport, |libstdc++, ... |libstdc++, ... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20949
[Bug middle-end/14311] builtins for atomic operations needed
--- Additional Comments From bkoz at redhat dot com 2005-04-11 17:14 --- Subject: Re: builtins for atomic operations needed I'm working on atomic builtins, but this will *not* resolve the problem of compiling for i386 and i486+. Indeed, it could easily make it worse because you won't have the kind of control you did before wrt hiding these operations in out-of-line functions. Hurray. I really think that the builtin solution is the right way forward for everybody, design-wise. Thanks for doing this Richard. Pre gcc-3.4, we had the same problem with i386/i486+ separation. I think, realistically, that i486 compilation should be a minimum requirement for linux distros circa 2005. (If not i586.). Thus, the solution I will be in favor of is eliminating i386 compatibility with the version of the toolchain that first implements the atomic builtins. For people that really want to support i386, they should use gcc-2.7 to gcc-3.4. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14311
[Bug middle-end/20931] [4.0/4.1 Regression] fold checking failure
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 17:16 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01193.html. -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20931
[Bug middle-end/20946] --enable-checking=yes,fold fails on the mainline
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 17:16 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01193.html. -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20946
[Bug fortran/18452] -fno-second-underscore induces warning for fortran that needs preprocessing
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-04-11 17:16 --- Subject: Re: -fno-second-underscore induces warning for fortran that needs preprocessing pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 12:48 --- (In reply to comment #5) It is annoying enough that the preprocessor is invoked via cc1. Is there a reason for this, besides that it is the example given in the specfiles? Besides that is the only preprocessor any more, there is not a seperate one anymore, it is integrated into cc1 now. We're using the traditional preprocessor. This is a separate executable, cpp, which is built separately. So the question remains: why do we run cc1? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18452
[Bug fortran/18452] -fno-second-underscore induces warning for fortran that needs preprocessing
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 17:20 --- (In reply to comment #8) We're using the traditional preprocessor. This is a separate executable, cpp, which is built separately. So the question remains: why do we run cc1? cpp just calls cc1. There used to be a cpp0 but that was removed a while back, long before gfortran was added, there was code in cc1 which made us not warn about the g77 options, that should be brought back. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18452
[Bug middle-end/20934] [4.1 Regression] Segmentation fault in gnat1
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 17:24 --- Created an attachment (id=8594) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8594action=view) patch which Caroline sent me to attach I mistakenly assumed that if current_function_decl was defined, then the decl would always have a function struct attached to it; also that when we were writing out debug information, current_function_decl would be defined. -- What|Removed |Added Attachment #8582 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20934
[Bug c/20951] bogus error passing va_list to va_list*
--- Additional Comments From sebor at roguewave dot com 2005-04-11 17:33 --- (In reply to comment #1) Right. I understand why it doesn't compile and how to work around it (with gcc at least). What I'm still not convinced of is that it's not a strict conformance bug. The same point was raised in the discussion you pointed me to but I couldn't find where it was addressed or if it was communicated to WG14. I.e., even if the requirement in C99 (that makes the test case well-formed) is non-normative and bogus, strictly speaking this would still be a conformance bug in the gcc implementation of va_list (after all, it is a gcc builtin, so it seems that the compiler could do some magic whereby taking the address of a va_list declared as an argument to a function would produce va_list* and not va_list**). Do you happen to know whether there's a C99 issue to fix the footnote? -- What|Removed |Added Component|target |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20951
[Bug c/20951] bogus error passing va_list to va_list*
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 17:35 --- (In reply to comment #2) Do you happen to know whether there's a C99 issue to fix the footnote? If you read that bug's comment, you will see in comment #8: My recollection from last time we were discussing this is that text above is an footnote that is not normative and in conflict with rest of the standard, so it needs to be ignored. While I agree that this behaviour is very unfortuante side effect of va-arg implementation, there are some other ABIS around (PPC SysV) doing the same so the only choice now is probably to avoid this construct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20951
[Bug fortran/18452] -fno-second-underscore induces warning for fortran that needs preprocessing
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-04-11 17:39 --- Subject: Re: -fno-second-underscore induces warning for fortran that needs preprocessing pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 17:20 --- (In reply to comment #8) We're using the traditional preprocessor. This is a separate executable, cpp, which is built separately. So the question remains: why do we run cc1? cpp just calls cc1. There used to be a cpp0 but that was removed a while back, long before gfortran was added, there was code in cc1 which made us not warn about the g77 options, that should be brought back. Oh, ok. OTOH one could maybe strip out options that are meaningless to preprocessing before calling cc1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18452
[Bug middle-end/20933] [4.1 Regression] gcc can no longer bootstrap itself
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-04-11 17:41 --- Testing fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20933
[Bug tree-optimization/20926] [4.1 Regressopm] ICE: tree check, in recent builds
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-04-11 17:49 --- The error existed before 04/01, AFAICT I don't believe so - I have a gcc build of 20050129 that does not do this; see my posting on the fortran list. Further evidence, if it helps, is that the code compiles, as provided, without any optimisation, using gcc-4.1 of 20050409 on RH9. With -O, something that does not happen with the Cygwin version: After a load of warning about arithmetic IFs 1 Warning: Obsolete: arithmetic IF statement at (1) In file lfk.f:2096 465 IF( i1-m) 410,480,410 1 Warning: Obsolete: arithmetic IF statement at (1) lfk.f: In function supply: lfk.f:6364: error: Found real variable when subvariables should have appeared while verifying SSA_NAME spacer_2781 in statement spacer_2781 = PHI spacer_3223(1), spacer_3639(6); lfk.f:6364: error: Found real variable when subvariables should have appeared while verifying SSA_NAME spacer_2782 in statement spacer_2782 = PHI spacer_2781(2), spacer_3638(4); lfk.f:6364: error: Found real variable when subvariables should have appeared while verifying SSA_NAME spacer_2783 in statement spacer_2783 = PHI spacer_3086(0), spacer_3691(7); lfk.f:6364: error: Found real variable when subvariables should have appeared while verifying SSA_NAME spacer_2784 in statement spacer_2784 = PHI spacer_2783(9), spacer_3205(11), spacer_3205(14), spacer_3220(15); lfk.f:6364: error: Found real variable when subvariables should have appeared while verifying SSA_NAME spacer_2785 in statement spacer_2785 = PHI spacer_2784(17), spacer_3326(19); lfk.f:6364: error: Found real variable when subvariables should have appeared while verifying SSA_NAME spacer_2786 in statement spacer_2786 = PHI spacer_2784(16), spacer_3327(20); lfk.f:6364: error: Found real variable when subvariables should have appeared while verifying SSA_NAME spacer_2787 in statement spacer_2787 = PHI spacer_2786(22), spacer_3430(24); lfk.f:6364: error: Found real variable when subvariables should have appeared while verifying SSA_NAME spacer_2788 in statement spacer_2788 = PHI spacer_2786(21), spacer_3431(25); lfk.f:6364: error: Found real variable when subvariables should have appeared while verifying SSA_NAME spacer_2789 in statement spacer_2789 = PHI spacer_2788(27), spacer_3534(29); lfk.f:6364: error: Found real variable when subvariables should have appeared while verifying SSA_NAME spacer_2790 in statement spacer_2790 = PHI spacer_2788(26), spacer_3535(30); lfk.f:6364: error: Found real variable when subvariables should have appeared while verifying SSA_NAME spacer_3086 in statement # nt0_508 = V_MAY_DEF nt0_56; # spaces_509 = V_MAY_DEF spaces_58; # space0_510 = V_MAY_DEF space0_472; # base1_511 = V_MAY_DEF base1_121; which it does for a long time until # SFT.3523_598 = V_MAY_DEF SFT.3523_70; # SFT.3524_599 = V_MAY_DEF SFT.3524_69; # SFT.3525_600 = V_MAY_DEF SFT.3525_68; trace (SUPPLY , 8); lfk.f:6364: internal compiler error: verify_ssa failed. Please submit a full bug report, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20926
[Bug tree-optimization/20926] [4.1 Regressopm] ICE: tree check, in recent builds
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 17:51 --- (In reply to comment #7) The error existed before 04/01, AFAICT I don't believe so - I have a gcc build of 20050129 that does not do this; see my posting on the fortran list. He means April 1st and not January 4th, I hate writing dates out but since Europe and US disagress with what goes first, it is better :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20926
