[Bug other/28298] New: Problem compiling gcc 4.1.1
[...] make[3]: Entering directory `/tmp/gcc-4.1.1/host-i686-pc-linux-gnu/stage1-gcc' make \ CFLAGS="-g -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute " \ CONFIG_H="tconfig.h auto-host.h ../.././gcc/../include/ansidecl.h" TM_H="tm.h options.h ../.././gcc/config/i386/i386.h ../.././gcc/config/i386/unix.h ../.././gcc/config/i386/att.h ../.././gcc/config/dbxelf.h ../.././gcc/config/elfos.h ../.././gcc/config/svr4.h ../.././gcc/config/linux.h ../.././gcc/config/i386/linux.h ../.././gcc/defaults.h insn-constants.h insn-flags.h options.h" \ INCLUDES="-I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include " \ MAKEOVERRIDES= \ -f libgcc.mk all make[4]: Entering directory `/tmp/gcc-4.1.1/host-i686-pc-linux-gnu/stage1-gcc' /tmp/gcc-4.1.1/host-i686-pc-linux-gnu/gcc/xgcc -B/tmp/gcc-4.1.1/host-i686-pc-linux-gnu/gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -O2 -O2 -s -O3 -march=i686 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include -fexceptions -fvisibility=hidden -DHIDE_EXPORTS -c ../.././gcc/unwind-dw2.c -o libgcc/./unwind-dw2.o In file included from ../.././gcc/gthr-posix.h:43, from ./gthr-default.h:1, from ../.././gcc/gthr.h:114, from ../.././gcc/unwind-dw2.c:42: /usr/include/pthread.h:163: error: expected ';', ',' or ')' before '__thread' /usr/include/pthread.h:591: error: storage class specified for parameter 'type name' In file included from /usr/include/pthread.h:655, from ../.././gcc/gthr-posix.h:43, from ./gthr-default.h:1, from ../.././gcc/gthr.h:114, from ../.././gcc/unwind-dw2.c:42: /usr/include/bits/sigthread.h:36: error: storage class specified for parameter 'type name' In file included from ./gthr-default.h:1, from ../.././gcc/gthr.h:114, from ../.././gcc/unwind-dw2.c:42: ../.././gcc/gthr-posix.h:91: error: 'pthread_create' undeclared here (not in a function) ../.././gcc/gthr-posix.h:91: warning: type defaults to 'int' in declaration of '__gthrw_pthread_create' make[4]: *** [libgcc/./unwind-dw2.o] Error 1 make[4]: Leaving directory `/tmp/gcc-4.1.1/host-i686-pc-linux-gnu/stage1-gcc' make[3]: *** [libgcc.a] Error 2 make[3]: Leaving directory `/tmp/gcc-4.1.1/host-i686-pc-linux-gnu/stage1-gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/tmp/gcc-4.1.1' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/tmp/gcc-4.1.1' make: *** [all] Error 2 -- Summary: Problem compiling gcc 4.1.1 Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pierre42d at 9online dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28298
[Bug c/28289] composite_types called to do two different things
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-07-07 09:30 --- testcase? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28289
[Bug target/28282] Attempt to delete prologue/epilogue insn, again
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-07-07 09:44 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2006-07-07 09:44:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28282
[Bug rtl-optimization/26945] [4.0/4.1 regression] Attempt to delete prologue/epilogue insn
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-07-07 09:45 --- Dup of 28282 which has a simpler testcase. *** This bug has been marked as a duplicate of 28282 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26945
[Bug target/28282] Attempt to delete prologue/epilogue insn, again
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-07-07 09:45 --- *** Bug 26945 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||tausq at debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28282
[Bug target/28282] Attempt to delete prologue/epilogue insn, again
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-07-07 09:52 --- The question is why we need to ICE here. We may as well go ahead and pretend it was the users fault and not a bug in some previous pass... -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||12535 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28282
[Bug c/28299] New: ICE with -Wmissing-prototypes
$ cat ice.c
extern __typeof(foo) foo __asm__("") ;
void * foo (void) {};
$ gcc-4.2-HEAD -c ice.c -Wmissing-prototypes -o ice.o
ice.c:1: error: 'foo' undeclared here (not in a function)
ice.c:2: internal compiler error: tree check: expected function_type or
method_type, have integer_type in start_function, at c-decl.c:6039
Please submit a full bug report,
with preprocessed source if appropriate.
The ICE naturally goes away with -Wno-missing-prototype.
Maybe related to PR 27719
--
Summary: ICE with -Wmissing-prototypes
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aldot at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28299
[Bug other/28298] Problem compiling gcc 4.1.1
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-07-07 11:39 --- /usr/include/pthread.h:163: error: expected ';', ',' or ')' before '__thread' /usr/include/pthread.h:591: error: storage class specified for parameter 'type name' so, whats wrong there? This is really not enough information. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28298
[Bug tree-optimization/28187] [4.1/4.2 Regression] '-O2 -fwrapv' exhausts memory.
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-07-07 12:32 --- Subject: Bug 28187 Author: rguenth Date: Fri Jul 7 12:31:29 2006 New Revision: 115255 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115255 Log: 2006-07-07 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/28187 * tree-vrp.c (vrp_operand_equal_p): New function. (vrp_bitmap_equal_p): Likewise. (update_value_range): Use them to compare old and new max and min values. * gcc.dg/pr28187.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr28187.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28187
[Bug tree-optimization/28187] [4.1/4.2 Regression] '-O2 -fwrapv' exhausts memory.
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-07-07 12:34 --- Fixed on the mainline. pinskia, can you verify that as of comment #2 with the reduced and/or the original testcase? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28187
[Bug ada/21952] Many attribute directive ignored warnings during Alpha bootstrap
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2006-07-07 13:00 --- I think the Alpha back-end somewhat abuses the "builtin" machinery here. -- ebotcazou 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-07 13:00:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21952
[Bug ada/21952] Many attribute directive ignored warnings during Alpha bootstrap
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2006-07-07 13:01 --- However we are nice people and the Ada front-end will be change to cope with it. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-07-07 13:00:29 |2006-07-07 13:01:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21952
[Bug rtl-optimization/27616] [4.1/4.2 Regression] Internal error with -O1 (CSE)
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-07-07 13:36 --- Janis, Could you do a regression hunt on this bug for me? Thanks, Andrew Pinski -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27616
[Bug middle-end/28283] SuperH: Very unoptimal code generated for 64-bit ints
--- Comment #7 from amylaar at gcc dot gnu dot org 2006-07-07 13:50 --- (In reply to comment #3) > When I disable the offending code (by altering add_cost[DImode] at the right > moment), I get the right result for little endian. However, compiling for > big endian gives wrong code: > > _expand64: > mov #0,r5 > mov r4,r0 > rts > mov r5,r1 > .size _expand64, .-_expand64 > .ident "GCC: (GNU) 4.2.0 20060620 (experimental)" > > 3.4.0 was sane: > _expand64: > mov r4,r5 > mov #0,r4 > mov r4,r0 > rts > mov r5,r1 > .size _expand64, .-_expand64 > .ident "GCC: (GNU) 3.4.0 20040113 (experimental)" > Oops, I got mixed up here - I somehow thought the argument was long long, i.e. the lowpart in r5. Since the argument is actually unsigned int, it is passed in r4. And the 3.4.0 code for big endian is actually: _expand64: mov #0,r5 mov r4,r0 rts mov r5,r1 .size _expand64, .-_expand64 .ident "GCC: (GNU) 3.4.0 20040113 (experimental)" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28283
[Bug c++/28300] New: In-class partial specialization of class accepted
The following - IMHO according to [14.5.4]/6 invalid - code snippet is
accepted since at least GCC 2.95.3:
===
template struct A
{
template struct A;
};
===
--
Summary: In-class partial specialization of class accepted
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: accepts-invalid, 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=28300
[Bug c++/28301] New: [4.0/4.1/4.2 regression] ICE with broken specialization
The following invalid code snippet triggers an ICE since GCC 3.4.0:
===
template struct A
{
template void foo() // missing ;
};
template<> struct A
{
template void foo();
};
void bar()
{
A a;
a.foo<0>();
}
===
bug.cc:4: error: expected initializer before '}' token
bug.cc:6: error: explicit specialization in non-namespace scope 'struct A<
>'
bug.cc:6: error: enclosing class templates are not explicitly specialized
bug.cc:6: error: template parameters not used in partial specialization:
bug.cc:6: error: ''
bug.cc:15: error: expected `}' at end of input
bug.cc: In member function 'void A< >::bar()':
bug.cc:14: internal compiler error: in retrieve_specialization, at cp/pt.c:819
Please submit a full bug report, [etc.]
--
Summary: [4.0/4.1/4.2 regression] ICE with broken specialization
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, 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=28301
[Bug c++/28301] [4.0/4.1/4.2 regression] ICE with broken specialization
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28301
[Bug c++/28302] New: [4.0/4.1/4.2 regression] ICE with bit-complement for vectors
The following code snippet causes an ICE since GCC 4.0.2
(and in GCC 3.4.5, 3.4.6):
=
int __attribute__((vector_size(8))) x;
void foo()
{
~x;
}
=
bug.cc: In function 'void foo()':
bug.cc:5: internal compiler error: in perform_integral_promotions, at
cp/typeck.c:1575
Please submit a full bug report, [etc.]
The code was rejected before:
bug.cc: In function `void foo()':
bug.cc:5: error: wrong type argument to bit-complement
However, it is accepted by the C frontend since GCC 3.3.
--
Summary: [4.0/4.1/4.2 regression] ICE with bit-complement for
vectors
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=28302
[Bug c++/28302] [4.0/4.1/4.2 regression] ICE with bit-complement for vectors
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28302
[Bug c++/28303] New: [4.1/4.2 regression] ICE on invalid typedef
The following invalid code snippet triggers an ICE on the 4.1 branch
(introduced after 4.1.1) and mainline:
template struct A
{
typedef struct typename T::X X;
};
template A::X::X() {}
bug.cc:3: error: expected identifier before 'typename'
bug.cc:3: error: two or more data types in declaration of 'X'
bug.cc:6: error: ISO C++ forbids declaration of 'X' with no type
bug.cc:6: internal compiler error: in is_ancestor, at cp/name-lookup.c:2247
Please submit a full bug report, [etc.]
Probably related to PR27102.
--
Summary: [4.1/4.2 regression] ICE on invalid typedef
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
BugsThisDependsOn: 27102
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28303
[Bug c++/28303] [4.1/4.2 regression] ICE on invalid typedef
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28303
[Bug c++/28304] New: [4.0/4.1/4.2 regression] ICE looking up invalid member template
The following invalid code snippet triggers an ICE since GCC 4.0.0:
struct A {};
template void A::foo(T) {}
void bar()
{
A::foo(1);
}
bug.cc:3: error: no 'void A::foo(T)' member function declared in class 'A'
bug.cc:3: error: template definition of non-template 'void A::foo(T)'
bug.cc: In function 'void bar()':
bug.cc:7: internal compiler error: in lookup_member, at cp/search.c:1212
Please submit a full bug report, [etc.]
--
Summary: [4.0/4.1/4.2 regression] ICE looking up invalid member
template
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, 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=28304
[Bug c++/28304] [4.0/4.1/4.2 regression] ICE looking up invalid member template
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28304
[Bug c++/27019] [4.1 regression] ICE with designated initializers
--- Comment #6 from sje at gcc dot gnu dot org 2006-07-07 15:15 --- Subject: Bug 27019 Author: sje Date: Fri Jul 7 15:15:00 2006 New Revision: 115260 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115260 Log: PR c++/27019 * g++.dg/ext/pr27019.C: New. Added: trunk/gcc/testsuite/g++.dg/ext/pr27019.C Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27019
[Bug c++/28291] [4.1/4.2 regression] ICE on invalid designated initializer
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-07-07 15:21 --- Related to PR 27019. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||27019 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28291
[Bug ada/28305] New: GNAT bug when inlining instance of a generic subprogram
A GNAT bug is detected whenever pragma Inline is applied to an instance of a generic subprogram and front-end inlining is activated (-gnatN). The problem can be worked around by either applying the pragma Inline to the generic subprogram declaration or deactivating front-end inlining. The test case I used is as follows: gcc -c -gnatN test.ads generic type T is private; function A (Value : T) return T; function A (Value : T) return T is begin return Value; end A; with A; pragma Elaborate_All (A); function Test is new A (Integer); pragma Inline (Test); -- Summary: GNAT bug when inlining instance of a generic subprogram Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dewi dot daniels at silver-software dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28305
[Bug middle-end/28268] [4.2 regression] ICE with simple vector operations
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-07-07 16:30 --- Subject: Bug 28268 Author: rguenth Date: Fri Jul 7 16:30:36 2006 New Revision: 115263 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115263 Log: 2006-07-07 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/28268 * tree.h (build_one_cst): Declare. * tree.c (build_one_cst): New function. * tree-ssa-math-opts.c (get_constant_one): Remove. (insert_reciprocals): Use build_one_cst. * fold-const.c (fold_plusminus_mult): Likewise. * gcc.dg/torture/pr28268.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr28268.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-math-opts.c trunk/gcc/tree.c trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28268
[Bug middle-end/28268] [4.2 regression] ICE with simple vector operations
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-07-07 16:31 --- 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=28268
[Bug other/28298] Problem compiling gcc 4.1.1
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-07 16:37 --- /usr/include/pthread.h:163: error: expected ';', ',' or ')' before '__thread' Did you disable fixincludes? If so this is why you don't disable fixincludes :). If you did not, then you might be better off updating glibc since the old glibc headers are broken. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28298
[Bug c/28289] composite_types called to do two different things
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-07-07 16:47 --- (In reply to comment #1) > testcase? > I couldn't find one yet. I suspect this is hidden by tree-optimizers and missed optimization issues. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28289
[Bug c/28306] New: const / pure call with ignored argument emitted.
There is code in the expanders which is supposed to avoid emitting calls to pure functions which have their result ignored, but it doesn't appear to work when the function called is represented as a COND_EXPR. -- Summary: const / pure call with ignored argument emitted. Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu OtherBugsDependingO 28289 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28306
[Bug c/28306] const / pure call with ignored argument emitted.
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-07-07 16:54 --- Created an attachment (id=11850) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11850&action=view) test case The available source code for the functions allows the compiler to see that the called functions are const. This should be sufficient for the compiler to figure out the call is not needed. Likewise, the pure attributes should also be sufficient to figure this out. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28306
[Bug middle-end/27889] [4.1/4.2 Regression] ICE on complex assignment in nested function
--- Comment #17 from mmitchel at gcc dot gnu dot org 2006-07-07 17:03 --- Yes, I did miss Comment #6. I've reset this to P2, in light of that. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P5 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27889
[Bug target/28307] New: [4.1/4.2 Regression] pthread functions in libgcc not weak any more on Tru64 UNIX
While investigating the root cause of PR libgcj/28189, I noticed that both on the 4.1 branch and on mainline (where the libjava testsuite timeouts occur) the boehm-gc test had started failing as well (which easily goes unnoticed due to PR boehm-gc/11412): gctest fails like this: Key creation failed 18446744073709551615 Test failed FAIL: gctest It turns out that this happens when pthread_key_create returns -1. Printing errno at this point reveals that errno is 0, which is unexpected and shouldn't happen with the function from libpthread. Upon further investigation, it turned out that the pthread function definitions from gthr-posix.c aren't marked weak any more, so the dummy function definitions make it into libgcc.a and libgcc_s.so.1, which of course every usage of the real pthread functions. This was introduce by this patch and it's successors: 2005-11-09 Alexandre Oliva <[EMAIL PROTECTED]> PR other/4372 * gthr-dce.h, gthr-posix.h, gthr-posix95.h, gthr-solaris.h, gthr-tpf.h: Define __gthrw. For all identifiers that might be weak, introduce weakrefs or non-weak aliases with __gthrw, and prefix all uses with __ghtrw. Before that change, there were #pragma weak declarations for all functions defined in gthr-posix.c, so those definitions became weak. Afterwards, those declarations were lost and the definitions became strong. Environment: System: OSF1 bartok V5.1 2650 alpha Machine: alpha host: alpha-dec-osf5.1b build: alpha-dec-osf5.1b target: alpha-dec-osf5.1b configured with: /vol/gcc/src/gcc/configure --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls --host alpha-dec-osf5.1b --build alpha-dec-osf5.1b --target alpha-dec-osf5.1b --with-gmp-dir=/vol/gnu/obj/gmp-4.1.3 --with-mpfr-dir=/vol/gnu/obj/gmp-4.1.3/mpfr --enable-languages=c,c++,fortran,java,objc,ada --disable-libmudflap How-To-Repeat: Investigate e.g. the pthread_key_create definition in libgcc.a and libgcc_s.so.1 with stdump: On the 4.0 branch, it is marked weak: 6. (file 0) (0x10) pthread_key_create Proc Text symref (indexNil) (weakext) while on mainline and the 4.1 branch this is lost: 6. (file 0) (0x10) pthread_key_create Proc Text symref (indexNil) --- Comment #1 from ro at techfak dot uni-bielefeld dot de 2006-07-07 17:06 --- Fix: I'm currently testing the following patch (which is difficult due to lots of other unrelated breakage on mainline ;-). It probably needs some cleanup and comments, but gives the basic idea. Index: gthr-posix.c === --- gthr-posix.c(revision 115230) +++ gthr-posix.c(working copy) @@ -28,6 +28,7 @@ Software Foundation, 51 Franklin Street, #include "tconfig.h" #include "tm.h" +# define __gthrw_pragma(pragma) _Pragma (#pragma) /* Define so we provide weak definitions of functions used by libobjc only. */ #define _LIBOBJC_WEAK #include "gthr.h" Index: gthr-posix.h === --- gthr-posix.h(revision 115230) +++ gthr-posix.h(working copy) @@ -59,8 +59,12 @@ typedef pthread_mutex_t __gthread_recurs #endif #if SUPPORTS_WEAK && GTHREAD_USE_WEAK +# ifndef __gthrw_pragma +# define __gthrw_pragma(pragma) +# endif # define __gthrw2(name,name2,type) \ - static __typeof(type) name __attribute__ ((__weakref__(#name2))); + static __typeof(type) name __attribute__ ((__weakref__(#name2))); \ + __gthrw_pragma(weak name2) # define __gthrw_(name) __gthrw_ ## name #else # define __gthrw2(name,name2,type) -- Summary: [4.1/4.2 Regression] pthread functions in libgcc not weak any more on Tru64 UNIX Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at techfak dot uni-bielefeld dot de GCC build triplet: alpha-dec-osf5.1b GCC host triplet: alpha-dec-osf5.1b GCC target triplet: alpha-dec-osf5.1b http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28307
[Bug target/28307] [4.1/4.2 Regression] pthread functions in libgcc not weak any more on Tru64 UNIX
--- Comment #2 from ro at gcc dot gnu dot org 2006-07-07 17:09 --- Alexandre, your patch introduced this regression. Could you have a look if the suggested fix in Comment #1 seems reasonable? Thanks. Rainer -- ro at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28307
[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)
--- Comment #5 from pcarlini at suse dot de 2006-07-07 17:17 --- (In reply to comment #4) > However, we know that it should be possible to write cancel-safe C++ > libraries (including, in particular, libstdc++); otherwise, it's hard to > use C++ in a multi-threaded application. And, we know that we can do it > with a very simple hook: we just need a way to ask whether the current > thread is being cancelled. GLIBC has lots of extensions; if we can have > __thread_cancelled(), we've got enough, without having to solve the > problem of whether or not it should be possible to catch (and not > rethrow) the thread-cancellation exception. (I'd rather have a name for > the thread exception, as that seems more natural, but this is a > difference only of syntax; the hook function would be a perfectly > satisfactory way to make progress.) FWIW my personal opinion about this issue, I concur. Now, assuming all the knowledgeable people do indeed agree, is it really feasible to add such feature to glibc? Is someone going to ask glibc maintainers opinion? -- pcarlini at suse dot de changed: What|Removed |Added CC||pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28145
[Bug c/28306] const / pure call with ignored argument emitted.
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-07-07 17:30 --- Confirmed. -- rguenth 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-07 17:30:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28306
[Bug c++/27820] [4.0/4.1/4.2 regression] ICE with duplicate label
--- Comment #5 from lmillward at gcc dot gnu dot org 2006-07-07 17:57 --- Subject: Bug 27820 Author: lmillward Date: Fri Jul 7 17:57:12 2006 New Revision: 115265 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115265 Log: PR c++/27820 * decl.c (define_label): Return error_mark_node on error. * semantics.c (finish_label_stmt): Don't call add_stmt for invalid labels. * g++.dg/other/label1.C: New test. Added: trunk/gcc/testsuite/g++.dg/other/label1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27820
[Bug target/28307] [4.1/4.2 Regression] pthread functions in libgcc not weak any more on Tru64 UNIX
--- Comment #3 from ro at gcc dot gnu dot org 2006-07-07 17:58 --- Created an attachment (id=11851) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11851&action=view) Revised patch Minor correction: with the original patch, some functions (those which didn't use #pragma extern_prefix) were still not marked weak. In the presence of #pragma extern_prefix, #pragma weak still needs to refer to the unprefixed name. With the attached patch, at least the unmodified boehm-gc 6.7 tested successfully. -- ro at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28307
[Bug c++/27820] [4.0/4.1 regression] ICE with duplicate label
--- Comment #6 from lmillward at gcc dot gnu dot org 2006-07-07 17:59 --- Fixed on mainline. Will apply to release branches once testing completes. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 regression] ICE|[4.0/4.1 regression] ICE |with duplicate label|with duplicate label http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27820
[Bug libgcj/28189] [4.1/4.2 Regression] Many libjava execution tests time out on Tru64 UNIX
--- Comment #1 from ro at gcc dot gnu dot org 2006-07-07 18:02 --- PR target/28307 seems to be the root cause. -- ro at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||28307 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28189
[Bug target/26397] Program crashes when rethrowing exception
--- Comment #7 from stuart dot downing at sungard dot com 2006-07-07 18:25 --- Created an attachment (id=11852) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11852&action=view) Sample code that exhibits segmentation fault This is a simplified code sample that produces the symptom -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26397
[Bug target/26397] Program crashes when rethrowing exception
--- Comment #8 from stuart dot downing at sungard dot com 2006-07-07 18:28 --- We are also observing this symptom, but only when gcc is configured with --disable-shared. This configuration... /devp/src/bld/gcc4.1.1.s/usr/local/bin/g++ -v Target: powerpc-ibm-aix5.1.0.0 Configured with: /devp/src/gcc-4.1.1/configure --enable-languages=c,c++ --disable-nls --disable-threads --disable-shared Thread model: aix gcc version 4.1.1 exhibits a segmentation fault but this one /devp/src/bld/gcc4.1.1/usr/local/bin/g++ - Using built-in specs. Target: powerpc-ibm-aix5.1.0.0 Configured with: /devp/src/gcc-4.1.1/configure --enable-languages=c,c++ --disable-nls --disable-threads --enable-shared Thread model: aix gcc version 4.1.1 does not. -- stuart dot downing at sungard dot com changed: What|Removed |Added CC||stuart dot downing at ||sungard dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26397
[Bug fortran/28201] gfortran ICE if argument list does not match generic interface
--- Comment #2 from pault at gcc dot gnu dot org 2006-07-07 18:46 ---
This fixes the fault and i presently regtesting:
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c (revision 115245)
--- gcc/fortran/resolve.c (working copy)
*** resolve_generic_s (gfc_code * c)
*** 1500,1508
if (m == MATCH_ERROR)
return FAILURE;
! if (sym->ns->parent != NULL)
{
! gfc_find_symbol (sym->name, sym->ns->parent, 1, &sym);
if (sym != NULL)
{
m = resolve_generic_s0 (c, sym);
--- 1500,1511
if (m == MATCH_ERROR)
return FAILURE;
! if (sym->ns->parent != NULL || sym->attr.use_assoc)
{
! if (sym->attr.use_assoc)
! gfc_find_symbol (sym->name, sym->ns, 1, &sym);
! else
! gfc_find_symbol (sym->name, sym->ns->parent, 1, &sym);
if (sym != NULL)
{
m = resolve_generic_s0 (c, sym);
If all is well, I will prepare a testsuite case and submit tomorrow.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28201
[Bug c++/28308] New: Language linkage not part of function type
>From the C++ standard, 7.5p1:
Two function types with different language linkages are distinct types even if
they are otherwise identical.
The following code tests for this and should compile (a successful compile
indicates a test pass).
template
struct static_assert;
template<>
struct static_assert {};
extern "C"
{
char myexit(void (*)(void));
typedef void (*CF)(void);
}
int myexit(void (*f)())
{
static_assert e1;
return myexit((CF)f);
}
int main()
{
}
extern "C"
{
char myexit(void (*)(void))
{
return 0;
}
}
--
Summary: Language linkage not part of function type
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hhinnant at apple dot com
GCC host triplet: Darwin ppc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28308
[Bug c++/28308] Language linkage not part of function type
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-07 20:52 --- *** This bug has been marked as a duplicate of 2316 *** -- 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=28308
[Bug c++/2316] g++ fails to overload on language linkage
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-07-07 20:52 --- *** Bug 28308 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||hhinnant at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
[Bug target/27991] [4.2 regression] ICE in reload_cse_simplify_operands
--- Comment #4 from pbrook at gcc dot gnu dot org 2006-07-07 23:39 --- Subject: Bug 27991 Author: pbrook Date: Fri Jul 7 23:38:56 2006 New Revision: 115272 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115272 Log: 2006-07-08 Paul Brook <[EMAIL PROTECTED]> PR target/27991 * config/m68k/m68k.md: Add r-m patterns for 68881 movxf. Modified: trunk/gcc/ChangeLog trunk/gcc/config/m68k/m68k.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27991
[Bug target/27991] [4.2 regression] ICE in reload_cse_simplify_operands
--- Comment #5 from pbrook at gcc dot gnu dot org 2006-07-07 23:39 --- Fixed. -- pbrook at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27991
[Bug libgcj/11502] fastjar error: "Error in JAR file format. zip-style comment?"
--- Comment #16 from init dot six at gmail dot com 2006-07-08 00:36 --- I found this bug report by googling for the same error message. In my case it showed up on a suse9 machine. I corrected the problem by changing my PATH environment variable. The broken PATH contained: /nfs/platform/suse9/jdk1.5.0_06/jre/bin/ The corrected PATH contained /nfs/platform/suse9/jdk1.5.0_06/bin/ Maybe this will help someone else down the road. Best Regards, init.six AT gmail DOT com -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11502
[Bug libgomp/28296] libgomp fails to configure on Tru64 UNIX
--- Comment #2 from echristo at apple dot com 2006-07-08 01:04 --- Well, it shouldn't have mattered, but try re-adding the CFLAGS line that I think I accidentally deleted just after XPCFLAGS: CFLAGS="$CFLAGS -pthread" which is also just plain wrong, but perhaps this too should be moved inside the case block. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28296
[Bug libgomp/28296] libgomp fails to configure on Tru64 UNIX
--- Comment #3 from echristo at apple dot com 2006-07-08 01:11 --- Oh yes, FWIW it worked on both x86-darwin and x86-linux which are the only platforms I can test :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28296
[Bug target/27875] [4.2 Regression] ICE on gcc testsuite.
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-07-08 02:26 --- http://gcc.gnu.org/ml/gcc/2006-04/msg00463.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27875
[Bug target/27287] [4.1/4.2 Regression] returning constant double
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-07-08 02:28 --- 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-07-08 02:28:58 date|| Summary|loading 0 constant causes an|[4.1/4.2 Regression] |ICE (freescale's messy |returning constant double |targets)| Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug target/27875] [4.2 Regression] ICE on gcc testsuite.
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-07-08 02:29 --- This is really a dup of bug 27287 which is also affects 4.1. *** This bug has been marked as a duplicate of 27287 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27875
[Bug target/27287] [4.1/4.2 Regression] returning constant double
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-07-08 02:29 --- *** Bug 27875 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||edmar at freescale dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug target/27287] [4.1/4.2 Regression] returning constant double
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-07-08 02:34 --- Just for future reference this was orginally reported at: http://gcc.gnu.org/ml/gcc/2006-04/msg00463.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug target/27288] barfs on glibc code with an ICE (freescale's messy targets)
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-08 02:35 --- Just for future reference this was orginally reported at: http://gcc.gnu.org/ml/gcc/2006-04/msg00463.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27288
[Bug target/27287] [4.1/4.2 Regression] returning constant double
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-07-08 02:36 --- Also reported here: http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00823.html Which was CC'd to Aldy and there was no answer at that point :(. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug target/27288] barfs on glibc code with an ICE (freescale's messy targets)
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-08 02:37 --- Also reported http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00823.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27288
[Bug target/27287] [4.1/4.2 Regression] returning constant double
--- Comment #8 from dje at gcc dot gnu dot org 2006-07-08 03:13 --- The patch looks consistent with the rest of the e500 design, although I am not familiar enough with the e500 ISA to determine if the code will be correct under all circumstances. I'm willing to approve the patch if someone with e500 knowledge concurs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug libgomp/28296] [4.2 Regression] libgomp fails to configure on Tru64 UNIX
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build Summary|libgomp fails to configure |[4.2 Regression] libgomp |on Tru64 UNIX |fails to configure on Tru64 ||UNIX Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28296
[Bug target/28282] Attempt to delete prologue/epilogue insn, again
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-07-08 04:48 --- (In reply to comment #6) The problem is that flow (which does the instruction deletion) is semi stupid and does not check. I bet this will be fixed with the dataflow branch or at least easier to fix :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28282
[Bug target/27288] barfs on glibc code with an ICE (freescale's messy targets)
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-07-08 04:52 --- This works on the mainline at least. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27288
[Bug target/27565] [4.1 Regression] ICE in assign_stack_temp_for_type for vectors with SPE
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-08 04:52 --- This works for me on the mainline now, I just tried. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2 Regression] ICE in |[4.1 Regression] ICE in |assign_stack_temp_for_type |assign_stack_temp_for_type |for vectors with SPE|for vectors with SPE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27565
[Bug target/27566] [4.1/4.2 Regression] ICEs in final_scan_insn and reload_cse_simplify_operands for vectors with SPE
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-08 04:56 ---
We have before reload:
(insn 45 44 46 3 (set (reg:V4HI 131 [ D.1754 ])
(const_vector:V4HI [
(const_int 0 [0x0])
(const_int 0 [0x0])
(const_int 0 [0x0])
(const_int 0 [0x0])
])) 933 {*movv4hi_internal} (nil)
(nil))
Which then gets turned into:
(insn 73 44 45 3 (set (reg:SI 10 10)
(high:SI (symbol_ref/u:SI ("*.LC0") [flags 0x2]))) 319 {elf_high} (nil)
(nil))
(insn 45 73 74 3 (set (reg:V4HI 0 0 [orig:131 D.1754 ] [131])
(mem/u/c/i:V4HI (lo_sum:SI (reg:SI 10 10)
(symbol_ref/u:SI ("*.LC0") [flags 0x2])) [0 S8 A64])) 933
{*movv4hi_internal} (nil)
(nil))
Which is normally fine except for the fact V4HI memory only accepts reg+reg and
not reg+imm.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27566
[Bug fortran/28309] New: -std=f2003 and call flush()
If I compile the program --- program test write(*,*) 'Hello' call flush() end program test --- without options, it works. However, using -std=f2003: /tmp/cc4pdLnc.o: In function `MAIN__': flush.f90:(.text+0x77): undefined reference to `flush_' Expected: As flush is part of Fortran 2003, it should work. -- Summary: -std=f2003 and call flush() Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28309
