[Bug bootstrap/26936] fix-header segfault with glibc-2.4 header
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-31 07:50 --- Subject: Bug 26936 Author: rguenth Date: Fri Mar 31 07:49:59 2006 New Revision: 112573 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112573 Log: 2006-03-31 Richard Guenther <[EMAIL PROTECTED]> PR bootstrap/26936 Backport from mainline. 2006-02-25 Juergen Weigert <[EMAIL PROTECTED]> Richard Guenther <[EMAIL PROTECTED]> * scan-decls.c (scan_decls): Don't fetch new statement after CPP_EOF. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/scan-decls.c --- Comment #4 from rguenth at gcc dot gnu dot org 2006-03-31 07:50 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26936
[Bug bootstrap/26936] fix-header segfault with glibc-2.4 header
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-31 07:50 --- Subject: Bug 26936 Author: rguenth Date: Fri Mar 31 07:49:59 2006 New Revision: 112573 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112573 Log: 2006-03-31 Richard Guenther <[EMAIL PROTECTED]> PR bootstrap/26936 Backport from mainline. 2006-02-25 Juergen Weigert <[EMAIL PROTECTED]> Richard Guenther <[EMAIL PROTECTED]> * scan-decls.c (scan_decls): Don't fetch new statement after CPP_EOF. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/scan-decls.c --- Comment #4 from rguenth at gcc dot gnu dot org 2006-03-31 07:50 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26936
[Bug tree-optimization/26830] [4.1/4.2 Regression] Insane amount of compile-time / memory needed at -O1 and above
--- Comment #24 from paolo dot bonzini at lu dot unisi dot ch 2006-03-31 07:37 --- Subject: Re: [4.1/4.2 Regression] Insane amount of compile-time / memory needed at -O1 and above > Note that the regression is in 4.1, too, so we should consider backporting > changes that accumulate here to the branch after a while. > Sure, but I am a bit nervous about backporting right away a change to parts I am not familar with. Let's wait until a week after *all* patches are applied. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug tree-optimization/26859] [4.2 Regression] ICE Segmentation Fault
--- Comment #12 from reichelt at gcc dot gnu dot org 2006-03-31 07:16 --- Fixed on mainline. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26859
[Bug c++/26950] Error diagnostic not issued for unacceptable result of lookup for a name used in a nested-name-specifier
--- Comment #4 from widman at gimpel dot com 2006-03-31 05:36 --- Subject: Re: Error diagnostic not issued for unacceptable result of lookup for a name used in a nested-name-specifier On Mar 30, 2006, at 11:47 PM, Daveed Vandevoorde wrote: > > On Mar 30, 2006, at 4:06 PM, James Widman wrote: >> "enum N" is not an enumerator name; it's an enumeration name (or >> an /enum-name/ [7.2p1]), so "enum N" cannot be ignored. > > Ah, you're right. It turns out that the grammar in this area > has changed since the 1998 standard (as John Spicer pointed > out to me). The 1998 version of the standard had > > nested-name-specifier: > class-or-namespace-name :: nested-name-specifieropt > class-or-namespace-name :: template nested-name-specifier > > which meant only classes or namespace names were considered. > That could be read as meaning that 3.4.3/1 never was reached > with an enumeration type name, but there is no unanimity on > that reading. > > With the current wording (which was introduced because the > earlier wording didn't correctly deal with template-dependent > qualifiers), it's pretty unambiguous that your example is > ill-formed and we think the standard should not be changed > in that regard. > > I've filed a defect numbered EDGcpfe/7621 to track this. > > Cheers, > > Daveed Vandevoorde > Edison Design Group Thanks; that should help to simplify our lookup routines ever-so- slightly. (: For those with a superstitious bent, I'd like to point out that this week saw a total eclipse of the sun, news of genetically modified pigs (perhaps with wings next), and now it's been revealed that GCC and EDG have the same front end bug for a case where *every other C++ front end* appears to get it right. This is clearly a sign that the end is nigh. It's apocalypse party time. (: -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26950
[Bug bootstrap/22195] Missing Documentation
--- Comment #5 from rmathew at gcc dot gnu dot org 2006-03-31 05:30 --- (In reply to comment #4) > > I was not intending to modify GCC (as the requirements for modifying it do > list > Texinfo). I was intending to compile it. Out of the box compile on my system > failed, and Ranjit's system. Thus a bug, no? (And even if it still isn't > deemed a bug, the fix is a simple one-liner, which I provided.) When you're downloading an SVN snapshot, which is intended for developers, you do not get much of the automatically generated stuff that's available in releases. For SVN snapshots, you must read the "modifying GCC" portion of the pre-requisites documentation. > Perhaps the term "modify" implies "CVS" -- if so, perhaps that could be > emphasized on the prerequisite page? That is, "If you download GCC from the > repository (regardless of whether you want to modify it or not), you must have > the following ..." Agreed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22195
[Bug bootstrap/22195] Missing Documentation
--- Comment #4 from dave at joot dot com 2006-03-31 05:23 --- The page at http://gcc.gnu.org/install/prerequisites.html under "Tools/packages necessary for building GCC" does NOT list "Texinfo version 4.4 (or later)" as a requirement. I was not intending to modify GCC (as the requirements for modifying it do list Texinfo). I was intending to compile it. Out of the box compile on my system failed, and Ranjit's system. Thus a bug, no? (And even if it still isn't deemed a bug, the fix is a simple one-liner, which I provided.) Perhaps the term "modify" implies "CVS" -- if so, perhaps that could be emphasized on the prerequisite page? That is, "If you download GCC from the repository (regardless of whether you want to modify it or not), you must have the following ..." -- dave at joot dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22195
[Bug libfortran/26890] SIZE parameter interacts with same variable in IO list character length specification.
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-03-31 05:15 --- Subject: Bug 26890 Author: jvdelisle Date: Fri Mar 31 05:15:42 2006 New Revision: 112571 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112571 Log: 2006-03-30 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/26890 * gfortran.dg/read_size_noadvance.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/read_size_noadvance.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26890
[Bug libfortran/26890] SIZE parameter interacts with same variable in IO list character length specification.
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-03-31 05:11 --- Subject: Bug 26890 Author: jvdelisle Date: Fri Mar 31 05:11:03 2006 New Revision: 112570 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112570 Log: 2006-03-30 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/26890 * io/io.h: Add size_used to st_parameter_dt, adjust pad size. *io/transfer.c (data_transfer_init): Initialize size_used to zero. (read_sf): Use size_used. (read_block): Likewise. (read_block_direct): Likewise. (write_block): Likewise. (write_buf): Likewise and eliminate erroneous FAILURE return. (finalize_transfer): Assign value of size_used to *dtp->size. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/io.h trunk/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26890
[Bug target/26879] LibJava not compile under alpha
--- Comment #11 from rmathew at gcc dot gnu dot org 2006-03-31 04:29 --- Created an attachment (id=11172) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11172&action=view) Shell script to help narrow the problem in PR26879. Save this file in a folder. Save "debugx" and "debug" from: http://gcc.gnu.org/ml/gcc/2004-03/msg01195.html into the *same* folder. Give execute permissions to all of these scripts: chmod +x rep26879.sh debugx debug Now execute "rep26879.sh", assuming you have *not* wiped out the build folder given in the build log: "/gcc-8eea83c766efc28763a9d30e4baba897/gcc.build.lnx" The script leaves you in GDB. On the GDB prompt, enter "run". When the segmentation fault happens, enter "list" and then enter "backtrace". Copy-paste all of the output into this bug report. If this does not work, I'm afraid we'll have to wait for a hacker with an alpha box to help us out. :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26879
[Bug bootstrap/22195] Missing Documentation
--- Comment #3 from rmathew at gcc dot gnu dot org 2006-03-31 03:43 --- FWIW, I am getting the same error with GCC 3.4.6 and I *do have* GNU Texinfo 4.8. I have FSF GCC 3.4.5 sources and I downloaded GCC 3.4.6 diffs for "core" and "g++" - the patches applied successfully, but "make bootstrap" terminates with the same error as reported by the filer. I'm on i686-pc-linux-gnu and the starting compiler is FSF GCC 3.4.5. The command for configuration was: /root/inst/gcc-3.4.6/configure --prefix=/usr/local --disable-debug \ --disable-nls --disable-checking --enable-threads=posix \ --enable-languages=c,c++ --enable-__cxa_atexit --with-system-zlib \ --with-gnu-ld --with-gnu-as --with-arch=pentium3 --with-tune=pentium3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22195
[Bug bootstrap/26892] Can't compile a 64-bit gcc
--- Comment #2 from lucier at math dot purdue dot edu 2006-03-31 03:01 --- Subject: Re: Can't compile a 64-bit gcc I don't know. Why does 4.2 use libiconv and 4.1 not use it? (I'm presuming that 4.1 doesn't use it because I was able to build a 64-bit gcc on darwin). Should gcc ship libiconv source and compile it using BOOTCFLAGS, like it ends up doing with libiberty? Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26892
[Bug target/26885] [4.1/4.2 regression] -m64 -m32 no longer creates 32-bit object
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-03-31 02:52 --- Jakub -- Sorry about introducing this bug! I'm not sure how best to handle it, but I'll fix it somehow, if you like. I won't have time to work on it for about a week, but I'll be happy to handle it then. If you'd like that, please assign the bug to me. Thanks, -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26885
[Bug c++/14644] enum of value zero not converted to (null) pointer
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-03-31 02:28 --- As Roger says, this not a bug. Roger's analysis is spot on. (For reference, EDG also rejects this program.) -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14644
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #23 from amodra at bigpond dot net dot au 2006-03-31 01:54 --- Fixed -- amodra at bigpond dot net dot au changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||03/msg01751.html Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #22 from amodra at gcc dot gnu dot org 2006-03-31 01:27 --- Subject: Bug 26459 Author: amodra Date: Fri Mar 31 01:27:44 2006 New Revision: 112562 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112562 Log: PR target/26459 * config/rs6000/rs6000.h (CANNOT_CHANGE_MODE_CLASS): Limit 2003-12-08 change to FLOAT_REGS. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/rs6000/rs6000.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #21 from amodra at gcc dot gnu dot org 2006-03-31 01:25 --- Subject: Bug 26459 Author: amodra Date: Fri Mar 31 01:25:35 2006 New Revision: 112561 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112561 Log: PR target/26459 * config/rs6000/rs6000.h (CANNOT_CHANGE_MODE_CLASS): Limit 2003-12-08 change to FLOAT_REGS. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug fortran/21130] 38822 lines of Fortran 90 takes more than 10 minutes to compile on a dual 3GHz P4 Linux box with lots of RAM
--- Comment #12 from bdavis at gcc dot gnu dot org 2006-03-31 00:47 --- Subject: Bug 21130 Author: bdavis Date: Fri Mar 31 00:47:13 2006 New Revision: 112558 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112558 Log: 2006-03-30 Paul Thomas <[EMAIL PROTECTED]> Bud Davis <[EMAIL PROTECTED]> PR 21130 * module.c (load_needed): Traverse entire tree before returning. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21130
[Bug libstdc++/26926] double vs. long double libmath export confusion
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-31 00:33 --- I actually don't see why this is a problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26926
[Bug c++/26922] Compile/link failure with -frepo and g++ 4.1
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-31 00:32 --- Well if you read the instructions on how to report a bug, a tar file is not really liked :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26922
[Bug c++/26957] [4.0/4.1/4.2 regression] ICE in make_decl_rtl, at varasm.c:871
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-31 00:12 --- This works just fine on x86. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26957
[Bug c++/26957] [4.0/4.1/4.2 regression] ICE in make_decl_rtl, at varasm.c:871
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26957
[Bug c++/26957] [4.0 regression] ICE in make_decl_rtl, at varasm.c:871
--- Comment #1 from tausq at debian dot org 2006-03-30 23:52 --- Created an attachment (id=11171) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11171&action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26957
[Bug c++/26957] New: [4.0 regression] ICE in make_decl_rtl, at varasm.c:871
$ g++ -c bug.cc bug.cc: In member function 'void TAO_DynCommon::_ZTv0_n100_N13TAO_DynCommon17insert_longdoubleEN7ACE_CDR10LongDoubleE(CORBA::LongDouble)': bug.cc:28887: internal compiler error: in make_decl_rtl, at varasm.c:871 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see . Testcase is extracted from the "ace" package on Debian. -- Summary: [4.0 regression] ICE in make_decl_rtl, at varasm.c:871 Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tausq at debian dot org GCC build triplet: hppa-unknown-linux GCC host triplet: hppa-unknown-linux GCC target triplet: hppa-unknown-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26957
[Bug c++/26950] Error diagnostic not issued for unacceptable result of lookup for a name used in a nested-name-specifier
--- Comment #3 from widman at gimpel dot com 2006-03-30 23:31 --- Subject: Re: Error diagnostic not issued for unacceptable result of lookup for a name used in a nested-name-specifier On Mar 30, 2006, at 4:06 PM, widman at gimpel dot com wrote: > > So when I read that excerpt of 3.4.3/1, I thought to myself: > > "During the lookup for a name preceding the :: scope resolution > operator, ordinary names are ignored, except that typedef names and > namespace names are considered." > > ... with the implication being that tag names (including the names of > classes, unions, and enumerations) are considered without exception. What was the intention in 3.4.3p1? Presumably it's to prevent lookup from finding names that don't refer to namespaces or classes. If that's the case then we probably want a change in wording here -- maybe something like: During the lookup for a name preceding the :: scope resolution operator, only the following kinds of names are considered: - class-names, - class template names (when used to form a template-id), - namespace names, and - typedef names All other names are ignored. If the name found does not designate: - a class, - a dependent type that could possibly refer to a class during instantiation, or - a namespace, then the program is ill-formed. If the name designates a dependent type, no diagnostic is required. (See also http://www.open-std.org/jtc1/sc22/wg21/docs/ cwg_active.html, item 215) James Widman -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26950
[Bug c++/26938] [4.0/4.1/4.2 regression] ICE with wrong number of template parameters
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 23:18 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||error-recovery Last reconfirmed|-00-00 00:00:00 |2006-03-30 23:18:48 date|| Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26938
[Bug regression/26928] ICE in in bsi_last, at tree-flow-inline.h:760 on valid code with -march=i686.
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-30 23:17 --- Even in the sources from today I cannot reproduce this so closing as invalid. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26928
[Bug middle-end/22375] fold_builtins creates mis-matched types
--- Comment #3 from roger at eyesopen dot com 2006-03-30 23:01 --- This has now been fixed on mainline, and I've also checked that the extra load mentioned in comment #1 is now also resolved. -- roger at eyesopen dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22375
[Bug middle-end/22375] fold_builtins creates mis-matched types
--- Comment #2 from sayle at gcc dot gnu dot org 2006-03-30 22:38 --- Subject: Bug 22375 Author: sayle Date: Thu Mar 30 22:37:55 2006 New Revision: 112547 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112547 Log: PR middle-end/22375 * trans.c (gfc_trans_runtime_check): Promote the arguments of __builtin_expect to the correct types, and the result back to boolean_type_node. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22375
[Bug tree-optimization/26939] loop number of iterations analysis confused by what PRE did (PRE is doing its job)
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-03-30 22:25 --- Note that the patch for 23855 will only help for invariant conditions in the loop header, while the problem exists also for non-invariant ones. So, as Danny notes, SCEV should be improved to maybe handle this case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26939
[Bug tree-optimization/26939] loop number of iterations analysis confused by what PRE did (PRE is doing its job)
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-03-30 22:24 --- Yes, probably - though that patch doesn't apply anymore and wasn't reviewed either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26939
[Bug target/26879] LibJava not compile under alpha
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-03-30 22:18 --- *** Bug 26878 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26879
[Bug target/26878] LibJava not compile
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-30 22:18 --- *** This bug has been marked as a duplicate of 26879 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26878
[Bug tree-optimization/26939] loop number of iterations analysis confused by what PRE did (PRE is doing its job)
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-03-30 22:16 --- Won't this get fixed by the patch which patches loop header copy for PR 23855? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26939
[Bug other/26914] missed optimization / lack of conditional moves
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-03-30 22:16 --- Related to / dup of PR22568. Meta-bug ifcvt sucks. Or cmov sucks on the P4 - whatever you like ;) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||22568 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26914
[Bug middle-end/26898] Fold does not fold signed + CST1 CMP signed + CST2
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-30 22:12 --- It also works for combined CST < CST1 or CST2, i.e. a +- c1 CMP b +- c2 to a CMP b +- c3 where c3 < c2 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|Fold does not fold signed + |Fold does not fold signed + |CST1 CMP signed + CST2 where|CST1 CMP signed + CST2 |CST1 == CST2| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26898
[Bug libfortran/26712] gfortran on mac intel runtime floating point exception when printing
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-03-30 22:08 --- 4.1.x is broken for i686-darwin other ways so this is not to be fixed for there. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.1.1 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26712
[Bug fortran/26920] Cannot build using static libraries
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 22:07 --- This is not a bug with GCC but Darwin does not have the static libraries for libc or even crt0.o for -static compiling. You cannot compile with -static on Darwin. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26920
[Bug c++/26917] [4.0/4.1/4.2 regression] ICE with -frepo on invalid code
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26917
[Bug other/26914] missed optimization / lack of conditional moves
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26914
[Bug other/26914] missed optimization / lack of conditional moves
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 22:04 --- Conditional move is not always faster. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26914
[Bug libfortran/26712] gfortran on mac intel runtime floating point exception when printing
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2006-03-30 22:04 --- Can someone confirm this issue is now fixed on trunk? I'd then apply the patch to 4.1 as well. And Erik, btw, the assign_2.f90 failure is PR25765. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-30 22:04:44 date|| Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26712
[Bug middle-end/26906] internal compiler error: in do_SUBST, at combine.c:447
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-30 22:01 --- 3.4.x is no longer being updated, can you try 4.0.x or 4.1.0? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal GCC target triplet|armeb-unknown-linux |armeb-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26906
[Bug c++/26905] default-visibility class symbol improperly resolved as hidden-visibility
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-30 22:00 ---
#pragma GCC visibility push(hidden)
struct __attribute__ ((visibility ("default"))) nsINIParser
{
static void Init();
};
__attribute__ ((visibility ("default")))
void
CheckCompatibility(void)
{
nsINIParser::Init();
}
Confirmed, not a regression, with -fPIC this should call a PLT based function
but does not.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|middle-end |c++
Ever Confirmed|0 |1
GCC build triplet|x86_64-unknown-linux-gcc|
GCC host triplet|x86_64-unknown-linux-gcc|
GCC target triplet|x86_64-unknown-linux-gcc|
Keywords||wrong-code
Known to fail||4.0.3 4.1.0 4.2.0
Last reconfirmed|-00-00 00:00:00 |2006-03-30 22:00:53
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26905
[Bug libfortran/26712] gfortran on mac intel runtime floating point exception when printing
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-03-30 22:00 --- Subject: Bug 26712 Author: fxcoudert Date: Thu Mar 30 22:00:21 2006 New Revision: 112546 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112546 Log: PR libfortran/26712 * config/fpu-387.h: Add special case for handling of SSE control bit on i386-darwin. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/config/fpu-387.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26712
[Bug target/26902] missed optimization during x87 args load with inline-asm
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 21:53 --- Note it works correctly without the inline-asm. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Component|other |target Keywords||missed-optimization Summary|missed optimization during |missed optimization during |x87 args load. |x87 args load with inline- ||asm http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26902
[Bug middle-end/26899] Fold does not fold (i0 > i1 + 1) || (i1 < i0 - 1)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26899
[Bug middle-end/26898] Fold does not fold signed + CST1 CMP signed + CST2 where CST1 == CST2
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-30 21:49 --- Confirmed, only when CST1 == CST2 does this work based on: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01746.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-30 21:49:44 date|| Summary|Fold does not fold signed +-|Fold does not fold signed + |CST CMP signed +- CST |CST1 CMP signed + CST2 where ||CST1 == CST2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26898
[Bug bootstrap/26892] Can't compile a 64-bit gcc
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 21:46 --- ld64 warning: in /usr/lib/libiconv.dylib, file does not contain requested architecture ld64 warning: in /usr/lib/libiconv.dylib, file does not contain requested architecture I don't think there is anything GCC can do to fix this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26892
[Bug target/17959] -mpowerpc64 can cause worse code than without it
--- Comment #3 from roger at eyesopen dot com 2006-03-30 21:35 --- This is now be fixed on mainline. With -mpowerpc64, we now generate: _div16: rldimi 3,4,0,32 srdi 4,3,4 srdi 3,3,36 blr -- roger at eyesopen dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17959
[Bug c++/22494] C++ front-end produces mis-match types in EQ_EXPR (array deconstructor)
--- Comment #2 from roger at eyesopen dot com 2006-03-30 21:24 --- This should now be fixed on mainline. -- roger at eyesopen dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22494
[Bug libfortran/26889] selected_int_kind.inc broken, causing failure
--- Comment #38 from quanah at stanford dot edu 2006-03-30 21:18 --- Yeah, I'll give that a shot next week (i'm now in a freeze period). I've also been poking at MPFR. There are apparently 10 or more patches now for 2.2.0, that may resolve the issues, too. I'll look at that. I've rebuilt it, and ran the "check" area for mpfr, and 115/117 tests fail, so I'm guessing there are some serious issues there with MPFR. I've also subscribed to their list, because I can see that until MPFR is no longer busted, gcc isn't going to be working. ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug preprocessor/26857] Warning for absolute or dotted header paths
--- Comment #3 from mbland at google dot com 2006-03-30 21:09 --- Right, I've got a mainline patch now, too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26857
[Bug c++/26950] Error diagnostic not issued for unacceptable result of lookup for a name used in a nested-name-specifier
--- Comment #2 from widman at gimpel dot com 2006-03-30 21:06 ---
Subject: Error diagnostic not issued for unacceptable result of lookup for a
name used in a nested-name-specifier
On Mar 30, 2006, at 2:56 PM, Daveed Vandevoorde wrote:
> Hi James,
>
> On Mar 30, 2006, at 2:31 PM, James Widman wrote:
>
>> [This can probably also be categorized as "low priority".]
>>
>> The GCC and EDG front ends both appear to think that this test
>> case is well-formed:
>>
>> namespace N {
>> const int a = 42;
>> enum N { e0 = N::a };
>> }
>>
>> ... but I think 3.4.3p1 makes it ill-formed.
>
>
> Can you elaborate on that? 3.4.3/1 says:
>
> The name of a class or namespace member can be referred to
> after the :: scope resolution operator (5.1) applied to a
> nested-name-specifier that nominates its class or namespace.
> During the lookup for a name preceding the :: scope resolution
> operator, object, function, and enumerator names are ignored.
> If the name found is not a class-name (clause 9) or
> namespace-name (7.3.1), the program is ill-formed.
>
> So when looking up N in N::a, the "enum N" entry is ignored, and the
> "namespace N" entry is found. "a" is a member of that namespace, and
> it can be used in an integral constant-expression.
>
> Am I missing something?
>
> Daveed Vandevoorde
> Edison Design Group
"enum N" is not an enumerator name; it's an enumeration name (or an /
enum-name/ [7.2p1]), so "enum N" cannot be ignored.
In C (ignoring the namespace N for now), we would say that the
enumeration name N resides in the tag name space (along with the tag
names of structs and unions) and e0 resides in the ordinary name
space (along with the names of functions, variables, and typedef
names -- see C89: 3.1.2.3, C99:6.2.3).
So when I read that excerpt of 3.4.3/1, I thought to myself:
"During the lookup for a name preceding the :: scope resolution
operator, ordinary names are ignored, except that typedef names and
namespace names are considered."
... with the implication being that tag names (including the names of
classes, unions, and enumerations) are considered without exception.
>> I also reported this to:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26950
>>
>> MSVC (6 through 8) and Borland 5.6 appear to treat the enum-name
>> as hiding the namespace name during lookup for the nested-name-
>> specifier.
>>
>> James Widman
>> --
>> Gimpel Software
>> http://gimpel.com
>>
>>
>
James Widman
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26950
[Bug target/26877] configure switches --with-arch and --with-tune are broken on x86
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|trivial |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26877
[Bug preprocessor/26857] Warning for absolute or dotted header paths
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-30 20:12 --- Confirmed, just a note, all patches need to go on the mainline before even thinking about being backported. (Yes I know how long the copyright issues are because I am trying to get my fixed up too). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|N/A | GCC host triplet|N/A | GCC target triplet|N/A | Last reconfirmed|-00-00 00:00:00 |2006-03-30 20:12:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26857
[Bug rtl-optimization/26855] [4.2 Regression] ICE in add_deps_for_def with -fmodulo-sched -maltivec
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-30 20:11:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26855
[Bug middle-end/26853] [4.2 Regression] ACATS c43212a failure at runtime
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26853
[Bug rtl-optimization/26847] [4.2 Regression] Missed optimization in simplify_plus_minus
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 20:09 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-30 20:09:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26847
[Bug middle-end/26823] ICE with OpenMP in add_stmt_to_eh_region_fn, at tree-eh.c:100
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 20:04 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-30 20:04:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26823
[Bug c++/26950] Error diagnostic not issued for unacceptable result of lookup for a name used in a nested-name-specifier
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 20:02 --- Hmm, Comeau C++ does not reject this code either (but that does not mean this is not invalid code). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26950
[Bug rtl-optimization/26945] [3.4/4.0/4.1 regression] Attempt to delete prologue/epilogue insn
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-30 19:59 --- I am starting to think we should change a[outofbounds] = 1 to be an __builtin_trap() so that we will not run into stuff like this again. Also we should have a keyword for ice-on-undefined-code too :). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor GCC build triplet|hppa-unknown-linux | GCC host triplet|hppa-unknown-linux | Keywords|ice-on-valid-code | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26945
[Bug rtl-optimization/26942] Code generation bug -freorder-blocks-and-partition
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-30 19:57 --- This has nothing to do with -fprofile-use and all to do with -freorder-blocks-and-partition -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|Code generation bug (- |Code generation bug - |fprofile-use) |freorder-blocks-and- ||partition http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26942
[Bug c++/17353] type name in nested class conflicts with name in outer class
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-30 19:55 --- *** Bug 26940 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||v dot haisman at sh dot cvut ||dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17353
[Bug c++/26940] C++ name space issue
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 19:55 --- This is actually invalid code which the C++ standard says implementions don't have to error out about. *** This bug has been marked as a duplicate of 17353 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26940
[Bug target/26879] LibJava not compile under alpha
--- Comment #9 from zerocool at modemsoft dot it 2006-03-30 19:31 --- Hello Mathew, i have tried to perform your indications, but without success; with a lot of probability because of my little competence in matter. I would pray you, considering that I have posted the build complete log, if reading it, you succeed in giving me some more precise indication. Thanks for the patience and understanding Regards ! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26879
[Bug target/26879] LibJava not compile under alpha
--- Comment #8 from zerocool at modemsoft dot it 2006-03-30 19:28 --- Created an attachment (id=11169) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11169&action=view) The Gcc Build Log It's My build log... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26879
[Bug c++/26950] New: Error diagnostic not issued for unacceptable result of lookup for a name used in a nested-name-specifier
The following should elicit an error during processing of e0's initializer:
namespace N {
const int a = 42;
enum N { e0 = N::a };
}
... because 3.4.3p1 [basic.lookup.qual] indicates that the enumeration [tag]
name N should be found during lookup in the nested-name-specifier and renders
the program ill-formed.
--
Summary: Error diagnostic not issued for unacceptable result of
lookup for a name used in a nested-name-specifier
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: widman at gimpel dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26950
[Bug libfortran/26889] selected_int_kind.inc broken, causing failure
--- Comment #37 from ebotcazou at gcc dot gnu dot org 2006-03-30 18:48 --- > From the GMP 4.2 NEWS file: > > Mis-features: > * mpfr is gone, and will from now on be released only separately. Please > see > www.mpfr.org. Grumpf... Could you downgrade to 4.1.x then? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug target/26949] New: [4.2 regression] worse code generated for -march=pentium4
Compiling the code in PR26944 with -O2 -march=pentium4 -fno-tree-ch generates this for the loop: .L3: movl%esi, -4(%eax) addl$1, %edx addl$4, %eax cmpl-16(%ebp), %edx <- note an extra memory access here jle .L3 compiling for -march=i686 (or even just adding -fomit-frame-pointer) generates: .L3: addl$1, %ecx movl%ebx, -4(%edx) addl$4, %edx cmpl%eax, %ecx < no memory access here jle .L3 The above problem does not happen with gcc-4.0.3 or 4.1.0 -- Summary: [4.2 regression] worse code generated for - march=pentium4 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dann at godzilla dot ics dot uci dot edu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26949
[Bug tree-optimization/26948] ICE: tree check: expected ssa_name, have struct_field_tag in is_old_name, at tree-into-ssa.c:466
--- Comment #1 from micis at gmx dot de 2006-03-30 18:13 --- Created an attachment (id=11168) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11168&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26948
[Bug tree-optimization/26948] New: ICE: tree check: expected ssa_name, have struct_field_tag in is_old_name, at tree-into-ssa.c:466
With the actual snapshot (gcc-4.2-20060325) I get the ICE: tree check: expected ssa_name, have struct_field_tag in is_old_name, at tree-into-ssa.c:466 Michael Cieslinski g++42f -O1 -msse2 -mfpmath=sse -ftree-vectorize -c in.ii -S -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.2-20060325/configure --prefix=/usr/local/gcc42f --program-suffix=42f --with-arch=opteron --enable-languages=c,c++ --enable-__cxa_atexit --disable-nls --enable-threads=posix --disable-multilib --enable-checking Thread model: posix gcc version 4.2.0 20060325 (experimental) /usr/local/gcc42f/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/cc1plus -fpreprocessed in.ii -quiet -dumpbase in.ii -msse2 -mfpmath=sse -march=opteron -auxbase in -O1 -version -ftree-vectorize -o in.s GNU C++ version 4.2.0 20060325 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.2.0 20060325 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: b091679bfe10b065fa639aec2f0c7166 in.ii: In function 'EVT MatchDeadPix(int, MatchDeadPixParType, long int)': in.ii:49: internal compiler error: tree check: expected ssa_name, have struct_field_tag in is_old_name, at tree-into-ssa.c:466 Please submit a full bug report, with preprocessed source if appropriate. -- Summary: ICE: tree check: expected ssa_name, have struct_field_tag in is_old_name, at tree-into-ssa.c:466 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: micis at gmx dot de 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=26948
[Bug libfortran/26889] selected_int_kind.inc broken, causing failure
--- Comment #36 from quanah at stanford dot edu 2006-03-30 17:48 --- Just to note, if I haven't already, I was able to build gcc 4.0.3 with GMP 4.2 and MPFR 2.2.0 on i386 and amd64 without a problem (including fortran), so this seems to be a problem specific to Solaris 8/9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug target/17959] -mpowerpc64 can cause worse code than without it
--- Comment #2 from sayle at gcc dot gnu dot org 2006-03-30 17:47 --- Subject: Bug 17959 Author: sayle Date: Thu Mar 30 17:47:48 2006 New Revision: 112543 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112543 Log: PR target/17959 * expr.c (emit_group_store): Optimize group stores into a pseudo register by using a paradoxical subreg to initialize the destination if the first or last member of the group specifies a "low part". Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17959
[Bug libfortran/26889] selected_int_kind.inc broken, causing failure
--- Comment #35 from quanah at stanford dot edu 2006-03-30 17:40 --- >From the GMP 4.2 NEWS file: Mis-features: * mpfr is gone, and will from now on be released only separately. Please see www.mpfr.org. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug libfortran/26889] selected_int_kind.inc broken, causing failure
--- Comment #34 from ebotcazou at gcc dot gnu dot org 2006-03-30 17:35 --- > Program received signal SIGSEGV, Segmentation fault. > 0x0035c398 in mpfr_set_default_prec () > (gdb) bt > #0 0x0035c398 in mpfr_set_default_prec () OK. Could you ditch MPFR 2.2.0 entirely and use the MPFR library bundled with GMP 4.2? The configure line for GMP is on the Solaris build instructions page. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug libfortran/26889] selected_int_kind.inc broken, causing failure
--- Comment #33 from quanah at stanford dot edu 2006-03-30 17:17 --- GDB shows: GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.8"... (gdb) run Starting program: /afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_58/gcc/f951 Program received signal SIGSEGV, Segmentation fault. 0x0035c398 in mpfr_set_default_prec () (gdb) bt #0 0x0035c398 in mpfr_set_default_prec () #1 0x0001496c in gfc_arith_init_1 () at ../../../gcc-4.0.3/gcc/fortran/arith.c:180 #2 0x0003e730 in gfc_init_1 () at ../../../gcc-4.0.3/gcc/fortran/misc.c:287 #3 0x0005d7d4 in gfc_init () at ../../../gcc-4.0.3/gcc/fortran/f95-lang.c:292 #4 0x00281514 in toplev_main (argc=Variable "argc" is not available. ) at ../../../gcc-4.0.3/gcc/toplev.c:2019 #5 0x000118d4 in .nope () #6 0x000118d4 in .nope () -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug tree-optimization/21829] [4.1/4.2 Regression] missed jump threading after unroller
--- Comment #14 from law at redhat dot com 2006-03-30 17:15 --- Just a note on the compile-time regressions for tramp3d... After fixing the timevars it was pretty clear that it isn't the cprop code itself that is slow, it is in fact very fast. THe slowdowns for tramp3d are in operand scanning and incremental SSA updates. I built a little instrumentation code and was rewarded with some insight into why tramp3d behaves differently for operand scanning. When we propagate into a statement, we (of course) fold and rescan the operands for the use statement. Clearly if we propagate several distinct copies into a single use statement, then we end up wasting time rescanning the use statement. My instrumentation recorded how often we perform more than one propagation into a statement vs how often we only propagate into a statement one time. In my test bucket that ratio is a little less than 1:1. I would have expected significantly smaller, but it is what it is. What's interesting is that for tramp3d that ratio is about 3:1 -- primarily from copy propagating into VUSE and V_MAY_DEF operands. I'm currently experimenting with some code to queue folding/rescanning of use statements in cases where there's a reasonable chance we're going to do more than one propagation into the statement. Initial experiments are showing a measurable compile-time improvement for both tramp3d as well as my testbucket. [ Note that Diego's memory tag rewrite work may make all this moot one day... ] Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21829
[Bug libfortran/26889] selected_int_kind.inc broken, causing failure
--- Comment #32 from quanah at stanford dot edu 2006-03-30 17:10 --- Okay, I created the following file (as is generated by the script): solaris8-build:/tmp> cat /tmp/q1.f90 integer (kind=1) :: x end Then ran the build command on it as is done by the script: /afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_58/gcc/gfortran -B/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_58/gcc/ -B/usr/pubsw/sparc-sun-solaris2.8/bin/ -B/usr/pubsw/sparc-sun-solaris2.8/lib/ -isystem /usr/pubsw/sparc-sun-solaris2.8/include -isystem /usr/pubsw/sparc-sun-solaris2.8/sys-include -I . -Wall -fno-repack-arrays -fno-underscoring /tmp/q1.f90 and I get: :0: internal compiler error: Segmentation Fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. so the compiler is completely flailing on this. :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug libfortran/26889] selected_int_kind.inc broken, causing failure
--- Comment #31 from ebotcazou at gcc dot gnu dot org 2006-03-30 16:52 --- > No errors or anything... It just spits out the broken bits. OK. Could you then break apart the script and run the various pieces manually? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug java/26042] ICE in mark_reference_fields, at java/boehm.c:105
--- Comment #12 from tromey at gcc dot gnu dot org 2006-03-30 16:49 --- I checked the fix into the 4.1 branch and the trunk. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042
[Bug libfortran/26889] selected_int_kind.inc broken, causing failure
--- Comment #30 from quanah at stanford dot edu 2006-03-30 16:48 --- Here is what happens when I run it by hand: solaris8-build:/afs/ir/src/pubsw/languages/gcc-build/sun4x_58/sparc-sun-solaris2.8/libgfortran> /bin/ksh ../../../../gcc-4.0.3/libgfortran/mk-sik-inc.sh '/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_58/gcc/gfortran -B/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_58/gcc/ -B/usr/pubsw/sparc-sun-solaris2.8/bin/ -B/usr/pubsw/sparc-sun-solaris2.8/lib/ -isystem /usr/pubsw/sparc-sun-solaris2.8/include -isystem /usr/pubsw/sparc-sun-solaris2.8/sys-include -I . -Wall -fno-repack-arrays -fno-underscoring ' integer, parameter :: c = 0 type (int_info), parameter :: int_infos(c) = (/ & No errors or anything... It just spits out the broken bits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug java/26042] ICE in mark_reference_fields, at java/boehm.c:105
--- Comment #11 from tromey at gcc dot gnu dot org 2006-03-30 16:47 --- Subject: Bug 26042 Author: tromey Date: Thu Mar 30 16:47:23 2006 New Revision: 112541 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112541 Log: gcc/java PR java/26042: * parse.y (java_reorder_fields): Reset superclass field's size as well. libjava PR java/26042: * testsuite/libjava.compile/pr26042.java: New file. Added: branches/gcc-4_1-branch/libjava/testsuite/libjava.compile/pr26042.java - copied unchanged from r112540, trunk/libjava/testsuite/libjava.compile/pr26042.java Modified: branches/gcc-4_1-branch/gcc/java/ChangeLog branches/gcc-4_1-branch/gcc/java/parse.y branches/gcc-4_1-branch/libjava/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042
[Bug tree-optimization/26944] [4.1/4.2 Regression] -ftree-ch generates worse code
--- Comment #2 from dann at godzilla dot ics dot uci dot edu 2006-03-30 16:43 --- (In reply to comment #1) > Note that this may be also PRE confusing SCEV in presence of loop headers. Talking about PRE, here's a maybe interesting observation in the PRE dump: :; pretmp.30_53 = Int_Loc.0_4 * 200; pretmp.32_23 = (int[50] *) pretmp.30_53; pretmp.32_11 = pretmp.32_23 + Arr_2_Par_Ref_30; goto (); :; pretmp.27_59 = Int_Loc.0_4 * 200; pretmp.28_45 = (int[50] *) pretmp.27_59; pretmp.28_49 = Arr_2_Par_Ref_30 + pretmp.28_45; # Int_Index_37 = PHI ; :; D.1544_54 = pretmp.27_59; D.1545_55 = pretmp.28_45; D.1546_56 = pretmp.28_49; (*D.1546_56)[Int_Index_37] = Int_Loc_3; Int_Index_58 = Int_Index_37 + 1; if (D.1548_41 >= Int_Index_58) goto ; else goto ; :; goto (); :; # prephitmp.33_40 = PHI ; # prephitmp.33_18 = PHI ; # prephitmp.31_25 = PHI ; Compare pretmp.28_49 with pretmp.32_11, why are the arguments in a different order? Is there something unstable in the PRE algorithm? One has to wonder what are the tree-ch effects on more complex loops. It might be interesting test SPEC with and without tree-ch... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26944
[Bug java/26042] ICE in mark_reference_fields, at java/boehm.c:105
--- Comment #10 from tromey at gcc dot gnu dot org 2006-03-30 16:39 --- Subject: Bug 26042 Author: tromey Date: Thu Mar 30 16:39:17 2006 New Revision: 112540 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112540 Log: gcc/java PR java/26042: * parse.y (java_reorder_fields): Reset superclass field's size as well. libjava PR java/26042: * testsuite/libjava.compile/pr26042.java: New file. Added: trunk/libjava/testsuite/libjava.compile/pr26042.java Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/parse.y trunk/libjava/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042
[Bug rtl-optimization/26945] [3.4/4.0/4.1 regression] Attempt to delete prologue/epilogue insn
--- Comment #2 from tausq at debian dot org 2006-03-30 16:31 --- The code is valid syntactically, but there is actually a bug. the longoptions array only has 3 elements, but we try to fill in 4 entries. if we make the longoptions array bigger than it doesn't cause the ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26945
[Bug fortran/25031] Allocatable array can be reallocated.
--- Comment #5 from tkoenig at gcc dot gnu dot org 2006-03-30 16:30 --- Subject: Bug 25031 Author: tkoenig Date: Thu Mar 30 16:30:26 2006 New Revision: 112539 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112539 Log: 2006-03-30 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/25031 * runtime/memory.c (allocate_array): If stat is present and the variable is already allocated, free the variable, do the allocation and set stat. (allocate_array_64): Likewise. Whitespace fix. 2006-03-30 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/25031 * gfortran.dg/multiple_allocation_1.f90: Check that the size has changed after a re-allocation with stat. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/multiple_allocation_1.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/runtime/memory.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25031
[Bug rtl-optimization/26945] [3.4/4.0/4.1 regression] Attempt to delete prologue/epilogue insn
--- Comment #1 from tausq at debian dot org 2006-03-30 16:28 --- Created an attachment (id=11167) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11167&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26945
[Bug rtl-optimization/26945] New: [3.4/4.0/4.1 regression] Attempt to delete prologue/epilogue insn
Compile attached test case with optimization causes an ICE: $ gcc -c -O1 bug.c bug.c: In function 'parsearguments': bug.c:46: error: Attempt to delete prologue/epilogue insn: (insn/f 97 96 98 0 (set (mem:SI (plus:SI (reg/f:SI 30 %r30) (const_int -124 [0xff84])) [0 S4 A32]) (reg:SI 4 %r4)) -1 (nil) (nil)) bug.c:46: internal compiler error: in propagate_one_insn, at flow.c:1690 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see . This may be related to PR12535 but the code that triggers the problem is different. -- Summary: [3.4/4.0/4.1 regression] Attempt to delete prologue/epilogue insn Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tausq at debian dot org GCC build triplet: hppa-unknown-linux GCC host triplet: hppa-unknown-linux GCC target triplet: hppa-unknown-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26945
[Bug tree-optimization/26944] [4.1/4.2 Regression] -ftree-ch generates worse code
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-30 16:25 --- Note that this may be also PRE confusing SCEV in presence of loop headers. I.e. a sort of dup of PR26939. Confirmed though. A regression from 4.0.3, which is also fine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||26939 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|i686-pc-linux-gnu | Keywords||missed-optimization Known to work||4.0.3 Last reconfirmed|-00-00 00:00:00 |2006-03-30 16:25:17 date|| Summary|-ftree-ch generates worse |[4.1/4.2 Regression] -ftree- |code|ch generates worse code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26944
[Bug libfortran/26712] gfortran on mac intel runtime floating point exception when printing
--- Comment #8 from schnetter at aei dot mpg dot de 2006-03-30 16:18 --- I had the same problem. I replaced this file, ran the test cases, and sent the results. The summary is === gfortran Summary === # of expected passes12636 # of unexpected failures1 # of expected failures 7 # of unsupported tests 46 /Users/eschnett/src/gcc-build/gcc/testsuite/gfortran/../../gfortran version 4.2 .0 20060329 (experimental) with the unexpected failure FAIL: gfortran.dg/assign_2.f90 -O0 (test for excess errors) WARNING: gfortran.dg/assign_2.f90 -O0 compilation failed to produce executable which seems unrelated to me after looking at the source code and error message of that file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26712
[Bug tree-optimization/26944] New: -ftree-ch generates worse code
The loop from the code below is compiled to this when using gcc-4.1 -O2
.L5:
movl16(%ebp), %eax
addl%ecx, %eax
addl$1, %ecx
movl%edx, 20(%ebx,%eax,4)
leal(%edx,%ecx), %eax
cmpl%edi, %eax
jle .L5
but the code is much better when using gcc -fno-tree-ch -O2
.L3:
addl$1, %ecx
movl%ebx, -4(%edx)
addl$4, %edx
cmpl%eax, %ecx
jle .L3
This is a regression as gcc-3.4.3 generates similar code.
The code is from the Dhrystone as included in Unixbench.
The regression is quite important as embedded processor people still use
Dhrystone for benchmarking compiler/processor speed.
Its strange that tree-ch messes up, the loop is about as simple as loops can
get.
typedef int One_Fifty;
typedef int Arr_1_Dim [50];
typedef int Arr_2_Dim [50] [50];
extern int Int_Glob;
void Proc_8 (Arr_1_Par_Ref, Arr_2_Par_Ref, Int_1_Par_Val, Int_2_Par_Val)
Arr_1_Dim Arr_1_Par_Ref;
Arr_2_Dim Arr_2_Par_Ref;
int Int_1_Par_Val;
int Int_2_Par_Val;
{
register One_Fifty Int_Index;
register One_Fifty Int_Loc;
Int_Loc = Int_1_Par_Val + 5;
Arr_1_Par_Ref [Int_Loc] = Int_2_Par_Val;
Arr_1_Par_Ref [Int_Loc+1] = Arr_1_Par_Ref [Int_Loc];
Arr_1_Par_Ref [Int_Loc+30] = Int_Loc;
for (Int_Index = Int_Loc; Int_Index <= Int_Loc+1; ++Int_Index)
Arr_2_Par_Ref [Int_Loc] [Int_Index] = Int_Loc;
Arr_2_Par_Ref [Int_Loc] [Int_Loc-1] += 1;
Arr_2_Par_Ref [Int_Loc+20] [Int_Loc] = Arr_1_Par_Ref [Int_Loc];
Int_Glob = 5;
}
Intel's compiler generates even tighter code:
..B1.7: # Preds ..B1.10 ..B1.7
movl %ebx, (%ecx,%edx,4) #20.5
addl $1, %edx #19.55
cmpl %eax, %edx#19.3
jle ..B1.7# Prob 80% #19.3
--
Summary: -ftree-ch generates worse code
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26944
[Bug c++/26943] [gomp] firstprivate not working properly with non-POD
--- Comment #1 from rth at gcc dot gnu dot org 2006-03-30 15:56 --- Created an attachment (id=11166) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11166&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26943
[Bug c++/26943] New: [gomp] firstprivate not working properly with non-POD
Two problems here. The first was trying to show that we don't necessarily honor the requirement that all firstprivate copies are executed before the lastprivate assignment happens. The second is that we're not properly substituting for the global X here within the scope of the privatization. -- Summary: [gomp] firstprivate not working properly with non-POD Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code, openmp Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26943
[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector
--- Comment #32 from mckinlay at redhat dot com 2006-03-30 15:51 --- (In reply to comment #31) Yes, this patch should fix all the OpenOffice issues. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
[Bug tree-optimization/26830] [4.1/4.2 Regression] Insane amount of compile-time / memory needed at -O1 and above
--- Comment #23 from rguenth at gcc dot gnu dot org 2006-03-30 15:49 --- Note that the regression is in 4.1, too, so we should consider backporting changes that accumulate here to the branch after a while. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector
--- Comment #31 from rguenth at gcc dot gnu dot org 2006-03-30 15:48 --- How did you test the patch with OpenOffice? Are there OpenOffice modifications necessary? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
[Bug target/26734] [4.2 Regression] GCC cannot bootstrap on IA64 HP-UX
--- Comment #12 from mkuvyrkov at gcc dot gnu dot org 2006-03-30 15:43 --- The patch was reapplied: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01721.html -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26734
[Bug target/26734] [4.2 Regression] GCC cannot bootstrap on IA64 HP-UX
--- Comment #11 from mkuvyrkov at gcc dot gnu dot org 2006-03-30 15:41 --- Subject: Bug 26734 Author: mkuvyrkov Date: Thu Mar 30 15:41:00 2006 New Revision: 112538 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112538 Log: 2006-03-30 Maxim Kuvyrkov <[EMAIL PROTECTED]> PR target/26734 * rtl.def (DEPS_LIST): Change type of the second operand to 'int'. * target.h (struct gcc_target.speculate_insn): Change type of the second parameter to 'int'. * lists.c (alloc_DEPS_LIST): Change signature. Update reference to the second operand of the DEPS_LIST. (copy_DEPS_LIST_list): Update reference to the second operand of the DEPS_LIST. * rtl.h (alloc_DEPS_LIST): Update signature. * sched-int.h (ds_t): Change typedef to 'int'. (DEP_STATUS, BITS_PER_DEP_STATUS): Update. Modified: trunk/gcc/ChangeLog trunk/gcc/lists.c trunk/gcc/rtl.def trunk/gcc/rtl.h trunk/gcc/sched-int.h trunk/gcc/target.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26734
[Bug tree-optimization/26939] PRE confuses loop number of iterations analysis
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-03-30 15:29 --- Just for the record, the attached patch bootstrapped and regtested on x86_64-unknown-linux-gnu, with the following fallout: FAIL: gcc.dg/tree-ssa/loadpre4.c scan-tree-dump-times Eliminated: 1 1 FAIL: gcc.dg/tree-ssa/loadpre6.c scan-tree-dump-times Eliminated: 2 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26939
