[Bug c++/41997] [C++0x] constant initializer_list not optimised
--- Comment #2 from chris at bubblescope dot net 2009-11-10 08:14 ---
Sorry, one important thing I missed off my bug report. This problem seems to
just be connected to constant lists. The following is fully optimised away
int i = 1, j = 2;
return max_val({i,j});
As is the following, despite the fact the code never access the third element
of the initializer_list
int i = 1;
return max_val({1,2,i});
So this really seem to be some (mis)optimisation involving constant lists.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41997
[Bug ada/37945] GNAT Sockaddr and Sockaddr_In does not match c-structures on RTEMS
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-11-10 08:24 --- Was the patch posted on gcc-patches@ at some point? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37945
[Bug ada/37309] tasking is not implemented on NetBSD
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2009-11-10 08:26 --- What happened to this patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37309
[Bug c++/41997] [C++0x] constant initializer_list not optimised
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-10 08:28 --- The decl holding the constant initializer_list is not being marked as read only for some reason. Even the static to constant optimization is not marking it as read only. Tomorrow I will look further into it. To see why the decl is not being marked as such (which causes this missed optimization). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-10 08:28:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41997
[Bug ada/35998] debug info invalid x86_64 DW_AT_byte_size 0xffffffff
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-11-10 08:29 --- No feedback. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35998
[Bug ada/32548] gnat.dg tests for non-default multilib fail
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2009-11-10 08:32 --- Fixed in 4.4 -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32548
[Bug middle-end/31023] Fold is agnostic of integer sub-types
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2009-11-10 08:34 --- These sub-types are gone in 4.5. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31023
[Bug target/25743] crosscompiler fails to build ada-rts for target platform.
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2009-11-10 08:41 --- We regularly have Ada results for SPARC64/Linux. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25743
[Bug target/33331] FreeBSD __sparc64__ define no longer exists
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2009-11-10 08:43 --- No feedback. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
[Bug middle-end/31707] Spurious 'variable' may be used uninitialized in this function warnings when using __builtin_setjmp and loops and extern function call
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2009-11-10 09:00 --- Not realistically fixable. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31707
[Bug bootstrap/8686] multilib bootstrap fails: 32-bit Solaris 9 + Sun patch 112963-01
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2009-11-10 09:07 --- Not a bug. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8686
[Bug tree-optimization/41879] [4.5 Regression] 172.mgrid regression, vectorizer prevents predictive commoning
--- Comment #3 from irar at il dot ibm dot com 2009-11-10 10:02 --- (In reply to comment #0) This causes mgrid score to drop by almost 40% on x86_64 and the vectorized code is pretty bad because it uses unaligned accesses. Is the vectorized code worse than the scalar one even without predcom? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41879
[Bug debug/41679] [4.5 Regression] internal compiler error: in loc_cmp, at var-tracking.c:2433
--- Comment #5 from ramana at gcc dot gnu dot org 2009-11-10 10:36 --- Testcase in Comment #3 fails with -march=armv5te on arm-eabi cross on an x86_64-linux-gnu host with trunk. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|armv5tel-unknown-linux- |armv5tel-unknown-linux- |gnueabi |gnueabi, arm-eabi Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2009-11-10 10:36:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41679
[Bug middle-end/20548] [4.3/4.4/4.5 regression] ACATS c52103x c52104x c52104y segfault
--- Comment #43 from ebotcazou at gcc dot gnu dot org 2009-11-10 11:24 --- Subject: Bug 20548 Author: ebotcazou Date: Tue Nov 10 11:23:54 2009 New Revision: 154061 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154061 Log: PR ada/20548 * explow.c (probe_stack_range): Fix typo. * config/sparc/sparc.md (probe_stack): New expander. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.md trunk/gcc/explow.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20548
[Bug ada/37945] GNAT Sockaddr and Sockaddr_In does not match c-structures on RTEMS
--- Comment #5 from joel at gcc dot gnu dot org 2009-11-10 11:57 --- (In reply to comment #4) Was the patch posted on gcc-patches@ at some point? It has been over a year and I honestly don't know. I will repost on general principal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37945
[Bug middle-end/20548] [4.3/4.4/4.5 regression] ACATS c52103x c52104x c52104y segfault
--- Comment #44 from ebotcazou at gcc dot gnu dot org 2009-11-10 12:38 --- Subject: Bug 20548 Author: ebotcazou Date: Tue Nov 10 12:37:56 2009 New Revision: 154063 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154063 Log: PR ada/20548 * system-linux-alpha.ads (Stack_Check_Probes): Set to true. * system-linux-hppa.ads (Stack_Check_Probes): Likewise. * system-linux-sparc.ads (Stack_Check_Probes): Likewise. * system-linux-sparcv9.ads (Stack_Check_Probes): Likewise. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/system-linux-alpha.ads trunk/gcc/ada/system-linux-hppa.ads trunk/gcc/ada/system-linux-sparc.ads trunk/gcc/ada/system-linux-sparcv9.ads -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20548
[Bug fortran/41977] gfortran -fopenp and ACML_MP seem incompatible
--- Comment #13 from nmm1 at cam dot ac dot uk 2009-11-10 13:32 --- Oh, joy. This went soft yesterday, and today I can't repeat the effects. I have some of the evidence in Email I sent to the ACML expert, who has managed to repeat them at least once. But, at BEST, the effects seem to depend on static/dynamic linking, Clib versions, Old Uncle Tom Cobbley and all. Here is the main effect I was reporting: gosset$gfortran -Wall -std=f2003 -pedantic -O3 -fopenmp -o Cholesky_one_f \ gossetAnswers/Cholesky/one.f90 -lacml_mp gosset$./Cholesky_one_f fred_f_1000 Error in calling LAPACK Instrumenting the source showed that was INFO=15, which indicates that pivot 15 was zero, which is ridiculous. And it is THAT one which was the bug that primarily concerned me. I may have made some mistakes in identifying the performance issues. Given where the OpenMP directives are in the solver, some slowdown is to be expected. That is clearly not a bug. I distinctly remember having to break in after 4+ minutes using gfortran 4.3.2, when the 'normal' time was about 30 seconds. That could be a Linux scheduler problem, of course. Until and unless I can produce some more demonstrably incorrect performance, I suggest ignoring that aspect of my report. If I can't repeat it, either I got myself confused, or it will be too evil to justify the effort of investigating. In either case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41977
[Bug target/41500] [4.4 Regression] ARM: 4.4 compiler segfault when compiling gcc
--- Comment #13 from armin76 at gentoo dot org 2009-11-10 15:06 --- 4.4.2 works fine, so i'll close this as fixed. -- armin76 at gentoo dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41500
[Bug tree-optimization/41987] [4.5 Regression] expected class �constant�, have �binary� (rdiv_expr) in build_complex, at tree.c:1485
--- Comment #8 from ghazi at gcc dot gnu dot org 2009-11-10 16:17 --- Subject: Bug 41987 Author: ghazi Date: Tue Nov 10 16:16:57 2009 New Revision: 154065 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154065 Log: PR tree-optimization/41987 * fold-const.c (const_binop): Avoid using fold_buildN(). testsuite: * gcc.c-torture/compile/pr41987.c: New. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr41987.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41987
[Bug lto/41932] LTO ICE when compiling ocaml trunk (incompatible type)
--- Comment #9 from jamborm at gcc dot gnu dot org 2009-11-10 16:20 --- Proposed patch: http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00501.html -- jamborm at gcc dot gnu dot org changed: What|Removed |Added CC|mjambor at suse dot cz |jamborm at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41932
[Bug pending/41998] New: GCC 4.6 pending patches meta-bug
Collecting pending patches for GCC 4.6 that can be applied after GCC 4.5 branches -- Summary: GCC 4.6 pending patches meta-bug Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: pending AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: law at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41998
[Bug pending/41998] GCC 4.6 pending patches meta-bug
--- Comment #1 from law at redhat dot com 2009-11-10 17:15 --- Created an attachment (id=19002) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19002action=view) Patch for better reassignment of pseudos during/after reloading Discussion here: http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00502.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41998
[Bug c++/36406] [4.3/4.4/4.5 regression] ICE with template delete operator
--- Comment #7 from jason at gcc dot gnu dot org 2009-11-10 18:19 --- Subject: Bug 36406 Author: jason Date: Tue Nov 10 18:18:51 2009 New Revision: 154072 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154072 Log: PR c++/34158 PR c++/36406 * call.c (non_placement_deallocation_fn_p): Split out... (build_op_delete_call): ...from here. Use instantiate_type for placement delete. Simplify logic. * pt.c (primary_template_instantiation_p): Non-static. * cp-tree.h: Declare it. Added: trunk/gcc/testsuite/g++.dg/init/placement4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36406
[Bug c++/34158] Template delete doesn't call if exception thrown in constructor
--- Comment #7 from jason at gcc dot gnu dot org 2009-11-10 18:19 --- Subject: Bug 34158 Author: jason Date: Tue Nov 10 18:18:51 2009 New Revision: 154072 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154072 Log: PR c++/34158 PR c++/36406 * call.c (non_placement_deallocation_fn_p): Split out... (build_op_delete_call): ...from here. Use instantiate_type for placement delete. Simplify logic. * pt.c (primary_template_instantiation_p): Non-static. * cp-tree.h: Declare it. Added: trunk/gcc/testsuite/g++.dg/init/placement4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34158
[Bug c++/40527] #pragma pack([push,] n) should be coded in the signature
--- Comment #3 from jason at gcc dot gnu dot org 2009-11-10 18:53 --- This falls in the category of diagnosing ODR violations, which we don't really try to do currently. It would be possible to do some ODR checking based on the debug info that we already emit; that seems a more promising route than breaking the ABI for this sort of thing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40527
[Bug fortran/41977] gfortran -fopenp and ACML_MP seem incompatible
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2009-11-10 20:30 --- Marking status as waiting. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41977
[Bug c/41999] New: Bug in generation of interrupt function code for ARM processor
Compiling the code:
/* similar bug 27859 */
static unsigned cnt=0;
extern void external(unsigned);
__attribute__((interrupt (IRQ))) void irq_() ;
void irq_()
{
external(cnt);
cnt=2*cnt;
external(cnt);
}
with
arm-none-eabi-gcc -c ../src/trap-bug.c -Wall -O2 -S -o trap-bug.s
results in:
irq_:
@ Interrupt Service Routine.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
sub lr, lr, #4
stmfd sp!, {r0, r1, r2, r3, r4, ip, lr}
ldr r4, .L3
sub sp, sp, #4 --- why this sub ?
ldr r0, [r4, #0]
bl external
ldr r0, [r4, #0]
mov r3, r0, asl #1
mov r0, r3
str r3, [r4, #0]
bl external
ldmfd sp!, {r0, r1, r2, r3, r4, ip, pc}^
arm-none-eabi-gcc -v
Using built-in specs.
Target: arm-none-eabi
Configured with: /scratch/julian/2009q3-respin-eabi-lite/src/gcc-4.4/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-eabi
--enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch
--enable-extra-sgxxlite-multilibs --with-gnu-as --with-gnu-ld
--with-specs='%{O2:%{!fno-remove-local-statics: -fremove-local-statics}}
%{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics: -fremove-local-statics}}}'
--enable-languages=c,c++ --disable-shared --disable-lto --with-newlib
--with-pkgversion='Sourcery G++ Lite 2009q3-68'
--with-bugurl=https://support.codesourcery.com/GNUToolchain/ --disable-nls
--prefix=/opt/codesourcery --with-headers=yes
--with-sysroot=/opt/codesourcery/arm-none-eabi
--with-build-sysroot=/scratch/julian/2009q3-respin-eabi-lite/install/arm-none-eabi
--with-gmp=/scratch/julian/2009q3-respin-eabi-lite/obj/host-libs-2009q3-68-arm-none-eabi-i686-pc-linux-gnu/usr
--with-mpfr=/scratch/julian/2009q3-respin-eabi-lite/obj/host-libs-2009q3-68-arm-none-eabi-i686-pc-linux-gnu/usr
--with-ppl=/scratch/julian/2009q3-respin-eabi-lite/obj/host-libs-2009q3-68-arm-none-eabi-i686-pc-linux-gnu/usr
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-cloog=/scratch/julian/2009q3-respin-eabi-lite/obj/host-libs-2009q3-68-arm-none-eabi-i686-pc-linux-gnu/usr
--disable-libgomp --enable-poison-system-directories
--with-build-time-tools=/scratch/julian/2009q3-respin-eabi-lite/install/arm-none-eabi/bin
--with-build-time-tools=/scratch/julian/2009q3-respin-eabi-lite/install/arm-none-eabi/bin
Thread model: single
gcc version 4.4.1 (Sourcery G++ Lite 2009q3-68)
Some remarks:
- The bug seems to be similar to bug 27859
- compiling with -O0 results in a similar behavior
Kind regards
Hans Buchmann
--
Summary: Bug in generation of interrupt function code for ARM
processor
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hans dot buchmann at fhnw dot ch
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41999
[Bug target/10127] -fstack-check let's program crash
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2009-11-10 20:45 --- Subject: Bug 10127 Author: ebotcazou Date: Tue Nov 10 20:45:25 2009 New Revision: 154079 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154079 Log: PR target/10127 PR ada/20548 * expr.h (anti_adjust_stack_and_probe): Declare. * explow.c (anti_adjust_stack_and_probe): Make global, add ADJUST_BACK parameter and rewrite head comment. (allocate_dynamic_stack_space): Adjust call to above function. * function.c (expand_function_end): Handle STACK_CHECK_MOVING_SP. * tree.h (dwarf2out_args_size): Delete. * dwarf2out.c (dwarf2out_args_size): Make static and move around. (dwarf2out_args_size_adjust): Delete prototype and move around. (dwarf2out_frame_debug_expr): Do not record arg size adjustments for ACCUMULATE_OUTGOING_ARGS targets. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/explow.c trunk/gcc/expr.h trunk/gcc/function.c trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10127
[Bug middle-end/20548] [4.3/4.4/4.5 regression] ACATS c52103x c52104x c52104y segfault
--- Comment #45 from ebotcazou at gcc dot gnu dot org 2009-11-10 20:45 --- Subject: Bug 20548 Author: ebotcazou Date: Tue Nov 10 20:45:25 2009 New Revision: 154079 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154079 Log: PR target/10127 PR ada/20548 * expr.h (anti_adjust_stack_and_probe): Declare. * explow.c (anti_adjust_stack_and_probe): Make global, add ADJUST_BACK parameter and rewrite head comment. (allocate_dynamic_stack_space): Adjust call to above function. * function.c (expand_function_end): Handle STACK_CHECK_MOVING_SP. * tree.h (dwarf2out_args_size): Delete. * dwarf2out.c (dwarf2out_args_size): Make static and move around. (dwarf2out_args_size_adjust): Delete prototype and move around. (dwarf2out_frame_debug_expr): Do not record arg size adjustments for ACCUMULATE_OUTGOING_ARGS targets. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/explow.c trunk/gcc/expr.h trunk/gcc/function.c trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20548
[Bug fortran/41977] gfortran -fopenp and ACML_MP seem incompatible
--- Comment #15 from nmm1 at cam dot ac dot uk 2009-11-10 21:49 --- It's come back again. The more that it does that, the more that I am convinced that it is something horrible in thread management, perhaps a symbol clash, race condition or overwriting, and the root cause might well not be in gfortran or ACML. Ugh. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41977
[Bug pending/41998] GCC 4.6 pending patches meta-bug
--- Comment #2 from law at redhat dot com 2009-11-10 23:00 --- Created an attachment (id=19003) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19003action=view) Avoid incorrect accumulation of registers in ALLOCNO_TOTAL_CONFLICT_HARD_REGS A minor code generation improvement by avoiding incorrect accumulation of registers in ALLOCNO_TOTAL_CONFLICT_HARD_REGS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41998
[Bug c++/40538] Compiler crashes while using decimal float point in a function argument
--- Comment #3 from jason at gcc dot gnu dot org 2009-11-10 23:05 --- It is a duplicate, both have to do with mangling. *** This bug has been marked as a duplicate of 39131 *** -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40538
[Bug c++/39131] decimal float point: ICE on typeid( 0.dd )
--- Comment #2 from jason at gcc dot gnu dot org 2009-11-10 23:05 --- *** Bug 40538 has been marked as a duplicate of this bug. *** -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||igodard at pacbell dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39131
[Bug c++/39131] decimal float point: ICE on typeid( 0.dd )
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-02-12 23:17:54 |2009-11-10 23:06:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39131
[Bug c++/42000] New: missing -Wuninitialized warning on a user-defined class ctor
gcc misses the access to the uninitialized member S::i in the program below
and fails to issue a warning for it.
I would expect to see a warning not only for the access to the member but
also for the definition of the user-defined constructor that fails to
initialize the data member.
$ cat t.cpp gcc -Wuninitialized -Wall -Wextra -W -c t.cpp
int main () {
struct S {
int i;
S() { }
} s;
return s.i;
}
--
Summary: missing -Wuninitialized warning on a user-defined class
ctor
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: msebor at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42000
[Bug testsuite/41913] ERROR: tcl error sourcing /home/dave/gnu/gcc-4.5/gcc/gcc/testsuite/gcc.dg/lto/lt
--- Comment #1 from hjl dot tools at gmail dot com 2009-11-10 23:51 --- I also saw it on Linux/ia32. Revision 153552 is OK. Revision 153563 is bad. It is very likely caused by revision 153557: http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg01212.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||nickc at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|hppa-unknown-linux-gnu | GCC host triplet|hppa-unknown-linux-gnu | GCC target triplet|hppa-unknown-linux-gnu | Last reconfirmed|-00-00 00:00:00 |2009-11-10 23:51:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41913
[Bug testsuite/41913] ERROR: tcl error sourcing /home/dave/gnu/gcc-4.5/gcc/gcc/testsuite/gcc.dg/lto/lt
--- Comment #2 from hjl dot tools at gmail dot com 2009-11-10 23:55 --- It may be caused by revision 153555: http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg01210.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41913
[Bug testsuite/42001] New: LTO test failures
On Linux/ia32, this patch: http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01547.html caused: Executing on host: /export/build/gnu/gcc/build-i686-linux/gcc/xgcc -B/export/build/gnu/gcc/build-i686-linux/gcc/ -r -nostdlib -c -o c_lto_20081212-1_0.o /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/lto/20081212-1_0.c (timeout = 300) PASS: gcc.dg/lto/20081212-1 c_lto_20081212-1_0.o assemble, -r -nostdlib Executing on host: /export/build/gnu/gcc/build-i686-linux/gcc/xgcc -B/export/build/gnu/gcc/build-i686-linux/gcc/ c_lto_20081212-1_0.o -r -nostdlib -lm -o gcc-dg-lto-20081212-1-01(timeout = 300) /usr/local/bin/ld: cannot find -lm^M collect2: ld returned 1 exit status^M compiler exited with status 1 output is: /usr/local/bin/ld: cannot find -lm^M collect2: ld returned 1 exit status^M FAIL: gcc.dg/lto/20081212-1 c_lto_20081212-1_0.o-c_lto_20081212-1_0.o link UNRESOLVED: gcc.dg/lto/20081212-1 c_lto_20081212-1_0.o-c_lto_20081212-1_0.o execute -r -nostdlib It may also cause PR 41913. -- Summary: LTO test failures Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite 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=42001
[Bug tree-optimization/41987] [4.5 Regression] expected class �constant�, have �binary� (rdiv_expr) in build_complex, at tree.c:1485
--- Comment #9 from ghazi at gcc dot gnu dot org 2009-11-11 02:46 --- Fixed. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41987
[Bug bootstrap/42002] New: Bootstrap failure: ld doesn't find 64-bit libelf on Fedora 11
I configured today's mainline with ../../mainline/configure --prefix=/pkgs/gcc-mainline --enable-languages=c,c++ --enable-stage1-languages=c,c++ --with-cpu=default64 --enable-checking=release and bootstrap fails with /home/lucier/programs/gcc/objdirs/mainline/./prev-gcc/xgcc -B/home/lucier/programs/gcc/objdirs/mainline/./prev-gcc/ -B/pkgs/gcc-mainline/powerpc64-unknown-linux-gnu/bin/ -B/pkgs/gcc-mainline/powerpc64-unknown-linux-gnu/bin/ -B/pkgs/gcc-mainline/powerpc64-unknown-linux-gnu/lib/ -isystem /pkgs/gcc-mainline/powerpc64-unknown-linux-gnu/include -isystem /pkgs/gcc-mainline/powerpc64-unknown-linux-gnu/sys-include -g -O2 -gtoggle -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o c-parser.o rs6000-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o \ dummy-checksum.o main.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/home/lucier/programs/gcc/objdirs/mainline/./gmp/.libs -L/home/lucier/programs/gcc/objdirs/mainline/./gmp/_libs -L/home/lucier/programs/gcc/objdirs/mainline/./mpfr/.libs -L/home/lucier/programs/gcc/objdirs/mainline/./mpfr/_libs -lmpfr -lgmp -rdynamic -ldl -L../zlib -lz -lelf /usr/bin/ld: skipping incompatible /usr/lib/libelf.so when searching for -lelf /usr/bin/ld: cannot find -lelf collect2: ld returned 1 exit status The object files are 64-bit: [luc...@lambda-head mainline]$ file gcc/rs6000-c.o gcc/rs6000-c.o: ELF 64-bit MSB relocatable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), not stripped and a 64-bit libelf is installed: [luc...@lambda-head mainline]$ file /usr/lib64/libelf* /usr/lib64/libelf-0.142.so: ELF 64-bit MSB shared object, 64-bit PowerPC or cisco 7500, version 1 (SYSV), dynamically linked, stripped /usr/lib64/libelf.so.1: symbolic link to `libelf-0.142.so' but I don't know why it isn't being found. -- Summary: Bootstrap failure: ld doesn't find 64-bit libelf on Fedora 11 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu GCC build triplet: powerpc64-unknown-linux-gnu/ GCC host triplet: powerpc64-unknown-linux-gnu GCC target triplet: powerpc64-unknown-linux-gnu/ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42002
[Bug middle-end/42004] New: [4.5 regression] Revision 154079 failed g++.dg/torture/stackalign/unwind-2.C
On Linux/ia32, revision 154079: http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00300.html caused: FAIL: g++.dg/torture/stackalign/unwind-2.C -O1 execution test FAIL: g++.dg/torture/stackalign/unwind-2.C -O2 execution test FAIL: g++.dg/torture/stackalign/unwind-2.C -O2 -flto execution test FAIL: g++.dg/torture/stackalign/unwind-2.C -O2 -fwhopr execution test -- Summary: [4.5 regression] Revision 154079 failed g++.dg/torture/stackalign/unwind-2.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=42004
[Bug fortran/41807] [4.5/4.4 Regression] data statement with nested type constructors
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-11-11 05:20 --- I have tracked through the matchers and as suspected, the iterator is being initialised correctly. Start, End, and Step are all constants. This hints at some corruption. As time allows I will follow the iterator through to the array spec and try to see where we are losing it. By the time we get into resolve.c, start is no longer a constant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
[Bug rtl-optimization/41619] [4.4/4.5 regression] ICE in insert_save (caller-save.c) for SPEC CPU2000's 252.eon
--- Comment #5 from hjl dot tools at gmail dot com 2009-11-11 05:34 --- Revision 149212: http://gcc.gnu.org/ml/gcc-cvs/2009-07/msg00089.html may be the cause. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41619
[Bug testsuite/42001] LTO test failures
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-11 05:39 --- A simple test like: gcc -r t.o t1.o -nostdlib -lm -v -B /home/pinskia/src/gcc/local/gcc/objdir/gcc Works so I don't know what is going wrong with your build. The only thing I can think of is that your ld is build incorrectly and does not include /lib /usr/lib by default. You are the only one who has this failure from what I can tell from the testresults too. See http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00875.html for an example where it works (and yes that includes lto testing too because of the C++ failures). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42001
[Bug testsuite/41913] ERROR: tcl error sourcing /home/dave/gnu/gcc-4.5/gcc/gcc/testsuite/gcc.dg/lto/lt
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-11 05:40 --- At best these patches exposes the failure here. This was the failure I was getting with spu-elf before my patch to use -r -nostdlib. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41913
[Bug c/42005] New: too many expressions recognised as null pointer constants?
The following code prompts a warning on the line f(n - 1), but not on the line
f(n - n). I guess this is because n - n is being turned into zero too early.
(Definition of null pointer constant says it must be a constant expression; n -
n is not one.)
void g(int n)
{
void f(int *);
f(n - 1);
f(n - n);
}
--
Summary: too many expressions recognised as null pointer
constants?
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot norrish at gmail dot com
GCC host triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42005
[Bug testsuite/41913] ERROR: tcl error sourcing /home/dave/gnu/gcc-4.5/gcc/gcc/testsuite/gcc.dg/lto/lt
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-11-11 05:44 --- Also I think PR 42001 is the real cause of your issues. Your linker is broken ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41913
[Bug c/42005] too many expressions recognised as null pointer constants?
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-11 05:49 --- Fixed on the trunk for 4.5 by: 2009-03-29 Joseph Myers jos...@codesourcery.com PR c/456 PR c/5675 PR c/19976 PR c/29116 PR c/31871 PR c/35198 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42005
[Bug testsuite/42001] LTO test failures
--- Comment #2 from hjl dot tools at gmail dot com 2009-11-11 06:02 --- GNU linker doesn't search any directories when -r is used. Gcc driver doesn't pass explicit search directories to linker: [...@gnu-29 gcc]$ ./xgcc -B./ -v x.o Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: i686-pc-linux-gnu Configured with: ../src-trunk/configure --enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld Thread model: posix gcc version 4.5.0 20091110 (experimental) [trunk revision 154081] (GCC) COMPILER_PATH=./ LIBRARY_PATH=./:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-B./' '-v' '-mtune=generic' ./collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o ./crtbegin.o -L. x.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed ./crtend.o /usr/lib/crtn.o [...@gnu-29 gcc]$ ./xgcc -B./ -r x.o -lm -v Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: i686-pc-linux-gnu Configured with: ../src-trunk/configure --enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld Thread model: posix gcc version 4.5.0 20091110 (experimental) [trunk revision 154081] (GCC) COMPILER_PATH=./ LIBRARY_PATH=./:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-B./' '-r' '-v' '-mtune=generic' ./collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -r /usr/lib/crt1.o /usr/lib/crti.o ./crtbegin.o -L. x.o -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed ./crtend.o /usr/lib/crtn.o /usr/local/i686-pc-linux-gnu/bin/ld: cannot find -lm collect2: ld returned 1 exit status [...@gnu-29 gcc]$ That is why ld -r -lm fails. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42001
[Bug testsuite/42001] LTO test failures
--- Comment #3 from hjl dot tools at gmail dot com 2009-11-11 06:05 --- You have to see it on a machine without multilib support. Otherwise, gcc driver will pass -L... to linker. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42001
[Bug testsuite/42001] LTO test failures
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-11-11 06:07 --- It works for me: pins...@gcc13:~/src/local$ gcc -r t.o t1.o -nostdlib -lm -v -B /home/pinskia/src/gcc/local/gcc/objdir/gcc -Wl,-v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release x86_64-linux-gnu Thread model: posix gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) /usr/lib/gcc/x86_64-linux-gnu/4.1.2/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -r -L/usr/lib/gcc/x86_64-linux-gnu/4.1.2 -L/usr/lib/gcc/x86_64-linux-gnu/4.1.2 -L/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 t.o t1.o -lm -v collect2 version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) (x86-64 Linux/ELF) /usr/bin/ld --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -r -L/usr/lib/gcc/x86_64-linux-gnu/4.1.2 -L/usr/lib/gcc/x86_64-linux-gnu/4.1.2 -L/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 t.o t1.o -lm -v GNU ld version 2.17 Debian GNU/Linux Oh it looks like SPECS difference between x86_64 and i386 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42001
[Bug testsuite/42001] LTO test failures
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-11-11 06:08 --- well most targets are multilibbed now so I never saw it. I think you should just remove -lm then . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42001
[Bug testsuite/42001] LTO tests fail with non multilib targets (but still not --disable-multilib )
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-11-11 06:15 --- Oh multilib.h is correct for --disable-multilib case ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42001
[Bug c/42006] New: Termination problem with -O2 and -O3
Using r154087, the code below never terminates with -O2 and -O3.
y...@yang-working:~$ svngcc -O2 -o small2 small.c
y...@yang-working:~$ ./small2
1
1
...
y...@yang-working:~$ ./small1
1
2
exit!
y...@yang-working:~$ cat small.c
#include stdio.h
static int
my_add(int si1, int si2)
{
return (si1 (50-si2)) ? si1 : (si1 + si2);
}
static unsigned int
my_shift(unsigned int left, int right)
{
return (right 100) ? left : (left right);
}
static int func_4(unsigned int p_6)
{
for (p_6 = 1; p_6 3; p_6 = my_add(p_6, 1))
{
printf (%d\n, p_6);
if (my_shift(p_6, p_6))
{
return 0;
}
}
return 0;
}
int main(void)
{
func_4(0);
printf(exit!\n);
return 0;
}
y...@yang-working:~$ svngcc -v
Using built-in specs.
COLLECT_GCC=svngcc
COLLECT_LTO_WRAPPER=/home/yang/compilers/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --enable-lto --prefix=/home/yang/compilers
--program-prefix=svn --enable-languages=c,c++
--with-libelf=/home/yang/compilers : (reconfigured) ../configure --enable-lto
--prefix=/home/yang/compilers --program-prefix=svn
--with-libelf=/home/yang/compilers --enable-languages=c,lto,c++ --no-create
--no-recursion : (reconfigured) ../configure --enable-lto
--prefix=/home/yang/compilers --program-prefix=svn
--with-libelf=/home/yang/compilers --enable-languages=c,c++,lto --no-create
--no-recursion : (reconfigured) ../configure --enable-lto
--prefix=/home/yang/compilers --program-prefix=svn
--with-libelf=/home/yang/compilers --enable-languages=c,c++,lto --no-create
--no-recursion : (reconfigured) ../configure --enable-lto
--prefix=/home/yang/compilers --program-prefix=svn
--with-libelf=/home/yang/compilers --enable-languages=c,c++,lto --no-create
--no-recursion
Thread model: posix
gcc version 4.5.0 20091110 (experimental) (GCC)
--
Summary: Termination problem with -O2 and -O3
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chenyang at cs dot utah dot edu
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42006
[Bug bootstrap/42002] Bootstrap failure: ld doesn't find 64-bit libelf on Fedora 11
--- Comment #1 from jakub at gcc dot gnu dot org 2009-11-11 06:51 --- The last command shows that while you have libelf installed, you don't have libelf.so symlink for the 64-bit libelf. So, you need to yum install elfutils-libelf-devel.ppc64 -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42002
[Bug driver/42007] New: Make -mfloat-gprs=double the default when compiling for powerpc-linux-gnuspe target
The problem applied both to building the compiler proper, as well as application on/for the given host triplet. Most (all?) Freescale SPE enabled cores these days are dual-precision capable e500v2, and this is the case for couple of years now. However, when building the compiler for the triplet in question, gcc internal libraries are only built with single precision SPE ops emitted. Making gcc to build these libraries with proper DP support requires setting of the *_FOR_TARGET variables during the build to contain -mfloat-gprs=double. Same applies for normal application compiles. Single precision FP instructions are used by default, unless the flag is set. It seems beneficial and probably not harmful (e500v1 was never too popular and rather short-lived) to make -mfloat-gprs=double a default behavior. -- Summary: Make -mfloat-gprs=double the default when compiling for powerpc-linux-gnuspe target Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: oakad at yahoo dot com GCC target triplet: powerpc-linux-gnuspe http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42007
