[Bug fortran/46087] Double precision values, when read in from data file, include random trailing numbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46087 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2010-10-20 07:20:18 UTC --- (In reply to comment #0) Results using gfortran 4.5.1: 2.18015987 There are also different philosophies how many digits shall be printed with list-directed I/O (fmt=*). Some compilers do not print the last / the last few digits to avoid such puzzling results. gfortran prints all to allow lossless reading of the written data. However, you can use an explicit format and print fewer significant digits, which avoids showing the last digits; for instance print '(g0.7)', 2.18 shows 2.18 Regarding the output: Results using f77: 2.1800 That looks like a bug in Absoft's compiler: If the compiler shows that many digits, it ought to show also the non-zero digits. For comparison, Intel, PathScale and NAG show the following: 2.18015987 2.18016000 2.18015987
[Bug bootstrap/46086] fail to build gcc 4.5.2 on sparc64-portbld-freebsd9.0 - configure: error: cannot compute suffix of object files: cannot compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46086 --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-10-20 07:26:30 UTC --- The versions of the libraries mentioned on my box are above the minimum recommended: mpfr-3.0.0 gmp-5.0.1 binutils-2.20.1_3 or did I miss something else? Yes, to read carefully, especially the second paragraph.
[Bug rtl-optimization/46088] [4.6 Regression] ICE: SIGSEGV in ix86_binary_operator_ok (i386.c:15025) with -Os -fnon-call-exceptions -fpeel-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46088 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 CC||jakub at gcc dot gnu.org
[Bug fortran/46079] [4.6 Regression] ABI for empty stop statement broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46079 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug c++/46078] [4.6 regression] new valgrind warnings when compiling an optimization test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46078 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-20 08:20:06 UTC --- The errors in libcpp is just something that we need to suppress in valgrind suppressions.
[Bug middle-end/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 CC||jakub at gcc dot gnu.org
[Bug tree-optimization/46068] [4.6 Regression] ICE: in consider_split, at ipa-split.c:313 with asm goto and __builtin_unreachable ()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46068 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/46066] [4.6 Regression] ICE: in create_parallel_loop, at tree-parloops.c:1455 with -ftree-parallelize-loops -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46066 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 CC||jakub at gcc dot gnu.org
[Bug target/46080] [4.4/4.5/4.6 Regression] incorrect precision of sqrtf builtin for x87 arithmetic (-mfpmath=387)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080 --- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2010-10-20 08:28:57 UTC --- (In reply to comment #2) Created attachment 22089 [details] sh script to test sqrtf Similar problems can also be found with: printf (%.60f\n%.60f\n%.60f\n, sqrtf(x), sqrtf(x), sqrtf(x)); I've found that every GCC version I could test was showing some incorrect behavior (but GCC 4.2.4 was the most consistent one). With the attached script, I get: -DSEP -O0 -O1 -O2 GCC 3.4.6 SSS SSS SDD SDD GCC 4.1.3 SSS SSS DSS DDS GCC 4.2.4 SSS SSS DDD DDD (x86) GCC 4.3.5 SSS SSS DSS DDD (ditto with GCC 4.3.2 on x86) GCC 4.4.5 DSS SSD DSS DDD where S means that one gets the result in single precision (as expected) and D means that one gets the result in double precision. You should use -ffloat-store to remove excess precision.
[Bug c++/46065] [4.6 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'tree_list' in poplevel_named_label_1, at cp/decl.c:477
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46065 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 CC||jakub at gcc dot gnu.org
[Bug tree-optimization/45860] [4.6 Regression] ICE: verify_ssa failed: virtual SSA name for non-VOP decl at -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45860 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 CC||jakub at gcc dot gnu.org
[Bug c++/46056] [C++0x] range-based for loop does not destruct iterators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46056
--- Comment #6 from Rodrigo Rivas rodrigorivascosta at gmail dot com
2010-10-20 08:56:30 UTC ---
Ok, thank you for the report...
It looks like the range-for temporary completely ignore destructors.
Also, if the range is a temporary it gets destructed quite early, instead of
being kept alive because of the implicit reference.
for (auto x : temp() )
//the temporary is destroyed here
{
//...
} //instead of here
It shouldn't be too difficult to patch, though, so I'll try and have a patch in
a while...
[Bug objc/23709] [4.3/4.4/4.5/4.6 Regression] error recovery is not smart enough
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23709 --- Comment #11 from Nicola Pero nicola at gcc dot gnu.org 2010-10-20 09:03:10 UTC --- Author: nicola Date: Wed Oct 20 09:03:06 2010 New Revision: 165713 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165713 Log: In gcc/testsuite/: 2010-10-20 Nicola Pero nicola.p...@meta-innovation.com PR objc/23709 * objc.dg/pr23709.m: New. * obj-c++.dg/pr23709.m: New. Added: trunk/gcc/testsuite/obj-c++.dg/pr23709.mm trunk/gcc/testsuite/objc.dg/pr23709.m Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/46092] New: Improve constant handling of thumb2 instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46092
Summary: Improve constant handling of thumb2 instructions
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: car...@google.com
CC: car...@google.com
Host: i686-linux
Target: arm-eabi
Build: i686-linux
Compile the following code with options -march=armv7-a -mthumb -Os
unsigned long tv(unsigned long x)
{
if (x = 65521)
x = x - 65521;
return x;
}
gcc generates:
tv:
movwr3, #65520
cmp r0, r3
ittthi
subhi r0, r0, #65024 // A
subhi r0, r0, #496 // B
subhi r0, r0, #1 // C
bx lr
Notice that (x = x - 65521) is translated into 3 instructions. Actually 65521
can be loaded into register with one instruction. So the shorter result is:
tv:
movwr3, #65520
cmp r0, r3
ittthi
movwhi r1, #65521
subhi r0, r1
bx lr
This should be improved by function arm_gen_constant. The function is already
commented with
/* ??? This needs more work for thumb2. */
[Bug target/46080] [4.4/4.5/4.6 Regression] incorrect precision of sqrtf builtin for x87 arithmetic (-mfpmath=387)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-20 09:39:29 UTC --- Or in 4.6 better yet -std=c99 or -fexcess-precision=standard
[Bug tree-optimization/46066] [4.6 Regression] ICE: in create_parallel_loop, at tree-parloops.c:1455 with -ftree-parallelize-loops -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46066 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.10.20 09:52:32 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-20 09:52:31 UTC --- Created attachment 22090 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22090 gcc46-pr46066.patch Untested fix.
[Bug target/46080] [4.4/4.5/4.6 Regression] incorrect precision of sqrtf builtin for x87 arithmetic (-mfpmath=387)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080 --- Comment #5 from Paul Zimmermann zimmerma+gcc at loria dot fr 2010-10-20 09:54:01 UTC --- (In reply to comment #3) You should use -ffloat-store to remove excess precision. the main issue is not the excess of precision, but the fact that identical calls to printf with identical arguments give different values in the same program! The fact that different versions of GCC behave differently vs precision is a different issue. Paul
[Bug tree-optimization/45860] [4.6 Regression] ICE: verify_ssa failed: virtual SSA name for non-VOP decl at -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45860 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-20 09:57:41 UTC --- I have a patch.
[Bug c++/46056] [C++0x] range-based for loop does not destruct iterators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46056 --- Comment #7 from Rodrigo Rivas rodrigorivascosta at gmail dot com 2010-10-20 10:06:39 UTC --- I've just sent a patch to gcc-patches: http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01699.html In the testcase I added a lot of other destructor checks, just to be sure.
[Bug lto/46083] gcc.dg/initpri1.c FAILs with -flto/-fwhopr (attribute constructor/destructor doesn't work)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46083 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-20 10:06:54 UTC --- Honza, maybe your constructor re-ordering doesn't honor priority?
[Bug target/46080] [4.4/4.5/4.6 Regression] incorrect precision of sqrtf builtin for x87 arithmetic (-mfpmath=387)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-20 10:46:14 UTC --- That depends on the register allocation, whether the result of fsqrt needs to be flushed into memory or can stay in the i387 register stack. In the former case it gets rounded from long double to float, in the latter case it doesn't. OT, I wonder about: /* Test the result; if it is NaN, set errno=EDOM because the argument was not in the domain. */ do_compare_rtx_and_jump (target, target, EQ, 0, GET_MODE (target), NULL_RTX, NULL_RTX, lab, /* The jump is very likely. */ REG_BR_PROB_BASE - (REG_BR_PROB_BASE / 2000 - 1)); Why do we use (EQ target target) here instead of (ORDERED target target)? At least on i?87 the latter is cheaper than the former, we eventually simplify it, but it would be IMHO better to avoid generating useless rtx when the comparison often needs to be split into ORDERED UNEQ.
[Bug target/46093] New: code compiled with -fsplit-stack crashes when passing large struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46093 Summary: code compiled with -fsplit-stack crashes when passing large struct Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 22091 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22091 testcase Output (-g is not needed to reproduce): $ gcc -fsplit-stack testcase.c -g $ gdb ./a.out ... Program received signal SIGSEGV, Segmentation fault. 0x00400ca9 in foo (s=...) at testcase.c:14 14bar (s); (gdb) bt #0 0x00400ca9 in foo (s=...) at testcase.c:14 #1 0x00400d84 in __morestack () at /mnt/svn/gcc-trunk/libgcc/config/i386/morestack.S:374 #2 0x00400d00 in main () at testcase.c:21 I am not sure if that can be a problem here, but this is my binutils info: $ ld -v GNU ld (GNU Binutils) 2.20.1.20100303
[Bug tree-optimization/45860] [4.6 Regression] ICE: verify_ssa failed: virtual SSA name for non-VOP decl at -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45860 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-20 11:09:57 UTC --- Author: rguenth Date: Wed Oct 20 11:09:54 2010 New Revision: 165718 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165718 Log: 2010-10-20 Richard Guenther rguent...@suse.de PR tree-optimization/45860 * tree-ssa-phiopt.c (cond_store_replacement): Do not do conditional store replacement for non-register type stores. * gcc.dg/torture/pr45860.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr45860.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-phiopt.c
[Bug tree-optimization/46085] [4..6 Regression] gcc.dg/vect/fast-math-vect-reduc-[57].c failed with -mavx -ffast-math -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46085 --- Comment #4 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2010-10-20 11:21:22 UTC --- Author: hjl Date: Wed Oct 20 11:21:19 2010 New Revision: 165719 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165719 Log: Correct reduc_splus_v8sf and reduc_splus_v4df. gcc/ 2010-10-20 H.J. Lu hongjiu...@intel.com PR target/46085 * config/i386/sse.md (reduc_splus_v8sf): Updated. (reduc_splus_v4df): Likewise. gcc/testsuite/ 2010-10-20 H.J. Lu hongjiu...@intel.com PR target/46085 * gcc.target/i386/pr46085-1.c: New. * gcc.target/i386/pr46085-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/pr46085-1.c trunk/gcc/testsuite/gcc.target/i386/pr46085-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog
[Bug target/46094] New: -fsplit-stack doesn't honour x86_64 ABI wrt. stack alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46094 Summary: -fsplit-stack doesn't honour x86_64 ABI wrt. stack alignment Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz If I understand http://www.x86-64.org/documentation/abi.pdf correctly, and the ABI described here is valid enough, -fsplit-stack doesn't align stack correctly when calling functions. At the moment of function entry, this should hold: (rsp15)==8 As example, I will use the testcase from PR46093 ( http://gcc.gnu.org/bugzilla/attachment.cgi?id=22091 ). There are values of rsp at the moment of function entry: GDB breakpoints: b main b foo b __morestack b __morestack_block_signals b __generic_morestack b __morestack_unblock_signals b __generic_releasestack b pthread_sigmask b sigprocmask (for some reason, breakpoint at __morestack wasn't set correctly by this procedure, so I had to set it manually) functionrsp main0x7fffde58 __morestack 0x7fffde50 __morestack_block_signals 0x7fffddf0 sigprocmask 0x7fffddf0 __generic_morestack 0x7fffde00 __morestack_unblock_signals 0x77ff9ff8 sigprocmask 0x77ff9ff8 foo 0x77ff5fe8 ... this could cause problem if (for example) sigprocmask() used SSE instructions to access stack
[Bug tree-optimization/46085] [4..6 Regression] gcc.dg/vect/fast-math-vect-reduc-[57].c failed with -mavx -ffast-math -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46085 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2010-10-20 11:26:39 UTC --- Fixed.
[Bug c++/46065] [4.6 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'tree_list' in poplevel_named_label_1, at cp/decl.c:477
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46065 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.20 11:34:47 CC||hjl.tools at gmail dot com Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-10-20 11:34:47 UTC --- It is caused by revision 162223: http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00577.html
[Bug tree-optimization/45860] [4.6 Regression] ICE: verify_ssa failed: virtual SSA name for non-VOP decl at -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45860 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-20 12:11:17 UTC --- Fixed.
[Bug bootstrap/45954] LTO isn't enabled in stage1 cc1 with --with-build-config=bootstrap-lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45954 --- Comment #7 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2010-10-20 12:38:33 UTC --- Author: hjl Date: Wed Oct 20 12:38:22 2010 New Revision: 165721 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165721 Log: Add LTO to boot language if it is enabled. 2010-10-20 H.J. Lu hongjiu...@intel.com PR bootstrap/45954 * config-lang.in (boot_language): Set to $enable_lto. Modified: trunk/gcc/lto/ChangeLog trunk/gcc/lto/config-lang.in
[Bug bootstrap/45954] LTO isn't enabled in stage1 cc1 with --with-build-config=bootstrap-lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45954 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2010-10-20 12:40:11 UTC --- Fixed.
[Bug fortran/46067] [F03] invalid procedure pointer assignment not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46067
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2010.10.20 13:11:39
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #5 from janus at gcc dot gnu.org 2010-10-20 13:11:39 UTC ---
Mine. The accepts-invalid problem in comment #2 is fixed by the following
patch:
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c(revision 165712)
+++ gcc/fortran/interface.c(working copy)
@@ -1056,7 +1056,7 @@ gfc_compare_interfaces (gfc_symbol *s1, gfc_symbol
}
/* Check type and rank. */
-if (!compare_type_rank (f1-sym, f2-sym))
+if (!compare_type_rank (f2-sym, f1-sym))
{
if (errmsg != NULL)
snprintf (errmsg, err_len, Type/rank mismatch in argument '%s',
[Bug debug/46095] New: [4.6 Regression] ICE: in dwarf2out_frame_debug_expr, at dwarf2out.c:2341 with -fstack-protector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46095 Summary: [4.6 Regression] ICE: in dwarf2out_frame_debug_expr, at dwarf2out.c:2341 with -fstack-protector Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 22092 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22092 reduced testcase Compiler output: $ gcc -O -fschedule-insns2 -fno-omit-frame-pointer -fstack-protector pr46095.c pr46095.c: In function 'foo': pr46095.c:8:1: internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2341 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r165719 - crash r163636 - OK
[Bug c/46090] 16 bit uint16_t puts non-zero in highest bits when shifting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46090 --- Comment #2 from Kamo Shakhnazaryan kshakhna at gmail dot com 2010-10-20 13:30:40 UTC --- (In reply to comment #1) input * 0x0101 is really ((int)input) * 0x0101. So this behavior is correct. input is declared as uint16_t. Why input * 0x0101 is really ((int)input) * 0x0101 ?
[Bug c/46090] 16 bit uint16_t puts non-zero in highest bits when shifting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46090 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-20 13:34:31 UTC --- Because that's what the C standard says, under the rules for integer promotions
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970 --- Comment #88 from John David Anglin danglin at gcc dot gnu.org 2010-10-20 13:41:38 UTC --- (In reply to comment #85) Created attachment 22079 [details] patch I haven't yet tested this on a cross-compiler, but it bootstrapped and regtested fine on x86_64-pc-linux-gnu. I also tested the patch on armv5tejl-unknown-linux-gnueabi. The ICE in function '__popcountsi2' is still there, so this must be a separate issue.
[Bug c++/46065] [4.6 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'tree_list' in poplevel_named_label_1, at cp/decl.c:477
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46065 Nathan Froyd froydnj at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |froydnj at gcc dot gnu.org |gnu.org | --- Comment #2 from Nathan Froyd froydnj at gcc dot gnu.org 2010-10-20 13:46:08 UTC --- I will fix this shortly after stage 3 starts.
[Bug c/45062] [4.6 Regression] Revision 162223 caused ICE at c-decl.c:4064
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45062 Nathan Froyd froydnj at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||froydnj at gcc dot gnu.org AssignedTo|unassigned at gcc dot |froydnj at gcc dot gnu.org |gnu.org | --- Comment #3 from Nathan Froyd froydnj at gcc dot gnu.org 2010-10-20 13:47:51 UTC --- I will fix this shortly after stage 3 starts.
[Bug c++/46096] New: Code produces two different outputs when optimized respectively with -O2 and without it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46096 Summary: Code produces two different outputs when optimized respectively with -O2 and without it. Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: zwei...@gmail.com Created attachment 22093 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22093 Minimal testcase The code attached is a very simple application of threads using SDL_threads library. In the code just one thread is created and it should enter in a loop waiting for a class variable to become 4 and exit printing END on the screen. Since the variable is modified to 4 in the main program, the thread should exit and print END on the screen always. However, this does not happen all the time in the -O2 compiled version. The compiled version WITHOUT -O2 gives the expected output END (Reproducible: always). On the other hand, the -O2 version of the code produces an executable which sometimes print and sometimes do not print END on the screen (Occasionally one may need to run the program 20 times to spot 1 error). I attached the very simple test.cpp file. And here is the output from g++ without optimization: g++ -v -save-temps -o sdl_thread -Wall test.cpp -lSDL Using built-in specs. Target: i686-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.3.4/work/gcc-4.3.4/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.3.4 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.4 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.4/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.4/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --disable-fixed-point --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --disable-libgcj --with-arch=i686 --enable-languages=c,c++,treelang,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.4 p1.1, pie-10.1.5' Thread model: posix gcc version 4.3.4 (Gentoo 4.3.4 p1.1, pie-10.1.5) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'sdl_thread' '-Wall' '-shared-libgcc' '-mtune=generic' '-march=i686' /usr/libexec/gcc/i686-pc-linux-gnu/4.3.4/cc1plus -E -quiet -v -D_GNU_SOURCE test.cpp -D_FORTIFY_SOURCE=2 -mtune=generic -march=i686 -Wall -fpch-preprocess -o test.ii ignoring nonexistent directory /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/../../../../i686-pc-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4 /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/i686-pc-linux-gnu /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/backward /usr/local/include /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'sdl_thread' '-Wall' '-shared-libgcc' '-mtune=generic' '-march=i686' /usr/libexec/gcc/i686-pc-linux-gnu/4.3.4/cc1plus -fpreprocessed test.ii -quiet -dumpbase test.cpp -mtune=generic -march=i686 -auxbase test -Wall -version -o test.s GNU C++ (Gentoo 4.3.4 p1.1, pie-10.1.5) version 4.3.4 (i686-pc-linux-gnu) compiled by GNU C version 4.3.4, GMP version 4.3.2, MPFR version 2.4.1-p5. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: a9af7e955b36498814b0c0d47ad1b377 COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'sdl_thread' '-Wall' '-shared-libgcc' '-mtune=generic' '-march=i686' /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/../../../../i686-pc-linux-gnu/bin/as -V -Qy -o test.o test.s GNU assembler version 2.18 (i686-pc-linux-gnu) using BFD version (GNU Binutils) 2.18 COMPILER_PATH=/usr/libexec/gcc/i686-pc-linux-gnu/4.3.4/:/usr/libexec/gcc/i686-pc-linux-gnu/4.3.4/:/usr/libexec/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/:/usr/lib/gcc/i686-pc-linux-gnu/:/usr/libexec/gcc/i686-pc-linux-gnu/4.3.4/:/usr/libexec/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/:/usr/lib/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/../../../../i686-pc-linux-gnu/bin/ LIBRARY_PATH=/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/:/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/:/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/../../../../i686-pc-linux-gnu/lib/:/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'sdl_thread' '-Wall' '-shared-libgcc' '-mtune=generic' '-march=i686' /usr/libexec/gcc/i686-pc-linux-gnu/4.3.4/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker
[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169 --- Comment #23 from Vladimir Makarov vmakarov at gcc dot gnu.org 2010-10-20 13:51:37 UTC --- Author: vmakarov Date: Wed Oct 20 13:51:31 2010 New Revision: 165722 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165722 Log: 2010-10-20 Vladimir Makarov vmaka...@redhat.com PR fortran/42169 * ira-emit.c (store_can_be_removed_p): Return false instead of gcc_unreachable. Modified: trunk/gcc/ChangeLog trunk/gcc/ira-emit.c
[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46096 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Severity|major |normal --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-20 14:00:49 UTC --- There is no memory synchronisation, so there is no guarantee that the write to alpha1-number ever becomes visible to other threads.
[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169 --- Comment #24 from Vladimir Makarov vmakarov at gcc dot gnu.org 2010-10-20 14:05:25 UTC --- Author: vmakarov Date: Wed Oct 20 14:05:21 2010 New Revision: 165723 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165723 Log: 2010-10-20 Vladimir Makarov vmaka...@redhat.com PR fortran/42169 * ira-emit.c (store_can_be_removed_p): Return false instead of gcc_unreachable. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/ira-emit.c
[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169 --- Comment #25 from Vladimir Makarov vmakarov at gcc dot gnu.org 2010-10-20 14:06:11 UTC --- Author: vmakarov Date: Wed Oct 20 14:06:08 2010 New Revision: 165724 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165724 Log: 2010-10-20 Vladimir Makarov vmaka...@redhat.com PR fortran/42169 * ira-emit.c (store_can_be_removed_p): Return false instead of gcc_unreachable. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/ira-emit.c
[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46096 --- Comment #2 from Danilo zweifel at gmail dot com 2010-10-20 14:07:45 UTC --- (In reply to comment #1) There is no memory synchronisation, so there is no guarantee that the write to alpha1-number ever becomes visible to other threads. According to http://wiki.libsdl.org/moin.cgi/SDL_CreateThread, the threads created share the same memory. So I guess sync is not needed.
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970 --- Comment #89 from Paolo Bonzini bonzini at gnu dot org 2010-10-20 14:09:33 UTC --- The armv5 failure is a stage2 miscompilation. Is it caused by Bernd's patch too? Or by fwprop? According to comment 22, previously it was not bootstrapping but the failure was elsewhere. But we don't know if it is one or two bugs, and we don't know how it relates with the fwprop problem (which was latent all the time even before Bernd's patch). The only good news is that a stage2 libgcc crash is slightly simpler to debug than a stage3 comparison failure. In any case, the next thing to do is to bisect to find where the crash appeared, then go to the previous revision, try applying my patch and see if it fixes the failure of comment 22.
[Bug lto/45667] [4.6 Regression] ICE: verify_stmts failed: type mismatch in address expression with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45667 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-20 14:11:09 UTC --- Author: rguenth Date: Wed Oct 20 14:11:06 2010 New Revision: 165725 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165725 Log: 2010-10-20 Richard Guenther rguent...@suse.de PR lto/45667 * lto-streamer-out.c (output_gimple_stmt): Fix typo. * tree-cfg.c (verify_gimple_call): Properly get the call fndecl. (verify_gimple_assign_single): Disable ADDR_EXPR type check when in LTO. * g++.dg/lto/20101020-1_0.h: New testcase. * g++.dg/lto/20101020-1_0.C: Likewise. * g++.dg/lto/20101020-1_1.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/lto/20101020-1_0.C trunk/gcc/testsuite/g++.dg/lto/20101020-1_0.h trunk/gcc/testsuite/g++.dg/lto/20101020-1_1.C Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-out.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c
[Bug c++/46056] [C++0x] range-based for loop does not destruct iterators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46056 --- Comment #8 from Jason Merrill jason at gcc dot gnu.org 2010-10-20 14:13:44 UTC --- Author: jason Date: Wed Oct 20 14:13:38 2010 New Revision: 165726 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165726 Log: PR c++/46056 * parser.c (cp_convert_range_for): Call cp_finish_decl instead of finish_expr_stmt. Added: trunk/gcc/testsuite/g++.dg/cpp0x/range-for7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug lto/45667] [4.6 Regression] ICE: verify_stmts failed: type mismatch in address expression with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45667 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-20 14:14:07 UTC --- Fixed.
[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46096 Danilo zweifel at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #3 from Danilo zweifel at gmail dot com 2010-10-20 14:17:30 UTC --- Changed the status back to unconfirmed.
[Bug c++/46056] [C++0x] range-based for loop does not destruct iterators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46056
Alexander Klimov alserkli at inbox dot ru changed:
What|Removed |Added
Attachment #22086|0 |1
is obsolete||
--- Comment #9 from Alexander Klimov alserkli at inbox dot ru 2010-10-20
14:19:23 UTC ---
Created attachment 22094
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22094
simple testcase
Your patch seems to work, thanks!
Btw, the original simple testcase did not contain
It(const It){ ++it_counter; }
and thus would fail (It() is called twice, while ~It() -- thrice).
[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46096 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-20 14:24:30 UTC --- yes, they share the same address space, but modern processors have multilevel caches and unless you provide suitable synchronisation the write to alpha1-number might not get made visible to other threads I suggest you use a mutex around shared data
[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46096 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-20 14:27:18 UTC --- The field is not volatile, so in the loop nothing forces -number field to be loaded from memory again. So it is perfectly fine to optize the whole loop into: if (alpha1-number!=4) for (;;); /* Endless loop. */
[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46096 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-20 14:29:09 UTC --- Using a mutex around the reads and writes of shared data will make it work as expected, the compiler won't optimise away the read and will re-read the value every time.
[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46096 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-10-20 14:34:40 UTC --- Using a mutex around the reads and writes of shared data will make it work as expected, the compiler won't optimise away the read and will re-read the value every time. This is overkill here though, you just need: volatile alpha *alpha1 = ( alpha * )data;
[Bug c++/46097] New: Switch to warn of global variables in a C++ shared object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097 Summary: Switch to warn of global variables in a C++ shared object Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: noloa...@gmail.com Feature reqeust only. Not a bug. C++ shared objects are an interesting beast under certain circumstances (many times, the shared object acts like a generic C module). Interesting includes: * C++ module * Shared object * Shared object throws an exception which will cross module boundaries * Shared object opened with RTLD_GLOBAL * Shared object has global objects with destructors Lots have been said about C++ exceptions, RTTI, type equality for the 'catch(const Exception)', and RTLD_GLOBAL (versus RTLD_LOCAL) [1,2,3,4,5]. When a module meets the above compile and runtime requirements, a crash can occur in global objects with destructors when more than one process loads and subsequently unloads a shared object. A switch to warn of global variables in a compilation unit would be very helpful for those who are aware of the issue (and the circumstances to encounter the issue). It appears that GCC does not supply such a switch [6]. The switch would be useful for module writers since its not always feasible to 'hand audit' all project files. And a warning would be exetremely useful for package maintainers who don't write the module - they simply fixup the code and package it for a distribution. Perhaps -Wglobal-variable? Jeffrey Walton Baltimore, MD, US [1] Minimal GCC/Linux shared lib + EH bug example, http://gcc.gnu.org/ml/gcc/2002-05/msg00866.html [2] dlopen and placing exception body in .cpp file, http://gcc.gnu.org/ml/gcc-help/2010-08/msg00290.html [3] Comparing types across SOs (sic), http://groups.google.com/group/cryptopp-users/browse_thread/thread/eb815f228db50380 [4] Errors with multiple loading cryptopp as shared lib on Linux, http://groups.google.com/group/cryptopp-users/browse_thread/thread/68fbc22e8c6e2f48 [5] RTLD_GLOBAL and libcryptopp.so crash, http://groups.google.com/group/cryptopp-users/browse_thread/thread/7eae009a4e02e726 [6] Audit Use of Global Variables in C++ Shared Object (GCC Warning?), GCC-Help mailing list, October, 2010 [not yet indexed].
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970 --- Comment #90 from dave at hiauly1 dot hia.nrc.ca 2010-10-20 14:39:26 UTC --- The armv5 failure is a stage2 miscompilation. Is it caused by Bernd's patch too? Or by fwprop? Actually, the ICE I saw this morning was in stage3. This box is only accessible at my contractor's site, so my access to it is limited. Dave
[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46096 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-20 14:40:21 UTC --- I don't recommend people use volatile to avoid multithreading races, it only prevents compiler optimisations, not hardware reordering. Using proper atomics, memory barriers or other explicit synchronisation is better. But for this testcase, yes, volatile will fix it. Danilo, you might like to read these http://www.drdobbs.com/cpp/201804238 http://www.drdobbs.com/high-performance-computing/212701484
[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46096 --- Comment #9 from Danilo zweifel at gmail dot com 2010-10-20 14:43:18 UTC --- (In reply to comment #7) Using a mutex around the reads and writes of shared data will make it work as expected, the compiler won't optimise away the read and will re-read the value every time. This is overkill here though, you just need: volatile alpha *alpha1 = ( alpha * )data; This solved it! Did not know about volatile variables. I was trying to avoid exactly the use of mutexes and the like. Thank you very much!
[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46096 Danilo zweifel at gmail dot com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #10 from Danilo zweifel at gmail dot com 2010-10-20 14:45:18 UTC --- (In reply to comment #8) I don't recommend people use volatile to avoid multithreading races, it only prevents compiler optimisations, not hardware reordering. Using proper atomics, memory barriers or other explicit synchronisation is better. But for this testcase, yes, volatile will fix it. Danilo, you might like to read these http://www.drdobbs.com/cpp/201804238 http://www.drdobbs.com/high-performance-computing/212701484 Thanks you very much, Jonathan! I will surely read the references. I am considering this as closed.
[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46096 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-20 14:46:24 UTC --- Busy waiting is rarely a good idea, so it depends on what are you exactly waiting for and whether say pthread_barrier_wait, or mutex, or condvar etc. wouldn't be more appropriate.
[Bug tree-optimization/38153] ICE in testcase when compiled with -ftree-parallelize-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38153
Zdenek Sojka zsojka at seznam dot cz changed:
What|Removed |Added
CC||zsojka at seznam dot cz
--- Comment #4 from Zdenek Sojka zsojka at seznam dot cz 2010-10-20 14:52:32
UTC ---
A bit different testcase, crashes on x86_64-pc-linux-gnu, r165719
- testcase.c -
void
foo (void **a, int i)
{
while (i--)
a[i] = label;
label:;
}
--
$ gcc -O -ftree-parallelize-loops=2 testcase.c
testcase.c: In function 'foo':
testcase.c:2:1: error: label
label has incorrect context in bb 6testcase.c:2:1: internal compiler error:
verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
-ftree-parallelize-loops=N, crashes for N=2
[Bug target/45946] ICE: in extract_insn, at recog.c:2127 when using _Decimal128 with -Os -fno-omit-frame-pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45946 Zdenek Sojka zsojka at seznam dot cz changed: What|Removed |Added Known to fail||4.3.5, 4.4.5, 4.5.2 --- Comment #1 from Zdenek Sojka zsojka at seznam dot cz 2010-10-20 15:02:12 UTC --- 4.1.2 doesn't know _Decimal128, 4.2.4 refuses to compile $ gcc-4.1.2 -Os -fno-omit-frame-pointer pr45946.c pr45946.c:3: warning: parameter names (without types) in function declaration $ gcc-4.2.4 pr45946.c pr45946.c:2: error: decimal floating point not supported for this target 4.3.5 and newer compile without any optimisation, but fail with given flags
[Bug c++/45983] [4.5 Regression] ICE: tree code 'template_parm_index' is not supported in gimple streams with -lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45983 --- Comment #16 from Jason Merrill jason at gcc dot gnu.org 2010-10-20 15:05:28 UTC --- Author: jason Date: Wed Oct 20 15:05:22 2010 New Revision: 165728 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165728 Log: PR c++/45983 * tree.c (cp_build_qualified_type_real): Don't reuse a variant with a different typedef variant of the element type. Added: branches/gcc-4_5-branch/gcc/testsuite/g++.dg/lto/pr45983_0.C Modified: branches/gcc-4_5-branch/gcc/cp/ChangeLog branches/gcc-4_5-branch/gcc/cp/tree.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug target/46098] New: [4.5/4.6 Regression] ICE: in extract_insn, at recog.c:2100 with -msse3 -ffloat-store and __builtin_ia32_loadupd()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46098
Summary: [4.5/4.6 Regression] ICE: in extract_insn, at
recog.c:2100 with -msse3 -ffloat-store and
__builtin_ia32_loadupd()
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
- testcase.c -
typedef double v2df __attribute__((vector_size (16)));
v2df foo (double *d)
{
return __builtin_ia32_loadupd (d);
}
--
Compiler output:
$ gcc -msse3 -ffloat-store testcase.c
testcase.c: In function 'foo':
testcase.c:6:1: error: unrecognizable insn:
(insn 7 6 8 3 (set (mem/c/i:V2DF (plus:DI (reg/f:DI 54 virtual-stack-vars)
(const_int -16 [0xfff0])) [0 D.2706+0 S16 A128])
(unspec:V2DF [
(mem:V2DF (reg:DI 60) [0 S16 A8])
] UNSPEC_MOVU)) testcase.c:5 -1
(nil))
testcase.c:6:1: internal compiler error: in extract_insn, at recog.c:2110
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Tested revisions:
r165719 - crash
r153685 - crash
4.5 r163761 - crash
4.4 r160770 - OK
[Bug tree-optimization/45919] [4.6 Regression] ICE: SIGSEGV in fold_ctor_reference (tree-ssa-ccp.c:1527) at -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45919 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-20 15:19:12 UTC --- Created attachment 22095 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22095 gcc46-pr45919.patch Untested fix.
[Bug c++/46097] Switch to warn of global variables in a C++ shared object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-20 15:52:53 UTC --- (In reply to comment #0) When a module meets the above compile and runtime requirements, a crash can occur in global objects with destructors when more than one process loads and subsequently unloads a shared object. Are you saying independent processes interfere with each other?
[Bug tree-optimization/46099] New: [4.5/4.6 Regression] ICE: in replace_ssa_name, at tree-cfg.c:5643 with -ftree-parallelize-loops -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46099 Summary: [4.5/4.6 Regression] ICE: in replace_ssa_name, at tree-cfg.c:5643 with -ftree-parallelize-loops -g Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 22096 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22096 reduced testcase Compiler output: $ gcc -ftree-parallelize-loops=2 -g -O pr46099.c pr46099.c: In function 'foo': pr46099.c:7:1: internal compiler error: in replace_ssa_name, at tree-cfg.c:5643 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r165719 - crash r158095 - crash r153685 - OK 4.5 r163761 - crash 4.4 r160770 - OK
[Bug fortran/46100] New: Non-variable pointer expression as actual argument to INTENT(OUT) non-pointer dummy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46100 Summary: Non-variable pointer expression as actual argument to INTENT(OUT) non-pointer dummy Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Reported at c.l.f by Thomas Jahns: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread /a64e2f255466a87a GNU Fortran (and most other compilers) reject passing a non-variable pointer expression as actual argument to an INTENT(OUT)/INTENT(INOUT) non-pointer dummy argument. The reason for rejecting is that the pointer expression (i.e. a function returning a pointer) itself is not definable. However, I believe now that it the code is valid. Thus, only if the argument were a pointer dummy or the expression were not a pointer expression, it would be invalid. Example: call one (two ()) contains subroutine one (x) integer, intent(inout) :: x end subroutine one function two () integer, pointer :: two allocate(two) end function two end Error message: call one (two ()) 1 Error: Non-variable expression in variable definition context (actual argument to INTENT = OUT/INOUT) at (1)
[Bug rtl-optimization/43721] Failure to optimise (a/b) and (a%b) into single __aeabi_idivmod call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43721 Andrew Stubbs ams at gcc dot gnu.org changed: What|Removed |Added CC||ams at gcc dot gnu.org --- Comment #6 from Andrew Stubbs ams at gcc dot gnu.org 2010-10-20 16:53:13 UTC --- Here's the problem: expand_divmod always prefers the straight div library call over the divmod library call, no exceptions. Yes, divmodsi4 in a .md is indeed preferred over divsi4, so the optimization works fine on targets that have those, but ARM doesn't, so those rules are irrelevant. ARM does not provide a separate library function for mod, so expand_divmod does use divmod for mod operations, but never for div operations. The reason for the apparent opposite rules appears to be that the divmodsi4 rule can be coded to auto-detect the most optimal kind of underlying operation to use, whereas the library call is fixed, once chosen. I see two possible ways to fix this: 1. Teach CSE (or somewhere) that div and divmod library calls have some overlap. 2. Always prefer divmod, and find some other way to convert it to div, where appropriate. I don't see any way to generate the RTL with the right call, so I'm pretty sure it does have to be fixed up after the fact. Or, I could be way off. :)
[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46096 --- Comment #12 from Danilo zweifel at gmail dot com 2010-10-20 16:53:53 UTC --- (In reply to comment #11) Busy waiting is rarely a good idea, so it depends on what are you exactly waiting for and whether say pthread_barrier_wait, or mutex, or condvar etc. wouldn't be more appropriate. My objective of using threads is to detach a system in a simulation environment. For this reason, it would be impracticable to use any type of lock for everytime the I/O changes (which will happen all the time), so I guess volatiles are the only way?? I am still reading the sites posted by Jonathan and understanding the difficulties of doing this in modern CPUs, while it is so easy in hardware. Maybe just always compiling without optimizations will do?
[Bug debug/46101] New: [4.6 Regression] ICE: in build_abbrev_table, at dwarf2out.c:10333 with -feliminate-dwarf2-dups -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46101 Summary: [4.6 Regression] ICE: in build_abbrev_table, at dwarf2out.c:10333 with -feliminate-dwarf2-dups -g Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 22097 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22097 reduced testcase Compiler output: $ gcc -feliminate-dwarf2-dups -g pr46101.C pr46101.C:6:4: internal compiler error: in build_abbrev_table, at dwarf2out.c:10333 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r165719 - crash r161659 - crash r159696 - OK 4.5 r163761 - OK
[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46096 --- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-20 16:57:45 UTC --- If the value changes because of IO (rather than being set by another thread, as in your testcase) then volatile might be the right option. Condvars could also work and allow you to block, rather than doing a busy wait while holding a lock.
[Bug target/46098] [4.5/4.6 Regression] ICE: in extract_insn, at recog.c:2100 with -msse3 -ffloat-store and __builtin_ia32_loadupd()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46098 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.20 16:58:52 CC||hjl.tools at gmail dot com, ||matz at gcc dot gnu.org Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-10-20 16:58:52 UTC --- It is caused by revision 146817: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01459.html
[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46096 --- Comment #14 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-10-20 17:18:33 UTC --- Maybe just always compiling without optimizations will do? Adding volatile is exactly saying do not optimize this loop, i.e. you get at -O2 what you do at -O0, nothing more, nothing less. This is a language feature that is orthogonal to the synchronization stuff.
[Bug fortran/46100] Non-variable pointer expression as actual argument to INTENT(OUT) non-pointer dummy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46100 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2010-10-20 17:21:30 UTC --- Forgot to add: In the current ISO Fortran standard (Fortran 2008), one finds: If a nonpointer dummy argument without the VALUE attribute corresponds to a pointer actual argument that is pointer associated with a target, the dummy argument becomes argument associated with that target. The INTENT (INOUT) attribute for a nonpointer dummy argument specifies that any actual argument that corresponds to the dummy argument shall be definable. definable -- capable of definition and permitted to become defined Thus, it boils down to the questions whether the target (to which the pointer is pointer associated) is definable. I think that is usually the case, which makes the example valid. * * * Note, however, that Richard Maine disagrees - he thinks that it is invalid Fortran 2003, while it might be valid Fortran 2008. I cannot see an essential difference between the F2003 and F2008 wording, but there might be. (See thread and see interpretation request F95/0074 in http://j3-fortran.org/doc/standing/links/022.txt . Using a pointer function as LHS of an assignment is tracked by F2008's PR 40054.)
[Bug c++/46097] Switch to warn of global variables in a C++ shared object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097 --- Comment #2 from Jeffrey Walton noloader at gmail dot com 2010-10-20 17:33:43 UTC --- (In reply to comment #1) (In reply to comment #0) When a module meets the above compile and runtime requirements, a crash can occur in global objects with destructors when more than one process loads and subsequently unloads a shared object. Are you saying independent processes interfere with each other? Yes and No :/ If each process loads the SO with RTLD_LOCAL, then No. If the processes each load with RTLD_GLOBAL (so an exception can be caught) *AND* the SO has an non-trivial global (such as an object with a destructor) then YES. Crpyto++ has a test case demonstrating the RTLD_GLOBAL crash at [1]. [1] is accompanied by an analysis under GDB at [2]. Unfortunately, the test case is not minimal. It is based on the Crypto++ library and needs intermediate SOs to load the SO of interest. So the final executable never directly loads the Crypto++ shared object. Based on the demonstartion, Wei Dai modified global objects so that only PODs were global. Non-trivial objects were hidden in a GetGlobalXxx() (some hand waiving). A write up distribution packagers (from our understanding of the moving parts) is available at [3,4]. [1] http://www.cryptopp.com/w/images/8/89/Cryptopp-SO-Test-1.zip [2] http://groups.google.com/group/cryptopp-users/browse_thread/thread/7eae009a4e02e726 [3] http://www.cryptopp.com/wiki/Linux#Note_for_Shared_Object_Callers [4] http://www.cryptopp.com/wiki/Linux#Note_for_Distribution_Packagers
[Bug c++/46024] g++.dg/warn/miss-format-1.C FAILs on Solaris 8 and 9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46024 --- Comment #2 from Rainer Orth ro at gcc dot gnu.org 2010-10-20 17:36:24 UTC --- Author: ro Date: Wed Oct 20 17:36:15 2010 New Revision: 165731 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165731 Log: fixincludes: PR c++/46024 * inclhack.def (solaris_sys_va_list): New fix. * fixincl.x: Regenerate. * tests/base/sys/va_list.h: New test. gcc/testsuite: PR c++/46024 * g++.dg/warn/miss-format-1.C: Enclose dg-error target list in braces. Added: trunk/fixincludes/tests/base/sys/va_list.h Modified: trunk/fixincludes/ChangeLog trunk/fixincludes/fixincl.x trunk/fixincludes/inclhack.def trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/warn/miss-format-1.C
[Bug c++/46097] Switch to warn of global variables in a C++ shared object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097 --- Comment #3 from Jeffrey Walton noloader at gmail dot com 2010-10-20 17:38:59 UTC --- (In reply to comment #2) (In reply to comment #1) (In reply to comment #0) When a module meets the above compile and runtime requirements, a crash can occur in global objects with destructors when more than one process loads and subsequently unloads a shared object. Are you saying independent processes interfere with each other? ... Crpyto++ has a test case demonstrating the RTLD_GLOBAL crash at [1]. [1] is accompanied by an analysis under GDB at [2]. Unfortunately, the test case is not minimal. It is based on the Crypto++ library and needs intermediate SOs to load the SO of interest. So the final executable never directly loads the Crypto++ shared object. If a picture is worth a 1000 words, here's the scenario we are trying to accomplist (to verify Crypto++ does not crash when unloaded). But keep in mind that two distinct process will perform what's in the image. http://www.cryptopp.com/wiki/File:Cryptopp-so-test.png
[Bug fortran/46100] [Fortran 2008] Non-variable pointer expression as actual argument to INTENT(OUT) non-pointer dummy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46100 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Summary|Non-variable pointer|[Fortran 2008] Non-variable |expression as actual|pointer expression as |argument to INTENT(OUT) |actual argument to |non-pointer dummy |INTENT(OUT) non-pointer ||dummy --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2010-10-20 17:45:27 UTC --- After carefully reading the interpretation request, http://www.j3-fortran.org/doc/year/08/08-172.txt, I think the reason that it is invalid in Fortran 95/2003 is that only variables are definable and as f() is not a variable, it is invalid. Fortran 2008 has (cf. PR 40054): R602 variable is designator or expr C602 (R602) expr shall be a reference to a function that has a pointer result. Which makes the program valid.
[Bug debug/46102] New: ICE: SIGSEGV in dwarf2out_finish (dwarf2out.c:8490) with -feliminate-dwarf2-dups when using precompiled headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46102 Summary: ICE: SIGSEGV in dwarf2out_finish (dwarf2out.c:8490) with -feliminate-dwarf2-dups when using precompiled headers Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz - testcase.H - /* NOTHING */ -- - testcase.C - #include testcase.H int i; -- Generate files: echo testcase.H echo '#include testcase.H' testcase.C echo 'int i;' testcase.C Compile: (testcase.H can be compiled with -feliminate-dwarf2-dups, it still fails) $ gcc -g testcase.H $ gcc -g testcase.C -feliminate-dwarf2-dups testcase.C:2:6: 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. Related valgrind output: ==21702== Invalid read of size 8 ==21702==at 0x74AB61: dwarf2out_finish (dwarf2out.c:8490) ==21702==by 0x9C6A15: toplev_main (toplev.c:961) ==21702==by 0x658ABBC: (below main) (in /lib64/libc-2.11.2.so) ==21702== Address 0x20 is not stack'd, malloc'd or (recently) free'd ==21702== testcase.C:2:6: 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. Tested revisions: r165719 - crash r158095 - crash r153685 - crash 4.1.2, 4.2.4, 4.3.5, 4.4.5 - crash
[Bug debug/46101] [4.6 Regression] ICE: in build_abbrev_table, at dwarf2out.c:10333 with -feliminate-dwarf2-dups -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46101 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug tree-optimization/46099] [4.5/4.6 Regression] ICE: in replace_ssa_name, at tree-cfg.c:5643 with -ftree-parallelize-loops -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46099 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.5.2
[Bug fortran/46100] [Fortran 2008] Non-variable pointer expression as actual argument to INTENT(OUT) non-pointer dummy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46100
--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2010-10-20
18:01:54 UTC ---
Untested patch:
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 5711634..ef516a4 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -4316,7 +4316,18 @@ gfc_check_vardef_context (gfc_expr* e, bool pointer,
const char* context)
symbol_attribute attr;
gfc_ref* ref;
- if (e-expr_type != EXPR_VARIABLE)
+ if (!pointer e-expr_type == EXPR_FUNCTION
+ e-symtree-n.sym-result-attr.pointer)
+{
+ if (!(gfc_option.allow_std GFC_STD_F2008))
+ {
+ if (context)
+ gfc_error (Fortran 2008: Pointer functions in variable definition
+ context (%s) at %L, context, e-where);
+ return FAILURE;
+ }
+}
+ else if (e-expr_type != EXPR_VARIABLE)
{
if (context)
gfc_error (Non-variable expression in variable definition context
(%s)
[Bug target/45946] ICE: in extract_insn, at recog.c:2127 when using _Decimal128 with -Os -fno-omit-frame-pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45946 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW URL||http://gcc.gnu.org/ml/gcc-p ||atches/2010-10/msg01724.htm ||l Last reconfirmed||2010.10.20 18:03:32 CC||hjl.tools at gmail dot com Ever Confirmed|0 |1 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2010-10-20 18:03:32 UTC --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01724.html
[Bug fortran/40054] [F08] Pointer functions as lvalue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40054 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2010-10-20 18:05:23 UTC --- Another example (from PR 46100): two() = 7 contains function two () integer, pointer :: two allocate(two) end function two end Fails with: function two () 1 two() = 7 2 Error: Procedure 'two' at (1) is already defined at (2) function two () 1 Error: INTERNAL-PROC procedure at (1) is already declared as STATEMENT-PROC procedure
[Bug c++/46103] New: [c++0x] moving from std::array copies the elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46103
Summary: [c++0x] moving from std::array copies the elements
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marc.gli...@normalesup.org
Hello,
this is probably another not implemented yet (although the status page seems
to say that this is done), but I noticed that moving from:
struct A { Type t; };
properly moves t while moving from:
struct B { Type t[1]; };
copies t[0] (this is the case for std::array).
Re: [Bug fortran/40054] [F08] Pointer functions as lvalue
two() = 7 I don't see how it is possible to distinguish between a statement function and an assignment here.
[Bug debug/46095] [4.6 Regression] ICE: in dwarf2out_frame_debug_expr, at dwarf2out.c:2341 with -fstack-protector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46095 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.20 19:09:13 CC||hjl.tools at gmail dot com, ||rth at gcc dot gnu.org Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-10-20 19:09:13 UTC --- It is caused by revision 164628: http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00926.html
[Bug tree-optimization/46099] [4.5/4.6 Regression] ICE: in replace_ssa_name, at tree-cfg.c:5643 with -ftree-parallelize-loops -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46099 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.20 20:37:15 CC||hjl.tools at gmail dot com, ||jakub at redhat dot com Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-10-20 20:37:15 UTC --- It is caused by revision 157402: http://gcc.gnu.org/ml/gcc-cvs/2010-03/msg00239.html
[Bug c++/46103] [c++0x] moving from std::array copies the elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46103
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-20
21:10:27 UTC ---
so this would demonstrate the problem?
struct MoveOnly {
MoveOnly(const MoveOnly) = delete;
MoveOnly(MoveOnly) { }
MoveOnly() = default;
};
struct A {
MoveOnly mo[1];
};
int main() {
A a;
A aa = static_castA(a);
}
(I haven't checked whether this is valid, or is meant to be implemented yet in
g++)
[Bug c/46104] New: Linker error cannot find -liberty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46104 Summary: Linker error cannot find -liberty Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: enrico.migl...@ovi.com CC: dougmenc...@gmail.com Host: Ubuntu 10.04 LT Target: ARM LPC32xx This error was received trying to compile sourced for the ARM EABI firmware from Embedded Artists using the gnu toolchain of CodeSourcery G++ Lite for ARM EABI. The toolchain compile correctly the sources, generate libraries and create object files, but at link time linker reports the following error: /home/tech/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-eabi/4.4.1/../../../../arm-none-eabi/bin/ld: cannot find -liberty The specific linker command from the toolchain commands sequence is the following: arm-none-eabi-gcc timer_example.o ../common/crt0_gnu.o -static -Wl,--start-group /home/tech/CodeSourcery/software/csps/lpc32xx/lib/liblpc32xxgnu.a /home/tech/CodeSourcery/software/csps/lpc32xx/bsps/ea3250/lib/libea3250gnu.a /home/tech/CodeSourcery/software/lpc/lib/liblpcarm926ej-sgnu.a -lgcc -lc -lg -lm -liberty -lstdc++ -lsupc++ -Wl,--end-group -Xlinker -Map -Xlinker \ timer.map -Xlinker -T ../linker/ldscript_ram_gnu.ld \ -o timer.elf After investigations and tests, the problem concerns libiberty library, that is installed in the toolchain of CodeSourcery only as static library and not shared. Trying to find the library in the host, the result is the following: $ find / -name *libiberty* -print /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/arm-none-linux-gnueabi/sysroot/lib/libiberty.a /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/arm-none-linux-gnueabi/sysroot/vfp/lib/libiberty.a /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/arm-none-linux-gnueabi/lib/libiberty.a /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/arm-none-linux-gnueabi/lib/vfp/libiberty.a /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/lib/libiberty.a
[Bug c++/46105] New: Ordering failure among partial specializations with non-deduced context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46105 Summary: Ordering failure among partial specializations with non-deduced context Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: pot...@mac.com See attachment. The second arguments of the two partial specializations evaluate to void. If void is substituted manually, the code works fine. (But the desired SFINAE side effect is removed.) As neither such argument contains a parameter in a deduced context, they should not participate in deduction. Once the partial specialization has been determined to match, the parameters should be substituted and evaluated to simply void.
[Bug c++/46105] Ordering failure among partial specializations with non-deduced context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46105 --- Comment #1 from David Krauss potswa at mac dot com 2010-10-20 21:15:27 UTC --- Created attachment 22098 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22098 small example
[Bug tree-optimization/46066] [4.6 Regression] ICE: in create_parallel_loop, at tree-parloops.c:1455 with -ftree-parallelize-loops -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46066 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-20 21:15:52 UTC --- Author: jakub Date: Wed Oct 20 21:15:49 2010 New Revision: 165739 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165739 Log: PR tree-optimization/46066 * tree-parloops.c (create_parallel_loop): Use gsi_last_nondebug_bb instead of gsi_last_bb. * gcc.dg/autopar/pr46066.c: New test. Added: trunk/gcc/testsuite/gcc.dg/autopar/pr46066.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-parloops.c
[Bug bootstrap/46055] [4.6 Regression] -fwhopr failed configure test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46055 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #12 from H.J. Lu hjl.tools at gmail dot com 2010-10-20 21:17:30 UTC --- Fixed by http://gcc.gnu.org/ml/gcc-cvs/2010-10/msg00840.html
[Bug c++/46105] Ordering failure among partial specializations with non-deduced context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46105 David Krauss potswa at mac dot com changed: What|Removed |Added Attachment #22098|0 |1 is obsolete|| --- Comment #2 from David Krauss potswa at mac dot com 2010-10-20 21:18:02 UTC --- Created attachment 22099 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22099 third time's a charm… content type autodetect failed
[Bug tree-optimization/45919] [4.6 Regression] ICE: SIGSEGV in fold_ctor_reference (tree-ssa-ccp.c:1527) at -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45919 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-20 21:17:35 UTC --- Author: jakub Date: Wed Oct 20 21:17:30 2010 New Revision: 165740 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165740 Log: PR tree-optimization/45919 * tree-ssa-ccp.c (fold_nonarray_ctor_reference): Handle flexible array members. * gcc.c-torture/compile/pr45919.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr45919.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c
[Bug lto/45907] [4.6 Regression] Revision 164995 failed gcc.dg/torture/fp-int-convert-*.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45907 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2010-10-20 21:18:25 UTC --- Fixed.
[Bug c/46106] New: Error in Manpage? -fstack-protection = -fstack-protector(-all)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46106 Summary: Error in Manpage? -fstack-protection = -fstack-protector(-all) Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: cdp...@gmx.net CC: cdp...@gmx.net Hi, isn't that wrong? Here is my very tiny patch for the gcc.1: --- gcc.12010-10-20 23:11:16.0 +0200 +++ gcc.1.new2010-10-20 23:11:24.0 +0200 @@ -7661,7 +7661,7 @@ ratio is 3. .IP \fBssp-buffer-size\fR 4 .IX Item ssp-buffer-size The minimum size of buffers (i.e. arrays) that will receive stack smashing -protection when \fB\-fstack\-protection\fR is used. +protection when \fB\-fstack\-protector\fR is used. .IP \fBmax-jump-thread-duplication-stmts\fR 4 .IX Item max-jump-thread-duplication-stmts Maximum number of statements allowed in a block that needs to be with best regards Steffen
[Bug tree-optimization/46066] [4.6 Regression] ICE: in create_parallel_loop, at tree-parloops.c:1455 with -ftree-parallelize-loops -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46066 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-20 21:19:08 UTC --- Fixed.
[Bug tree-optimization/45919] [4.6 Regression] ICE: SIGSEGV in fold_ctor_reference (tree-ssa-ccp.c:1527) at -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45919 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-20 21:19:34 UTC --- Fixed.
