[Bug fortran/40443] Elemental procedure in genericl interface incorrectly selected in preference to specific procedure
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-15 07:46 --- Paul, I CC you as you are our generic-resolution expert. * * * gfortran 4.1 to 4.5, NAG f95 5.1, g95, ifort 11, openf95, Sun Studio 12 all print the following: E S, S E E, E ! you expect an S, S here Looking at the following excerpt from Fortran 2003, it looks indeed as if all the compiler get it wrong. Especially, the standard does not assume (to my reading) that the generic resolution depends on the order. However, before changing it, one needs to double check - that several compiler gets it wrong and (of my collection) none gets it correct also happens only rarely. * * * 12.4.4.1 Resolving procedure references to names established to be generic (1) If the reference is consistent with a nonelemental reference to one of the specific interfaces of a generic interface that has that name and either is in the scoping unit in which the reference appears or is made accessible by a USE statement in the scoping unit, the reference is to the specific procedure in the interface block that provides that interface. The rules in 16.2.3 ensure that there can be at most one such specific procedure. (2) If (1) does not apply, if the reference is consistent with an elemental reference to one of the specific interfaces of a generic interface that has that name and either is in the scoping unit in which the reference appears or is made accessible by a USE statement in the scoping unit, the reference is to the specific elemental procedure in the interface block that provides that interface. The rules in 16.2.3 ensure that there can be at most one such specific elemental procedure. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot ||org, burnus at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i586-pc-mingw32 | GCC host triplet|i586-pc-mingw32 | GCC target triplet|i586-pc-mingw32 | Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2009-06-15 07:46:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40443
[Bug fortran/40443] Elemental procedure in genericl interface incorrectly selected in preference to specific procedure
--- Comment #2 from jpr at csc dot fi 2009-06-15 08:28 --- (In reply to comment #1) Paul, I CC you as you are our generic-resolution expert. * * * gfortran 4.1 to 4.5, NAG f95 5.1, g95, ifort 11, openf95, Sun Studio 12 all print the following: E S, S E E, E ! you expect an S, S here FWIW, Portland and Intel compilers both print E S, S E S, S BR, Juha -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40443
[Bug fortran/40440] [4.4/4.5 Regression] Garbage or segmentation fault in allocatable array derived type structures
--- Comment #3 from burnus at gcc dot gnu dot org 2009-06-15 08:52 --- (In reply to comment #2) COmplete code for the test case including the module iso_varying_string Works with: gfortran 4.3.3, ifort 11, sunf95, NAG f95 5.1 (w/o flush statements) Fails (abort) with gfortran 4.4.1/4.5 Valgrind shows several uninitialized accesses (gfortran 4.3.3, 4.4, and 4.5), but no errors with NAG f95 or ifort. Interestingly, it runs through with valgrind + gfortran 4.5, which means that it could be no regression and working in 4.3.3 only by chance. valgrind finds essentially the following two errors with gfortran 4.5: Invalid read of size 1 at 0x4091FC: __iso_varying_string_MOD_char_auto (foo.f90:868) by 0x40B73F: __syntax_rules_MOD_monitor_syntax_rules (foo.f90:3450) by 0x40B8F5: __syntax_rules_MOD_syntax_get_rule_ptr (foo.f90:3431) by 0x40C242: set_children.6490 (foo.f90:3410) by 0x40C933: __syntax_rules_MOD_set_rule_contents (foo.f90:3366) by 0x40E9E5: __syntax_rules_MOD_syntax_init_from_ifile (foo.f90:3287) by 0x412C6E: MAIN__ (foo.f90:3472) Use of uninitialised value of size 8 at 0x40C261: set_children.6490 (foo.f90:3410) by 0x40C933: __syntax_rules_MOD_set_rule_contents (foo.f90:3366) by 0x40E9E5: __syntax_rules_MOD_syntax_init_from_ifile (foo.f90:3287) by 0x412C6E: MAIN__ (foo.f90:3472) by 0x412D09: main (foo.f90:3462) -- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Known to fail||4.4.1 4.5.0 Known to work||4.3.3 Summary|[4.5.0 Regression] Garbage |[4.4/4.5 Regression] Garbage |or segmentation fault in|or segmentation fault in |allocatable array derived |allocatable array derived |type structures |type structures Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40440
[Bug libffi/40385] new testcases bought in by Revision 148285 fail on ia64
--- Comment #4 from dominiq at lps dot ens dot fr 2009-06-15 09:05 ---
I have applied the following patch on revision 148472
diff -up libffi/testsuite/libffi.call/err_bad_abi.c
/opt/gcc/gcc-4.5-work/libffi/testsuite/libffi.call/err_bad_abi.c
--- libffi/testsuite/libffi.call/err_bad_abi.c 2009-06-12 19:21:34.0
+0200
+++ /opt/gcc/gcc-4.5-work/libffi/testsuite/libffi.call/err_bad_abi.c
2009-06-15 00:31:41.0 +0200
@@ -4,7 +4,7 @@
PR: none.
Originator: Blake Chaffin 6/6/2007 */
-/* { dg-do run { xfail mips*-*-* arm*-*-* strongarm*-*-* xscale*-*-*
i*86-*-linux-* x86_64-*-linux-* sh*-*-* } } */
+/* { dg-do run { xfail mips*-*-* arm*-*-* strongarm*-*-* xscale*-*-*
i*86-*-linux-* x86_64-*-linux-* sh*-*-* *-apple-* } } */
#include ffitest.h
static void
diff -up libffi/testsuite/libffi.call/err_bad_typedef.c
/opt/gcc/gcc-4.5-work/libffi/testsuite/libffi.call/err_bad_typedef.c
--- libffi/testsuite/libffi.call/err_bad_typedef.c 2009-06-12
19:21:34.0 +0200
+++ /opt/gcc/gcc-4.5-work/libffi/testsuite/libffi.call/err_bad_typedef.c
2009-06-15 00:31:00.0 +0200
@@ -4,7 +4,7 @@
PR: none.
Originator: Blake Chaffin 6/6/2007 */
-/* { dg-do run { xfail mips*-*-* arm*-*-* strongarm*-*-* xscale*-*-*
i*86-*-linux-* x86_64-*-linux-* sh*-*-* } } */
+/* { dg-do run { xfail mips*-*-* arm*-*-* strongarm*-*-* xscale*-*-*
i*86-*-linux-* x86_64-*-linux-* sh*-*-* *-apple-* } } */
#include ffitest.h
int main (void)
and I get:
=== libffi tests ===
Running target unix
=== libffi Summary for unix ===
# of expected passes1594
# of expected failures 10
# of unsupported tests 15
Running target unix/-m64
FAIL: libffi.call/closure_fn0.c -O0 -W -Wall execution test
FAIL: libffi.call/closure_fn1.c -O0 -W -Wall execution test
FAIL: libffi.call/closure_fn2.c -O0 -W -Wall execution test
FAIL: libffi.call/closure_fn3.c -O0 -W -Wall execution test
FAIL: libffi.call/closure_fn4.c -O0 -W -Wall execution test
FAIL: libffi.call/closure_fn5.c -O0 -W -Wall execution test
FAIL: libffi.call/closure_fn6.c -O0 -W -Wall execution test
FAIL: libffi.call/closure_loc_fn0.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_12byte.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_16byte.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_18byte.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_19byte.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_1_1byte.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_20byte.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_20byte1.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_24byte.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_2byte.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_3_1byte.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_3byte1.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_3byte2.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_4_1byte.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_4byte.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_5_1_byte.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_5byte.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_64byte.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_6_1_byte.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_6byte.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_7_1_byte.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_7byte.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_8byte.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_9byte1.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_9byte2.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_align_double.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_align_float.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_align_longdouble.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_align_longdouble_split.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_align_longdouble_split2.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_align_pointer.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_align_sint16.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_align_sint32.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_align_sint64.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_align_uint16.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_align_uint32.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_align_uint64.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_dbls_struct.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_double.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_double_va.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_float.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_longdouble.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_longdouble_va.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_multi_schar.c -O0 -W -Wall execution test
FAIL: libffi.call/cls_multi_sshort.c -O0 -W -Wall execution test
FAIL:
[Bug tree-optimization/40413] [4.5 Regression] Internal error in connection with optimization and allocatable objects
--- Comment #9 from jamborm at gcc dot gnu dot org 2009-06-15 09:07 --- Created an attachment (id=18001) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18001action=view) Fix This was quite a serious oversight on my part, I wonder how it went for so long unnoticed. I am about to bootstrap and regression test this patch and will submit it if both succeed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40413
[Bug libffi/40385] new testcases bought in by Revision 148285 fail on ia64
--- Comment #5 from aph at gcc dot gnu dot org 2009-06-15 09:07 --- That probably is my fault. However, I can't do anything about it until I see the testsuite log file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40385
[Bug libffi/40385] new testcases bought in by Revision 148285 fail on ia64
--- Comment #6 from aph at gcc dot gnu dot org 2009-06-15 09:08 --- Re http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00929.html: That was answered on Fri, 12 Jun by Kaz Kojima. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40385
[Bug tree-optimization/40432] [4.5 Regression] verify_stmts failed with -O2: non-register as LHS of unary operation
--- Comment #4 from jamborm at gcc dot gnu dot org 2009-06-15 09:09 --- Created an attachment (id=18002) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18002action=view) Fix OK, the statement is fine except that it is not gimple ;-). Fixed with this patch, I will submit it if it passes bootstrap and testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40432
[Bug target/40416] unnecessary register spill
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-15 09:14:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40416
[Bug libffi/40385] new testcases bought in by Revision 148285 fail on ia64
--- Comment #7 from dominiq at lps dot ens dot fr 2009-06-15 09:19 --- That probably is my fault. However, I can't do anything about it until I see the testsuite log file. The log file looks like: ... Executing on host: /opt/gcc/i686-darwin/gcc/xgcc -B/opt/gcc/i686-darwin/gcc/ /opt/gcc/gcc-4.5-work/libffi/testsuite/libffi.call/closure_fn0.c -O0 -W -Wall -I/opt/gcc/i686-darwin/i686-apple-darwin9/x86_64/libffi/include -I/opt/gcc/gcc-4.5-work/libffi/testsuite/../include -I/opt/gcc/i686-darwin/i686-apple-darwin9/x86_64/libffi/include/.. -L/opt/gcc/i686-darwin/i686-apple-darwin9/x86_64/libffi/.libs -L/opt/gcc/i686-darwin/i686-apple-darwin9/x86_64/libstdc++-v3/src/.libs -shared-libgcc -lffi -lm -m64 -o ./closure_fn0.exe(timeout = 300) PASS: libffi.call/closure_fn0.c -O0 -W -Wall (test for excess errors) Setting LD_LIBRARY_PATH to .:/opt/gcc/i686-darwin/gcc:/opt/gcc/i686-darwin/i686-apple-darwin9/x86_64/libffi/.libs:/opt/gcc/i686-darwin/i686-apple-darwin9/x86_64/libstdc++-v3/src/.libs:.:/opt/gcc/i686-darwin/gcc:/opt/gcc/i686-darwin/i686-apple-darwin9/x86_64/libffi/.libs:/opt/gcc/i686-darwin/i686-apple-darwin9/x86_64/libstdc++-v3/src/.libs FAIL: libffi.call/closure_fn0.c -O0 -W -Wall execution test ... Quite terse, isn't it? What would you need precisely? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40385
[Bug c++/32534] gcc fails to initialize template's static data members before their use in some cases
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-06-15 09:19 --- (In reply to comment #0) I can't use template A Bint::a = something; form (which would help) because I have only empty ctor (like in the case of map). I'm not sure what you mean but this works fine: template A Bint::a = A(); -- jwakely dot gcc at gmail dot com changed: What|Removed |Added CC||jwakely dot gcc at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32534
[Bug libffi/40385] new testcases bought in by Revision 148285 fail on ia64
--- Comment #8 from dominiq at lps dot ens dot fr 2009-06-15 09:24 --- That was answered on Fri, 12 Jun by Kaz Kojima. Not exactly, it answered about some future goal of the tests, but without any name of platform(s) on which they work. My implicit question is does it make any sense to add XFAILed platforms instead of *-*-*, if the tests do not pass on any known platform? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40385
[Bug libffi/40385] new testcases bought in by Revision 148285 fail on ia64
--- Comment #9 from aph at gcc dot gnu dot org 2009-06-15 09:29 --- I need to know why it's crashing. Usually there's some sort of error message. If there's not, there's no choice but to debug. This Darwin problem is clearly not the same bug as 40385, so it needs a new Bugzilla entry. I expect that a patch to xfail err_bad_abi.c on *-*-* would be approved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40385
[Bug libffi/40444] New: [4.5 Regression] libffi badly broken with -m64 by some revision between 148383 and 148472.
See comment #4 of pr40385: === libffi Summary for unix === # of expected passes1594 # of expected failures 10 # of unsupported tests 15 Running target unix/-m64 FAIL: libffi.call/closure_fn0.c -O0 -W -Wall execution test ... FAIL: libffi.special/unwindtest.cc -shared-libgcc -lstdc++ execution test === libffi Summary for unix/-m64 === # of expected passes776 # of unexpected failures409 # of expected failures 10 # of unsupported tests 15 === libffi Summary === # of expected passes2370 # of unexpected failures409 # of expected failures 20 # of unsupported tests 30 I have had a look at some crash reports. They look as: [ibook-dhum] gcc/_gcc_clean% cat ~/Library/Logs/CrashReporter/closure_fn0.exe_2009-06-15-074300_ibook-dhum.crash Process: closure_fn0.exe [67697] Path:./closure_fn0.exe Identifier: closure_fn0.exe Version: ??? (???) Code Type: X86-64 (Native) Parent Process: expect [60005] Date/Time: 2009-06-15 07:43:00.456 +0200 OS Version: Mac OS X 10.5.7 (9J61) Report Version: 6 Anonymous UUID: E80146C8-66E0-457D-87E0-4A904418933C Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x000100100210 Crashed Thread: 0 Thread 0 Crashed: 0 ??? 0x000100100210 0 + 4296016400 1 closure_fn0.exe 0x000109f4 start + 52 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x000100100210 rbx: 0x7fff5fbf8c60 rcx: 0x0004 rdx: 0x0003 rdi: 0x0001 rsi: 0x0002 rbp: 0x7fff5fbf8ca0 rsp: 0x7fff5fbf8b88 r8: 0x007f r9: 0x01ad r10: 0x00012150 r11: 0x00014f20 r12: 0x r13: 0x r14: 0x r15: 0x rip: 0x000100100210 rfl: 0x00010246 cr2: 0x000100100210 Binary Images: 0x1 -0x10fff +closure_fn0.exe ??? (???) 6d8a3f27722de7f10c1822591331d4f3 /Volumes/MacBook/opt/gcc/i686-darwin/i686-apple-darwin9/libffi/testsuite/closure_fn0.exe 0x13000 -0x15ff7 +libffi.4.dylib ??? (???) ca0f9c56e408e1f77be7289ad188fc7e /opt/gcc/i686-darwin/i686-apple-darwin9/x86_64/libffi/.libs/libffi.4.dylib 0x1a000 -0x10001eff1 +libgcc_s.1.dylib ??? (???) 28ae595aba1589142c1755e5b0ac38dc /opt/gcc/i686-darwin/gcc/libgcc_s.1.dylib 0x7fff5fc0 - 0x7fff5fc2e643 dyld 97.1 (???) b40847f1ce1ba2ed13837aeccbf19284 /usr/lib/dyld 0x7fff82d7e000 - 0x7fff82f09ffb libSystem.B.dylib ??? (???) 558e10ab4bc6790fd3ee1abd14458085 /usr/lib/libSystem.B.dylib 0x7fff83fe2000 - 0x7fff83fe6fff libmathCommon.A.dylib ??? (???) /usr/lib/system/libmathCommon.A.dylib 0x7fe0 - 0x7fe01780 libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib -- Summary: [4.5 Regression] libffi badly broken with -m64 by some revision between 148383 and 148472. Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libffi AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40444
[Bug libffi/40385] new testcases bought in by Revision 148285 fail on ia64
--- Comment #10 from dominiq at lps dot ens dot fr 2009-06-15 09:42 --- This Darwin problem is clearly not the same bug as 40385, so it needs a new Bugzilla entry. This is now pr40444. I expect that a patch to xfail err_bad_abi.c on *-*-* would be approved. Probably err_bad_typedef.c also. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40385
[Bug c++/32534] gcc fails to initialize template's static data members before their use in some cases
--- Comment #4 from jwakely dot gcc at gmail dot com 2009-06-15 09:55
---
extern C int printf(const char*, ...);
struct A
{
A() : value(1) { printf(A::A %d\n, value); }
int value;
};
templateclass T
struct B
{
static A a;
};
templateclass T A BT::a = A();
templateclass T
struct C
{
C()
{
printf(C::C %d\n, Bint::a.value);
Bint::a.value = 2;
}
};
Cfloat c;
int main()
{
printf(main %d\n, Bint::a.value);
}
compiled with 4.3.2 prints:
C::C 0
A::A 1
main 1
but I expect:
A::A 1
C::C 1
main 2
It seems that the initializer for BT::a runs after the initialization of c,
so although the Bint::a.value gets set by C::C it then gets overwritten by
A::A
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32534
[Bug testsuite/40359] [4.5 Regression] Revision 148211 caused a lot of failures in the vect test suite.
--- Comment #12 from irar at il dot ibm dot com 2009-06-15 09:58 ---
(In reply to comment #9)
The patch in comment #8 fixes the failures reported in comment #7. I now see
(powerpc-apple-darwin9 with -m64):
FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect Alignment of access
forced using versioning 3
Is this target ([istarget *-*-darwin*] [is-effective-target lp64]) (meaning
vector_alignment_reachable is false for it)?
If so, why do we do peeling? And also why in that case it doesn't XPASS
Alignment of access forced using peeling 1 vect?
Otherwise, vector_alignment_reachable is true, and it is not supposed to look
for the versioning string at all (since the target is not vect_no_align,
right?).
It doesn't make sense to me either way...
Revital, maybe you can try to add brackets: { ! { vector_alignment_reachable }
} instead of { ! vector_alignment_reachable} ?
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40359
[Bug bootstrap/40439] [4.5 Regression] Bootstrap broken on FreeBSD in tree.c
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-06-15 10:05 --- Subject: Bug 40439 Author: rguenth Date: Mon Jun 15 10:05:29 2009 New Revision: 148486 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148486 Log: 2009-06-15 Richard Guenther rguent...@suse.de PR middle-end/40439 * tree.c (widest_int_cst_value): Fix bootstrap on 32bit HWI hosts. Modified: trunk/gcc/ChangeLog trunk/gcc/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40439
[Bug middle-end/40439] [4.5 Regression] Bootstrap broken on FreeBSD in tree.c
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-06-15 10:05 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Component|bootstrap |middle-end Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40439
[Bug tree-optimization/40087] [4.3 Regression] Number of iterations analysis wrong
--- Comment #14 from cnstar9988 at gmail dot com 2009-06-15 10:10 --- ping 4.3.4... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40087
[Bug testsuite/40359] [4.5 Regression] Revision 148211 caused a lot of failures in the vect test suite.
--- Comment #13 from eres at il dot ibm dot com 2009-06-15 10:41 ---
Created an attachment (id=18003)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18003action=view)
Patch to fix error in vect-42.c
Ira, thanks for the suggestion!
I deleted an extra space, so now the syntax is {! vector_alignment_reachable}.
Dominique -- if that still does not fix the problem I will try to add more
braces...
Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40359
[Bug c/40442] Option -I and POSIX conformance (c99 utility)
--- Comment #3 from joseph at codesourcery dot com 2009-06-15 10:57 ---
Subject: Re: Option -I and POSIX conformance (c99 utility)
On Mon, 15 Jun 2009, vincent at vinc17 dot org wrote:
This may be true for standard headers, but system directories don't contain
only standard headers: in practice, they generally also contain additional
libraries. And for instance, a -I/usr/include can be useful to override
headers/libraries installed in /usr/local/{include,lib}.
If you have modified the implementation (by putting headers/libraries in
standard directories where those headers/libraries were not provided by
the implementation in those versions in those directories, for example),
you are very definitely outside the scope of POSIX.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40442
[Bug libstdc++/13631] Problems in messages
--- Comment #16 from mrsam at courier-mta dot com 2009-06-15 11:13 --- After staring at the code for a while, I'm leaning towards thinking that this change does not really change the application ABI, so the soname bump is not needed. As far as I can tell, there are no public members of std::messages, so applications never access instances of std::messages, the only thing they do is invoke the inlined methods, which call the virtual methods. I don't think that the addition of a class member affects the instances' vtable. Applications do not construct instances of std::messages. I don't think anything gets exposed that does that, this is done by libstdc++, so as long as libstdc++ gets rebuilt using the new class definition, that's all that's needed. use_facet() does not expose any code that constructs the class, that's done elsewhere. So, without any class members being accessed, and no constructions or destructions occuring as part of the ABI, scratch the soname bump -- I don't think it's needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
[Bug fortran/40443] Elemental procedure in genericl interface incorrectly selected in preference to specific procedure
--- Comment #3 from burnus at gcc dot gnu dot org 2009-06-15 11:24 --- gfortran 4.1 to 4.5, NAG f95 5.1, g95, ifort 11, openf95, Sun Studio 12 all print the following: Correction, ifort 9.1 to 11.1 all print S, S - sorry for missing it. But the other compilers listed above indeed print E, E. FWIW, Portland and Intel compilers both print S, S -- burnus at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2009-06-15 07:46:13 |2009-06-15 11:24:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40443
[Bug libstdc++/13631] Problems in messages
--- Comment #17 from paolo dot carlini at oracle dot com 2009-06-15 11:36 --- Maybe it's because I didn't really look carefully at the patch: aren't you adding a new data member to the class? Changing either size or layout of a type specified in the C++ standard definitely changes the ABI, at least in the rather wide sense we are using in this project. You can find more informations here: http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
[Bug c/40442] Option -I and POSIX conformance (c99 utility)
--- Comment #4 from vincent at vinc17 dot org 2009-06-15 11:59 ---
(In reply to comment #3)
If you have modified the implementation (by putting headers/libraries in
standard directories where those headers/libraries were not provided by
the implementation in those versions in those directories, for example),
you are very definitely outside the scope of POSIX.
I'm not sure I understand what you mean. But the existing practice is that
additional headers/libraries (i.e. not those defined by the C standard)
provided by the vendor are stored under /usr/{include,lib}. And I don't think
this goes against POSIX. Concerning /usr/local, the FHS says:
The /usr/local hierarchy is for use by the system administrator when
installing software locally.
So, it should be safe to add libraries there. And again, this is the existing
practice.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40442
[Bug c++/40434] [C++0x] g++ does not obey 8.3.5p5?!
--- Comment #2 from jwakely dot gcc at gmail dot com 2009-06-15 12:06 --- 8.3.5p5? is that reference right? and I assume you mean line 10, not line 14. The pair(pair) constructor is not in the WP. Commenting it out causes the pair(pairU,V) constructor to be used, which fails to compile (as with the next line.) -- jwakely dot gcc at gmail dot com changed: What|Removed |Added CC||jwakely dot gcc at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40434
[Bug fortran/40440] [4.4/4.5 Regression] Garbage or segmentation fault in allocatable array derived type structures
--- Comment #4 from burnus at gcc dot gnu dot org 2009-06-15 12:16 ---
Note: syntax_get_rule_ptr is defined as:
function syntax_get_rule_ptr (syntax, key) result (rule)
type(syntax_rule_t), pointer :: rule
type(syntax_t), intent(in), target :: syntax
type(string_t), intent(in) :: key
and syntax_rule_set_sub is defined as follows where sub is the relevant
argument:
subroutine syntax_rule_set_sub (rule, i, sub)
type(syntax_rule_t), intent(inout) :: rule
integer, intent(in) :: i
type(syntax_rule_t), intent(in), target :: sub
If one looks at the dump for the following line in set_rule_contents
call syntax_rule_set_sub (rule, i, syntax_get_rule_ptr (syntax,
lexeme_get_contents (lexeme(i+3
one finds:
integer(kind=8) S.297;
struct varying_string D.6550;
D.6550 = lexeme_get_contents ((*lexeme)[(integer(kind=8)) (i + 3) + -1]);
syntax_rule_set_sub ((struct syntax_rule_t *) rule, i,
syntax_get_rule_ptr ((struct syntax_t *) syntax, D.6550));
which looks OK. But then it continues:
if (syntax_get_rule_ptr ((struct syntax_t *) syntax,
D.6550)-keyword.chars.data != 0B)
__builtin_free (syntax_get_rule_ptr ((struct syntax_t *) syntax,
D.6550)-keyword.chars.data);
syntax_get_rule_ptr ((struct syntax_t *) syntax,
D.6550)-keyword.chars.data = 0B;
if (syntax_get_rule_ptr ((struct syntax_t *) syntax,
D.6550)-separator.chars.data != 0B)
__builtin_free (syntax_get_rule_ptr ((struct syntax_t *) syntax,
D.6550)-separator.chars.data);
syntax_get_rule_ptr ((struct syntax_t *) syntax,
D.6550)-separator.chars.data = 0B;
S.297 = 0;
while (1)
{
if (S.297 1) goto L.27;
if (syntax_get_rule_ptr ((struct syntax_t *) syntax,
D.6550)-delimiter[S.297].chars.data != 0B)
__builtin_free (syntax_get_rule_ptr ((struct syntax_t *) syntax,
D.6550)-delimiter[S.297].chars.data);
syntax_get_rule_ptr ((struct syntax_t *) syntax,
D.6550)-delimiter[S.297].chars.data = 0B;
S.297 = S.297 + 1;
}
L.27:;
if (syntax_get_rule_ptr ((struct syntax_t *) syntax,
D.6550)-child.data != 0B)
__builtin_free (syntax_get_rule_ptr ((struct syntax_t *) syntax,
D.6550)-child.data);
syntax_get_rule_ptr ((struct syntax_t *) syntax, D.6550)-child.data = 0B;
if (D.6550.chars.data != 0B)
__builtin_free (D.6550.chars.data);
D.6550.chars.data = 0B;
Thus the problem seems to be that syntax_get_rule_ptr is treated as variable
and not as function call.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40440
[Bug testsuite/40359] [4.5 Regression] Revision 148211 caused a lot of failures in the vect test suite.
--- Comment #14 from dominiq at lps dot ens dot fr 2009-06-15 12:36 ---
(In reply to comment #13)
if that still does not fix the problem I will try to add more braces...
I tried several variants that were not working. The following patch works,
though I have no idea if it is right:
[karma] darwin_buildw/gcc% diff -up
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-42.c
/opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/vect/vect-42.c
--- /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-42.c 2009-06-05
18:02:02.0 +0200
+++ /opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/vect/vect-42.c 2009-06-15
14:17:38.0 +0200
@@ -63,7 +63,7 @@ int main (void)
}
/* { dg-final { scan-tree-dump-times vectorized 2 loops 1 vect } } */
-/* { dg-final { scan-tree-dump-times Alignment of access forced using
versioning 3 vect { target { vect_no_align || { { !
vector_alignment_reachable} {!vect_hw_misalign} } } } } } */
+/* { dg-final { scan-tree-dump-times Alignment of access forced using
versioning 3 vect { target { vect_no_align || { { !
vector_alignment_reachable } vect_hw_misalign } } } } } */
/* { dg-final { scan-tree-dump-times Vectorizing an unaligned access 4
vect { xfail { { vect_no_align || vect_hw_misalign } || { !
vector_alignment_reachable } } } } } */
/* { dg-final { scan-tree-dump-times Alignment of access forced using
peeling 1 vect { xfail { { vect_no_align || vect_hw_misalign } || { !
vector_alignment_reachable } } } } } */
/* { dg-final { cleanup-tree-dump vect } } */
[karma] darwin_buildw/gcc% make -k check-gcc RUNTESTFLAGS=vect.exp=vect-42.c
--target_board=unix'{,-m64}'
...
WARNING: Couldn't find the global config file.
Test Run By dominiq on Mon Jun 15 14:17:58 2009
Native configuration is powerpc-apple-darwin9
=== gcc tests ===
Schedule of variations:
unix
unix/-m64
Running target unix
Using /sw/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /sw/share/dejagnu/config/unix.exp as generic interface file for target.
Using /opt/gcc/gcc-4.5-work/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/vect/vect.exp ...
=== gcc Summary for unix ===
# of expected passes5
Running target unix/-m64
Using /sw/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /sw/share/dejagnu/config/unix.exp as generic interface file for target.
Using /opt/gcc/gcc-4.5-work/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/vect/vect.exp ...
=== gcc Summary for unix/-m64 ===
# of expected passes3
# of expected failures 2
=== gcc Summary ===
# of expected passes8
# of expected failures 2
/opt/gcc/darwin_buildw/gcc/xgcc version 4.5.0 20090614 (experimental) [trunk
revision 148466] (GCC)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40359
[Bug testsuite/40359] [4.5 Regression] Revision 148211 caused a lot of failures in the vect test suite.
--- Comment #15 from dominiq at lps dot ens dot fr 2009-06-15 12:46 --- With the patch in comment #14, on i686-apple-darwin9 I get: === gcc tests === Schedule of variations: unix unix/-m64 Running target unix Using /sw/share/dejagnu/baseboards/unix.exp as board description file for target. Using /sw/share/dejagnu/config/unix.exp as generic interface file for target. Using /opt/gcc/gcc-4.5-work/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/vect/vect.exp ... === gcc Summary for unix === # of expected passes3 # of expected failures 2 Running target unix/-m64 Using /sw/share/dejagnu/baseboards/unix.exp as board description file for target. Using /sw/share/dejagnu/config/unix.exp as generic interface file for target. Using /opt/gcc/gcc-4.5-work/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/vect/vect.exp ... === gcc Summary for unix/-m64 === # of expected passes3 # of expected failures 2 === gcc Summary === # of expected passes6 # of expected failures 4 /Volumes/MacBook/opt/gcc/i686-darwin/gcc/xgcc version 4.5.0 20090614 (experimental) [trunk revision 148472] (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40359
[Bug c/40442] Option -I and POSIX conformance (c99 utility)
--- Comment #5 from joseph at codesourcery dot com 2009-06-15 13:06 ---
Subject: Re: Option -I and POSIX conformance (c99 utility)
On Mon, 15 Jun 2009, vincent at vinc17 dot org wrote:
--- Comment #4 from vincent at vinc17 dot org 2009-06-15 11:59 ---
(In reply to comment #3)
If you have modified the implementation (by putting headers/libraries in
standard directories where those headers/libraries were not provided by
the implementation in those versions in those directories, for example),
you are very definitely outside the scope of POSIX.
I'm not sure I understand what you mean. But the existing practice is that
additional headers/libraries (i.e. not those defined by the C standard)
provided by the vendor are stored under /usr/{include,lib}. And I don't think
this goes against POSIX. Concerning /usr/local, the FHS says:
The /usr/local hierarchy is for use by the system administrator when
installing software locally.
So, it should be safe to add libraries there. And again, this is the existing
practice.
It is not, however, safe to add libraries there that in any way conflict
with the libraries provided by the system in /usr (such as different
versions of the same libraries).
A POSIX-conforming system should have a POSIX conformance document that
explains the circumstances under which the claims of POSIX conformance are
made. Those circumstances will include restrictions on any modification
of system directories, such as limits on the contents of files in /etc for
the system to be conforming and limits on what may go in /usr/local if
some POSIX applications search that directory by default. This document
is nothing to do with GCC on its own; it has to be provided by the system
integrator and describes properties of the whole system. If the document
for the POSIX system you are using is inadequate, you should raise that
with the system integrator (and if necessary with whoever certified
conformance). And if POSIX does not render undefined options that have
the effect of changing internal configuration details of applications,
where those details have to be in a particular form for conformance (for
example, conformance requiring header and library directories in a
particular order), this is a bug in POSIX. -I or -L options pointing to
any of an implementation-defined set of system directories, or any
directory with duplicates of headers or libraries in system directories,
should be undefined behavior.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40442
[Bug fortran/40440] Automatic deallocation component of DT function return value
--- Comment #5 from burnus at gcc dot gnu dot org 2009-06-15 13:09 --- Juergen: Thanks for the report, but it is not a regression - it might not crash with 4.3 (or your 4.4) but I think that's just by chance. Paul, I think also this bug touches code for which you have the expertise. The problem is the automatic deallocation of an allocatable component. The DT with this component is returned by a function but treated as variable and not as function. The crucial part is that the return value is a pointer! If I don't use a pointer, the dump looks as follows: D.1558 = func (); sub (D.1558); if (D.1558.a.data != 0B) __builtin_free (D.1558.a.data); D.1558.a.data = 0B; with POINTER: sub (func ()); if (func ()-a.data != 0B) __builtin_free (func ()-a.data); func ()-a.data = 0B; Testcase: ! implicit none type t integer, allocatable :: A(:) end type t call sub(func()) contains function func() type(t),pointer :: func integer :: i = 0 if (i /= 0) call abort() i = i + 1 end function func subroutine sub(a) type(t), intent(IN),target :: a end subroutine sub end -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot ||org, burnus at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|both MAC OS X Darwin 9.7.0 | |and Linux Debian Edge | Known to fail|4.4.1 4.5.0 |4.4.1 4.5.0 4.3.3 Known to work|4.3.3 | Last reconfirmed|-00-00 00:00:00 |2009-06-15 13:09:45 date|| Summary|[4.4/4.5 Regression] Garbage|Automatic deallocation |or segmentation fault in|component of DT function |allocatable array derived |return value |type structures | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40440
[Bug c++/40445] New: g++ void f() { __builtin_unreachable(); }
Compiling the single line program
void f() { __builtin_unreachable(); }
works fine with gcc, but triggers an ICE when compiled with g++
unreachable.c:1:37: internal compiler error: in remove_insn, at emit-rtl.c:3796
I'm using SVN revision 148487.
--
Summary: g++ void f() { __builtin_unreachable(); }
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wouter dot vermaelen at scarlet dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40445
[Bug fortran/40443] Elemental procedure in genericl interface incorrectly selected in preference to specific procedure
--- Comment #4 from pault at gcc dot gnu dot org 2009-06-15 13:21 --- (In reply to comment #1) Paul, I CC you as you are our generic-resolution expert. Well, gosh golly, that's a mantle that I did not seek:-) Note that my account at the CC address is no longer valid - I'll fix that. In the mean time I will peruse the standard. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40443
[Bug testsuite/40359] [4.5 Regression] Revision 148211 caused a lot of failures in the vect test suite.
--- Comment #16 from eres at il dot ibm dot com 2009-06-15 13:32 ---
-/* { dg-final { scan-tree-dump-times Alignment of access forced using
versioning 3 vect { target { vect_no_align || { { !
vector_alignment_reachable} {!vect_hw_misalign} } } } } } */
+/* { dg-final { scan-tree-dump-times Alignment of access forced using
versioning 3 vect { target { vect_no_align || { { !
vector_alignment_reachable } vect_hw_misalign } } } } } */
hmmm... versioning should not be done for targets that support
vect_hw_misalign...
Although this change fixes the failures it does not seem to be right...
Thanks again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40359
[Bug middle-end/40446] New: [4.4/4.5 Regression] ICE in gen_lowpart_general
#include emmintrin.h
#include complex
#include cstdlib
int
main ()
{
union { __m128d vec; double val[2]; } u;
std::complexdouble c = std::complexdouble(0, 1);
u.vec = _mm_load_pd ((double*)c);
if (u.val[0] != 0 || u.val[1] != 1)
abort ();
}
ICEs with -O1 and above in g++ 4.4 and above. More reduced testcase:
struct S
{
S (double r, double i) { __real__ s = r; __imag__ s = i; }
__complex__ double s;
};
double __attribute__((vector_size (16)))
foo ()
{
S c (0, 1);
return *(double __attribute__((vector_size (16))) *) c;
}
--
Summary: [4.4/4.5 Regression] ICE in gen_lowpart_general
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40446
[Bug bootstrap/40447] New: Add a switch to configure to allow *source* directory of mprt and gmp to be specified.
It's currently possible to build gcc in two ways. 1) Compiler and install mpfr and use switches to indicate the location of their instalation --with-mpfr=/somedirector -- 2) Put directories mpfr and gmp under the source of gcc. What I propose is to allow a couple of extra switches --mpfr-source-dir= --gmp-source-dir= Apart from making installation easier, it would mean anyone doing a 'gcc -v' would know what versions of the mpfr and gmp were used. Dave -- Summary: Add a switch to configure to allow *source* directory of mprt and gmp to be specified. Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: david dot kirkby at onetel dot net GCC build triplet: N/A GCC host triplet: N/A GCC target triplet: N/A http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40447
[Bug middle-end/40446] [4.4/4.5 Regression] ICE in gen_lowpart_general
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40446
[Bug c++/40445] [4.5 Regression] g++ void f() { __builtin_unreachable(); }
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|g++ void f() {|[4.5 Regression] g++ void
|__builtin_unreachable(); } |f() {
||__builtin_unreachable(); }
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40445
[Bug tree-optimization/40087] [4.3 Regression] Number of iterations analysis wrong
--- Comment #15 from mikpe at it dot uu dot se 2009-06-15 14:24 --- (In reply to comment #14) ping 4.3.4... The PR40087 fix depends on changes from the PR39455 fix. Both of them are 4.3 regressions, and I've used both fixes in my 4.3 tree for a while now without issues. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40087
[Bug middle-end/40446] [4.4/4.5 Regression] ICE in gen_lowpart_general
--- Comment #1 from jakub at gcc dot gnu dot org 2009-06-15 14:35 --- Caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=134947 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40446
[Bug middle-end/40446] [4.4/4.5 Regression] ICE in gen_lowpart_general
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-06-15 14:55 --- (In reply to comment #1) Caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=134947 In this case, exposed as VIEW_CONVERT_EXPR was not widely used before so there will be some bugs that we did not hit until that patch :). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40446
[Bug bootstrap/40447] Add a switch to configure to allow *source* directory of mprt and gmp to be specified.
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-15 14:59 --- You can use soft links inside the source directory to say where the source directories are located. Is that good enough? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|Add a switch to configure to|Add a switch to configure to |allow *source* directory of |allow *source* directory of |mprt and gmp to be |mprt and gmp to be |specified. |specified. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40447
[Bug c++/40445] g++ void f() { __builtin_unreachable(); }
--- Comment #1 from hjl dot tools at gmail dot com 2009-06-15 14:59 ---
Why is this a regression? Do we support _builtin_unreachable() in 4.4?
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Summary|[4.5 Regression] g++ void |g++ void f() {
|f() { |__builtin_unreachable(); }
|__builtin_unreachable(); } |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40445
[Bug c++/40445] g++ void f() { __builtin_unreachable(); }
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-06-15 15:00 --- (In reply to comment #1) Why is this a regression? Do we support _builtin_unreachable() in 4.4? Well it is a regression as it compiled before and did not do what the user expected though. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40445
[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475
--- Comment #97 from bonzini at gnu dot org 2009-06-15 15:14 --- Brad, could you try to time compiler.i with and without -ftime-report to see how much of the tree stmt walking timevar is just accounting overhead? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug libffi/40444] [4.5 Regression] libffi badly broken with -m64 by some revision between 148383 and 148472.
--- Comment #1 from aph at gcc dot gnu dot org 2009-06-15 15:47 --- Adding Andreas Tobler; perhaps he knows. -- aph at gcc dot gnu dot org changed: What|Removed |Added CC||andreast at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40444
[Bug libfortran/40344] O32 libgfortran.so fails to link on IRIX 6.5
--- Comment #2 from rwild at gcc dot gnu dot org 2009-06-15 16:11 --- Would it help to work around this issue by collecting the objects in one or more convenience archives and linking those (plus at least one plain object) together to form libgfortran.la? The intermediate partially linked objects could hit a different code path in the linker (but could also cause for some less-optimal linking, at least with LTO?). Of course 'ld -r' has been known to expose other linker bugs so this might be trading one issue for an unknown other set... -- rwild at gcc dot gnu dot org changed: What|Removed |Added CC||rwild at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40344
[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475
--- Comment #98 from lucier at math dot purdue dot edu 2009-06-15 16:11 --- I don't quite understand how you would like me to configure and run the test. First, I've applied your patches to speed up computing DF to my tree; do you want them included in the test, or should I use a pristine mainline? Second, when configuring mainline, should I include, or not include 1. --enable-gather-detailed-mem-stats 2. --enable-checking=release After that, I think you just want to run two compiles with and without -ftime-report, is that right? (Nothing about -fmem-report.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475
--- Comment #99 from paolo dot bonzini at gmail dot com 2009-06-15 16:20 --- Subject: Re: [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475 First, I've applied your patches to speed up computing DF to my tree; do you want them included in the test, or should I use a pristine mainline? It doesn't matter, but yes, use them. Second, when configuring mainline, should I include, or not include 1. --enable-gather-detailed-mem-stats 2. --enable-checking=release Again it shouldn't matter, but use only --enable-checking=release. After that, I think you just want to run two compiles with and without -ftime-report, is that right? (Nothing about -fmem-report.) Yes, and the output of -ftime-report is not needed. Just the time ./cc1 ... output for the two. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug bootstrap/40447] Add a switch to configure to allow *source* directory of mprt and gmp to be specified.
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-06-15 16:53 --- GCC already outputs the version of GMP/MPFR: GNU C (GCC) version 4.5.0 20090519 (experimental) [trunk revision 147718] (i386-apple-darwin8.11.1) compiled by GNU C version 4.5.0 20090519 (experimental) [trunk revision 147718], GMP version 4.2.2, MPFR version 2.4.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40447
[Bug bootstrap/40447] Add a switch to configure to allow *source* directory of mprt and gmp to be specified.
--- Comment #4 from david dot kirkby at onetel dot net 2009-06-15 16:56 --- I assume this is only in your experimental version. I can see that is an improvement. I still think the switch would be useful, but it does reduce the need for it somewhat. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40447
[Bug testsuite/40426] [4.5 Regression] Revision 148408 caused many DWARF tests faulures
--- Comment #3 from jakub at gcc dot gnu dot org 2009-06-15 17:08 ---
Subject: Bug 40426
Author: jakub
Date: Mon Jun 15 17:08:02 2009
New Revision: 148497
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148497
Log:
PR testsuite/40426
* lib/gcc-dg.exp (gcc-dg-debug-runtest): For type -gdwarf-2 and
level != use separate -gdwarf-2 -g${level} options instead of
-gdwarf-2${level}.
* lib/gfortran-dg.exp (gfortran-dg-debug-runtest): Likewise.
* gfortran.dg/debug/pr37738.f: Also skip if -gdwarf-2 -g1.
* gfortran.dg/debug/pr35154-dwarf2.f: Likewise.
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/debug/pr35154-dwarf2.f
trunk/gcc/testsuite/gfortran.dg/debug/pr37738.f
trunk/gcc/testsuite/lib/gcc-dg.exp
trunk/gcc/testsuite/lib/gfortran-dg.exp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40426
[Bug bootstrap/40447] Add a switch to configure to allow *source* directory of mprt and gmp to be specified.
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-06-15 17:19 --- Older versions show the information too: $ echo | gcc -v -x c -c - 21 | fgrep -B1 GMP GNU C (GCC) version 4.3.2 (i686-pc-linux-gnu) compiled by GNU C version 4.3.2, GMP version 4.2.3, MPFR version 2.3.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40447
[Bug bootstrap/40447] Add a switch to configure to allow *source* directory of mprt and gmp to be specified.
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-06-15 17:20 --- Has been true since: r124822 | ghazi | 2007-05-17 19:04:02 -0700 (Thu, 17 May 2007) | 3 lines * toplev.c (print_version): Output GMP/MPFR version info. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40447
[Bug other/40448] New: Incompetable Error when build
Dear GUN team, I came across the following error when I try to compile gcc4.04: /usr/bin/ld: skipping incompatible /usr/lib64//libc.so when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib64//libc.a when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib64/libc.so when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib64/libc.a when searching for -lc /usr/bin/ld: cannot find -lc collect2: ld returned 1 exit status I am very stuck right now, and don't know what to do. My OS is centos3.4(final), the current gcc version is 3.2.3 Could you please help me install gcc4.0.4 on my machine? Thanks in advance! Kai -- Summary: Incompetable Error when build Product: gcc Version: 4.0.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ksong at lbl dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40448
[Bug other/40448] Incompetable Error when build
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-15 17:57 --- You need to install the 32bit userland. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary|Incompetable Error when |Incompetable Error when |build |build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40448
[Bug other/40449] New: Incompetable Error when build
Dear GUN team, I came across the following error when I try to compile gcc4.04: /usr/bin/ld: skipping incompatible /usr/lib64//libc.so when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib64//libc.a when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib64/libc.so when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib64/libc.a when searching for -lc /usr/bin/ld: cannot find -lc collect2: ld returned 1 exit status I am very stuck right now, and don't know what to do. My OS is centos3.4(final), the current gcc version is 3.2.3 Could you please help me install gcc4.0.4 on my machine? Thanks in advance! Kai -- Summary: Incompetable Error when build Product: gcc Version: 4.0.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ksong at lbl dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40449
[Bug other/40449] Incompetable Error when build
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-15 18:00 --- *** This bug has been marked as a duplicate of 40448 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Summary|Incompetable Error when |Incompetable Error when |build |build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40449
[Bug other/40448] Incompatible Error when build
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-06-15 18:00 --- *** Bug 40449 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40448
[Bug fortran/39682] compiler give bus error
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2009-06-15 18:17 --- Without any more information, there's nothing we can do. I tried to reproduce with a simple testcase, but I can't. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39682
[Bug debug/35463] [4.3/4.4 only] typedef missing in debug information with -gdwarf-2 for c++
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|powerpc-apple-darwin9 | Known to fail||4.4.0 Known to work||4.5.0 Last reconfirmed|-00-00 00:00:00 |2009-06-15 18:21:49 date|| Summary|typedef missing in debug|[4.3/4.4 only] typedef |information with -gdwarf-2 |missing in debug information |for c++ |with -gdwarf-2 for c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35463
[Bug other/40448] Incompatible Error when build
--- Comment #3 from ksong at lbl dot gov 2009-06-15 18:21 --- (In reply to comment #1) You need to install the 32bit userland. Thanks for your response. I am not familiar with 32 bit userland. Can you give me more instructions, or links that I can learn more about it? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40448
[Bug target/36241] Executable compiled with -m64 almost three times faster than the one compiled with -m32 on Core2Duo
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-06-15 18:32 --- This is not darwin-specific, I also see it happening on x86_64-linux. And what's more, the output changes between -m32 and -m64. $ cat u.f90 integer(8), parameter :: l = z'5fe6eb3be000' integer, parameter :: ni = 3 integer :: i, j, n integer(8) :: k real(8) :: a, b, e, m, s equivalence (b, k) a = 1.0d0 e = epsilon(1.0)/2.0d0**4 m = 0.0d0 s = 0.0d0 n = 0 do n = n + 1 b = a k = l - ishft(k, -1_8) do i = 1, ni b = b*(1.5-(0.5*a)*b*b) end do b = b + b*(0.5-(0.5*a)*b*b) ! b = 1.0d0/sqrt(a) m = max(m, abs(a*b*b - 1.0d0)) s = s + abs(a*b*b - 1.0d0) a = a + e if (a == 2.0d0) exit end do print *, n, m/epsilon(a), s/(n*epsilon(a)) end $ gfortran -m64 -O3 u.f90 time ./a.out 134217728 2. 0.36966567113995552 ./a.out 3.05s user 0.00s system 100% cpu 3.049 total $ gfortran -m32 -O3 u.f90 time ./a.out 134217728 9.765625000E-004 1.82069155926001258E-004 ./a.out 6.80s user 0.00s system 99% cpu 6.854 total $ gfortran -m32 -O3 u.f90 -ffast-math time ./a.out 134217728 1.464843750E-003 2.97074087939108722E-004 ./a.out 6.74s user 0.00s system 99% cpu 6.743 total $ gfortran -m64 -O3 u.f90 -ffast-math time ./a.out 134217728 3. 0.59681034088134766 ./a.out 3.18s user 0.00s system 99% cpu 3.178 total -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|i686-apple-darwin9 | GCC host triplet|i686-apple-darwin9 | GCC target triplet|i686-apple-darwin9 |i686 Known to fail||4.4.0 4.5.0 Last reconfirmed|2008-05-15 09:06:21 |2009-06-15 18:32:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36241
[Bug fortran/40450] New: [F03] procedure pointer as actual argument
The following program gives a segfault at runtime:
MODULE m
ABSTRACT INTERFACE
SUBROUTINE sub()
END SUBROUTINE sub
END INTERFACE
CONTAINS
SUBROUTINE passf(f)
PROCEDURE(sub), POINTER:: f
CALL callf(f)
END SUBROUTINE passf
SUBROUTINE callf(f)
PROCEDURE(sub), POINTER :: f
PRINT*, 'calling f'
CALL f()
END SUBROUTINE callf
END MODULE m
PROGRAM prog
USE m
PROCEDURE(sub), POINTER :: f
f = s
CALL passf(f)
CONTAINS
SUBROUTINE s
PRINT*, 'sub'
END SUBROUTINE s
END PROGRAM prog
-fdump-tree-original shows that the problem lies in 'passf':
passf (void (*T63) (void) * f)
{
callf (f);
}
--
Summary: [F03] procedure pointer as actual argument
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40450
[Bug target/36241] Executable compiled with -m64 almost three times faster than the one compiled with -m32 on Core2Duo
--- Comment #4 from kargl at gcc dot gnu dot org 2009-06-15 18:44 --- (In reply to comment #3) This is not darwin-specific, I also see it happening on x86_64-linux. And what's more, the output changes between -m32 and -m64. The code is invalid Fortran, so gfortran is not required to give any sensible output. $ cat u.f90 integer(8), parameter :: l = z'5fe6eb3be000' integer, parameter :: ni = 3 integer :: i, j, n integer(8) :: k real(8) :: a, b, e, m, s equivalence (b, k) a = 1.0d0 e = epsilon(1.0)/2.0d0**4 m = 0.0d0 s = 0.0d0 n = 0 do n = n + 1 b = a When you do the assignment to b, k is/becomes undefined. k = l - ishft(k, -1_8) When you do the assignment to k, b becomes undefined. Not to mention, that the RHS uses k, which is undefined. See Section 14.7.6 (1) and (9). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36241
[Bug target/22145] /usr/include/objc/objc-runtime.h on powerpc-darwin7.8.0 needs fixed included
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2009-06-15 18:45 --- I'm not sure it's still present: if I look into the 10.3.9 and the 10.4u headers, I see: #ifdef __cplusplus Class super_class; #else Class class; #endif The 10.5 header is very different, but it doesn't seem affected either. Is this bug still present? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22145
[Bug target/40414] gcc 4.4.0 error at postreload.c:396
--- Comment #3 from gni at gecko dot de 2009-06-15 19:36 --- Subject: gcc 4.4.0 error at postreload.c:396 (In reply to comment #2) Could be a duplicate of one of PR30064, PR34439, PR37053. I compiled the provided testcases as stated in the appropriate PR with the following result: The testcase for PR30064 does ICE with 3.4.6 and 4.[012].0, it doesn't ICE with 4.[34].0. The testcase for PR34439 does ICE with 3.4.6 when not optimizing, does always ICE with 4.[012].0. No ICE with 4.[34].0. The testcase for PR37053 does ICE with 2.95.x without optimization, 3.[34].6 and 4.[012].0 always ICE, 4.[34].0 does ICE with optimization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40414
[Bug rtl-optimization/33928] [4.3/4.4 Regression] 30% performance slowdown in floating-point code caused by r118475
--- Comment #102 from lucier at math dot purdue dot edu 2009-06-15 19:57 --- Subject: Re: [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475 On Mon, 2009-06-15 at 16:20 +, paolo dot bonzini at gmail dot com wrote: Yes, and the output of -ftime-report is not needed. Just the time ./cc1 ... output for the two. Thanks! The two commands: time /pkgs/gcc-mainline/bin/gcc -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp -c compiler.i 261.424u 1.184s 4:22.76 99.9% 0+0k 0+28456io 0pf+0w time /pkgs/gcc-mainline/bin/gcc -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp -c compiler.i -ftime-report 263.424u 4.900s 4:28.68 99.8% 0+0k 0+28480io 0pf+0w -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475
--- Comment #103 from lucier at math dot purdue dot edu 2009-06-15 20:21 --- Regarding comment #101 ... With heine:~/programs/gcc/objdirs/gsc-fft-tests/gambc-v4_1_2 /pkgs/gcc-mainline/bin/gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../../mainline/configure --prefix=/pkgs/gcc-mainline --enable-languages=c --disable-multilib --enable-checking=release Thread model: posix gcc version 4.5.0 20090608 (experimental) [trunk revision 148276] (GCC) (and including Paolo's patch to speed up DF), the routine in direct.c takes 168 ms cpu time (168 user, 0 system) As reported here http://www.math.purdue.edu/~lucier/bugzilla/9/ with gcc-4.2.4, this routine takes 156 ms on the same machine. Comment #9 gives the code that 4.2.4 generates at the start of the main loop; the start of the main loop with the version of 4.5.0 I gave above is: .L2938: movq%rcx, %rdx addq8(%rax), %rdx leaq4(%rcx), %rbx movq%rdx, -8(%rax) leaq4(%rdx), %rdi addq8(%rax), %rdx movq%rdi, -16(%rax) movq%rdx, -24(%rax) leaq4(%rdx), %rdi addq8(%rax), %rdx movq%rdi, -32(%rax) movq%rdx, -40(%rax) leaq4(%rdx), %rdi movq40(%rax), %rdx movq%rdi, -48(%rax) movsd 7(%rdx,%rdi,2), %xmm7 movq-40(%rax), %rdi leaq7(%rdx,%rcx,2), %r8 addq$8, %rcx movsd (%r8), %xmm4 cmpq%rcx, %r13 movsd 7(%rdx,%rdi,2), %xmm10 movq-32(%rax), %rdi movsd 7(%rdx,%rdi,2), %xmm5 movq-24(%rax), %rdi movsd 7(%rdx,%rdi,2), %xmm6 movq-16(%rax), %rdi movsd 7(%rdx,%rdi,2), %xmm13 movq-8(%rax), %rdi movsd 7(%rdx,%rdi,2), %xmm11 leaq(%rbx,%rbx), %rdi movsd 7(%rdi,%rdx), %xmm9 movq24(%rax), %rdx movapd %xmm11, %xmm14 movsd 15(%rdx), %xmm1 movsd 7(%rdx), %xmm2 movapd %xmm1, %xmm8 movsd 31(%rdx), %xmm3 movapd %xmm2, %xmm12 mulsd %xmm10, %xmm8 mulsd %xmm7, %xmm12 mulsd %xmm2, %xmm10 mulsd %xmm1, %xmm7 movsd 23(%rdx), %xmm0 So, to my mind, this is still a 4.5 regression, as there is still a slow-down and the code is still much less optimized by 4.5.0 than by 4.2.4. 168/156 ~ 1.08, so if you want to change the Summary of this bug to 8% regression, or some other things, that's fine, but I've changed this PR back to being a 4.5 regression. I was not really thrilled when Richard marked PR 39157 as a duplicate of this PR. To my mind, there are three more or less independent things---run time of Gambit-generated code, compile time of the code, and the space required to compile the code. This PR is about run time; PR 39157 was about space needed by the compiler; PR 26854 is about compile time. They seem to have all been mushed together. -- lucier at math dot purdue dot edu changed: What|Removed |Added Known to work|4.5.0 | Summary|[4.3/4.4 Regression] 30%|[4.3/4.4/4.5 Regression] 30% |performance slowdown in |performance slowdown in |floating-point code caused |floating-point code caused |by r118475 |by r118475 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug other/36368] Fixincludes corrupts sysmacros.h
--- Comment #3 from geir at cray dot com 2009-06-15 20:47 --- For another point of reference, I see this problem in our GCC 4.3.1 build; but the problem did not occur in our gcc 4.3.0 and 4.3.2 versions. I assume this was an error on our part. $ diff /opt/gcc/4.3.1/snos/lib/gcc/x86_64-suse-linux/4.3.1/include-fixed/sys/sysmacros.h /opt/gcc/4.3.0/snos/lib/gcc/x86_64-suse-linux/4.3.0/include-fixed/sys/sysmacros.h 11c11 Copyright (C) 1996, 1997, 1999, 2003 Free Software Foundation, Inc. --- Copyright (C) 1996, 1997, 1999, 2003, 2004 Free Software Foundation, Inc. 51c51 gnu_dev_major (unsigned long long int __dev) __THROW --- __NTH (gnu_dev_major (unsigned long long int __dev)) 57c57 gnu_dev_minor (unsigned long long int __dev) __THROW --- __NTH (gnu_dev_minor (unsigned long long int __dev)) 63c63 gnu_dev_makedev (unsigned int __major, unsigned int __minor) __THROW --- __NTH (gnu_dev_makedev (unsigned int __major, unsigned int __minor)) $ diff /opt/gcc/4.3.1/snos/lib/gcc/x86_64-suse-linux/4.3.1/include-fixed/sys/sysmacros.h /opt/gcc/4.3.2/snos/lib/gcc/x86_64-suse-linux/4.3.2/include-fixed/sys/sysmacros.h 11c11 Copyright (C) 1996, 1997, 1999, 2003 Free Software Foundation, Inc. --- Copyright (C) 1996, 1997, 1999, 2003, 2004 Free Software Foundation, Inc. 51c51 gnu_dev_major (unsigned long long int __dev) __THROW --- __NTH (gnu_dev_major (unsigned long long int __dev)) 57c57 gnu_dev_minor (unsigned long long int __dev) __THROW --- __NTH (gnu_dev_minor (unsigned long long int __dev)) 63c63 gnu_dev_makedev (unsigned int __major, unsigned int __minor) __THROW --- __NTH (gnu_dev_makedev (unsigned int __major, unsigned int __minor)) $ diff /opt/gcc/4.3.0/snos/lib/gcc/x86_64-suse-linux/4.3.0/include-fixed/sys/sysmacros.h /opt/gcc/4.3.2/snos/lib/gcc/x86_64-suse-linux/4.3.2/include-fixed/sys/sysmacros.h $ -- geir at cray dot com changed: What|Removed |Added CC||geir at cray dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36368
[Bug fortran/40451] New: procedure-pointer assignment rejected
The following program is rejected with: f = sin 1 Error: Interfaces don't match in procedure pointer assignment at (1) However, if one removes the module m; contains it is accepted module m contains function f() intrinsic :: sin procedure(sin), pointer :: f f = sin end function f end module m -- Summary: procedure-pointer assignment rejected Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40451
[Bug fortran/40451] procedure-pointer assignment rejected
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-15 21:10 --- Post script: With your current patch, the error message is: Error: Interface mismatch in procedure pointer assignment at (1): 'sin' has the wrong number of arguments -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40451
[Bug fortran/40452] New: -fbounds-check: False positive due to ignoring storage association
Follow up to PR 37746 / PR 40383. I believe the following program is valid due to the storage association/argument association. However, with -fcheck=bounds one gets: At line 5 of file aa.f90 Fortran runtime error: Actual string length is shorter than the declared one for dummy argument 'a' (2/4) Note: If one changes the actual argument to [ab] or [a,b] both NAG f95 and gfortran are able to diagnose the problem at compile time. For the program below, neither compilers gives a compile-time error/warning. (Nor does NAG with -C=all give a run-time error.) program test implicit none call sub([ab, cd]) contains subroutine sub(a) character(len=4) :: a(1) print *, a(1) end subroutine sub end program test From the standard (F2003, cf. 16.4.3 Storage association): In a storage association context [...] (3) A nonpointer scalar object of type default character and character length len occupies len contiguous character storage units; [...] (7) A nonpointer array occupies a sequence of contiguous storage sequences, one for each array element, in array element order (6.2.2.2); [...] A sequence of storage sequences forms a storage sequence. (And a bit further down one finds a bit more to argument association.) The challenge is diagnose this properly. The problem is that the array size is _not_ passed. One solution would be to enable the check only with -std=f95. I believe the argument association is only allowed since Fortran 2003. Or one does a proper argument checking by checking whether the argument is an array. For this one needs -fcheck=call and save the arguments in some external variable, then one checks whether the current procedure matches the procedure where the global variable stores the argument information - and then uses this information for the array check. Sorry, I don't have any better idea at the moment. Note: The primary use of the argument association is: call c_func(abc) with subroutine c_func(str) bind(C) character(len=1,kind=c_char) :: str(*) as otherwise one had to use 'call c_func([a,b,c])' which is awkward! -- Summary: -fbounds-check: False positive due to ignoring storage association Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40452
[Bug libstdc++/13631] Problems in messages
--- Comment #18 from mrsam at courier-mta dot com 2009-06-15 21:53 --- Yes, the patch does add a new data member to the class. I see that this would fall under item #8 under prohibited changes, although, as I said, AFAIK it won't actually break binary compatibility with existing applications, for the reasons I outlined. I think I see a way of doing this without changing the existing std::messages class, but it's ugly. Basically -- I think I can subclass std::messages and put the new data member into the subclass (__gnu_internal::messages?), then override all the virtual methods and find all places in libstdc++ that instantiate std::messages, and change them to instantiate __gnu_internal::messages. I was able to find two places in libstdc++ that instantiate std::messages, which would be changed to instantiate __gnu_internal::messages instead. If I missed any, the results won't be catastrophic -- I think anything that falls through the cracks would just fall back to using the existing implementation, and that can always be fixed up later. This patch would be bigger and uglier (and I'd still like my first one better), but before I try to write it up, is there any reason, that I'm missing, why this approach wouldn't work? One other detail -- anyone know which version of glibc first had libintl that implemented dgettext()? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
[Bug libstdc++/13631] Problems in messages
--- Comment #19 from paolo dot carlini at oracle dot com 2009-06-15 22:06 --- I think we are definitely going to wait for the next ABI, sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
[Bug libstdc++/13631] Problems in messages
--- Comment #20 from paolo dot carlini at oracle dot com 2009-06-15 22:18 --- One last clarification, maybe necessary because not spelled out (yet) in the docs: really, when we say *ABI* we mean it in a very wide sense, also including linking together objects built with different versions of the headers. All in all, anything changing either the size or the layout of types defined in the C++ standard is certainly a no-no, but there are also many other subtler forbidden changes, as you may easily understand. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
[Bug fortran/40276] Matching GENERIC procedure: Wrong INTENT should give directly an error message
--- Comment #2 from burnus at gcc dot gnu dot org 2009-06-15 22:40 --- Also for OPTIONAL a suitable error message would be useful. For finding a specific interface, the OPTIONAL attribute could be ignored similarly to INTENT; however, one needs to be careful as for ambiguity checks and if the actual argument is not present, the OPTIONAL is still relevant. PURE is another item which should be checked, which is simpler, however. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40276
[Bug fortran/40453] New: Enhanced argument checking:
Follow up to PR 36947/PR 40039. I think there was no PR yet, if not - mark as duplicate. See also PR 40276. I think some other checks should still be added, e.g. a) PUREness check (see example below); passing/assigning a pure to a non-pure dummy/proc-pointer is OK; doing vice versa is not. See 12.4.1.3 (dummy-actual arguments) If the interface of the dummy argument is explicit, the characteristics listed in 12.2 shall be the same for the associated actual argument and the corresponding dummy argument, except that a pure actual argument may be associated with a dummy argument that is not pure and an elemental intrinsic actual procedure may be associated with a dummy procedure (which is prohibited from being elemental). And also 7.4.2.2 (proc-pointer assignment): If proc-pointer-object has an explicit interface, its characteristics shall be the same as proc-target except that proc-target may be pure even if proc-pointer-object is not pure and proc-target may be an elemental intrinsic procedure even if proc-pointer-object is not elemental. b) Similarly for ELEMENTAL. For proc-pointer assignments, use the first example with PURE changed to ELEMENTAL. That non-intrinsic elementals are not allowed as actual argument, is already checked for (cf. C1228). Except of the remark in parentheses I could not find in F2003/F2008 anything which prohibits ELEMENTAL for the dummy argument; however, the parentheses is normative. Maybe one should re-check the standard before adding an error check (see example below). c) One needs to go recursively over the arguments as the second example below shows. PROGRAM PURENESS implicit none interface subroutine one(a,b,c,d,e,f,g,h,i) implicit none integer,intent(in) :: a,b,c,d,e,f,g,h,i end subroutine one pure subroutine two(a,b,c,d,e,f,g,h,i) implicit none integer,intent(in) :: a,b,c,d,e,f,g,h,i end subroutine two end interface procedure(two), pointer :: ptr ptr = one ! Invalid: (pure) = (unpure) end program pureness program RecursiveInterface interface subroutine a(x) real :: x end subroutine a subroutine b(a) integer :: a end subroutine b subroutine c(f) procedure(a) :: f end subroutine c subroutine d(f) procedure(b) :: f end subroutine d subroutine e(f) procedure(c) :: f end subroutine e end interface call e(d) ! Argument (dummy subroutine) d has an integer argument ! but e's f expects a real argument end program RecursiveInterface interface elemental subroutine a() ! Expected: Warning: ELEMENTAL procedure ! without arguments ! (Having ELEMENTAL does not make much sense without arguments, but ! it is valid) end subroutine a subroutine sub(f) interface elemental subroutine f(a) integer,intent(IN) :: a end subroutine f end interface ! Invalid per 12.4.1.3? ! an elemental intrinsic actual procedure may be associated with ! a dummy procedure (which is prohibited from being elemental). ! ! Todo: Find it elsewhere in the standard - or in the corrigenda; ! other compilers accept it. However, the part above is normative end subroutine sub end interface end program elementalCheck -- Summary: Enhanced argument checking: Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40453
[Bug middle-end/39254] [4.4/4.5 Regression] gcc.c-torture/execute/va-arg-trap-1.c ICEs on powerpc-apple-darwin9
--- Comment #14 from dje at gcc dot gnu dot org 2009-06-15 23:06 --- This patch also fixes the gcc.c-torture/compile/pr34688.c failures. RTL-PRE finds RTL with deep LABEL_REFs. When it creates a move, the emit_use and the REG_NOTE on the move itself share RTL. I suspect we need to apply the patch and deal with the fall-out separately. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39254
[Bug libstdc++/13631] Problems in messages
--- Comment #21 from peturrun at gmail dot com 2009-06-15 23:10 --- Isn't it possible to add more data to messages without breaking the ABI by changing the type of one of the existing members? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
[Bug libstdc++/13631] Problems in messages
--- Comment #22 from paolo dot carlini at oracle dot com 2009-06-15 23:14 --- A patch would help understanding what you exactly mean, at the moment, I'm skeptical. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
[Bug c/40454] New: GCC 4.4.0 vs 3.4.0 - PNGCrush is about 20% slower when compiled with GCC 4.4.0
Hi, I notice that PNGCrush compiled with GCC 4.4.0 (release) is about 20% slower compared to GCC 3.4.0 build. (Amiga 68...@50mhz). CFLAGS = -I. -DNO_FSEEKO -O2 -fomit-frame-pointer -Wall -m68060 -s PNGCrush test.png out.png Here are the results: GCC 3.4.0 build: CPU time used = 267.340 seconds (decoding 16.940, encoding 247.800, other 2.600 seconds) GCC 4.4.0 build: CPU time used = 328.360 seconds (decoding 16.800, encoding 309.260, other 2.300 seconds) Maybe someone with m68k Debian/PPC/x86 can compile PNGCrush with GCC 3.4.0 and GCC 4.4.0, so we will know if this regression happens there too? Here is a link to the source code (I used PNGCrush 1.6.15 for test): http://sourceforge.net/project/showfiles.php?group_id=1689package_id=1641 Here is a link to PNG image: http://www.filejumbo.com/Download/D8F7981723E5F07C/ Regards -- Summary: GCC 4.4.0 vs 3.4.0 - PNGCrush is about 20% slower when compiled with GCC 4.4.0 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ami_stuff at o2 dot pl GCC host triplet: i686-cygwin GCC target triplet: m68k-amigaos http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40454
[Bug c/40435] [4.5 regression] Many regressions on trunk
--- Comment #4 from hp at gcc dot gnu dot org 2009-06-16 02:28 --- Mee too! I mean, seen for cris-elf too! BTW, isn't it odd that for recent regressions, the committer's testing never seem to have shown the regressions seen by every other target after commit? 1/2 ;) (Definitely _not_ just you, Aldy.) -- hp at gcc dot gnu dot org changed: What|Removed |Added CC||hp at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-16 02:28:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40435
[Bug c/40435] [4.5 regression] Many regressions on trunk
--- Comment #5 from hp at gcc dot gnu dot org 2009-06-16 02:36 --- To add something useful, I should have mentioned that they were ok for 148440, regressed for 148444 for cris-elf, so that leaves only commit's from Aldy and Steven B., IIUC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40435
[Bug libstdc++/13631] Problems in messages
--- Comment #23 from mrsam at courier-mta dot com 2009-06-16 03:51 --- Created an attachment (id=18004) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18004action=view) Revised patch Well, this is approximately what I have in mind. Aside from the formatting style, which I can clean up, as far as I can tell no existing classes get modified. -- mrsam at courier-mta dot com changed: What|Removed |Added Attachment #17994|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
[Bug tree-optimization/39455] [4.3 Regression] ICE : in compare_values_warnv, at tree-vrp.c:1073
--- Comment #13 from cnstar9988 at gmail dot com 2009-06-16 03:54 --- ping 4.3.4... -- cnstar9988 at gmail dot com changed: What|Removed |Added CC||cnstar9988 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39455
[Bug tree-optimization/39455] [4.3 Regression] ICE : in compare_values_warnv, at tree-vrp.c:1073
--- Comment #14 from cnstar9988 at gmail dot com 2009-06-16 03:56 --- ping 4.3.4... The PR40087 fix depends on changes from the this fix, thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39455
[Bug c/40435] [4.5 regression] Revision 148442 caused many regressions on trunk
--- Comment #6 from hjl dot tools at gmail dot com 2009-06-16 04:30 --- All regressions are caused by revision 148442, including gcc.dg/func-ptr-conv-1.c. You may need to enable checking to see it. -- hjl dot tools at gmail dot com changed: What|Removed |Added Summary|[4.5 regression] Many |[4.5 regression] Revision |regressions on trunk|148442 caused many ||regressions on trunk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40435
[Bug bootstrap/40455] New: gcc trunk does not bootstrap as of commit r148408
As of commit r148408, http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg00388.html, gcc trunk does not bootstrap on cygwin using configure like this: ../gcc/configure --enable-threads=posix --enable-libgcj --disable-sjlj-exceptions --with-system-zlib --enable-nls --enable-static --enable-shared --enable-shared-libgcc --enable-__cxa_atexit --disable-libmudflap --enable-version-specific-runtime-libs --without-included-gettext --with-dwarf2 --disable-symvers --enable-libssp --with-mpc --without-ppl --without-cloog --enable-languages=c,c++ Configuring stage 2 in ./intl configure: creating cache ./config.cache checking whether make sets $(MAKE)... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether NLS is requested... yes checking for msgfmt... /usr/bin/msgfmt checking for gmsgfmt... /usr/bin/msgfmt checking for xgettext... /usr/bin/xgettext checking for msgmerge... /usr/bin/msgmerge checking for i686-pc-cygwin-gcc... /usr/local/src/trunk/objdir/./prev-gcc/xgcc -B/usr/local/src/trunk/objdir/./prev-gcc/ -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include -isystem /usr/local/i686-pc-cygwin/sys-include checking for C compiler default output file name... a.exe checking whether the C compiler works... configure: error: in `/usr/local/src/trunk/objdir/intl': configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. make[2]: *** [configure-stage2-intl] Error 1 make[2]: Leaving directory `/usr/local/src/trunk/objdir' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/usr/local/src/trunk/objdir' make: *** [all] Error 2 nd looking into intl/config.log I see this: This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by configure, which was generated by GNU Autoconf 2.59. Invocation command line was $ /usr/local/src/trunk/gcc/intl/configure --cache-file=./config.cache --enable-threads=posix --enable-libgcj --disable-sjlj-exceptions --with-system-zlib --enable-nls --enable-static --enable-shared --enable-shared-libgcc --enable-__cxa_atexit --disable-libmudflap --enable-version-specific-runtime-libs --without-included-gettext --with-dwarf2 --disable-symvers --enable-libssp --with-mpc --without-ppl --without-cloog --enable-languages=c,c++ --program-transform-name=s,y,y, --build=i686-pc-cygwin --host=i686-pc-cygwin --target=i686-pc-cygwin --srcdir=../../gcc/intl --with-build-libsubdir=. --enable-werror-always ## - ## ## Platform. ## ## - ## hostname = snip uname -m = i686 uname -r = 1.7.0(0.210/5/3) uname -s = CYGWIN_NT-5.1 uname -v = 2009-05-06 14:21 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = i686 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/local/src/trunk/objdir/i686-pc-cygwin/libstdc++-v3/.libs PATH: /usr/local/src/trunk/objdir/i686-pc-cygwin/libssp/.libs PATH: /usr/local/src/trunk/objdir/./gcc/shlib PATH: /usr/local/src/trunk/objdir/./prev-gcc/shlib PATH: /usr/local/src/trunk/objdir/i686-pc-cygwin/libstdc++-v3/.libs PATH: /usr/local/src/trunk/objdir/i686-pc-cygwin/libssp/.libs PATH: /usr/local/src/trunk/objdir/./gcc/shlib PATH: /usr/local/src/trunk/objdir/./prev-gcc/shlib PATH: /usr/local/bin PATH: /usr/bin PATH: /bin PATH: /usr/X11R6/bin snip ## --- ## ## Core tests. ## ## --- ## configure:1229: creating cache ./config.cache configure:1338: checking whether make sets $(MAKE) configure:1358: result: yes configure:1406: checking for a BSD-compatible install configure:1472: result: /usr/bin/install -c configure:1497: checking whether NLS is requested configure:1506: result: yes configure:1544: checking for msgfmt configure:1575: result: /usr/bin/msgfmt configure:1584: checking for gmsgfmt configure:1615: result: /usr/bin/msgfmt configure:1654: checking for xgettext configure:1685: result: /usr/bin/xgettext configure:1725: checking for msgmerge configure:1755: result: /usr/bin/msgmerge configure:1798: checking for i686-pc-cygwin-gcc configure:1824: result: /usr/local/src/trunk/objdir/./prev-gcc/xgcc -B/usr/local/src/trunk/objdir/./prev-gcc/ -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include -isystem /usr/local/i686-pc-cygwin/sys-include configure:2108: checking for C compiler version configure:2111: /usr/local/src/trunk/objdir/./prev-gcc/xgcc -B/usr/local/src/trunk/objdir/./prev-gcc/ -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include -isystem /usr/local/i686-pc-cygwin/sys-include--version /dev/null 5 xgcc (GCC)
