Re: [Bug c++/45462] Bad optimization in -O3 sometimes
I am not talking about a library solution at all. I am talking about a solution inside the compiler. Gcc will optimize memcpy; how much for MIPS is a good question. Try it out and see. Oh if you are using scei's gcc you really should be reporting issues to them. On Aug 31, 2010, at 10:03 PM, yotambarnoy at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #8 from yotambarnoy at gmail dot com 2010-09-01 05:03 --- Unfortunately, a lib based solutions are difficult for me to implement. The reason is that the current PSP SDK uses newlib. I can probably change my personal toolchain with some work, but then it's a custom modification that needs to be replicated to every other ScummVM dev as well as our buildbot. Not impossible, but not work I'd like to get in to right now. In any case, it sounds like what you're saying is that memcpy has asm instructions in the right place to use lwl and lwr. I can also do that in my implementation. My request was more general, as in gcc needs some kind of custom keyword to tell it to allow unaligned pointers and to generate appropriate unaligned code, so we don't have to trick the compiler into doing it in a way that ruins optimization. Something like __unaligned__ uint32 *ptr32 = bytePtr; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45462
[Bug c++/45462] Bad optimization in -O3 sometimes
--- Comment #9 from pinskia at gmail dot com 2010-09-01 06:17 --- Subject: Re: Bad optimization in -O3 sometimes I am not talking about a library solution at all. I am talking about a solution inside the compiler. Gcc will optimize memcpy; how much for MIPS is a good question. Try it out and see. Oh if you are using scei's gcc you really should be reporting issues to them. On Aug 31, 2010, at 10:03 PM, yotambarnoy at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #8 from yotambarnoy at gmail dot com 2010-09-01 05:03 --- Unfortunately, a lib based solutions are difficult for me to implement. The reason is that the current PSP SDK uses newlib. I can probably change my personal toolchain with some work, but then it's a custom modification that needs to be replicated to every other ScummVM dev as well as our buildbot. Not impossible, but not work I'd like to get in to right now. In any case, it sounds like what you're saying is that memcpy has asm instructions in the right place to use lwl and lwr. I can also do that in my implementation. My request was more general, as in gcc needs some kind of custom keyword to tell it to allow unaligned pointers and to generate appropriate unaligned code, so we don't have to trick the compiler into doing it in a way that ruins optimization. Something like __unaligned__ uint32 *ptr32 = bytePtr; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45462 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45462
[Bug fortran/45474] New: Missing definable check actuals to INTENT(INOUT) dummies of intrinsics
No error is printed for:
call execute_command_line(date, .true.,(1),(1),('aa'))
end
although the third to fifth argument are declared as INTENT(INOUT) in
intrinsic.c and thus they have to be definable. The example is for
execute_command_line, but I think it applies to all intrinsics.
--
Summary: Missing definable check actuals to INTENT(INOUT) dummies
of intrinsics
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: accepts-invalid
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=45474
[Bug fortran/45474] Missing definable check actuals to INTENT(INOUT) dummies of intrinsics
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-01 08:34:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45474
[Bug target/44670] arm port fails to build with --enable-build-with-cxx
--- Comment #1 from ramana at gcc dot gnu dot org 2010-09-01 08:49 --- This is partially subsumed by the other bug at PR45444 *** This bug has been marked as a duplicate of 45444 *** -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44670
[Bug bootstrap/45444] [4.6 regression] ARM bootstrap failure: uninitialized const member in 'neon_builtin_datum' is invalid in C++ [-Werror=c++-compat]
--- Comment #3 from ramana at gcc dot gnu dot org 2010-09-01 08:49 --- *** Bug 44670 has been marked as a duplicate of this bug. *** -- ramana at gcc dot gnu dot org changed: What|Removed |Added CC||amylaar at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45444
[Bug tree-optimization/45470] [4.6 Regression] ICE: verify_flow_info failed: BB 2 can not throw but has an EH edge with -ftree-vectorize -fnon-call-exceptions
--- Comment #3 from irar at il dot ibm dot com 2010-09-01 09:06 --- r163260 only made this BB vectorizable. I checked lookup_stmt_eh_lp for the last stmt of the BB and EDGE_EH flags before and after vectorization (basic block SLP), and in both cases lookup_stmt_eh_lp returns 0 and there is an EH edge from the basic block. I also tried to add cleanup_eh pass after SLP. If is somewhere before pass_tree_loop_done, there is no ICE: Index: passes.c === --- passes.c(revision 163538) +++ passes.c(working copy) @@ -925,6 +925,7 @@ init_optimization_passes (void) NEXT_PASS (pass_parallelize_loops); NEXT_PASS (pass_loop_prefetch); NEXT_PASS (pass_iv_optimize); + NEXT_PASS (pass_cleanup_eh); NEXT_PASS (pass_tree_loop_done); } NEXT_PASS (pass_cse_reciprocals); If cleanup_eh is scheduled after tree_loop_done, there is ICE: Index: passes.c === --- passes.c(revision 163538) +++ passes.c(working copy) @@ -926,6 +926,7 @@ init_optimization_passes (void) NEXT_PASS (pass_loop_prefetch); NEXT_PASS (pass_iv_optimize); NEXT_PASS (pass_tree_loop_done); + NEXT_PASS (pass_cleanup_eh); } NEXT_PASS (pass_cse_reciprocals); NEXT_PASS (pass_reassoc); -- irar at il dot ibm dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-01 09:06:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45470
[Bug tree-optimization/42172] inefficient bit fields assignments
--- Comment #6 from ramana at gcc dot gnu dot org 2010-09-01 09:07 --- Leaving this open as per comment #4 -- 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 |2010-09-01 09:07:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42172
[Bug tree-optimization/42172] inefficient bit fields assignments
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42172
[Bug lto/45475] New: target use in libcpp breaks LTO bootstrap
I know I'm at least partly to blame for this :) With a LTO bootstrap I get now /home/ak/gcc/git/gcc/libcpp/lex.c:2838:1: sorry, unimplemented: gimple bytecode streams do not support the target attribute because of the new __target__ use in libcpp/lex.c -- Summary: target use in libcpp breaks LTO bootstrap Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: andi-gcc at firstfloor dot org GCC host triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45475
[Bug target/45476] New: libgcc should contain TFmode functions
As the Fortran front-end now uses soft-float quad precision floating-point
types (__float128 and its complex counterpart), it would be nice for libgcc to
contain TFmode functions on Intel/darwin.
This is present on *86*-{linux,mingw,solaris} and ia64-{linux,hpux}. It was
recently introduced in *86*-freebsd, see patch at
http://gcc.gnu.org/ml/gcc-patches/2010-08/msg02139.html
--
Summary: libgcc should contain TFmode functions
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
GCC target triplet: *86*-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45476
[Bug bootstrap/45444] [4.6 regression] ARM bootstrap failure: uninitialized const member in 'neon_builtin_datum' is invalid in C++ [-Werror=c++-compat]
--- Comment #4 from amylaar at gcc dot gnu dot org 2010-09-01 09:38 --- The 'uninitialized const members' warning also affects cross builds when using --enable-build-with-cxx, see PR44670 -- amylaar at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||44433 nThis|| GCC host triplet|armv5tel-unknown-linux- |armv5tel-unknown-linux- |gnueabi |gnueabi, i686-pc-linux-gnu GCC target triplet||*-arm-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45444
[Bug lto/45475] target use in libcpp breaks LTO bootstrap
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-09-01 09:42 --- The problem is of course that the target and optimization attribute data format is auto-generated. A solution would be to simply byte-copy TREE_TARGET_OPTION with pre-pending its size and check the size on LTO read-in. Of course that will introduce another host-dependency on the LTO byte format (so eventually store a magic 0x11223344 integer value as well). -- 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 |2010-09-01 09:42:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45475
[Bug tree-optimization/45470] [4.6 Regression] ICE: verify_flow_info failed: BB 2 can not throw but has an EH edge with -ftree-vectorize -fnon-call-exceptions
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-09-01 09:43 --- I'll have a look. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45470
[Bug c++/45462] Bad optimization in -O3 sometimes
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-09-01 09:45
---
(In reply to comment #8)
Unfortunately, a lib based solutions are difficult for me to implement. The
reason is that the current PSP SDK uses newlib. I can probably change my
personal toolchain with some work, but then it's a custom modification that
needs to be replicated to every other ScummVM dev as well as our buildbot. Not
impossible, but not work I'd like to get in to right now.
In any case, it sounds like what you're saying is that memcpy has asm
instructions in the right place to use lwl and lwr. I can also do that in my
implementation.
My request was more general, as in gcc needs some kind of custom keyword to
tell it to allow unaligned pointers and to generate appropriate unaligned
code,
so we don't have to trick the compiler into doing it in a way that ruins
optimization. Something like __unaligned__ uint32 *ptr32 = bytePtr;
typedef my_unaligned_aliasing_uint32 uint32
__attribute__((aligned(1),may_alias));
inline __attribute__((__always_inline__)) uint32 READ_UINT32(const void *ptr)
{
return *(const my_unaligned_aliasing_uint32 *)ptr;
}
should do it and does not require -fno-strict-aliasing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45462
[Bug rtl-optimization/45472] [4.5/4.6 Regression] ICE: in move_op_ascend, at sel-sched.c:6124 with -fselective-scheduling2
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472
[Bug target/45476] libgcc should contain TFmode functions
--- Comment #1 from ubizjak at gmail dot com 2010-09-01 10:12 --- Intel/darwin already supports __float128. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45476
[Bug lto/45477] New: target use in libcpp breaks LTO bootstrap
I know I'm at least partly to blame for this :) With a LTO bootstrap I get now /home/ak/gcc/git/gcc/libcpp/lex.c:2838:1: sorry, unimplemented: gimple bytecode streams do not support the target attribute because of the new __target__ use in libcpp/lex.c -- Summary: target use in libcpp breaks LTO bootstrap Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: andi-gcc at firstfloor dot org GCC host triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45477
[Bug lto/45477] target use in libcpp breaks LTO bootstrap
--- Comment #1 from andi-gcc at firstfloor dot org 2010-09-01 10:14 --- Working on a fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45477
[Bug lto/45475] target use in libcpp breaks LTO bootstrap
--- Comment #2 from andi-gcc at firstfloor dot org 2010-09-01 10:15 --- Yes, I have most of a patch already, but will add the check value. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45475
[Bug tree-optimization/45470] [4.6 Regression] ICE: verify_flow_info failed: BB 2 can not throw but has an EH edge with -ftree-vectorize -fnon-call-exceptions
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-09-01 10:19 ---
I see before SLP:
bb 2:
MEM[(struct A *)this_1(D)].a = 0;
MEM[(struct A *)this_1(D)].b = 0;
MEM[(struct A *)this_1(D)].c = 0;
[LP 2] MEM[(struct A *)this_1(D) + 12B].a = 0;
and after:
bb 2:
vect_cst_.1_16 = { 0, 0, 0, 0 };
vect_p.5_17 = MEM[(struct A *)this_1(D)].a;
M*vect_p.5_17{misalignment: 0} = vect_cst_.1_16;
so EH info has not been properly transfered. Now that only
MEM[(struct A *)this_1(D) + 12B].a can throw internally but not
MEM[(struct A *)this_1(D)].c = 0; is a fact that the frontend establishes.
The following mitigates the problem by simply removing the dead EH edges.
Index: gcc/tree-vect-slp.c
===
--- gcc/tree-vect-slp.c (revision 163721)
+++ gcc/tree-vect-slp.c (working copy)
@@ -2474,6 +2474,9 @@ vect_schedule_slp (loop_vec_info loop_vi
}
}
+ if (bb_vinfo)
+gimple_purge_dead_eh_edges (BB_VINFO_BB (bb_vinfo));
+
return is_store;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45470
[Bug target/45476] libgcc should contain TCmode functions
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2010-09-01 10:21
---
It partially does. But TC functions are missing:
$ cat a.c
typedef _Complex float __attribute__((mode(TC))) __complex128;
__complex128 foo (__complex128 z1, __complex128 z2) {
return z1 * z2; }
__complex128 bar (__complex128 z1, __complex128 z2) {
return z1 / z2; }
int main (void) {
(void) foo (0, 0);
return 0;
}
$ ./bin/gcc a.c -W -Wall
Undefined symbols:
___divtc3, referenced from:
_bar in ccqf0ZEK.o
___multc3, referenced from:
_foo in ccqf0ZEK.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
$ ./bin/gcc -v
Using built-in specs.
COLLECT_GCC=./bin/gcc
COLLECT_LTO_WRAPPER=/Users/fx/devel/gcc/irun/libexec/gcc/x86_64-apple-darwin10.4.0/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10.4.0
Configured with: ../trunk/configure --prefix=/Users/fx/devel/gcc/irun
--with-gmp=/Users/fx/devel/gcc/deps --enable-languages=c,fortran --without-ppl
Thread model: posix
gcc version 4.6.0 20100901 (experimental) [trunk revision 163721] (GCC)
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
Summary|libgcc should contain TFmode|libgcc should contain TCmode
|functions |functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45476
[Bug target/45476] libgcc should contain TCmode functions
--- Comment #3 from ubizjak at gmail dot com 2010-09-01 10:30 --- (In reply to comment #2) It partially does. But TC functions are missing: Ah, I see. Put these defines somewhere: /* Put all *tf routines in libgcc. */ #undef LIBGCC2_HAS_TF_MODE #define LIBGCC2_HAS_TF_MODE 1 #define LIBGCC2_TF_CEXT q #define TF_SIZE 113 -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-01 10:30:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45476
[Bug target/45478] New: ICE: in c_builtin_function_ext_scope, at c-decl.c:2852 with -mno-sse/-march=i386
Command line: $ gcc -mno-sse testcase.c or $ gcc -m32 -march=i386 testcase.c (or other target without sse support) Compiler output: $ gcc -mno-sse testcase.c testcase.c:9: internal compiler error: in c_builtin_function_ext_scope, at c-decl.c:2852 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r163636 - crash 4.4 r149995 - crash -- Summary: ICE: in c_builtin_function_ext_scope, at c-decl.c:2852 with -mno-sse/-march=i386 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz GCC target triplet: x86(_64)-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45478
[Bug target/43588] ICE in copy_to_mode_reg, at explow.c:635
--- Comment #1 from ramana at gcc dot gnu dot org 2010-09-01 10:31 --- I'm not sure how well supported the old Linux target is with respect to the Neon builtins. It never received much testing and probably needs work since this target is in maintenance mode only. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P4 Last reconfirmed|-00-00 00:00:00 |2010-09-01 10:31:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43588
[Bug target/45478] ICE: in c_builtin_function_ext_scope, at c-decl.c:2852 with -mno-sse/-march=i386
--- Comment #1 from zsojka at seznam dot cz 2010-09-01 10:33 --- Created an attachment (id=21632) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21632action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45478
[Bug rtl-optimization/44025] Multiple load 0 to register
--- Comment #2 from ramana at gcc dot gnu dot org 2010-09-01 10:34 --- I'm not sure where this will be handled but I can see this with trunk today. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2010-09-01 10:34:47 date|| Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44025
[Bug lto/45475] target use in libcpp breaks LTO bootstrap
--- Comment #3 from andi-gcc at firstfloor dot org 2010-09-01 10:36 --- *** Bug 45477 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45475
[Bug lto/45477] target use in libcpp breaks LTO bootstrap
--- Comment #2 from andi-gcc at firstfloor dot org 2010-09-01 10:36 --- *** This bug has been marked as a duplicate of 45475 *** -- andi-gcc at firstfloor dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45477
[Bug tree-optimization/44328] switch/case optimization produces an invalid lookup table index
--- Comment #27 from jamborm at gcc dot gnu dot org 2010-09-01 11:10 --- As far as I understand it, this is fixed with http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00577.html -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug testsuite/42855] FAIL: gcc.dg/tree-ssa/pr42585.c scan-tree-dump-times optimized *
--- Comment #9 from jamborm at gcc dot gnu dot org 2010-09-01 11:13 --- Fixed. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42855
[Bug tree-optimization/44328] switch/case optimization produces an invalid lookup table index
--- Comment #28 from jamborm at gcc dot gnu dot org 2010-09-01 11:23 --- Hm, no, I was too quick pruning my inbox. The patch apparently has not been applied to the 4.5 branch. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug tree-optimization/44328] switch/case optimization produces an invalid lookup table index
--- Comment #29 from jamborm at gcc dot gnu dot org 2010-09-01 11:24 --- I'll do that, hopefully sooner rather than later. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|REOPENED|ASSIGNED Last reconfirmed|2010-07-05 13:43:01 |2010-09-01 11:24:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug tree-optimization/44328] switch/case optimization produces an invalid lookup table index
--- Comment #30 from ibolton at gcc dot gnu dot org 2010-09-01 11:25 --- (In reply to comment #28) Hm, no, I was too quick pruning my inbox. The patch apparently has not been applied to the 4.5 branch. It's on its way. I've been testing in conjunction with a couple of other backports and ran into some issues unrelated to this patch. I'm hoping to be ready to apply to 4.5 tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug tree-optimization/44328] switch/case optimization produces an invalid lookup table index
--- Comment #31 from jamborm at gcc dot gnu dot org 2010-09-01 11:32 --- (In reply to comment #30) (In reply to comment #28) Hm, no, I was too quick pruning my inbox. The patch apparently has not been applied to the 4.5 branch. It's on its way. I've been testing in conjunction with a couple of other backports and ran into some issues unrelated to this patch. I'm hoping to be ready to apply to 4.5 tomorrow. OK, reassigning to you then. Please do not forget to add a hunk adding the new dependence of tree-switch-conversion.o in Makefile.in. Thanks. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jamborm at gcc dot gnu dot |ibolton at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug tree-optimization/44328] switch/case optimization produces an invalid lookup table index
--- Comment #32 from jifl-bugzilla at jifvik dot org 2010-09-01 11:47 --- I don't know if there are plans for more releases in the 4.4 series, but can it be applied to the 4.4 branch too? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug tree-optimization/44328] switch/case optimization produces an invalid lookup table index
--- Comment #33 from jakub at gcc dot gnu dot org 2010-09-01 11:50 --- Yes, 4.4.5 and maybe 4.4.6 is planned. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug bootstrap/45321] [4.6 regression] ARM bootstrap failure due to stdarg_p change
--- Comment #2 from ramana at gcc dot gnu dot org 2010-09-01 11:53 --- Subject: Bug 45321 Author: ramana Date: Wed Sep 1 11:52:55 2010 New Revision: 163726 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163726 Log: 2010-09-01 Mikael Pettersson mi...@it.uu.se PR bootstrap/45321 * tree.c (stdarg_p): Make fntype parameter const. * tree.h (stdarg_p): Likewise. (function_args_iterator): Remove unused fntype field. (function_args_iter_init): Do not initialize fntype field. Make fntype parameter const. Modified: trunk/gcc/ChangeLog trunk/gcc/tree.c trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45321
[Bug tree-optimization/45470] [4.6 Regression] ICE: verify_flow_info failed: BB 2 can not throw but has an EH edge with -ftree-vectorize -fnon-call-exceptions
--- Comment #6 from irar at il dot ibm dot com 2010-09-01 11:54 ---
(In reply to comment #5)
I see before SLP:
bb 2:
MEM[(struct A *)this_1(D)].a = 0;
MEM[(struct A *)this_1(D)].b = 0;
MEM[(struct A *)this_1(D)].c = 0;
[LP 2] MEM[(struct A *)this_1(D) + 12B].a = 0;
and after:
bb 2:
vect_cst_.1_16 = { 0, 0, 0, 0 };
vect_p.5_17 = MEM[(struct A *)this_1(D)].a;
M*vect_p.5_17{misalignment: 0} = vect_cst_.1_16;
so EH info has not been properly transfered.
How should it be done? Is it ok to assume that if one of the old stmts can
throw, then we can set TREE_THIS_NOTRAP for the new access to 0? (and then we
can call maybe_duplicate_eh_stmt (new_stmt, old_stmt)).
Or maybe it's better to avoid vectorization?...
Thanks,
Ira
Now that only
MEM[(struct A *)this_1(D) + 12B].a can throw internally but not
MEM[(struct A *)this_1(D)].c = 0; is a fact that the frontend establishes.
The following mitigates the problem by simply removing the dead EH edges.
Index: gcc/tree-vect-slp.c
===
--- gcc/tree-vect-slp.c (revision 163721)
+++ gcc/tree-vect-slp.c (working copy)
@@ -2474,6 +2474,9 @@ vect_schedule_slp (loop_vec_info loop_vi
}
}
+ if (bb_vinfo)
+gimple_purge_dead_eh_edges (BB_VINFO_BB (bb_vinfo));
+
return is_store;
}
--
irar at il dot ibm dot com changed:
What|Removed |Added
Target Milestone|4.6.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45470
[Bug fortran/45466] Bus Error: C program calls Fortran Function which has returned value as Character string
--- Comment #8 from burnus at gcc dot gnu dot org 2010-09-01 12:01 --- (In reply to comment #0) Main program is written in C. (see the following) I strongly suggest using the C Binding facility of Fortran 2003 instead of relying on the internals of a given compiler. GCC/gfortran supports the C binding since 4.3.0 and newer version of most other compilers support it as well. Cf. http://gcc.gnu.org/onlinedocs/gfortran/Interoperability-with-C.html The article at http://www.fortranplus.co.uk/resource/fortran_2003_2008_compiler_support.pdf lists for some compilers the support of Fortran 2003 (and 2008) features; interesting for you are the items Interoperability with C. Note: The list is incomplete as not all vendors have submitted their data. Regarding GCC/gfortran 4.1: I have no idea why it worked for you, but the calling convention of 4.1 was the same (I just checked). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45466
[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
--- Comment #10 from burnus at gcc dot gnu dot org 2010-09-01 12:02 --- I think this is a variant of PR 42647: Allocatable components of allocatable scalars are not correctly handled. -- burnus at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||42647 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
[Bug bootstrap/45321] [4.6 regression] ARM bootstrap failure due to stdarg_p change
--- Comment #3 from ramana at gcc dot gnu dot org 2010-09-01 12:03 --- Fixed. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45321
[Bug rtl-optimization/45353] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in sel_bb_head, at sel-sched-ir.c:4329 with -fselective-scheduling and __builtin_unreachable()
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2010-09-01 12:24 --- Subject: Bug 45353 Author: ebotcazou Date: Wed Sep 1 12:24:35 2010 New Revision: 163731 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163731 Log: Backport from mainline 2010-08-20 Jakub Jelinek ja...@redhat.com PR rtl-optimization/45353 * sel-sched-ir.c (sel_bb_head): Return NULL even if next_nonnote_insn after bb_note is a BARRIER. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/sel-sched-ir.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45353
[Bug target/45476] libgcc should contain TCmode functions
--- Comment #4 from dominiq at lps dot ens dot fr 2010-09-01 12:31 --- (In reply to comment #3) On x86_64-apple-darwin10 I have applied the following patch --- ../_clean/gcc/config/i386/darwin.h 2010-07-19 11:51:25.0 +0200 +++ ../p_work/gcc/config/i386/darwin.h 2010-09-01 14:10:53.0 +0200 @@ -148,6 +148,12 @@ extern int darwin_emit_branch_islands; #define SHIFT_DOUBLE_OMITS_COUNT 0 +/* Put all *tf routines in libgcc. */ +#undef LIBGCC2_HAS_TF_MODE +#define LIBGCC2_HAS_TF_MODE 1 +#define LIBGCC2_TF_CEXT q +#define TF_SIZE 113 + #undef TARGET_ASM_FILE_END #define TARGET_ASM_FILE_END darwin_file_end and bootstrap fails at stage 1 with ld: duplicate symbol ___fixtfdi in fixtfdi_s.o and _fixtfdi_s.o Any idea? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45476
[Bug target/37954] [4.3 only] odd sized packed structures passed by value, under ARM, cause lockup of application
--- Comment #14 from ramana at gcc dot gnu dot org 2010-09-01 12:41 --- Patches should be submitted to gcc-patc...@gcc.gnu.org. This is a 4.3 only issue. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||4.3.1 4.3.5 Known to work||4.4.2 4.5.0 Last reconfirmed|-00-00 00:00:00 |2010-09-01 12:41:33 date|| Summary|odd sized packed structures |[4.3 only] odd sized packed |passed by value, under ARM, |structures passed by value, |cause lockup of application |under ARM, cause lockup of ||application Target Milestone|--- |4.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37954
[Bug c++/45479] New: Exceptions not delivered properly after thread cancellation
[r...@localhost Desktop]# gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/apps/gnu/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.6-20100828/configure --prefix=/apps/gnu --disable-bootstrap --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-languages=c,c++ --with-ppl=/apps/gnu --with-cloog=/apps/gnu --with-mpc=/apps/gnu --with-mpfr=/apps/gnu --with-gmp=/apps/gnu --with-libelf=/apps/gnu --disable-multilib --disable-werror Thread model: posix gcc version 4.6.0 20100828 (experimental) (GCC) When a thread is cancelled via pthread_cancel, the cancelled thread's stack is not being unwound properly and exception delivery is bugged. This issue is preventing me from being able to port a working system from Sun Studio/Solaris to gcc/Linux. -- Summary: Exceptions not delivered properly after thread cancellation Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mikedalpee at enginsol dot com GCC build triplet: x86_64-unknown-linux GCC host triplet: x86_64-unknown-linux GCC target triplet: x86_64-unknown-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479
[Bug c++/45479] Exceptions not delivered properly after thread cancellation
--- Comment #1 from mikedalpee at enginsol dot com 2010-09-01 13:13 --- Created an attachment (id=21633) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21633action=view) Program that demonstrates the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479
[Bug c++/45479] Exceptions not delivered properly after thread cancellation
--- Comment #2 from mikedalpee at enginsol dot com 2010-09-01 13:13 --- Created an attachment (id=21634) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21634action=view) script that builds the bug program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479
[Bug lto/45194] lto1: internal compiler error: in lto_varpool_replace_node, at lto-symtab.c:292
--- Comment #3 from jamborm at gcc dot gnu dot org 2010-09-01 13:15 --- No, I still get the same ICE (on both the reduced testcase and firefox as such) even with a recent checkout of trunk (revision 163677 from yesterday). Not only I use the same version of gold but apparently also the same binary on the same computer :-) How do you configure the gcc? I use /abuild/mjambor/icln/configure --prefix=/abuild/mjambor/inst/icln/ --enable-checking=yes --enable-languages=c,c++ --disable-bootstrap --enable-gold --with-plugin-ld=/usr/bin/gold -- jamborm at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-01 13:15:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45194
[Bug c++/45479] Exceptions not delivered properly after thread cancellation
--- Comment #3 from mikedalpee at enginsol dot com 2010-09-01 13:16 --- Created an attachment (id=21635) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21635action=view) output of the bug program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479
[Bug target/45478] ICE: in c_builtin_function_ext_scope, at c-decl.c:2852 with -mno-sse/-march=i386
--- Comment #2 from zsojka at seznam dot cz 2010-09-01 13:23 --- Created an attachment (id=21636) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21636action=view) different testcase This testcase crashes the same way with -mno-sse2. It was reduced from lex.i as well. $ gcc -mno-sse2 pr45478-2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45478
[Bug c++/45479] Exceptions not delivered properly after thread cancellation
--- Comment #4 from mikedalpee at enginsol dot com 2010-09-01 13:27 --- Created an attachment (id=21637) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21637action=view) Expected output of bug program - generated on Solaris 9 using Sun Studio 12. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479
[Bug lto/45480] New: [4.6 Regression] New LTO failures
On Linux/x86, revision 163680 gave FAIL: gcc.dg/lto/20081201-2 c_lto_20081201-2_0.o-c_lto_20081201-2_1.o execute -O3 -fwhopr FAIL: gcc.dg/lto/ipareference2 c_lto_ipareference2_0.o-c_lto_ipareference2_1.o link, -O1 -fwhopr -fwhole-program Revision 163670 is OK. -- Summary: [4.6 Regression] New LTO failures Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45480
[Bug target/45476] libgcc should contain TCmode functions
--- Comment #5 from burnus at gcc dot gnu dot org 2010-09-01 13:31 --- Cf. patch by Uros for cygming, darwin, freebsd at http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00040.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45476
[Bug c++/45479] Exceptions not delivered properly after thread cancellation
--- Comment #5 from mikedalpee at enginsol dot com 2010-09-01 13:32 --- This bug occurs across all versions of the compiler I have tested - 4.3, 4.4, 4.5, and 4.6. The bug is preventing me from porting software, because correct destructor excecution in a cancelled thread is fundamental to the proper functioning of this software. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479
[Bug lto/45480] [4.6 Regression] New LTO failures
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-09-01 13:33 --- Confirmed. Obviously Honzas. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-01 13:33:11 date|| Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45480
[Bug c++/45481] New: Exception is erroneously rethrown from a constructor initializer try/catch block
[r...@localhost exception1]# gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/apps/gnu/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.6-20100828/configure --prefix=/apps/gnu --disable-bootstrap --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-languages=c,c++ --with-ppl=/apps/gnu --with-cloog=/apps/gnu --with-mpc=/apps/gnu --with-mpfr=/apps/gnu --with-gmp=/apps/gnu --with-libelf=/apps/gnu --disable-multilib --disable-werror Thread model: posix gcc version 4.6.0 20100828 (experimental) (GCC) -- Summary: Exception is erroneously rethrown from a constructor initializer try/catch block Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mikedalpee at enginsol dot com GCC build triplet: x86_64-unknown-linux GCC host triplet: x86_64-unknown-linux GCC target triplet: x86_64-unknown-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45481
[Bug target/45476] libgcc should contain TCmode functions
--- Comment #6 from burnus at gcc dot gnu dot org 2010-09-01 13:35 --- Uros, did you see the comment of Dominique regarding x86_64-apple-darwin10? (In reply to comment #4) and bootstrap fails at stage 1 with ld: duplicate symbol ___fixtfdi in fixtfdi_s.o and _fixtfdi_s.o That's with the patch from comment 2 (or comment 4) - but I think that's identical to the submitted patch (comment 5). -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||ubizjak at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45476
[Bug c++/45481] Exception is erroneously rethrown from a constructor initializer try/catch block
--- Comment #1 from mikedalpee at enginsol dot com 2010-09-01 13:36 --- Created an attachment (id=21638) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21638action=view) Program that demonstrates the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45481
[Bug c++/45481] Exception is erroneously rethrown from a constructor initializer try/catch block
--- Comment #2 from mikedalpee at enginsol dot com 2010-09-01 13:36 --- Created an attachment (id=21639) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21639action=view) script that builds the bug program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45481
[Bug c++/45481] Exception is erroneously rethrown from a constructor initializer try/catch block
--- Comment #3 from mikedalpee at enginsol dot com 2010-09-01 13:38 --- Created an attachment (id=21640) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21640action=view) output of the bug program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45481
[Bug c++/45479] Exceptions not delivered properly after thread cancellation
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-09-01 13:40 --- I am sure this is more a pthread implementation issue, so a glibc bug on sourceware.org/bugzilla would be more appropriate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479
[Bug c++/45481] Exception is erroneously rethrown from a constructor initializer try/catch block
--- Comment #4 from mikedalpee at enginsol dot com 2010-09-01 13:41 --- Created an attachment (id=21641) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21641action=view) Expected output of bug program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45481
[Bug c++/45479] Exceptions not delivered properly after thread cancellation
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479
[Bug c++/45481] Exception is erroneously rethrown from a constructor initializer try/catch block
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45481
[Bug bootstrap/45482] New: Bootstrap fails on PPC error: conflicting types for 'malloc'
The error I get is the same as in the old pr 33130. I don't see why this is so. Ian Lance Taylor suggested looking at STDC_HEADERS, and indeed in libiberty/config.h it is defined in stage1, but not in stage2. I am attaching a few config files; please let me know what else is needed to figure this out. = make[3]: Entering directory `/home/snfilip/GNUBUILD/obj-4.6.0/libiberty' if [ x != x ]; then \ /home/snfilip/GNUBUILD/obj-4.6.0/./prev-gcc/xgcc -B/home/snfilip/GNUBUILD/obj-4.6.0/./prev-gcc/ -B/home/snfilip/GNUBUILD/gnu460/powerpc64-unknown-linux-gnu/bin/ -B/home/snfilip/GNUBUILD/gnu460/powerpc64-unknown-linux-gnu/bin/ -B/home/snfilip/GNUBUILD/gnu460/powerpc64-unknown-linux-gnu/lib/ -isystem /home/snfilip/GNUBUILD/gnu460/powerpc64-unknown-linux-gnu/include -isystem /home/snfilip/GNUBUILD/gnu460/powerpc64-unknown-linux-gnu/sys-include-c -DHAVE_CONFIG_H -g -O2 -gtoggle -I. -I../../gcc-4.6.0/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic ../../gcc-4.6.0/libiberty/regex.c -o pic/regex.o; \ else true; fi /home/snfilip/GNUBUILD/obj-4.6.0/./prev-gcc/xgcc -B/home/snfilip/GNUBUILD/obj-4.6.0/./prev-gcc/ -B/home/snfilip/GNUBUILD/gnu460/powerpc64-unknown-linux-gnu/bin/ -B/home/snfilip/GNUBUILD/gnu460/powerpc64-unknown-linux-gnu/bin/ -B/home/snfilip/GNUBUILD/gnu460/powerpc64-unknown-linux-gnu/lib/ -isystem /home/snfilip/GNUBUILD/gnu460/powerpc64-unknown-linux-gnu/include -isystem /home/snfilip/GNUBUILD/gnu460/powerpc64-unknown-linux-gnu/sys-include-c -DHAVE_CONFIG_H -g -O2 -gtoggle -I. -I../../gcc-4.6.0/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic ../../gcc-4.6.0/libiberty/regex.c -o regex.o ../../gcc-4.6.0/libiberty/regex.c:130:1: warning: function declaration isn't a prototype [-Wstrict-prototypes] ../../gcc-4.6.0/libiberty/regex.c:130:7: warning: conflicting types for built-in function 'malloc' [enabled by default] ../../gcc-4.6.0/libiberty/regex.c:131:1: warning: function declaration isn't a prototype [-Wstrict-prototypes] ../../gcc-4.6.0/libiberty/regex.c:131:7: warning: conflicting types for built-in function 'realloc' [enabled by default] In file included from /home/snfilip/GNUBUILD/obj-4.6.0/./prev-gcc/include-fixed/bits/string2.h:1308:0, from /usr/include/string.h:417, from ../../gcc-4.6.0/libiberty/regex.c:149: /usr/include/stdlib.h:589:14: error: conflicting types for 'malloc' ../../gcc-4.6.0/libiberty/regex.c:130:7: note: previous declaration of 'malloc' was here In file included from ../../gcc-4.6.0/libiberty/regex.c:638:0: ../../gcc-4.6.0/libiberty/regex.c: In function 'byte_regex_compile': ../../gcc-4.6.0/libiberty/regex.c:2439:7: warning: implicit declaration of function 'free' [-Wimplicit-function-declaration] ../../gcc-4.6.0/libiberty/regex.c:2439:33: warning: incompatible implicit declaration of built-in function 'free' [enabled by default] ../../gcc-4.6.0/libiberty/regex.c:2500:17: warning: incompatible implicit declaration of built-in function 'free' [enabled by default] ../../gcc-4.6.0/libiberty/regex.c:2533:36: warning: incompatible implicit declaration of built-in function 'free' [enabled by default] ../../gcc-4.6.0/libiberty/regex.c:2640:28: warning: incompatible implicit declaration of built-in function 'free' [enabled by default] ../../gcc-4.6.0/libiberty/regex.c:3643:26: warning: incompatible implicit declaration of built-in function 'free' [enabled by default] ../../gcc-4.6.0/libiberty/regex.c:4150:5: warning: incompatible implicit declaration of built-in function 'free' [enabled by default] ../../gcc-4.6.0/libiberty/regex.c: In function 'byte_re_compile_fastmap': ../../gcc-4.6.0/libiberty/regex.c:4835:11: warning: implicit declaration of function 'abort' [-Wimplicit-function-declaration] ../../gcc-4.6.0/libiberty/regex.c:4835:11: warning: incompatible implicit declaration of built-in function 'abort' [enabled by default] ../../gcc-4.6.0/libiberty/regex.c: In function 'byte_re_match_2_internal': ../../gcc-4.6.0/libiberty/regex.c:7424:11: warning: incompatible implicit declaration of built-in function 'abort' [enabled by default] ../../gcc-4.6.0/libiberty/regex.c: In function 'xregcomp': ../../gcc-4.6.0/libiberty/regex.c:7978:4: warning: incompatible implicit declaration of built-in function 'free' [enabled by default] ../../gcc-4.6.0/libiberty/regex.c: In function 'xregexec': ../../gcc-4.6.0/libiberty/regex.c:8053:7: warning: incompatible implicit declaration of built-in function 'free' [enabled by default] ../../gcc-4.6.0/libiberty/regex.c: In function 'xregerror': ../../gcc-4.6.0/libiberty/regex.c:8081:5: warning: incompatible implicit declaration of built-in function 'abort' [enabled by default] ../../gcc-4.6.0/libiberty/regex.c: In function 'xregfree': ../../gcc-4.6.0/libiberty/regex.c:8115:5: warning: incompatible implicit declaration of built-in
[Bug bootstrap/45482] Bootstrap fails on PPC error: conflicting types for 'malloc'
--- Comment #1 from sfilippone at uniroma2 dot it 2010-09-01 13:44 --- Created an attachment (id=21642) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21642action=view) Main config.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45482
[Bug bootstrap/45482] Bootstrap fails on PPC error: conflicting types for 'malloc'
--- Comment #2 from sfilippone at uniroma2 dot it 2010-09-01 13:44 --- Created an attachment (id=21643) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21643action=view) stage 1 libiberty/config.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45482
[Bug bootstrap/45482] Bootstrap fails on PPC error: conflicting types for 'malloc'
--- Comment #3 from sfilippone at uniroma2 dot it 2010-09-01 13:44 --- Created an attachment (id=21644) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21644action=view) stage 1 libiberty/config.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45482
[Bug bootstrap/45482] Bootstrap fails on PPC error: conflicting types for 'malloc'
--- Comment #4 from sfilippone at uniroma2 dot it 2010-09-01 13:45 --- Created an attachment (id=21645) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21645action=view) stage 2 libiberty/config.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45482
[Bug bootstrap/45482] Bootstrap fails on PPC error: conflicting types for 'malloc'
--- Comment #5 from sfilippone at uniroma2 dot it 2010-09-01 13:45 --- Created an attachment (id=21646) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21646action=view) stage 2 libiberty/config.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45482
[Bug c++/45481] Exception is erroneously rethrown from a constructor initializer try/catch block
--- Comment #5 from paolo dot carlini at oracle dot com 2010-09-01 13:49 --- For the record, building with ICC gives the same behavior of GCC. Let's ask Jason' opinion about this. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45481
[Bug c++/45479] Exceptions not delivered properly after thread cancellation
--- Comment #7 from paolo dot carlini at oracle dot com 2010-09-01 13:53 --- Likewise about ICC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479
[Bug fortran/45466] Bus Error: C program calls Fortran Function which has returned value as Character string
--- Comment #9 from Lulin dot Song at gmail dot com 2010-09-01 14:22 --- (In reply to comment #8) (In reply to comment #0) Main program is written in C. (see the following) I strongly suggest using the C Binding facility of Fortran 2003 instead of relying on the internals of a given compiler. GCC/gfortran supports the C binding since 4.3.0 and newer version of most other compilers support it as well. Cf. http://gcc.gnu.org/onlinedocs/gfortran/Interoperability-with-C.html The article at http://www.fortranplus.co.uk/resource/fortran_2003_2008_compiler_support.pdf lists for some compilers the support of Fortran 2003 (and 2008) features; interesting for you are the items Interoperability with C. Note: The list is incomplete as not all vendors have submitted their data. Thank you all for the information and suggestions. Fortran2003 C Binding facility seems to be what we should do next. Our project is a large Fortran77,90,95 C mixing language software been developed for years. It is hard to make it work with three different compilers (Intel ifort, AbfSalford ftn95 and gfortran). Regarding GCC/gfortran 4.1: I have no idea why it worked for you, but the calling convention of 4.1 was the same (I just checked). It is mystery to me too. The small program I submitted here works if compiled with 4.1.2 . Another curious thought. When the return value is integer or double, the dump looks like requestdouble (real(kind=8) rlat, real(kind=8) rlng) when the return value is character string, is it more intuitive to be requestdouble ( real(kind=8) rlat, real(kind=8) rlng,character(kind=1)[1:16] __result, integer(kind=4) .__result) instead of requestdouble (character(kind=1)[1:16] __result, integer(kind=4) .__result , real(kind=8) rlat, real(kind=8) rlng) ? I mean the .__result appending to arguments list instead inserting before arguments list. Many thanks again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45466
[Bug fortran/43018] alloc_comp_scalar_1.f90: Valgrind Invalid read of size 4
--- Comment #1 from janus at gcc dot gnu dot org 2010-09-01 14:26 --- (In reply to comment #0) Invalid read of size 1 I don't see this at r163721 (probably has been fixed by r159445). Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43018
[Bug fortran/45466] Bus Error: C program calls Fortran Function which has returned value as Character string
--- Comment #10 from burnus at gcc dot gnu dot org 2010-09-01 14:32 --- (In reply to comment #9) when the return value is character string, is it more intuitive to be requestdouble ( real(kind=8) rlat, real(kind=8) rlng,character(kind=1)[1:16] __result, integer(kind=4) .__result) instead of requestdouble (character(kind=1)[1:16] __result, integer(kind=4) .__result , real(kind=8) rlat, real(kind=8) rlng) ? I find both equally intuitive. I think the current order matches g77 and some other compilers; for instance NAG uses: void requestdouble_(requestdouble_Result,requestdouble_ResultLen,rlat_,rlng_) Thus as the other order is not clearly superior, sticking to the current order avoids a lot of trouble both for the compiler development and for user code. with three different compilers (Intel ifort, AbfSalford ftn95 and gfortran). Ifort supports Fortran 2003's C binding since quite some time; I think Salfort doesn't nor does Absoft, but I might be wrong. (Of AbfSalfort I have never heard.) For general Fortran discussion, I suggest the newsgroup comp.lang.fortran (via your news server or via http://groups.google.com/group/comp.lang.fortran/) or the gfortran mailing list. A bug report is not the proper method of communication :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45466
[Bug fortran/43018] alloc_comp_scalar_1.f90: Valgrind Invalid read of size 4
--- Comment #2 from burnus at gcc dot gnu dot org 2010-09-01 14:36 --- Using 4.6.0 20100901 (experimental) [trunk revision 163720], I still see: gfortran -g alloc_comp_scalar_1.f90 valgrind ./a.out ==14804== Invalid read of size 8 ==14804==at 0x400B82: MAIN__ (alloc_comp_scalar_1.f90:14) ==14804==by 0x400D22: main (alloc_comp_scalar_1.f90:17) ==14804== Address 0x58e63d0 is 0 bytes inside a block of size 4 alloc'd ==14804==at 0x4C26C36: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==14804==by 0x4008F9: MAIN__ (alloc_comp_scalar_1.f90:12) ==14804==by 0x400D22: main (alloc_comp_scalar_1.f90:17) -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43018
[Bug lto/44812] m32 lto produces non-relocatable subtraction expression errors
--- Comment #30 from howarth at nitro dot med dot uc dot edu 2010-09-01 14:38 --- Original -m32 lto testsuite failures due to non-relocatable subtraction expression errors were made latent by the commit... Author: ak Date: Tue Aug 31 16:58:46 2010 New Revision: 163680 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163680 Log: * common.opt (fwhopr=): Update for -fwhopr=jobserver * doc/invoke.texi (fwhopr): Document -fwhopr=jobserver. * lto-wrapper.c (run_gcc): Add jobserver mode. * opts.c (common_handle_option): Fix OPT_fwhopr for non numeric argument. Modified: trunk/gcc/ChangeLog trunk/gcc/common.opt trunk/gcc/doc/invoke.texi trunk/gcc/lto-wrapper.c trunk/gcc/opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44812
Re: [Bug lto/44812] m32 lto produces non-relocatable subtraction expression errors
Original -m32 lto testsuite failures due to non-relocatable subtraction expression errors were made latent by the commit... Hmm, this does not make much sense. What changed? Honza
[Bug lto/44812] m32 lto produces non-relocatable subtraction expression errors
--- Comment #31 from hubicka at ucw dot cz 2010-09-01 14:42 --- Subject: Re: m32 lto produces non-relocatable subtraction expression errors Original -m32 lto testsuite failures due to non-relocatable subtraction expression errors were made latent by the commit... Hmm, this does not make much sense. What changed? Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44812
[Bug target/36502] i386/darwin generates unnecessary stack ops in every function
--- Comment #31 from hjl dot tools at gmail dot com 2010-09-01 14:51 --- (In reply to comment #30) With only gcc-pr45234-2.patch at r163712 , I am seeing the following regressions... FAIL: gcc.c-torture/execute/builtins/sprintf-chk.c compilation, -Os (internal compiler error) Please provide preprocessed .i file. FAIL: gcc.dg/stack-usage-1.c scan-file foo\t(256|264)\tstatic FAIL: gcc.target/i386/stack-usage-realign.c scan-file main\t48\tdynamic,bounded whereas with gcc-pr45234-2.patch and... I compared revision 163733 against revision 163733 + gcc-pr45234-2.patch with a cross compiler to x86_64-apple-darwin10.4.0. I saw no differences in .su files for gcc.dg/stack-usage-1.c nor gcc.target/i386/stack-usage-realign.c. Are you sure they pass on Darwin with revision 163733? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36502
[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3
--- Comment #1 from ramana at gcc dot gnu dot org 2010-09-01 14:54 --- With r163667 and fixes for PR45444 applied I don't see issues with a v7-a bootstrap. Can we see if a later version works for you ? Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45445
[Bug c/45483] New: gcc-4.4.3: probably wrong optimization options chosen by -march=native
I checked what options are being chosen on one of my laptops following the following instructions: http://en.chys.info/2010/04/what-exactly-marchnative-means/ But, when reviewing used options I got: $ ps af | grep cc1 18118 pts/1S+ 0:00 \_ grep --colour=auto cc1 18116 pts/0S+ 0:00 \_ /usr/libexec/gcc/i686-pc-linux-gnu/4.4.3/cc1 -quiet - -D_FORTIFY_SOURCE=2 -march=prescott --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=generic -quiet -dumpbase - -auxbase-strip /dev/null -o /tmp/ccLS5xw5.s 13580 tty3 S+ 0:00 \_ /usr/libexec/gcc/i686-pc-linux-gnu/4.4.3/cc1 -quiet - -D_FORTIFY_SOURCE=2 -march=prescott --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=generic -quiet -dumpbase - -auxbase-strip /dev/null -o /tmp/ccSnTxP2.s My /proc/cpuinfo is the following: $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 14 model name : Genuine Intel(R) CPU T2300 @ 1.66GHz stepping: 8 cpu MHz : 996.000 cache size : 2048 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon bts aperfmperf pni monitor vmx est tm2 xtpr pdcm bogomips: 3324.55 clflush size: 64 cache_alignment : 64 address sizes : 32 bits physical, 32 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 14 model name : Genuine Intel(R) CPU T2300 @ 1.66GHz stepping: 8 cpu MHz : 996.000 cache size : 2048 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon bts aperfmperf pni monitor vmx est tm2 xtpr pdcm bogomips: 3324.56 clflush size: 64 cache_alignment : 64 address sizes : 32 bits physical, 32 bits virtual power management: And, then, I see two problems: 1. -mtune=generic is being passed instead of, for example, -mtune=specific option As I can read in man gcc, looks like code is really being compiled for a generic set of CPUs instead of specific one: generic Produce code optimized for the most common IA32/AMD64/EM64T processors. If you know the CPU on which your code will run, then you should use the corresponding -mtune option instead of -mtune=generic. But, if you do not know exactly what CPU users of your application will have, then you should use this option. As new processors are deployed in the marketplace, the behavior of this option will change. Therefore, if you upgrade to a newer version of GCC, the code generated option will change to reflect the processors that were most common when that version of GCC was released. There is no -march=generic option because -march indicates the instruction set the compiler can use, and there is no generic instruction set applicable to all processors. In contrast, -mtune indicates the processor (or, in this case, collection of processors) for which the code is optimized. 2. -march=prescott I am unsure about my processor is really a prescott one, even supporting sse3 it's listed as a Pentium-M based processor in the following links: http://en.wikipedia.org/wiki/List_of_Intel_microprocessors#Intel_Core http://en.wikipedia.org/wiki/Yonah_(microprocessor) http://en.wikipedia.org/wiki/List_of_Intel_Core_microprocessors#Core_Duo Then, I would pass -march=pentium-m -msse3 instead. Thanks a lot for your help -- Summary: gcc-4.4.3: probably wrong optimization options chosen by -march=native Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pacho at condmat1 dot ciencias dot uniovi dot es http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45483
[Bug target/36502] i386/darwin generates unnecessary stack ops in every function
--- Comment #32 from howarth at nitro dot med dot uc dot edu 2010-09-01 15:18 --- (In reply to comment #31) I compared revision 163733 against revision 163733 + gcc-pr45234-2.patch with a cross compiler to x86_64-apple-darwin10.4.0. I saw no differences in .su files for gcc.dg/stack-usage-1.c nor gcc.target/i386/stack-usage-realign.c. Are you sure they pass on Darwin with revision 163733? HJ, Actually it appears that... FAIL: gcc.c-torture/execute/builtins/sprintf-chk.c compilation, -Os (internal compiler error) UNRESOLVED: gcc.c-torture/execute/builtins/sprintf-chk.c execution, -Os FAIL: gcc.dg/stack-usage-1.c scan-file foo\\t(256|264)\\tstatic FAIL: gcc.target/i386/stack-usage-realign.c scan-file main\\t48\\tdynamic,bounded are actually new regressions present in unpatched gcc trunk... http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00042.html I will do a regression hunt later today to find out the offending commit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36502
[Bug fortran/45466] Bus Error: C program calls Fortran Function which has returned value as Character string
--- Comment #11 from Lulin dot Song at gmail dot com 2010-09-01 15:29 --- (In reply to comment #10) (In reply to comment #9) when the return value is character string, is it more intuitive to be requestdouble ( real(kind=8) rlat, real(kind=8) rlng,character(kind=1)[1:16] __result, integer(kind=4) .__result) instead of requestdouble (character(kind=1)[1:16] __result, integer(kind=4) .__result , real(kind=8) rlat, real(kind=8) rlng) ? I find both equally intuitive. I think the current order matches g77 and some other compilers; for instance NAG uses: void requestdouble_(requestdouble_Result,requestdouble_ResultLen,rlat_,rlng_) Thus as the other order is not clearly superior, sticking to the current order avoids a lot of trouble both for the compiler development and for user code. with three different compilers (Intel ifort, AbfSalford ftn95 and gfortran). Ifort supports Fortran 2003's C binding since quite some time; I think Salfort doesn't nor does Absoft, but I might be wrong. (Of AbfSalfort I have never heard.) AbfSalfort is typo. We use Salfort ftn95 on Windows. For general Fortran discussion, I suggest the newsgroup comp.lang.fortran (via your news server or via http://groups.google.com/group/comp.lang.fortran/) or the gfortran mailing list. A bug report is not the proper method of communication :-) Thanks a lot for your explaining. I thought it was bug since it behaves different when the return type is different. I will submit future report to mail list first to see anyone can answer there to avoid flooding the bugzilla. -- Lulin dot Song at gmail dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45466
[Bug target/36502] i386/darwin generates unnecessary stack ops in every function
--- Comment #33 from howarth at nitro dot med dot uc dot edu 2010-09-01 15:30 --- Created an attachment (id=21647) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21647action=view) Don't redefine STACK_BOUNDARY and replace STACK_BOUNDARY with 128. -- howarth at nitro dot med dot uc dot edu changed: What|Removed |Added Attachment #21599|0 |1 is obsolete|| Attachment #21607|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36502
[Bug target/36502] i386/darwin generates unnecessary stack ops in every function
--- Comment #34 from hjl dot tools at gmail dot com 2010-09-01 15:31 --- (In reply to comment #33) Created an attachment (id=21647) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21647action=view) [edit] Don't redefine STACK_BOUNDARY and replace STACK_BOUNDARY with 128. Please do a proper regression test and report REAL regressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36502
[Bug target/36502] i386/darwin generates unnecessary stack ops in every function
--- Comment #35 from howarth at nitro dot med dot uc dot edu 2010-09-01 15:37 --- (In reply to comment #34) Please do a proper regression test and report REAL regressions. First we need to do a regression hunt in gcc trunk for the new stack test case failures. It is impossible to properly test the patch for PR36502 against a gcc trunk which is already regressed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36502
[Bug c/45483] gcc-4.4.3: probably wrong optimization options chosen by -march=native
--- Comment #1 from hjl dot tools at gmail dot com 2010-09-01 15:40 --- Please try gcc 4.5.2 and report what it does. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45483
[Bug c/45483] gcc-4.4.3: probably wrong optimization options chosen by -march=native
--- Comment #2 from pacho at condmat1 dot ciencias dot uniovi dot es 2010-09-01 15:51 --- gcc-4.5 is still hardmasked downstream in Gentoo, then, I am unsure about installing it :-/, are you sure this bug could be solved in 4.5* ? -- pacho at condmat1 dot ciencias dot uniovi dot es changed: What|Removed |Added Component|target |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45483
[Bug lto/45480] [4.6 Regression] New LTO failures
--- Comment #2 from hubicka at ucw dot cz 2010-09-01 15:56 --- Subject: Re: [4.6 Regression] New LTO failures Confirmed. Obviously Honzas. I had no commits in the specified range ;) It seems that Andi's patch just disable whopr... Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45480
[Bug target/45483] gcc-4.4.3: probably wrong optimization options chosen by -march=native
--- Comment #3 from hjl dot tools at gmail dot com 2010-09-01 15:56 --- (In reply to comment #2) gcc-4.5 is still hardmasked downstream in Gentoo, then, I am unsure about installing it :-/, are you sure this bug could be solved in 4.5* ? 1. -march=native is changed in gcc 4.5. 2. Your cpu is Core. 3. -mtune=generic generates the fastest code for Core. 4. Prescott and Core have the same instruction set. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45483
[Bug target/45483] gcc-4.4.3: probably wrong optimization options chosen by -march=native
--- Comment #4 from pacho at condmat1 dot ciencias dot uniovi dot es 2010-09-01 16:06 --- (In reply to comment #3) (In reply to comment #2) gcc-4.5 is still hardmasked downstream in Gentoo, then, I am unsure about installing it :-/, are you sure this bug could be solved in 4.5* ? 1. -march=native is changed in gcc 4.5. Will try then with 4.5.1 (4.5.2 is still not available on Gentoo) 2. Your cpu is Core. 3. -mtune=generic generates the fastest code for Core. 4. Prescott and Core have the same instruction set. Is -mtune=generic better than -mtune=prescott? man gcc looks to suggest last one would be better: If you know the CPU on which your code will run, then you should use the corresponding -mtune option instead of -mtune=generic. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45483
[Bug middle-end/45484] New: r163660 ICEs gcc.c-torture/execute/builtins/sprintf-chk.c compilation, -Os at -m32
The commit of r163660... Author: ebotcazou Date: Mon Aug 30 20:04:49 2010 New Revision: 163660 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163660 Log: Stack usage support * common.opt (-fstack-usage): New option. * doc/invoke.texi (Debugging options): Document it. * builtins.c (expand_builtin_apply): Pass TRUE as 4th argument to allocate_dynamic_stack_space. (expand_builtin_alloca): Add 4th bool parameter CANNOT_ACCUMULATE and propagate it to allocate_dynamic_stack_space. (expand_builtin) BUILT_IN_ALLOCA: Adjust for above change. * calls.c (initialize_argument_information): Pass TRUE as 4th argument to allocate_dynamic_stack_space. (expand_call): Set current_function_has_unbounded_dynamic_stack_size to 1 when pushing a variable-sized argument onto the stack. Pass TRUE as 4th argument to allocate_dynamic_stack_space. Update current_function_pushed_stack_size. (emit_library_call_value_1): Likewise. * explow.c (allocate_dynamic_stack_space): Add 4th bool parameter CANNOT_ACCUMULATE. If flag_stack_usage, look into the size and attempt to find an upper bound. Remove redundant code for the SETJMP_VIA_SAVE_AREA case. * expr.h (allocate_dynamic_stack_space): Add 4th bool parameter. * function.h (struct stack_usage): New structure. (current_function_static_stack_size): New macro. (current_function_dynamic_stack_size): Likewise. (current_function_pushed_stack_size): Likewise. (current_function_dynamic_alloc_count): Likewise. (current_function_has_unbounded_dynamic_stack_size): Likewise. (current_function_allocates_dynamic_stack_space): Likewise. (struct function): Add new field 'su'. * function.c (instantiate_virtual_regs): If SETJMP_VIA_SAVE_AREA, add the value of the dynamic offset to the dynamic stack usage. (gimplify_parameters): Set ALLOCA_FOR_VAR_P on call to BUILT_IN_ALLOCA for variable-sized objects. (prepare_function_start): Allocate cfun-su if flag_stack_usage. (rest_of_handle_thread_prologue_and_epilogue): Call output_stack_usage. * gimplify.c (gimplify_decl_expr): Set ALLOCA_FOR_VAR_P on call to BUILT_IN_ALLOCA for variable-sized objects. * output.h (output_stack_usage): Declare. * toplev.c (stack_usage_file): New file pointer. (output_stack_usage): New function. (open_auxiliary_file): Likewise. (lang_dependent_init): Open file if flag_stack_usage is set. (finalize): Close file if stack_usage_file is not null. * tree.h (ALLOCA_FOR_VAR_P): New macro. * config/alpha/alpha.c (compute_frame_size): New function. (alpha_expand_prologue): Use it. (alpha_start_function): Likewise. (alpha_expand_epilogue): Likewise. Set stack usage info. * config/i386/i386.c (ix86_expand_prologue): Likewise. * config/ia64/ia64.c (ia64_expand_prologue): Likewise. * config/mips/mips.c (mips_expand_prologue): Likewise. * config/pa/pa.c (hppa_expand_prologue): Likewise. * config/rs6000/rs6000.c (rs6000_emit_prologue): Likewise. * config/sparc/sparc.c (sparc_expand_prologue): Likewise. testsuite/ * lib/gcc-dg.exp (cleanup-stack-usage): New procedure. * lib/scanasm.exp (scan-stack-usage): Likewise. (scan-stack-usage-not): Likewise. * gcc.dg/stack-usage-1.c: New test. * gcc.target/i386/stack-usage-realign.c: Likewise. causes the regression... FAIL: gcc.c-torture/execute/builtins/sprintf-chk.c compilation, -Os (internal compiler error) UNRESOLVED: gcc.c-torture/execute/builtins/sprintf-chk.c execution, -Os at -m32 on x86_64-apple-darwin10 as well as the failure of its new test cases... FAIL: gcc.dg/stack-usage-1.c scan-file foo\\t(256|264)\\tstatic FAIL: gcc.target/i386/stack-usage-realign.c scan-file main\\t48\\tdynamic,bounded at -m32 as well. The sprintf error appears as... /fink.build/gcc46-4.6.0-1000/gcc-4.6-20100901/gcc/testsuite/gcc.c-torture/execute/builtins/sprintf-chk-lib.c /sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100901/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c -w -Os -lm -m32 -o /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/testsuite/gcc/sprintf-chk.x7 (timeout = 300)/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100901/gcc/testsuite/gcc.c-torture/execute/builtins/sprintf-chk.c:197:1: internal compiler error: in div_data_align, at dwarf2out.c:595 Please submit a full bug report, with preprocessed source if appropriate.See http://gcc.gnu.org/bugs.html for instructions. compiler exited with status 1 output is:/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100901/gcc/testsuite/gcc.c-torture/execute/builtins/sprintf-chk.c:197:1: internal compiler error: in div_data_align, at dwarf2out.c:595Please submit a full bug
[Bug middle-end/45484] r163660 ICEs gcc.c-torture/execute/builtins/sprintf-chk.c compilation, -Os at -m32
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-09-01 16:21 --- Original patch submitted with http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00440.html. Test cases added with http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00503.html. -- howarth at nitro dot med dot uc dot edu changed: What|Removed |Added Summary|r163660 ICEs gcc.c- |r163660 ICEs gcc.c- |torture/execute/builtins/spr|torture/execute/builtins/spr |intf-chk.c compilation, -Os|intf-chk.c compilation, -Os |at -m32 |at -m32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45484
[Bug libgomp/45485] New: OpenMP causes interprocess deadlock
On a system with more than 8 cores the following program causes an interprocess
deadlock if started twice. This Problem has been observed on following systems:
2 IntelCPUs with 4 Cores per CPU; 2 IntelCPUs with 6 Cores per CPU; 1 IntelCPUs
with 6 Cores per CPU and Hyperthreading on (results in 12 virtual Cores).
The problem can be observed with gcc 4.4.1, gcc 4.4.4 and gcc 4.5.1 on Suse and
Ubuntu systems.
The program was compiled in the following way: gcc -fopenmp -o omp_test
omp_test.c
The program is not very useful in itself. It is a condensate of a real problem
which causes a big software package to hang (from time to time) for a few
minutes in a simple omp loop.
This is the program:
#include omp.h
#define V_SIZ 1000
int main (int argc, char **argv)
{
unsigned int v[V_SIZ];
unsigned iter;
for (iter = 0; iter 100; iter++)
{
int i;
#pragma omp parallel for
for (i = 0; i V_SIZ; i++)
v[i] = 1;
}
return 0;
}
And gcc -v:
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.4
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap
--with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.4
--enable-linux-futex --without-system-libunwind --with-arch-32=i586
--with-tune=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.4.1 [gcc-4_4-branch revision 150839] (SUSE Linux)
--
Summary: OpenMP causes interprocess deadlock
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: h dot vogt at gom dot com
GCC target triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45485
[Bug middle-end/45458] [4.5/4.6 Regression] ICE: in add_labels_and_missing_jumps, at bb-reorder.c:1306 with-fnon-call-exceptions -freorder-blocks-and-partition -fprofile-use
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-01 16:35:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45458
[Bug target/45483] gcc-4.4.3: probably wrong optimization options chosen by -march=native
--- Comment #5 from hjl dot tools at gmail dot com 2010-09-01 16:37 --- (In reply to comment #4) (In reply to comment #3) (In reply to comment #2) gcc-4.5 is still hardmasked downstream in Gentoo, then, I am unsure about installing it :-/, are you sure this bug could be solved in 4.5* ? 1. -march=native is changed in gcc 4.5. Will try then with 4.5.1 (4.5.2 is still not available on Gentoo) 2. Your cpu is Core. 3. -mtune=generic generates the fastest code for Core. 4. Prescott and Core have the same instruction set. Is -mtune=generic better than -mtune=prescott? man gcc looks to suggest last one would be better: If you know the CPU on which your code will run, then you should use the corresponding -mtune option instead of -mtune=generic. -mtune=generic is the best tuning option for Intel processors, regardless whatever gcc manual says. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45483
[Bug libgomp/45485] OpenMP causes interprocess deadlock
--- Comment #1 from jakub at gcc dot gnu dot org 2010-09-01 16:38 --- *** This bug has been marked as a duplicate of 43706 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45485
[Bug libgomp/43706] scheduling two threads on one core leads to starvation
--- Comment #21 from jakub at gcc dot gnu dot org 2010-09-01 16:38 --- *** Bug 45485 has been marked as a duplicate of this bug. *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||h dot vogt at gom dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43706
