[Bug fortran/25818] Problem with handling optional and entry master arguments
--- Comment #5 from taschna at uni-muenster dot de 2006-07-31 07:49 --- (In reply to comment #3) Steve, > [...]It's more a question of "why is it a NULL pointer?" not > whether we can work around the NULL pointer. i finally found Paul's mail corresponding to patch revision 86128: http://gcc.gnu.org/ml/fortran/2004-08/msg00102.html There he explains the presence of the NULL: > For each entry point we generate a thunk function which tailcalls the master > functions, passing NULL for any arguments which don't exist for that > function. That seems to be the reason for his change in * trans-array.c (gfc_trans_dummy_array_bias): Treat all args as optional when multiple entry points are present. which I copied for my patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25818
[Bug c++/28514] [4.2 Regression] libstdc++ vs. anonymous namespaces
--- Comment #7 from jason at gcc dot gnu dot org 2006-07-31 08:16 --- The testcase gives the same errors for me when compiled as normal C++ as in PCH mode. The problem seems to be that you're removing the Rope_constants namespace name and creating a name lookup collision between the _S_concat enumerator and the _S_concat function in rope. Why would you want to mess with Rope_constants, anyway? It doesn't have any symbols in it, it just controls name lookup. When you take it away, name lookup changes, and things blow up. Moving them to the anonymous namespace has the same effect for name lookup as declaring them directly in __gnu_cxx. Furthermore, defining _Tag in an anonymous namespace will cause the compiler to give all functions with _Tag in their signature internal linkage. I don't understand why you would want this. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28514
[Bug c++/28514] [4.2 Regression] libstdc++ vs. anonymous namespaces
--- Comment #8 from jason at gcc dot gnu dot org 2006-07-31 08:20 --- In general, I think using the anonymous namespace in headers is not what you want. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28514
[Bug middle-end/28545] [4.1 Regression] Wrong code for hoisted multiplication
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-07-31 08:23 --- 4.0.3 works. (also does gcc 4.1.0 + patches as shipped with suse 10.1) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Known to fail|4.1.1 |4.1.0 4.1.1 Known to work|4.2.0 |4.2.0 4.0.3 Summary|[4.1 only] Wrong code for |[4.1 Regression] Wrong code |hoisted multiplication |for hoisted multiplication http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28545
[Bug libgcj/16990] [meta-bug] TimeZone Issues in libgcj/classpath
--- Comment #2 from andrew at operationaldynamics dot com 2006-07-31 08:48 --- TimeZone parsing, formatting, and default (aka "localtime") issues reported in bug 28549 and bug 28550 AfC -- andrew at operationaldynamics dot com changed: What|Removed |Added BugsThisDependsOn||28549, 28550 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16990
[Bug debug/28518] Single stepping until exit ...
--- Comment #5 from alex dot jacob at logicacmg dot com 2006-07-31 09:27 --- Hi, I'm just using -gno optimisations. Cheers, Alex -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28518
[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)
--- Comment #6 from jason at gcc dot gnu dot org 2006-07-31 09:38 --- Created an attachment (id=11978) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11978&action=view) libstdc++ patch to allow catching forced unwind separately Trying to move this issue forward: here's a libsupc++ patch that allows users to detect forced unwind using a magic class. This is a little ugly, as there isn't actually an object for the catch parameter to bind to. It should also be discussed with the C++ ABI committee; I notice that the ABI EH document still says that you can't catch forced unwind (like Ada). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28145
[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)
--- Comment #7 from jason at gcc dot gnu dot org 2006-07-31 09:40 --- Created an attachment (id=11979) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11979&action=view) NPTL patch to allow discarding cancellation exception And here's a completely untested patch to NPTL to implement the "sticky cancel" semantics I've talked about; discarding the forced unwind exception causes the exiting bit to be unset, so that the next cancellation point starts unwinding again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28145
[Bug target/28490] [4.0/4.1/4.2 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088
--- Comment #7 from tbm at cyrius dot com 2006-07-31 11:29 --- This bug is also present in gcc 4.0 and 4.1 even though my original testcase didn't expose it there. My new one does: [EMAIL PROTECTED]:~$ gcc-4.0 -c -O ecl-asdf.c ecl-asdf.c: In function 'LC67traverse': ecl-asdf.c:81: internal compiler error: in ia64_expand_move, at config/ia64/ia64.c:1004 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 . [EMAIL PROTECTED]:~$ gcc-4.1 -c -O ecl-asdf.c ecl-asdf.c: In function 'LC67traverse': ecl-asdf.c:81: internal compiler error: in ia64_expand_move, at config/ia64/ia64.c:1052 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 . Preprocessed source stored into /tmp/ccQbxgpQ.out file, please attach this to your bugreport. [EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O ecl-asdf.c ecl-asdf.c: In function 'LC67traverse': ecl-asdf.c:81: internal compiler error: in ia64_expand_move, at config/ia64/ia64.c:1088 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. This is with: 4.0.4 20060630 4.1.2 20060715 4.2.0 20060721 -- tbm at cyrius dot com changed: What|Removed |Added Known to fail|4.2.0 |4.0.3 4.1.1 4.2.0 Known to work|4.0.3 4.1.1 |3.3.6 3.4.6 Summary|[4.2 regression] ICE in |[4.0/4.1/4.2 regression] ICE |ia64_expand_move, at|in ia64_expand_move, at |config/ia64/ia64.c:1088 |config/ia64/ia64.c:1088 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
[Bug target/28490] [4.0/4.1/4.2 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088
--- Comment #8 from tbm at cyrius dot com 2006-07-31 11:30 --- Created an attachment (id=11980) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11980&action=view) test case for 4.0, 4.1 and 4.2 Testcase from application "ecl". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
[Bug target/28490] [4.0/4.1/4.2 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-07-31 12:20 ---
Reduced testcase from comment #8
typedef union cl_lispunion *cl_object;
union cl_lispunion { cl_object cons; };
typedef union { cl_object data; } cl_symbol_initializer;
extern cl_symbol_initializer cl_symbols[];
extern void cl_funcall (cl_object);
extern int _setjmp(vois);
void LC67traverse (cl_object *lex0)
{
cl_object T0;
cl_funcall ((cl_object) (cl_symbols + 1));
if (_setjmp ())
;
if (lex0[0] == (cl_object) cl_symbols)
goto L791;
T0 = ((cl_object) (cl_symbols + 1));
L791:;
cl_funcall (T0);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
[Bug c++/28236] wrong "control reaches" warning with enums.
--- Comment #3 from pluto at agmk dot net 2006-07-31 14:35 ---
one more testcase that renders different warning.
typedef enum { X, Y } e;
e zoo( e __e )
{
e r;
switch ( __e )
{
case X: r = Y; break;
case Y: r = X; break;
}
return r;
}
bug.cpp: In function 'e zoo(e)':
bug.cpp:4: warning: 'r' may be used uninitialized in this function
e zoo(e) (__e)
{
e r;
e D.2076;
int __e.0;
:
switch ((int) __e)
{
case 0: goto ;
case 1: goto ;
default : goto ;
}
:;
r = 0;
goto ();
:;
goto ();
:;
r = 1;
:;
return r;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28236
[Bug middle-end/28417] suboptimal 'division by constant' optimization
--- Comment #8 from amylaar at gcc dot gnu dot org 2006-07-31 14:39 --- (In reply to comment #3) > Too bad there are no comments how the code works, what is mlow and mhigh. Tege has written a paper: http://swox.se/~tg/divcnst-pldi94.pdf Also, you might consider adding him to the CC list of this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28417
[Bug c++/28236] wrong "control reaches" warning with enums.
--- Comment #4 from pluto at agmk dot net 2006-07-31 14:41 --- so, -Werror is useless now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28236
[Bug target/28551] New: libgcc.a being generated in improper format for powerpc-eabi cross
2006-07-31 under KDE 3.4.0 Overview: When compiling trivial code with a gcc4.1.1 i686 to powerpc-eabi cross compiler and specifying -msim, I am getting a "could not read symbols: File format not recognized" error with libgcc.a. Details: Upon further research and experimentation of my problem case in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28133>28133 I'm still running into what may be a compiler issue. I'm currently trying to make a c cross-compiler from i686 to powerpc-eabi to test code in PSIM against a powerpc development board. I am using the usual steps- 1. build binutils (2.15, which is the most recent version I can build on the shared academic machine I'm using without building a whole new native gcc) 2. build a stripped-down gcc (4.1.1, the most recent as of the start of the project) 3. compile newlib (1.14.0) 4. build full gcc 1 and 2 go fine, but when I try to build anything with the stripped-down gcc I get libgcc.a(eabi.o)undefined symbol errors (see below) when I don't specify a target (eg -msim, -mads, ...) and File Format Not Recognized errors (see below) when I use -msim. The same problem appears to be http://sources.redhat.com/ml/gdb/2005-11/msg00639.html>documented by Barry Wealand for gcc3.4.4. I will continue to poke and investigate my case to see if it's just something stupid in my configuration, but even if the issue is only lack of -msim and an inadvertent library mistargeting, I've seen a few other reported cases where lack of a -mtarget has been a non-obvious roadblock, so it might be worth setting up a default target for embedded cross-compilation that is compatible with the default libgcc.a format. - output without -msim: powerpc-unknown-eabi-gcc arithtest.c /scratch/spkelly/ppcbin/lib/gcc/powerpc-unknown-eabi/4.1.1/../../../../powerpc-unknown-eabi/bin/ld: warning: cannot find entry symbol _start; defaulting to 01800074 /scratch/spkelly/ppcbin/lib/gcc/powerpc-unknown-eabi/4.1.1/libgcc.a(eabi.o)(.text+0xc4): In function `__eabi': /scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:232: undefined reference to `__init' /scratch/spkelly/ppcbin/lib/gcc/powerpc-unknown-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0x8):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:146: undefined reference to `__SDATA_START__' /scratch/spkelly/ppcbin/lib/gcc/powerpc-unknown-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0xc):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:148: undefined reference to `__SBSS_END__' /scratch/spkelly/ppcbin/lib/gcc/powerpc-unknown-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0x14):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:150: undefined reference to `__SDATA2_START__' /scratch/spkelly/ppcbin/lib/gcc/powerpc-unknown-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0x18):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:151: undefined reference to `__SBSS2_END__' /scratch/spkelly/ppcbin/lib/gcc/powerpc-unknown-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0x1c):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:152: undefined reference to `__GOT_START__' /scratch/spkelly/ppcbin/lib/gcc/powerpc-unknown-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0x28):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:155: undefined reference to `__GOT_END__' /scratch/spkelly/ppcbin/lib/gcc/powerpc-unknown-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0x2c):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:156: undefined reference to `__GOT2_START__' /scratch/spkelly/ppcbin/lib/gcc/powerpc-unknown-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0x30):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:157: undefined reference to `__GOT2_END__' /scratch/spkelly/ppcbin/lib/gcc/powerpc-unknown-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0x34):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:158: undefined reference to `__FIXUP_START__' /scratch/spkelly/ppcbin/lib/gcc/powerpc-unknown-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0x38):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:159: undefined reference to `__FIXUP_END__' /scratch/spkelly/ppcbin/lib/gcc/powerpc-unknown-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0x3c):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:163: undefined reference to `__CTOR_LIST__' /scratch/spkelly/ppcbin/lib/gcc/powerpc-unknown-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0x40):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:164: undefined reference to `__CTOR_END__' /scratch/spkelly/ppcbin/lib/gcc/powerpc-unknown-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0x44):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:165: undefined reference to `__DTOR_LIST__' /scratch/spkelly/ppcbin/lib/gcc/powerpc-unknown-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0x48):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:166: undefined reference to `__DTOR_END__' /scratch/spkelly/ppcbin/lib/gcc/powerpc-unknown-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0x4c):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:167: undefined reference to `__EXCEPT_START__' /scratch/spkelly/ppcbin/lib/gcc/powerpc-unknown-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0x50):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:171: undefined reference to `__EXCEPT_END__' collect2: ld returned 1 exit status - output with -msim: powerpc-unknown-eabi-gcc -ms
[Bug bootstrap/28133] Cross-compile of GCC fails with "C compiler cannot create executables" error
--- Comment #3 from spkelly at andrew dot cmu dot edu 2006-07-31 14:51 --- My bug has been further probed, wholely separated from 25035, and submitted independently as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28551 Don't bother investigating it as part of 25035 or 28133. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28133
[Bug target/28551] libgcc.a being generated in improper format for powerpc-eabi cross
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-31 14:52 --- If you want to use powerpc-eabi with the simulator, you to configure it as such. powerpc-eabisim is the correct target for the powerpc-eabi simulator. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28551
[Bug target/28551] libgcc.a being generated in improper format for powerpc-eabi cross
--- Comment #2 from spkelly at andrew dot cmu dot edu 2006-07-31 15:11 --- (In reply to comment #1) > If you want to use powerpc-eabi with the simulator, you to configure it as > such. > > powerpc-eabisim is the correct target for the powerpc-eabi simulator. > Will try. Thanks. I figured user error was a likely candidate :) Leaving the bug open ~just in case~ there's something wrong beyond configuration target, but it can probably be considered fixed. I'll update with success/failure once I've recompiled everything. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28551
[Bug rtl-optimization/28221] [4.1 regression] ICE in add_insn_before, at emit-rtl.c:3479
--- Comment #10 from sje at cup dot hp dot com 2006-07-31 16:19 --- My weekend bootstrapping and testing on ia64-hp-hpux11.23 and ia64 Linux on the 4.1 branch showed no regressions. I think I should send email to gcc-patches before checking it in on the 4.1 branch since the first patch is not technically a regression fix. Unless someone else wants to handle the checkin on the 4.1 branch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28221
[Bug java/28533] [ecj] Default warnings
--- Comment #2 from tromey at gcc dot gnu dot org 2006-07-31 16:29 --- Yes, the current 'ecj1' driver translates gnu-style options to eclipse-style options. So instead of funkyCaseWarning we have funky-case-warning, etc. Also we accept some "legacy" warning names, -Wno-foo, and the like. I didn't look too much at supporting names similar to what the rest of GCC supports, but this is a good idea. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-31 16:29:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28533
[Bug libgcj/28312] peer libraries are installed into gcjversionedlibdir, not into nativeexeclib
--- Comment #2 from fitzsim at gcc dot gnu dot org 2006-07-31 16:34 --- Subject: Bug 28312 Author: fitzsim Date: Mon Jul 31 16:34:28 2006 New Revision: 115839 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115839 Log: 2006-07-31 Thomas Fitzsimmons <[EMAIL PROTECTED]> PR libgcj/28312 * classpath/native/jni/midi-alsa/Makefile.am (libgjsmalsa_la_LDFLAGS): Add -avoid-version. * classpath/native/jni/midi-alsa/Makefile.in: Regenerate. * classpath/native/jni/midi-dssi/Makefile.am (libgjsmdssi_la_LDFLAGS): Add -avoid-version. * classpath/native/jni/midi-dssi/Makefile.in: Regenerate. * classpath/native/jni/qt-peer/Makefile.am: Remove GCJ LOCAL sections. (libqtpeer_la_LDFLAGS): Add -avoid-version. * classpath/native/jni/qt-peer/Makefile.in: Regenerate. * classpath/native/jni/gtk-peer/Makefile.am (libgtkpeer_la_LDFLAGS): Add -avoid-version. * classpath/native/jni/gtk-peer/Makefile.in: Regenerate. * classpath/native/jawt/Makefile.am (libjawt_la_LDFLAGS): Add -avoid-version. * classpath/native/jawt/Makefile.in: Regenerate. * Makefile.am (libjvm_la_LDFLAGS): Add -avoid-version. * Makefile.in: Regenerate. Modified: trunk/libjava/ChangeLog trunk/libjava/Makefile.am trunk/libjava/Makefile.in trunk/libjava/classpath/native/jawt/Makefile.am trunk/libjava/classpath/native/jawt/Makefile.in trunk/libjava/classpath/native/jni/gtk-peer/Makefile.am trunk/libjava/classpath/native/jni/gtk-peer/Makefile.in trunk/libjava/classpath/native/jni/midi-alsa/Makefile.am trunk/libjava/classpath/native/jni/midi-alsa/Makefile.in trunk/libjava/classpath/native/jni/midi-dssi/Makefile.am trunk/libjava/classpath/native/jni/midi-dssi/Makefile.in trunk/libjava/classpath/native/jni/qt-peer/Makefile.am trunk/libjava/classpath/native/jni/qt-peer/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28312
[Bug bootstrap/28511] can't bootstrap gcc / syntax error in gcc/opt-gather.awk
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-31 17:23 --- What is on line 24 in the awk file? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28511
[Bug fortran/28526] 'end' is recognized as a variable incorrectly
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-31 17:44 --- Hmm, end is keyword. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28526
[Bug bootstrap/28511] can't bootstrap gcc / syntax error in gcc/opt-gather.awk
--- Comment #2 from pluto at agmk dot net 2006-07-31 17:54 ---
(In reply to comment #1)
> What is on line 24 in the awk file?
(...)
#
# Usage: awk -f opt-gather.awk file1.opt [...] > outputfile
function sort(ARRAY, ELEMENTS) <=== line 24
{
for (i = 2; i <= ELEMENTS; ++i) {
(...)
with `export GAWK=gawk` (from opt/sfw/bin) gcc builds.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28511
[Bug c++/28553] New: string processing -O3 optimization bug under GCC 4.1.1
Note, the following is in reference to this Debian version of GCC: gcc version 4.1.2 20060729 (prerelease) (Debian 4.1.1-10) However, it also occurs under a version I have built myself: Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/usr/local/gcc-4.1 --enable-languages=c,c++,java Thread model: posix gcc version 4.1.1 My C++ knowledge isn't extensive enough to give further details of this other than it's related to string handling, or guess if it's already been reported, but the following preprocessed code reproduces the problem under -O3, but not -O2. The code performs correctly under GCC 3.4.6 and -O3 Here is the expected output: op [0]: "A" op [1]: "B" op [2]: "C" op [3]: "D" op [4]: "E" op [5]: "F" Here is a crash caught by GDB: CfgSchema (this=0xbfd0a400, [EMAIL PROTECTED]) at /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/bits/stl_algo.h:260 260 if (__pred(*__first)) (gdb) bt #0 CfgSchema (this=0xbfd0a400, [EMAIL PROTECTED]) at /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/bits/stl_algo.h:260 #1 0x08048ebe in main () at cfgtblopt.cpp:36 -- Summary: string processing -O3 optimization bug under GCC 4.1.1 Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: peter at chocky dot org GCC host triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28553
[Bug c++/28553] string processing -O3 optimization bug under GCC 4.1.1
--- Comment #1 from peter at chocky dot org 2006-07-31 17:56 --- Created an attachment (id=11981) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11981&action=view) Preprocessed C++ demonstrating problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28553
Re: [Bug bootstrap/28511] can't bootstrap gcc / syntax error in gcc/opt-gather.awk
> > > > --- Comment #2 from pluto at agmk dot net 2006-07-31 17:54 --- > (In reply to comment #1) > > What is on line 24 in the awk file? > > (...) > # > # Usage: awk -f opt-gather.awk file1.opt [...] > outputfile > > function sort(ARRAY, ELEMENTS) <=== line 24 Hehe, maybe Sun's awk is not a POSIX awk like most of their system is not either.
[Bug bootstrap/28511] can't bootstrap gcc / syntax error in gcc/opt-gather.awk
--- Comment #3 from pinskia at physics dot uc dot edu 2006-07-31 17:57 --- Subject: Re: can't bootstrap gcc / syntax error in gcc/opt-gather.awk > > > > --- Comment #2 from pluto at agmk dot net 2006-07-31 17:54 --- > (In reply to comment #1) > > What is on line 24 in the awk file? > > (...) > # > # Usage: awk -f opt-gather.awk file1.opt [...] > outputfile > > function sort(ARRAY, ELEMENTS) <=== line 24 Hehe, maybe Sun's awk is not a POSIX awk like most of their system is not either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28511
[Bug rtl-optimization/23454] [4.0 regression] ICE in invert_exp_1, at jump.c:1719
--- Comment #11 from tbm at cyrius dot com 2006-07-31 18:04 --- Created an attachment (id=11982) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11982&action=view) test case Testcase from application "xapian". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23454
[Bug bootstrap/25672] cross build's libgcc picks up CFLAGS
--- Comment #11 from dj at redhat dot com 2006-07-31 18:07 --- (1) I can manage my own bugzilla account, thankyouverymuch, and (2) I'm not the only build maintainer. -- dj at redhat dot com changed: What|Removed |Added CC|dj at redhat dot com| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25672
[Bug fortran/28526] 'end' is recognized as a variable incorrectly
--- Comment #2 from kargl at gcc dot gnu dot org 2006-07-31 18:20 --- Andrew, end is a keyword, but Fortran does not have reserved keywords. integer end end = 1 print *, end end The two 'end's are distinct. Yes, it's prudent not to use keywords in some other way, but Fortran does it prevent one from possibly shoot their foot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28526
[Bug rtl-optimization/26244] [4.2 Regression] FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O3 -fomit-frame-pointer -funroll-loops
--- Comment #31 from danglin at gcc dot gnu dot org 2006-07-31 18:29
---
The bug arises in simplifying this instruction in cse2:
(insn 141 140 142 11 builtin-bitops-2.c:10 (set (reg:SI 176)
(ashift:SI (reg:SI 139)
(minus:SI (const_int 31 [0x1f])
(reg:SI 183 178 {zvdep32} (nil)
(expr_list:REG_EQUAL (ashift:SI (reg:SI 139)
(reg:SI 169))
The constant portion of the shift simplifies to "-1":
(gdb) p debug_rtx (const_arg1)
(const_int -1 [0x])
We have a previous shift of "1":
(gdb) p debug_rtx (inner_const)
(const_int 1 [0x1])
In my opinion, the combined two shifts are larger than the size
of the object (32 bits). However, the code in cse.c for associating
shifts generates the following new constant:
(gdb) p debug_rtx (new_const)
(const_int 0 [0x0])
The check in cse.c fails to detect this case:
/* If we are associating shift operations, don't let this
produce a shift of the size of the object or larger.
This could occur when we follow a sign-extend by a right
shift on a machine that does a sign-extend as a pair
of shifts. */
if (is_shift && GET_CODE (new_const) == CONST_INT
&& INTVAL (new_const) >= GET_MODE_BITSIZE (mode))
{
/* As an exception, we can turn an ASHIFTRT of this
form into a shift of the number of bits - 1. */
if (code == ASHIFTRT)
new_const = GEN_INT (GET_MODE_BITSIZE (mode) - 1);
else
break;
}
So, the above check would appear to need fixing. Note that
SHIFT_COUNT_TRUNCATED is defined on this target and the
effect of the two shifts is actually a ASHIFT of 32.
Also, I would think that a ASHIFT larger than the size of the object should
produce a zero result. This might be considered as an enhancement. There
are probably some other special cases.
Roger, I added your name to the CC list since I thought that you would be
interested in this bug.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
CC||roger at eyesopen dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26244
[Bug target/28551] libgcc.a being generated in improper format for powerpc-eabi cross
--- Comment #3 from spkelly at andrew dot cmu dot edu 2006-07-31 18:35 --- I'd really expected to have good news, but even with newlib and gcc rebuilt for powerpc-eabisim, I still get the same error (with and without -msim, which sounds to be the default for *-eabisim anyway). I also found I needed to compile sim-crt0 manually after building gcc for eabisim, unlike with eabi. And now that I think about it, shouldn't output object files be compatible for building provided I keep the same host/build/target, regardless of whether that target is correct for the platform I plan to run on...? (eg, when I originally built for powerpc-eabi, shouldn't the default settings have let me compile programs for ~some~ real powerpc-eabi -mtarget, regardless of whether or not they ran in the simulator?) On the one hand I do feel guilty about getting dev assistance off a bug list when there may not actually be a bug involved. On the other hand, if there isn't a bug but simply so many caveats that one can't sit down, follow stock documentaton and get a working build, that in its self seems to point to a usability issue which could be better addressed. - The new error, as such, with a sim-crt0.o compiled from .../newlib-1.14.0/libgloss/rs6000/sim-crt0.S in the local directory (the 'No such file' error otherwise triggered is useless for telling where it should actually go): powerpc-eabisim-gcc -msim arithtest.c /scratch/spkelly/ppcbin/bin/../lib/gcc/powerpc-eabisim/4.1.1/libgcc.a: could not read symbols: File format not recognized collect2: ld returned 1 exit status - The line used to compile gcc (without errors): ../configure --target=powerpc-eabisim --prefix=/scratch/spkelly/ppcbin/ --disable-threads --disable-shared --enable-languages=c make all-gcc install-gcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28551
[Bug target/28551] libgcc.a being generated in improper format for powerpc-eabi cross
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-07-31 18:44 --- http://gcc.gnu.org/simtest-howto.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28551
[Bug c++/28554] New: Use of __attribute__ ((constructor)) on functions issues confusing error
In this test case, g++ issues a diagnostics which is confusing. If use of
__attribute__ ((constructor)) on a function with argument list other than
'void' is illegal, it should say so:
__attribute__ ((constructor))
static void Initialize(int argc, char *argv[], char *envp[]) {
}
% g++ -c ctor.C
ctor.C: In function '(static initializers for ctor.C)':
ctor.C:2: error: too few arguments to function 'void Initialize(int, char**,
char**)'
ctor.C:3: error: at this point in file
--
Summary: Use of __attribute__ ((constructor)) on functions issues
confusing error
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fjahanian at apple dot com
GCC build triplet: apple-ppc-darwin
GCC host triplet: apple-ppc-darwin
GCC target triplet: apple-ppc-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28554
[Bug bootstrap/28511] can't bootstrap gcc / syntax error in gcc/opt-gather.awk
--- Comment #4 from pluto at agmk dot net 2006-07-31 18:50 --- (In reply to comment #3) > Subject: Re: can't bootstrap gcc / syntax error in gcc/opt-gather.awk > > > > > > > > > --- Comment #2 from pluto at agmk dot net 2006-07-31 17:54 --- > > (In reply to comment #1) > > > What is on line 24 in the awk file? > > > > (...) > > # > > # Usage: awk -f opt-gather.awk file1.opt [...] > outputfile > > > > function sort(ARRAY, ELEMENTS) <=== line 24 > > Hehe, maybe Sun's awk is not a POSIX awk like most of their system is not > either. so it will be better if gcc searches gawk in $path rather than awk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28511
[Bug bootstrap/28511] can't bootstrap gcc / syntax error in gcc/opt-gather.awk
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-07-31 18:52 --- (In reply to comment #4) > so it will be better if gcc searches gawk in $path rather than awk. Why there are OS's which have real POSIX awk that are not gawk. Like mawk, etc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28511
[Bug c++/28554] Use of __attribute__ ((constructor)) on functions with more than one agrument issues confusing error
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-31 18:56 --- In 3.2.3 and before, we did not error out. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|apple-ppc-darwin| GCC host triplet|apple-ppc-darwin| GCC target triplet|apple-ppc-darwin| Version|unknown |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28554
[Bug c++/28554] Use of __attribute__ ((constructor)) on functions with more than one agrument issues confusing error
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-31 18:57 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||3.3.3 3.4.0 4.0.0 4.1.0 Last reconfirmed|-00-00 00:00:00 |2006-07-31 18:57:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28554
[Bug target/28551] libgcc.a being generated in improper format for powerpc-eabi cross
--- Comment #5 from spkelly at andrew dot cmu dot edu 2006-07-31 20:30 --- (In reply to comment #4) > http://gcc.gnu.org/simtest-howto.html > Thanks again, but... - make output: [15+ minutes of successful output] checking for shared libgcc... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[1]: *** [configure-target-libstdc++-v3] Error 1 make[1]: Leaving directory `/scratch/spkelly/cross_top/build' make: *** [all] Error 2 - I think that just further proves my point. Running the howto code verbatim, with the exception of substituting "powerpc-eabisim" for "arm-sim", the virtually-guaranteed-to-be-idiot-proof build method, still barfs. For reasons which look to be totally unrelated to the issue I first reported, I'll concede, but there's still something about embedded cross-compilation with gcc that makes the process less than straightforward. I'll twiddle the configure options closer to what I was trying for initially (fewer languages, fewer libs) and see whether that goes cleanly or whether there's still something odd lurking beneath the surface. Or you could just set the bug to WORKSFORME and be done with it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28551
[Bug libgcj/28546] [4.2 Regression] ./java/lang/Thread.h:31: error: using typedef-name '_Jv_Thread_t' after 'class'
--- Comment #4 from tromey at gcc dot gnu dot org 2006-07-31 21:14 --- The forward declaration is kind of a hack. I'm not sure why it is needed. In any case, no-threads is also a big hack. It wouldn't hurt to simply change the _Jv_Thread_t there to a class. -- tromey 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-07-31 21:14:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28546
[Bug c++/28557] New: [4.0/4.1/4.2 regression] Trouble with templated type conversion operator
The following valid code snippet is rejected since GCC 4.0.3.
On mainline it even triggers an ICE:
=
struct A
{
template operator T() { return T(); }
};
template void foo()
{
A().operator int();
}
void bar()
{
foo<0>();
}
=
bug.cc: In function 'void foo() [with int = 0]':
bug.cc:13: instantiated from here
bug.cc:8: error: invalid use of template type parameter
bug.cc: In member function 'A::operator T() [with T = T]':
bug.cc:8: instantiated from 'void foo() [with int = 0]'
bug.cc:13: instantiated from here
bug.cc:3: internal compiler error: in dependent_type_p, at cp/pt.c:12523
Please submit a full bug report, [etc.]
The code compiles fine, if I turn foo into a regular function.
--
Summary: [4.0/4.1/4.2 regression] Trouble with templated type
conversion operator
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, rejects-valid, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28557
[Bug c++/28558] New: [4.0/4.1/4.2 regression] Trouble with new and __attribute__
The following code snippet (I'm not sure whether it's valid or not)
triggers an ICE since GCC 3.1:
===
struct A {};
A *p = new A __attribute__((unused));
===
bug.cc:7: internal compiler error: in build_base_path, at cp/class.c:274
Please submit a full bug report, [etc.]
--
Summary: [4.0/4.1/4.2 regression] Trouble with new and
__attribute__
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28558
[Bug c++/28557] [4.0/4.1/4.2 regression] Trouble with templated type conversion operator
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28557
[Bug c++/28558] [4.0/4.1/4.2 regression] Trouble with new and __attribute__
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28558
[Bug c++/28559] New: [4.2 regression] ICE with friend and __attribute__
The following (probably valid) code snippet triggers an ICE on mainline:
==
template struct A
{
struct B;
};
struct C
{
template friend struct __attribute__((packed)) A::B;
};
==
bug.cc:8: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
--
Summary: [4.2 regression] ICE with friend and __attribute__
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28559
[Bug c++/28559] [4.2 regression] ICE with friend and __attribute__
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28559
[Bug c++/28560] New: [4.0/4.1/4.2 regression] Trouble with __attribute__ in template parameter
The following (probably valid) code snippet triggers an ICE since GCC 3.1:
==
template struct A {};
template struct B;
template struct C : A::X __attribute__((unused))> {};
==
bug.cc:5: internal compiler error: in layout_type, at stor-layout.c:1851
Please submit a full bug report, [etc.]
A similar code snippet causes a segfault:
==
template struct A {};
template struct B;
template<> struct A __attribute__((unused))> {};
==
--
Summary: [4.0/4.1/4.2 regression] Trouble with __attribute__ in
template parameter
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28560
[Bug libgcj/26506] Native build of Azureus 2.4.0.0 throws ArrayIndexOutOfBounds running under gcj 4.1.0
--- Comment #6 from tromey at gcc dot gnu dot org 2006-07-31 21:58 --- I'm fairly certain this is a duplicate. *** This bug has been marked as a duplicate of 23682 *** -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26506
[Bug libgcj/23682] gnu.java.nio.SelectorImpl.select(long) throws ArrayIndexOutOfBoundsException
--- Comment #6 from tromey at gcc dot gnu dot org 2006-07-31 21:58 --- *** Bug 26506 has been marked as a duplicate of this bug. *** -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||ryanwalklin at orcon dot net ||dot nz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23682
[Bug debug/25468] [4.0/4.1 Regression] -g makes g++ loop forever
--- Comment #11 from steven at gcc dot gnu dot org 2006-07-31 22:08 --- Subject: Bug 25468 Author: steven Date: Mon Jul 31 22:08:47 2006 New Revision: 115841 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115841 Log: PR debug/25468 Backport from mainline * config/elfos.h (ASM_OUTPUT_ASCII): Remove 'register' marks. Cache the last found '\0' marker to avoid quadratic behavior. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/elfos.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25468
[Bug libgcj/23682] gnu.java.nio.SelectorImpl.select(long) throws ArrayIndexOutOfBoundsException
--- Comment #7 from cvs-commit at developer dot classpath dot org 2006-07-31 22:09 --- Subject: Bug 23682 CVSROOT:/cvsroot/classpath Module name:classpath Changes by: Tom Tromey 06/07/31 22:08:00 Modified files: gnu/java/nio : SelectionKeyImpl.java SelectorImpl.java java/nio/channels: SelectionKey.java . : ChangeLog java/nio/channels/spi: AbstractSelectionKey.java Log message: PR libgcj/23682: * java/nio/channels/SelectionKey.java (attach): Now synchronized. (attachment): Likewise. * java/nio/channels/spi/AbstractSelectionKey.java (cancel): Now synchronized. (isValid): Likewise. * gnu/java/nio/SelectionKeyImpl.java (impl): Now final (ch): Likewise. (interestOps): Synchronize. (readyOps): Likewise. * gnu/java/nio/SelectorImpl.java (register): Synchronize around interestOps call. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/nio/SelectionKeyImpl.java?cvsroot=classpath&r1=1.9&r2=1.10 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/nio/SelectorImpl.java?cvsroot=classpath&r1=1.22&r2=1.23 http://cvs.savannah.gnu.org/viewcvs/classpath/java/nio/channels/SelectionKey.java?cvsroot=classpath&r1=1.8&r2=1.9 http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpath&r1=1.8279&r2=1.8280 http://cvs.savannah.gnu.org/viewcvs/classpath/java/nio/channels/spi/AbstractSelectionKey.java?cvsroot=classpath&r1=1.9&r2=1.10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23682
[Bug debug/25468] [4.0 Regression] -g makes g++ loop forever
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.2 |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25468
[Bug c++/28560] [4.0/4.1/4.2 regression] Trouble with __attribute__ in template parameter
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28560
[Bug debug/25468] [4.0 Regression] -g makes g++ loop forever
--- Comment #12 from steven at gcc dot gnu dot org 2006-07-31 22:13 --- Fixed in GCC 4.2 and GCC 4.1. But I am not interested in fixing this in GCC 4.0, so I'm finished with this bug. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Target Milestone|4.0.4 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25468
[Bug debug/25468] [4.0 Regression] -g makes g++ loop forever
-- steven at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.2 |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25468
[Bug libgcj/28546] [4.2 Regression] ./java/lang/Thread.h:31: error: using typedef-name '_Jv_Thread_t' after 'class'
--- Comment #5 from andreast at gcc dot gnu dot org 2006-07-31 22:15 --- Working on a patch. -- andreast at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |andreast at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-07-31 21:14:56 |2006-07-31 22:15:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28546
[Bug libgcj/28546] [4.2 Regression] ./java/lang/Thread.h:31: error: using typedef-name '_Jv_Thread_t' after 'class'
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2006-07-31
22:23 ---
Subject: Re: [4.2 Regression] ./java/lang/Thread.h:31: error: using
typedef-name '_Jv_Thread_t' after 'class'
> --- Comment #5 from andreast at gcc dot gnu dot org 2006-07-31 22:15
> ---
> Working on a patch.
Trying the patch below.
Dave
--
J. David Anglin [EMAIL PROTECTED]
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Index: include/no-threads.h
===
--- include/no-threads.h(revision 115793)
+++ include/no-threads.h(working copy)
@@ -25,7 +25,10 @@
typedef int _Jv_ConditionVariable_t;
typedef int _Jv_Mutex_t;
-typedef int _Jv_Thread_t;
+typedef struct _Jv_Thread_t
+{
+ int thread;
+};
typedef void _Jv_ThreadStartFunc (java::lang::Thread *);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28546
[Bug c++/6634] wrong parsing of "long long double"
--- Comment #11 from patchapp at dberlin dot org 2006-07-31 22:35 --- Subject: Bug number PR c++/6634 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01267.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6634
[Bug c++/6634] wrong parsing of "long long double"
--- Comment #12 from reichelt at gcc dot gnu dot org 2006-07-31 22:52 --- Subject: Bug 6634 Author: reichelt Date: Mon Jul 31 22:52:20 2006 New Revision: 115843 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115843 Log: PR c++/6634 * decl.c (grokdeclarator): Check whether "long" or "short" was specified for non-integral types. * g++.dg/parse/long1.C: Add more tests. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/parse/long1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6634
[Bug c/28418] [4.0/4.1/4.2 regression] ICE incrementing compound literal expression
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28418
[Bug c++/28420] [4.0/4.1/4.2 regression] ICE with "typeid" as template parameter
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28420
[Bug c++/28432] [4.0/4.1/4.2 regression] duplicate "no member function declared" message
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28432
[Bug driver/28437] [4.2 Regression] multiple fno-builtin-* flags broken
--- Comment #12 from mmitchel at gcc dot gnu dot org 2006-07-31 23:32 --- Shouldn't this issue be closed now? -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28437
[Bug c++/28450] [4.0/4.1/4.2 regression] ICE with new and complex/vector types
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28450
[Bug c++/28479] [4.2 regression] cc1plus just sits there eating CPU and RAM for a simple program
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28479
[Bug driver/28437] [4.2 Regression] multiple fno-builtin-* flags broken
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-07-31 23:33 --- Fixed, though really this is just a workaround as mentioned on the mailing list. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28437
[Bug gcov/profile/28480] [4.2 Regression] inliner-1.c:31: ICE: in set_bb_for_stmt, at tree-cfg.c:2775
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28480
[Bug rtl-optimization/28489] [4.2 regression] ICE in move_insn, at haifa-sched.c:1968
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28489
[Bug target/28490] [4.0/4.1/4.2 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
[Bug target/28495] [4.2 regression] ICE in final_scan_insn, at final.c:2448
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28495
[Bug c++/28506] [4.0/4.1/4.2 regression] ICE with initializers for functions
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28506
[Bug c++/28513] [4.0/4.1/4.2 Regression] QOI: Diagnostic missing since 3.3.x when naming rule is violated
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28513
[Bug target/28516] [4.2 regression] arm_unwind_emit_set, at config/arm/arm.c:15419 with -fexceptions
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
[Bug c++/28523] [4.0/4.1/4.2 Regression] Throw of a derived class casted to its base class using a C-style cast
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28523
[Bug driver/28528] [4.0/4.1/4.2 regression] Trouble compiling header files with "-x c++" using g++
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28528
[Bug tree-optimization/28544] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28544
[Bug libgcj/28546] [4.2 Regression] ./java/lang/Thread.h:31: error: using typedef-name '_Jv_Thread_t' after 'class'
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-07-31 23:42 --- Java is not release-critical. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28546
[Bug c++/28557] [4.0/4.1/4.2 regression] Trouble with templated type conversion operator
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28557
[Bug c++/28558] [4.0/4.1/4.2 regression] Trouble with new and __attribute__
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28558
[Bug c++/28559] [4.2 regression] ICE with friend and __attribute__
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28559
[Bug c++/28560] [4.0/4.1/4.2 regression] Trouble with __attribute__ in template parameter
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28560
[Bug bootstrap/28561] New: Broken dependencies
We've got some broken dependencies in the Makefiles: The definitions of REGS_H and BASIC_BLOCK_H in Makefile.in contain varray.h instead of $(VARRAY_H). Fixing this results in circular dependencies: make then reports problems with build/gencondmd.o: make[2]: Circular build/gencondmd.o <- insn-flags.h dependency dropped. The problem boils down to the following dependencies: build/gencondmd.o : ... $(REGS_H) ... REGS_H: ... $(VARRAY_H) ... $(BASIC_BLOCK_H) ... BASIC_BLOCK_H: ... $(VARRAY_H) ... VARRAY_H = ... $(TM_H) And $(TM_H) shouldn't be included by gen*. A second problem is that the #includes in a couple of header files don't really match the dependencies, e.g. in: basic-block.h c-common.h cgraph.h ddg.h expr.h ggc.h lambda.h regs.h tree-dump.h tree.h -- Summary: Broken dependencies Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28561
[Bug target/28247] [4.1/4.2 regression] libstdc++ cannot be build with Solaris threads
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-07-31 23:49 --- Should this issue be closed now that Roger's patches have been applied? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28247
[Bug target/28247] [4.1/4.2 regression] libstdc++ cannot be build with Solaris threads
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-01 00:15 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28247
[Bug libgcj/28546] [4.2 Regression] ./java/lang/Thread.h:31: error: using typedef-name '_Jv_Thread_t' after 'class'
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2006-08-01 00:16 --- Subject: Re: [4.2 Regression] ./java/lang/Thread.h:31: error: using typedef-name '_Jv_Thread_t' after 'class' > --- Comment #7 from mmitchel at gcc dot gnu dot org 2006-07-31 23:42 > --- > Java is not release-critical. Just thinking, wouldn't it save a bit of work if each component had its own default priority? Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28546
[Bug c++/28523] [4.0/4.1/4.2 Regression] Throw of a derived class casted to its base class using a C-style cast
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28523
[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)
--- Comment #8 from jason at gcc dot gnu dot org 2006-08-01 02:13 --- Created an attachment (id=11985) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11985&action=view) libstdc++ patch to prevent ... from catching forced unwird Finally, this patch stops ... from catching forced unwind, as specified by the ABI. I think the catch (abi::__forced_unwind &) patch should be uncontroversial, and works well with either solution to the catch (...) problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28145
[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)
--- Comment #9 from jason at gcc dot gnu dot org 2006-08-01 02:33 --- Created an attachment (id=11986) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11986&action=view) revision to forced-lib.patch that also adds __foreign_exception -- jason at gcc dot gnu dot org changed: What|Removed |Added Attachment #11978|0 |1 is obsolete|| AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28145
[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)
--- Comment #10 from drow at gcc dot gnu dot org 2006-08-01 02:47 ---
Subject: Re: C++ (throw() and catch(...) {/* fall through */ } ) and pthread
cancellation are incompatible (at least with NPTL)
On Tue, Aug 01, 2006 at 02:13:08AM -, jason at gcc dot gnu dot org wrote:
> Finally, this patch stops ... from catching forced unwind, as specified by the
> ABI.
Just making sure I understand - catch (...) { foo(); throw; } will no
longer call foo during forced unwinding, only destructors and explicit
forced unwinding catches will be called?
[What does this imply for throw()?]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28145
[Bug target/28490] [4.0/4.1/4.2 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088
--- Comment #10 from steven at gcc dot gnu dot org 2006-08-01 05:51 --- Why is this a P1 regression? ia-64 is not a primary platform. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
