[Bug c/39812] New: [4.5 regression] gcc.target/i386/cleanup-1.c and 8 gnat.dg tests FAIL between r146303 and r146339
Between: 146303 = http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg01859.html 146339 = http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg01961.html The following tests started failing on the -m32 run: FAIL: gcc.target/i386/cleanup-1.c execution test FAIL: gnat.dg/aliased_prefix_accessibility.adb execution test FAIL: gnat.dg/conv_bug.adb execution test FAIL: gnat.dg/curr_task.adb execution test FAIL: gnat.dg/iprot_test.adb execution test FAIL: gnat.dg/missing_acc_check.adb execution test FAIL: gnat.dg/not_null.adb execution test FAIL: gnat.dg/test_enum_io.adb execution test FAIL: gnat.dg/test_overflow_sum.adb execution test -- Summary: [4.5 regression] gcc.target/i386/cleanup-1.c and 8 gnat.dg tests FAIL between r146303 and r146339 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net GCC build triplet: i686-unknown-linux GCC host triplet: i686-unknown-linux GCC target triplet: i686-unknown-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39812
[Bug c/32061] (Wlogical-op) wording of warning of constant logicials need improvement
--- Comment #6 from manu at gcc dot gnu dot org 2009-04-19 11:04 --- Subject: Bug 32061 Author: manu Date: Sun Apr 19 11:04:13 2009 New Revision: 146344 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146344 Log: 2009-04-19 Manuel López-Ibáñez m...@gcc.gnu.org PR c/32061 PR c++/36954 * doc/invoke.texi: Add -Wlogical-op to -Wextra. * common.opt (Wlogical-op): Move from here... * c.opt (Wlogical-op): ... to here. * c-typeck.c (parser_build_binary_op): Update call to warn_logical_operator. * c-opts.c (c_common_post_options): Enable warn_logical_op with extra_warnings. * c-common.c (warn_logical_op): Update. * c-common.h (warn_logical_op): Update declaration. cp/ * call.c (build_new_op): Save the original codes of operands before folding. testsuite/ * gcc.dg/pr32061.c: New. * gcc.dg/Wlogical-op-1.c: Update. * g++.dg/warn/Wlogical-op-1.C: Update. * g++.dg/warn/pr36954.C: New. Added: trunk/gcc/testsuite/g++.dg/warn/pr36954.C trunk/gcc/testsuite/gcc.dg/pr32061.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/c-common.h trunk/gcc/c-opts.c trunk/gcc/c-typeck.c trunk/gcc/c.opt trunk/gcc/common.opt trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/warn/Wlogical-op-1.C trunk/gcc/testsuite/gcc.dg/Wlogical-op-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32061
[Bug c++/36954] Wrong warning with -Wlogical-op
--- Comment #2 from manu at gcc dot gnu dot org 2009-04-19 11:04 --- Subject: Bug 36954 Author: manu Date: Sun Apr 19 11:04:13 2009 New Revision: 146344 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146344 Log: 2009-04-19 Manuel López-Ibáñez m...@gcc.gnu.org PR c/32061 PR c++/36954 * doc/invoke.texi: Add -Wlogical-op to -Wextra. * common.opt (Wlogical-op): Move from here... * c.opt (Wlogical-op): ... to here. * c-typeck.c (parser_build_binary_op): Update call to warn_logical_operator. * c-opts.c (c_common_post_options): Enable warn_logical_op with extra_warnings. * c-common.c (warn_logical_op): Update. * c-common.h (warn_logical_op): Update declaration. cp/ * call.c (build_new_op): Save the original codes of operands before folding. testsuite/ * gcc.dg/pr32061.c: New. * gcc.dg/Wlogical-op-1.c: Update. * g++.dg/warn/Wlogical-op-1.C: Update. * g++.dg/warn/pr36954.C: New. Added: trunk/gcc/testsuite/g++.dg/warn/pr36954.C trunk/gcc/testsuite/gcc.dg/pr32061.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/c-common.h trunk/gcc/c-opts.c trunk/gcc/c-typeck.c trunk/gcc/c.opt trunk/gcc/common.opt trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/warn/Wlogical-op-1.C trunk/gcc/testsuite/gcc.dg/Wlogical-op-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36954
[Bug c++/36954] Wrong warning with -Wlogical-op
--- Comment #3 from manu at gcc dot gnu dot org 2009-04-19 11:08 --- FIXED in GCC 4.5 -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36954
[Bug c/32061] (Wlogical-op) wording of warning of constant logicials need improvement
--- Comment #7 from manu at gcc dot gnu dot org 2009-04-19 11:06 --- FIXED in GCC 4.5 -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32061
[Bug c++/39813] New: [feature request] __PRETTY_FUNCTION__ addition
Given the following code:
template typename T
struct A
{
void fn() { cout __PRETTY_FUNCTION__ endl; }
};
struct B
{
template typename T
void fn() { cout __PRETTY_FUNCTION__ endl; }
};
int main()
{
Aint().fn();
B().fnint();
}
g++ outputs:
void AT::fn() [with T = int]
void B::fn() [with T = int]
I think that the latter should output:
void B::fnT() [with T = int]
--
Summary: [feature request] __PRETTY_FUNCTION__ addition
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at daryl dot haresign dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39813
[Bug testsuite/39781] Fail: g++.dg/cpp/_Pragma1.C, gcc.dg/cpp/_Pragma6.c
--- Comment #1 from ramana at gcc dot gnu dot org 2009-04-19 11:37 --- Patch submitted here. http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01406.html -- 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-04-19 11:37:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39781
[Bug debug/39814] New: GCC does not emit debug info for a called function
The following program:
#include stdio.h
#include math.h
int main() {
printf(asin(1.0) = %f\n, asin(1.0));
return 0;
}
prints correctly 1.570796, but p asin(1.0) from within gdb prints 0. However,
this work fine:
(gdb) p ((double (*)(double))asin) (1.0)
$4 = 1.5707963267948966
Or, with libc debug symbols installed:
(gdb) p __asin (1.0)
$5 = 1.5707963267948966
The explanation from Daniel Jacobowitz is:
The C library does not contain debug info for a function named 'asin',
because the implementation is __asin, so GDB does not know it returns
a double. Also, GCC does not emit debug info for the called function
- I don't know why it doesn't, but probably to save space.
--
Summary: GCC does not emit debug info for a called function
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: arthur dot loiret at gmail dot com
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39814
[Bug c/39812] [4.5 regression] gcc.target/i386/cleanup-1.c and 8 gnat.dg tests FAIL between r146303 and r146339
--- Comment #1 from laurent at guerby dot net 2009-04-19 12:37 --- r146313 works and r146314 fails the 8 gnat.dg tests: r146314 | rguenth | 2009-04-18 15:02:00 +0200 (Sat, 18 Apr 2009) | 11 lines 2009-04-18 Richard Guenther rguent...@suse.de PR middle-end/39804 * tree-ssa-ccp.c (fold_stmt_1): New function factored from ... (fold_stmt): ... this and ... (fold_stmt_inplace): ... this. (fold_stmt_1): Fold references in calls and asms. * tree-cfg.c (remove_useless_stmts_cond): Use fold_stmt. * gcc.target/i386/pr39804.c: New testcase. -- laurent at guerby dot net changed: What|Removed |Added CC||laurent at guerby dot net, ||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39812
[Bug regression/35671] GCC 4.4.x vs. 4.2.x performance regression
--- Comment #8 from t dot artem at mailcity dot com 2009-04-19 13:51 --- If anyone cares to repeat my test results, here's a simple test case: 1) Obtain a large enough collection of WAV files (however I'm sure all other compressible material will also fit this test). If you have wine emulator installed you can get many large wav files by running this application (http://www.scene.org/file.php?file=/demos/groups/farb-rausch/fr-028.zipfileinfo) - record all files to the same folder. 2) Compress your test folder with RAR archiver (http://rarlabs.com/rar/rarlinux-3.8.0.tar.gz) using these parameters: rar -r -m5 -mdG arhive_name.rar folder 3) Compile unrar (http://www.rarlab.com/rar/unrarsrc-3.8.5.tar.gz) with the already given parameters. See :) (In reply to comment #7) For better speed with -march=pentium2 you should add -mtune=generic which will use only pentium2 features but tunes the code to not pessimize newer processors. As you can see 1) GCC 4.2 pessimizes code less than GCC 4.4, and 2) I'm sure no new pentium2 optimizations have been introduced for the last two years - so I'm sure general -O2 code produced by GCC 4.4 (and 4.3) is less optimized than code produced by GCC 4.2. At least it's quite obvious than most binaries are larger - but performance benefit is not so clear. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35671
[Bug fortran/38802] Seg fault for RESULT with allocatable components
--- Comment #4 from pault at gcc dot gnu dot org 2009-04-19 15:03 --- Fixed on trunk. Thanks for the report Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38802
[Bug libstdc++/39815] New: [4.5 Regression] Revision 146317 caused many libstdc++ failures
Revision 146317: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00954.html caused: FAIL: 29_atomics/atomic_flag/test_and_set/explicit.c (test for excess errors) FAIL: 29_atomics/atomic_flag/test_and_set/implicit.c (test for excess errors) FAIL: 29_atomics/headers/stdatomic.h/debug_mode.c (test for excess errors) FAIL: 29_atomics/headers/stdatomic.h/functions.c (test for excess errors) FAIL: 29_atomics/headers/stdatomic.h/macros.c (test for excess errors) FAIL: 29_atomics/headers/stdatomic.h/types.c (test for excess errors) -- Summary: [4.5 Regression] Revision 146317 caused many libstdc++ failures Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ 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=39815
[Bug middle-end/39816] New: [4.5 Regression] Revision 146322 failed gcc.target/i386/cleanup-1.c
Revision 146322: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00959.html caused: FAIL: gcc.target/i386/cleanup-1.c execution test FAIL: gcc.target/i386/cleanup-2.c execution test on Linux/Intel64 and Linux/ia32. -- Summary: [4.5 Regression] Revision 146322 failed gcc.target/i386/cleanup-1.c Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end 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=39816
[Bug c/39812] [4.5 regression] gcc.target/i386/cleanup-1.c and 8 gnat.dg tests FAIL between r146303 and r146339
--- Comment #2 from hjl dot tools at gmail dot com 2009-04-19 15:37 --- *** Bug 39816 has been marked as a duplicate of this bug. *** -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39812
[Bug middle-end/39816] [4.5 Regression] Revision 146322 failed gcc.target/i386/cleanup-1.c
--- Comment #1 from hjl dot tools at gmail dot com 2009-04-19 15:37 --- *** This bug has been marked as a duplicate of 39812 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39816
[Bug libobjc/39817] New: objc_msg_sendv crashes on AMD64
On AMD64, using objc_msg_sendv leads to a segfault. This is because libobjc uses __builtin_return in objc_msg_sendv, which is broken on AMD64. I'm not sure whether I should create another bug that it's broken on AMD64 or if I should just report it as a bug in libobjc. The workaround would be to use libffi in objc_msg_sendv. This bug renders libobjc pretty useless on AMD64, because forwarding is used a lot in objc and each time you forward something, it just crashes. This is the reason why I chose blocker as severity, it makes libobjc completely useless on AMD64. And I'm pretty sure this affects other architectures as well. The backtrace is: #0 0x00600c30 in _OBJC_SELECTOR_TABLE () #1 0x in ?? () If you change objc_msg_sendv to not use __builtin_return but instead return for example NULL, it works (though of course the return value is wrong). I really recommend getting this fixed for the next 4.3 release. Objc support is unusable as it is on AMD64 atm. I'm confused that none of the GNustep guys reported this before, but I remember that they're using libffi somewhere, so most likely they'll use it here as well. -- Summary: objc_msg_sendv crashes on AMD64 Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: libobjc AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: js-gcc at webkeks dot org GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39817
[Bug middle-end/39812] [4.5 regression] Revision 146322 failed gcc.target/i386/cleanup-1.c and 8 gnat.dg tests FAIL between r146303 and r146339
--- Comment #3 from hjl dot tools at gmail dot com 2009-04-19 15:40 --- This is caused by revision 146322: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00959.html I also saw FAIL: gcc.target/i386/cleanup-2.c execution test on Linux/Intel64. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jh at suse dot cz Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed|0 |1 GCC build triplet|i686-unknown-linux | GCC host triplet|i686-unknown-linux | GCC target triplet|i686-unknown-linux |x86 Last reconfirmed|-00-00 00:00:00 |2009-04-19 15:40:42 date|| Summary|[4.5 regression]|[4.5 regression] Revision |gcc.target/i386/cleanup-1.c |146322 failed |and 8 gnat.dg tests FAIL|gcc.target/i386/cleanup-1.c |between r146303 and r146339 |and 8 gnat.dg tests FAIL ||between r146303 and r146339 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39812
[Bug libstdc++/39815] [4.5 Regression] Revision 146317 caused many libstdc++ failures
--- Comment #1 from paolo dot carlini at oracle dot com 2009-04-19 15:42 --- This is already fixed, try again. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39815
[Bug middle-end/39812] [4.5 regression] Revision 146314 failed 8 gnat.dg tests
--- Comment #4 from hjl dot tools at gmail dot com 2009-04-19 15:43 --- Apparently, there are 2 bugs. I will reopen 39816 for gcc.target/i386/cleanup-1.c. -- hjl dot tools at gmail dot com changed: What|Removed |Added GCC build triplet||i686-pc-linux-gnu GCC host triplet||i686-pc-linux-gnu GCC target triplet|x86 |i686-pc-linux-gnu Summary|[4.5 regression] Revision |[4.5 regression] Revision |146322 failed |146314 failed 8 gnat.dg |gcc.target/i386/cleanup-1.c |tests |and 8 gnat.dg tests FAIL| |between r146303 and r146339 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39812
[Bug middle-end/39816] [4.5 Regression] Revision 146322 failed gcc.target/i386/cleanup-1.c
--- Comment #2 from hjl dot tools at gmail dot com 2009-04-19 15:43 --- Reopened. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39816
[Bug libobjc/39817] objc_msg_sendv crashes on AMD64
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-19 15:52 --- I really recommend getting this fixed for the next 4.3 release. Considering this has always been broken since the first release of libobjc which supported a target that passed via registers (aka have always been broken since the first release :) ), this is not going to be fixed until at least 4.5 now since 4.3 and 4.4 are both in regression only mode (aka release mode). *** This bug has been marked as a duplicate of 36610 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39817
[Bug libobjc/36610] objc_msg_sendv is broken for targets which pass argument via registers
--- Comment #15 from pinskia at gcc dot gnu dot org 2009-04-19 15:52 --- *** Bug 39817 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||js-gcc at webkeks dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36610
[Bug debug/39814] GCC does not emit debug info for a called function
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-19 16:04 --- Can you attach the preprocessed source? And what options are you using to compile the program? It might be the case that asin is defined in the glibc's header as a macro which causes no debug information to be emitted for asin as asin is not really used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39814
[Bug middle-end/39816] [4.5 Regression] Revision 146322 failed gcc.target/i386/cleanup-1.c
--- Comment #3 from hjl dot tools at gmail dot com 2009-04-19 16:50 --- Fixed as of revision 146350. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39816
[Bug preprocessor/20078] Gcc doesn't complain about non-benign macro definitions
--- Comment #2 from jsm28 at gcc dot gnu dot org 2009-04-19 17:11 --- Subject: Bug 20078 Author: jsm28 Date: Sun Apr 19 17:10:56 2009 New Revision: 146352 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146352 Log: libcpp: PR preprocessor/20078 * include/cpp-id-data.h (struct cpp_macro): Add extra_tokens field. * include/cpplib.h (SP_DIGRAPH, SP_PREV_WHITE): Define. (struct cpp_token): Change flags to unsigned short. * lex.c (_cpp_lex_direct): Initialize arg_no for CPP_PASTE tokens. (_cpp_equiv_tokens): Check arg_no for CPP_PASTE tokens. (cpp_token_val_index): Return CPP_TOKEN_FLD_ARG_NO for CPP_PASTE tokens. * macro.c (macro_real_token_count): New. (enter_macro_context, replace_args): Use macro_real_token_count. (create_iso_definition): Record whitespace surrounding and digraph spelling of # and ## tokens using SP_PREV_WHITE and SP_DIGRAPH. Set extra_tokens and save CPP_PASTE tokens with arg_no set for multiple consecutive ## tokens. (_cpp_create_definition): Initialize extra_tokens. (cpp_macro_definition): Use macro_real_token_count. gcc/testsuite: * gcc.dg/cpp/paste16.c, gcc.dg/cpp/redef4.c: New tests. Added: trunk/gcc/testsuite/gcc.dg/cpp/paste16.c trunk/gcc/testsuite/gcc.dg/cpp/redef4.c Modified: trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/include/cpp-id-data.h trunk/libcpp/include/cpplib.h trunk/libcpp/lex.c trunk/libcpp/macro.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20078
[Bug preprocessor/20078] Gcc doesn't complain about non-benign macro definitions
--- Comment #3 from jsm28 at gcc dot gnu dot org 2009-04-19 17:14 --- Fixed for 4.5 along with related issues about whitespace variations around # and ## operators, and variations in the number of consecutive ## operators, not always being diagnosed as invalid duplicate macro definitions. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.5.0 Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20078
[Bug preprocessor/39818] New: cpp_macro_definition should preserve # and ## spelling and whitespace
cpp_macro_definition, as used by options such as -dM, for PCH and for outputting macro definitions in debug info, should preserve the spelling (digraph or not) of # and ## operators, whether there is whitespace around them and sequences of consecutive ## and %:%: operators. After my patch for bug 20078, the relevant information is available at this point; it just isn't used for the textual output. -- Summary: cpp_macro_definition should preserve # and ## spelling and whitespace Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39818
[Bug middle-end/39275] -funroll-loop fails
--- Comment #2 from linuxl4 at sohu dot com 2009-04-19 17:30 --- can anybody comfirm? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39275
[Bug c/38243] Restrict constraint violation not an error with -pedantic-errors
--- Comment #2 from jsm28 at gcc dot gnu dot org 2009-04-19 18:25 --- Subject: Bug 38243 Author: jsm28 Date: Sun Apr 19 18:25:07 2009 New Revision: 146356 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146356 Log: PR c/38243 * c-decl.c (shadow_tag_warned): Diagnose use of restrict when declaring a tag. testsuite: * gcc.dg/c99-restrict-3.c: New test. Added: trunk/gcc/testsuite/gcc.dg/c99-restrict-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38243
[Bug c/38243] Restrict constraint violation not an error with -pedantic-errors
--- Comment #3 from jsm28 at gcc dot gnu dot org 2009-04-19 18:26 --- Fixed for 4.5. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.5.0 Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38243
[Bug tree-optimization/39804] [4.5 Regression] internal compiler error: in propagate_necessity, at tree-ssa-dce.c:754
--- Comment #8 from segher at kernel dot crashing dot org 2009-04-19 19:39 --- Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr39804.c Hi hjl, Why backport a single testcase from trunk to 4.4? This bug never existed on 4.4, it's not terribly useful as far as I can see. Also, I didn't see this on gcc-patches. Segher -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39804
[Bug middle-end/39812] [4.5 regression] Revision 146314 failed 8 gnat.dg tests
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-04-19 19:49 --- Any hint on what happens? My Ada skills are rather weak. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39812
[Bug middle-end/39812] [4.5 regression] Revision 146314 failed 8 gnat.dg tests
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39812
[Bug c/19771] VLA deallocation
--- Comment #5 from jsm28 at gcc dot gnu dot org 2009-04-19 20:20 --- Subject: Bug 19771 Author: jsm28 Date: Sun Apr 19 20:19:54 2009 New Revision: 146358 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146358 Log: PR c/19771 * c-semantics.c (pop_stmt_list): Propagate STATEMENT_LIST_HAS_LABEL to parent statement list. testsuite: * gcc.c-torture/execute/vla-dealloc-1.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/vla-dealloc-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-semantics.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19771
[Bug c/19771] VLA deallocation
--- Comment #6 from jsm28 at gcc dot gnu dot org 2009-04-19 20:21 --- Fixed for 4.5. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.5.0 Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19771
[Bug middle-end/39812] [4.5 regression] Revision 146314 failed 8 gnat.dg tests
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-04-19 20:37 --- Works for me on i686-linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39812
[Bug c/37481] -pedantic accepts flexible array member = string initialization
--- Comment #1 from jsm28 at gcc dot gnu dot org 2009-04-19 20:39 --- Subject: Bug 37481 Author: jsm28 Date: Sun Apr 19 20:38:53 2009 New Revision: 146359 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146359 Log: PR c/37481 * c-typeck.c (digest_init): Check for initializing an array with a string literal. testsuite: * gcc.dg/c99-flex-array-7.c: New test. Added: trunk/gcc/testsuite/gcc.dg/c99-flex-array-7.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37481
[Bug c/37481] -pedantic accepts flexible array member = string initialization
--- Comment #2 from jsm28 at gcc dot gnu dot org 2009-04-19 20:40 --- Fixed for 4.5. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.5.0 Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37481
[Bug middle-end/39812] [4.5 regression] Revision 146314 failed 8 gnat.dg tests
--- Comment #7 from laurent at guerby dot net 2009-04-19 20:49 --- For me with -m32: 146313: OK 146314: FAIL 146322: OK I'm rebuilding 146313 and 146314 and try to diff what changes -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39812
[Bug c/39819] New: Missed optimisation when setting 4-byte values
avr-gcc misses a number of optimisations when copying 4-byte values or
assigning a single byte value to 4 byte values. The issue actually applies to
other sized values as well, but since 4 byte values are common (such as for
32-bit ints, and for floats) the issue is especially relevant.
In summary, the compiler tends to produce code that is either a series of
direct memory accesses, or uses indirect access (through Z) in a loop. A
better choice would often be to set up Z as a pointer, then unroll the indirect
pointer loop.
All code was compiled using avr-gcc 4.3.2 from winavr-20090313, using -Os.
Look at the code:
typedef unsigned char uint8_t;
typedef unsigned long int uint32_t;
static uint8_t as[4];
static uint8_t bs[4];
void foo1(void) {
for (uint8_t i = 0; i sz; i++) {
bs[i] = as[1];
}
}
void foo2(void) {
for (uint8_t i = 0; i sz; i++) {
*(bs + i) = *(as + 1);
}
}
foo1 compiles to:
lds r24, as+1
sts bs, r24
sts bs+1, r24
sts bs+2, r24
sts bs+3, r24
ret
Excluding the ret, this is 10 words and 10 cycles.
foo2 is logically identical (array access and pointer access are the same
thing), but compiles to:
lds r24, as+1
ldi r30, lo8(bs)
ldi r31, hi8(bs)
.L1:
st Z+, r24
ldi r25, hi8(bs+4)
cpi r30, lo8(bs+4)
cpc r31, r25
brne L1
ret
Excluding the ret, this is 9 words and 31 cycles (27 on the XMega). Hoisting
the ldi r25, hi8(bs+4) above the label would save four cycles.
An implementation that is smaller than both of these, and slightly slower on
the Mega and slightly faster on the XMega, is:
lds r24, as+1
ldi r30, lo8(bs)
ldi r31, hi8(bs)
st Z+, r24
st Z+, r24
st Z+, r24
st Z+, r24
ret
Excluding the ret this is 8 words, and 12 cycles (8 on the XMega).
For the code:
static uint32_t al, bl;
static float af;
void foo3(void) {
al = 0;
}
void foo4(void) {
af = 0;
}
we get:
foo3:
sts al, __zero_reg__
sts (al)+1, __zero_reg__
sts (al)+2, __zero_reg__
sts (al)+3, __zero_reg__
ret
That's 8 words and 8 cycles (plus ret). Using
ldi r30, lo8(bs)
ldi r31, hi8(bs)
st Z+, __zero_reg__
st Z+, __zero_reg__
st Z+, __zero_reg__
st Z+, __zero_reg__
ret
Gives 6 words and 10 cycles, or 6 cycles on the XMega (plus ret)
Function foo4() should of course give the same code, but instead compiles to
the very inefficient:
foo4:
ldi r24, lo8(0x00)
ldi r25, hi8(0x00)
ldi r26, hlo8(0x00)
ldi r27, hhi8(0x00)
sts af, __zero_reg__
sts (af)+1, __zero_reg__
sts (af)+2, __zero_reg__
sts (af)+3, __zero_reg__
ret
That's 12 words and 12 cycles, and uses 4 registers unnecessarily.
Similar code is produced when copying values:
void foo5(void) {
al = bl;
}
compiles to:
foo5:
lds r24, bl
lds r25, (bl) + 1
lds r26, (bl) + 2
lds r27, (bl) + 3
sts al, r24
sts (al) + 1, r25
sts (al) + 2, r26
sts (al) + 3, r27
Using the Z and either X or Y pointers would make this code slightly smaller
but marginally slower on the Mega (and marginally faster on the XMega). Even
without that, re-arranging the code would allow a single register to be used
rather than four.
ret
--
Summary: Missed optimisation when setting 4-byte values
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david dot brown at hesbynett dot no
GCC host triplet: mingw
GCC target triplet: avr-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39819
[Bug target/39247] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
--- Comment #2 from ramana at gcc dot gnu dot org 2009-04-19 21:32 --- Still occurs with trunk today. -- 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-04-19 21:32:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39247
[Bug tree-optimization/39249] FAIL: g++.dg/ipa/iinline-1.C scan-ipa-dump inline String::funcOne[^\n]*inline copy in int main
-- 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-04-19 21:37:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39249
[Bug middle-end/35141] ARM: Constant generation inside a loop: Missed optimization opportunity
--- Comment #8 from ramana at gcc dot gnu dot org 2009-04-19 21:41 --- This appears to be fixed on all release branches. This probably should now be closed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35141
[Bug target/31938] Wrong code on int to short cast on armeb
--- Comment #3 from ramana at gcc dot gnu dot org 2009-04-19 21:59 --- I believe this is a case of wrong usage of the compiler and this bug could be closed as invalid. However the question remains about big endian and little endian compiler options and supporting or not support armeb options correctly and hence I am leaving this open for now. -- ramana at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31938
[Bug bootstrap/32101] xgcc invokes as with invalid -m option while assembling crtbegin.o
--- Comment #7 from ramana at gcc dot gnu dot org 2009-04-19 22:02 --- This doesn't appear with any of the release branches (4.3, 4.4) or trunk currently. Can this now be closed out ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32101
[Bug c++/39820] New: errors while compiling libc and the kernel
This is new: libc: In file included from regex.c:65: regexec.c: In function 're_search_stub': regexec.c:411: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[2]: *** [/home/a-12/LFS/gcc/glibc-build/posix/regex.o] Error 1 make[2]: Leaving directory `/home/name/LFS/gcc/glibc-20090413/posix' make[1]: *** [posix/subdir_lib] Error 2 make[1]: Leaving directory `/home/name/LFS/gcc/glibc-20090413' make: *** [all] Error 2 latest git: CC arch/x86/mm/pgtable.o arch/x86/mm/pgtable.c: In function 'pgd_prepopulate_pmd': arch/x86/mm/pgtable.c:352: error: incorrect sharing of tree nodes D.24886.pud.pgd = swapper_pg_dir[i]; swapper_pg_dir[i] arch/x86/mm/pgtable.c:352: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[1]: *** [arch/x86/mm/pgtable.o] Error 1 make: *** [arch/x86/mm] Error 2 I think I'll downgrade gcc(until further notice). -- Summary: errors while compiling libc and the kernel Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: justinmattock at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39820
[Bug target/39819] [avr] Missed optimisation when setting 4-byte values
-- eric dot weddington at atmel dot com changed: What|Removed |Added CC||eric dot weddington at atmel ||dot com Severity|enhancement |normal Component|c |target GCC host triplet|mingw | GCC target triplet|avr-gcc |avr-*-* Keywords||missed-optimization Summary|Missed optimisation when|[avr] Missed optimisation |setting 4-byte values |when setting 4-byte values http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39819
vector issue in g++?
I don't think this is a bug but certainly it is a problem.
Would you please consider it and let me know? I hope so. Thanks.
The following simple volcalc.cpp code compiles with no errors (and
works) in Windows Visual C++.
It simply sizes the alldata array later in the code.
With g++ v.4.3.2 instead I get the error reported hereby.
For some reason it does not like the fact that struct is declared
local. If you declare struct as global it will be working but I cannot
change the code so drastically.
I would thankfully appreciate any help (including tough critics to the code).
volcalc.cpp:26: error: template argument for ‘templateclass _Alloc
class std::allocator’ uses local type ‘main(int, char**)::series’
volcalc.cpp:26: error: trying to instantiate ‘templateclass _Alloc
class std::allocator’
volcalc.cpp:26: error: template argument 2 is invalid
volcalc.cpp:66: error: request for member ‘resize’ in ‘alldata’, which
is of non-class type ‘int’
int main(int argc, char *argv[])
{
struct series {
};
int nr;
vectorseries alldata; // line 26
// calculate nr as int.
alldata.resize(nr); // line 66
}
[Bug middle-end/39812] [4.5 regression] Revision 146314 failed 8 gnat.dg tests
--- Comment #8 from laurent at guerby dot net 2009-04-20 00:07 --- I made a procedural mistake above, the right FAIL point is: 146321: OK 146322: FAIL diff: +2009-04-18 Jan Hubicka j...@suse.cz + + * cgraph.c (cgraph_make_edge, dump_cgraph_node, cgraph_set_call_stmt): + Set nothrow flag. + * cgraph.h (struct function): Reduce loop_nest to 30 bits; add + can_throw_external flag. + * ipa-reference.c (ipa_utils_reduced_inorder): Update call. + * ipa-pure-const.c (ignore_edge): New function. + (propagate): Compute order for NOTHROW computation; set NOTHROWs + only over can_throw_external edges. + (local_pure_const): Add nothrow flag. + * ipa-utils.c (searchc): Add ignore_edge callback. + (ipa_utils_reduced_inorder): Add ignore_edge callback. + * ipa-utils.h (ipa_utils_reduced_inorder): Update prototype. + (set_nothrow_function_flags): Update cgraph. + * tree-cfg.c (verify_stmt): Relax nothrow checking when in IPA mode. + To reproduce on a simple test case: BUILD=/some/where SRC=/some/whereelse $BUILD/gcc/gnatmake -f -g -m32 --GCC=$BUILD/gcc/xgcc --GNATLINK=$BUILD/gcc/gnatlink --GNATBIND=$BUILD/gcc/gnatbind --RTS=$BUILD/x86_64-unknown-linux-gnu/32/libada/ $SRC/gcc/testsuite/gnat.dg/not_null.adb -cargs -B$BUILD/gcc -largs -B$BUILD/gcc ./not_null This will raise an exception which means the main program exception handler does not receive the exception. This was likely fixed by: 2009-04-19 Jan Hubicka j...@suse.cz * cgraph.c (cgraph_create_edge, cgraph_set_call_stmt): Set proper cfun. (dump_cgraph_node): Dump can throw external flag. * ipa-pure-const.c (propagate): Fix propagation of nothrow flags. I will confirm later on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39812
[Bug tree-optimization/39821] New: 120% slowdown with vectorizer
The vectorizer produces horrible code with this testcase:
$ cat dotproduct.c
#include inttypes.h
int64_t dotproduct(int32_t *v1, int32_t *v2, int order)
{
int64_t accum = 0;
while (order--)
accum += (int64_t) *v1++ * *v2++;
return accum;
}
int64_t dotproduct_order4(int32_t *v1, int32_t *v2, int order)
{
return dotproduct(v1, v2, 4);
}
$ gcc-4.4rc1 -o dotproduct.o -c dotproduct.c -O3
$ gcc-4.4rc1 -o dotproduct-no-vectorize.o -c dotproduct.c -O3
-fno-tree-vectorize
$ objdump -d dotproduct.o
dotproduct.o: file format elf64-x86-64
Disassembly of section .text:
dotproduct:
0: 31 c0 xor%eax,%eax
2: 85 d2 test %edx,%edx
4: 0f 84 4e 01 00 00 je 158 dotproduct+0x158
a: 41 89 d0mov%edx,%r8d
d: 44 8d 52 ff lea-0x1(%rdx),%r10d
11: 41 c1 e8 02 shr$0x2,%r8d
15: 83 fa 03cmp$0x3,%edx
18: 46 8d 0c 85 00 00 00lea0x0(,%r8,4),%r9d
1f: 00
20: 76 05 jbe27 dotproduct+0x27
22: 45 85 c9test %r9d,%r9d
25: 75 09 jne30 dotproduct+0x30
27: 31 c0 xor%eax,%eax
29: e9 fc 00 00 00 jmpq 12a dotproduct+0x12a
2e: 66 90 xchg %ax,%ax
30: 66 0f ef c0 pxor %xmm0,%xmm0
34: 31 c0 xor%eax,%eax
36: 66 45 0f ef c9 pxor %xmm9,%xmm9
3b: 31 c9 xor%ecx,%ecx
3d: 0f 1f 00nopl (%rax)
40: f3 0f 6f 14 07 movdqu (%rdi,%rax,1),%xmm2
45: 83 c1 01add$0x1,%ecx
48: 66 41 0f 6f d9 movdqa %xmm9,%xmm3
4d: f3 0f 6f 24 06 movdqu (%rsi,%rax,1),%xmm4
52: 66 45 0f 6f c1 movdqa %xmm9,%xmm8
57: 66 0f 6f ea movdqa %xmm2,%xmm5
5b: 48 83 c0 10 add$0x10,%rax
5f: 66 0f 66 dc pcmpgtd %xmm4,%xmm3
63: 66 0f 6f fc movdqa %xmm4,%xmm7
67: 66 44 0f 66 c2 pcmpgtd %xmm2,%xmm8
6c: 41 39 c8cmp%ecx,%r8d
6f: 66 0f 62 fb punpckldq %xmm3,%xmm7
73: 66 41 0f 62 e8 punpckldq %xmm8,%xmm5
78: 66 0f 6a e3 punpckhdq %xmm3,%xmm4
7c: 66 41 0f 6a d0 punpckhdq %xmm8,%xmm2
81: 66 0f 6f cf movdqa %xmm7,%xmm1
85: 66 0f 6f f5 movdqa %xmm5,%xmm6
89: 66 44 0f 6f d7 movdqa %xmm7,%xmm10
8e: 66 0f f4 cd pmuludq %xmm5,%xmm1
92: 66 0f 6f da movdqa %xmm2,%xmm3
96: 66 0f 73 d6 20 psrlq $0x20,%xmm6
9b: 66 0f f4 f7 pmuludq %xmm7,%xmm6
9f: 66 41 0f 73 d2 20 psrlq $0x20,%xmm10
a5: 66 0f 73 f6 20 psllq $0x20,%xmm6
aa: 66 41 0f f4 ea pmuludq %xmm10,%xmm5
af: 66 0f d4 ce paddq %xmm6,%xmm1
b3: 66 0f 73 f5 20 psllq $0x20,%xmm5
b8: 66 0f d4 cd paddq %xmm5,%xmm1
bc: 66 0f 6f ec movdqa %xmm4,%xmm5
c0: 66 0f d4 c8 paddq %xmm0,%xmm1
c4: 66 0f 73 d3 20 psrlq $0x20,%xmm3
c9: 66 0f 6f c4 movdqa %xmm4,%xmm0
cd: 66 0f f4 dc pmuludq %xmm4,%xmm3
d1: 66 0f 73 f3 20 psllq $0x20,%xmm3
d6: 66 0f 73 d5 20 psrlq $0x20,%xmm5
db: 66 0f f4 c2 pmuludq %xmm2,%xmm0
df: 66 0f f4 d5 pmuludq %xmm5,%xmm2
e3: 66 0f d4 c3 paddq %xmm3,%xmm0
e7: 66 0f 73 f2 20 psllq $0x20,%xmm2
ec: 66 0f d4 c2 paddq %xmm2,%xmm0
f0: 66 0f d4 c1 paddq %xmm1,%xmm0
f4: 0f 87 46 ff ff ff ja 40 dotproduct+0x40
fa: 42 8d 0c 8d 00 00 00lea0x0(,%r9,4),%ecx
101: 00
102: 66 0f 6f c8 movdqa %xmm0,%xmm1
106: 45 29 casub%r9d,%r10d
109: 89 c9 mov%ecx,%ecx
10b: 66 0f 73 d9 08 psrldq $0x8,%xmm1
110: 66 0f d4 c1 paddq %xmm1,%xmm0
114: 48 01 cfadd%rcx,%rdi
117: 48 01 ceadd%rcx,%rsi
11a: 44 39 cacmp%r9d,%edx
11d: 66 0f d6 44 24 f8 movq %xmm0,-0x8(%rsp)
123: 48 8b 44 24 f8 mov-0x8(%rsp),%rax
128: 74 2e je 158 dotproduct+0x158
12a: 45 89 d2mov%r10d,%r10d
12d: 31 d2 xor%edx,%edx
12f: 4e 8d 0c 95 04 00 00lea0x4(,%r10,4),%r9
136: 00
137: 66 0f 1f 84 00 00 00nopw 0x0(%rax,%rax,1)
13e: 00 00
140: 48 63 0c 16 movslq (%rsi,%rdx,1),%rcx
144: 4c 63 04 17 movslq (%rdi,%rdx,1),%r8
148: 48 83 c2 04 add$0x4,%rdx
14c: 49 0f af c8 imul %r8,%rcx
150: 48 01 c8add%rcx,%rax
153: 4c 39 cacmp%r9,%rdx
156:
Re: vector issue in g++?
On Sun, Apr 19, 2009 at 4:15 PM, Paolo Piacentini paolopi...@hotmail.com wrote: I don't think this is a bug but certainly it is a problem. Would you please consider it and let me know? I hope so. Thanks. The following simple volcalc.cpp code compiles with no errors (and works) in Windows Visual C++. It simply sizes the alldata array later in the code. If Visual C++ does not diagnose the error in the code in its best standards-conforming mode, that is a bug in Visual C++. Allowing it as an extension is an entirely reasonable thing to do though. With g++ v.4.3.2 instead I get the error reported hereby. For some reason it does not like the fact that struct is declared local. That is what C++ requires; template parameters must have external linkage, and in C++98 local types do not have external linkage. If you declare struct as global it will be working but I cannot change the code so drastically. I would thankfully appreciate any help (including tough critics to the code). The drastic change would be needed to make your code valid C++, and if you do that then g++ will compile it. There has been discussion of changing this rule for the next C++ standard, see e.g., http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2402.pdf though I don't see signs of it having been merged into the current committee draft. N2402 does mention the change in MSVC++ as being a relatively recent extension. A quick search hasn't turned up the current status of N2402, though there was some discussion of weakening it by removing support for using unnamed types as template parameters, and it seemed to have reasonably strong support in that form. -- James
[Bug target/32340] [arm] libjava build failure due to missing thread synchronization primitives
--- Comment #4 from ramana at gcc dot gnu dot org 2009-04-20 05:58 --- The build is broken currently for arm-none-eabi targets on trunk. Attempting a simple fix of supporting arm-eabi* got me past the error reported in the original bug report. but I still get a failure with the following error message. /home/ramana/cos/build-java-also/./gcc/xgcc -shared-libgcc -B/home/ramana/cos/build-java-also/./gcc -nostdinc++ -L/home/ramana/cos/build-java-also/arm-none-eabi/thumb/libstdc++-v3/src -L/home/ramana/cos/build-java-also/arm-none-eabi/thumb/libstdc++-v3/src/.libs -nostdinc -B/home/ramana/cos/build-java-also/arm-none-eabi/thumb/newlib/ -isystem /home/ramana/cos/build-java-also/arm-none-eabi/thumb/newlib/targ-include -isystem /home/ramana/cos/combined/newlib/libc/include -B/home/ramana/cos/build-java-also/arm-none-eabi/thumb/libgloss/arm -L/home/ramana/cos/build-java-also/arm-none-eabi/thumb/libgloss/libnosys -L/home/ramana/cos/combined/libgloss/arm -B/usr/local/arm-none-eabi/bin/ -B/usr/local/arm-none-eabi/lib/ -isystem /usr/local/arm-none-eabi/include -isystem /usr/local/arm-none-eabi/sys-include -L/home/ramana/cos/build-java-also/./ld -mthumb -DHAVE_CONFIG_H -I. -I../../../../combined/libjava -I./include -I./gcj -I../../../../combined/libjava -Iinclude -I../../../../combined/libjava/include -I../../../../combined/libjava/classpath/include -Iclasspath/include -I../../../../combined/libjava/classpath/native/fdlibm -I../../../../combined/libjava/../boehm-gc/include -I../boehm-gc/include -I../../../../combined/libjava/.././libjava/../gcc -I../../../../combined/libjava/../zlib -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\/usr/local\ -DTOOLEXECLIBDIR=\/usr/local/arm-none-eabi/lib/thumb\ -DJAVA_HOME=\/usr/local\ -DBOOT_CLASS_PATH=\/usr/local/share/java/libgcj-4.5.0.jar\ -DJAVA_EXT_DIRS=\/usr/local/share/java/ext\ -DGCJ_ENDORSED_DIRS=\/usr/local/share/java/gcj-endorsed\ -DGCJ_VERSIONED_LIBDIR=\/usr/local/lib/thumb/gcj-4.5.0-10\ -DPATH_SEPARATOR=\:\ -DECJ_JAR_FILE=\\ -DLIBGCJ_DEFAULT_DATABASE=\/usr/local/lib/thumb/gcj-4.5.0-10/classmap.db\ -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\gcj-4.5.0-10/classmap.db\ -g -O2 -mthumb -MT jni-libjvm.lo -MD -MP -MF .deps/jni-libjvm.Tpo -c ../../../../combined/libjava/jni-libjvm.cc -o jni-libjvm.o In file included from ../../../../combined/libjava/include/jvmpi.h:17, from ../../../../combined/libjava/include/jvm.h:670, from ../../../../combined/libjava/jni-libjvm.cc:14: ../../../../combined/libjava/classpath/include/jni.h:660: note: the mangling of va_list has changed in GCC 4.4 In file included from ../../../../combined/libjava/jni-libjvm.cc:14: ../../../../combined/libjava/include/jvm.h:795: error: ParkHelper does not name a type make[5]: *** [jni-libjvm.lo] Error 1 make[5]: Leaving directory `/home/ramana/cos/build-java-also/arm-none-eabi/thumb/libjava' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/ramana/cos/build-java-also/arm-none-eabi/thumb/libjava' make[3]: *** [multi-do] Error 1 make[3]: Leaving directory `/home/ramana/cos/build-java-also/arm-none-eabi/libjava' make[2]: *** [all-multi] Error 2 make[2]: Leaving directory `/home/ramana/cos/build-java-also/arm-none-eabi/libjava' make[1]: *** [all-target-libjava] Error 2 make[1]: Leaving directory `/home/ramana/cos/build-java-also' -- ramana at gcc dot gnu dot org changed: What|Removed |Added CC||aph at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-20 05:58:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32340
