[Bug tree-optimization/43159] Missing optimization

--- Comment #2 from steven at gcc dot gnu dot org 2010-02-24 09:40 --- Missing code hoisting. Dup of another bug. *** This bug has been marked as a duplicate of 23286 *** -- steven at gcc dot gnu dot org changed: What|Removed |Added --

[Bug tree-optimization/23286] missed fully redundant expression

--- Comment #30 from steven at gcc dot gnu dot org 2010-02-24 09:40 --- *** Bug 43159 has been marked as a duplicate of this bug. *** -- steven at gcc dot gnu dot org changed: What|Removed |Added

[Bug c/42935] Warning "u64 = u32 * u32;" - i.e. not casting one u32 to u64

--- Comment #2 from etienne_lorrain at yahoo dot fr 2010-02-24 09:45 --- It would be nice to have the warning in the second case too, i.e. for (unsigned long long)(val1*val2). Another solution, probably a lot more complex to implement, is to have a compilation switch to expand all calcu

[Bug target/43142] [4.5 Regression] ICE in output_505, at config/rs6000/rs6000.md:12485

--- Comment #8 from rguenth at gcc dot gnu dot org 2010-02-24 10:00 --- I can reproduce it on a powerpc machine with ../trunk/configure --target=powerpc64-suse-linux --with-cpu=default32 --enable-languages=c++ --with-long-double-128 --enable-secureplt --host=powerpc64-suse-linux --build

[Bug c/42935] Warning "u64 = u32 * u32;" - i.e. not casting one u32 to u64

--- Comment #3 from manu at gcc dot gnu dot org 2010-02-24 10:23 --- (In reply to comment #2) > It would be nice to have the warning in the second case too, i.e. for > (unsigned long long)(val1*val2). Actually, it is a bit weird that the operands are not promoted to unsigned long long.

[Bug c/43128] [4.5 Regression] c-c++-common/pr41779.c doesn't work

--- Comment #25 from manu at gcc dot gnu dot org 2010-02-24 10:39 --- PATCH: http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00969.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128

[Bug fortran/43146] Character constant declared in a module does not transfer correctly

--- Comment #8 from burnus at gcc dot gnu dot org 2010-02-24 10:46 --- (In reply to comment #7) > There are no changes if I compiled with *.f90 instead of *.F90 extension. Another idea - can you compile with "valgrind"? That is: gfortran -v find the line containing the call to f951 a

[Bug lto/43157] Segmentation fault in aggregate_value_p

--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-24 10:50 --- Confirmed. We somehow think that factorial_ has a body. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug debug/43150] Proper debug info for debugging VLAs

--- Comment #5 from jakub at gcc dot gnu dot org 2010-02-24 10:50 --- Subject: Bug 43150 Author: jakub Date: Wed Feb 24 10:50:13 2010 New Revision: 157032 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157032 Log: PR debug/43150 * gimplify.c (gimplify_type_sizes)

[Bug c++/43120] Diamond virtual inheritence with covariant return type confuses GCC

--- Comment #4 from goeran at uddeborg dot se 2010-02-24 11:02 --- Created an attachment (id=19944) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19944&action=view) A different simplification, avoiding the diamond inheritance The diamond inheritance does not seem to be a requireme

[Bug debug/43150] Proper debug info for debugging VLAs

-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org

[Bug debug/43160] New: Wrong debug info in guality/vla-1.c (f1)

Tracking the 1) issue of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43150#c2 here. In f1 say -O2 -m64 -g we have in *.alignments: (debug_insn 7 14 8 2 vla-1.c:15 (var_location:DI D#2 (sign_extend:DI (plus:SI (reg/v:SI 5 di [orig:62 i ] [62]) (const_int 1 [0x1] -1 (nil)) (debug_ins

[Bug debug/43161] New: Wrong debug info in guality/vla-1.c (f2)

Tracking http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43150#c2 issue 2) here: In f2 with -O2 -g -m64 we have in *.ce3 (which looks correct): (insn 2 53 3 2 vla-1.c:22 (set (reg/v:SI 41 r12 [orig:61 i ] [61]) (reg:SI 5 di [ i ])) 47 {*movsi_1} (expr_list:REG_DEAD (reg:SI 5 di [ i ])

[Bug debug/43150] Proper debug info for debugging VLAs

--- Comment #6 from jakub at gcc dot gnu dot org 2010-02-24 11:13 --- Closing as fixed, the 1) and 2) issues mentioned here are now tracked in PR43160 resp. PR43161. -- jakub at gcc dot gnu dot org changed: What|Removed |Added -

[Bug target/42894] [4.5 Regression] Invalid rtl sharing in Thumb1.

--- Comment #9 from rearnsha at gcc dot gnu dot org 2010-02-24 11:15 --- I think the real problem here is that shared_const_p thinks that _this_ const expression can't be shared (though I can't see any reason why it couldn't). The comment in that function says, "CONST can be shared if

[Bug target/42894] [4.5 Regression] Invalid rtl sharing in Thumb1.

--- Comment #10 from pinskia at gcc dot gnu dot org 2010-02-24 11:19 --- > shared_const_p Funny I was just helping with a PowerPC issue dealing with that function: see PR 42431. shared_const_p was introduced by the merge of the Dataflow branch but the code was outlined and the origina

[Bug c/43162] New: option to set the "promoted" type of parameters of calculus

In C, variables are promoted to unsigned int or int before operations like adding or multiplying so that we have on ia32 PC: unsigned char uc1 = 0x10, uc2 = 0x10; printf ("0x%X\n", uc1*uc2); -> display 0x100 unsigned short us1 = 0x1000, us2 = 0x10; printf ("0x%X\n", us1*us2); -> display 0x1

[Bug c/43162] option to set the "promoted" type of parameters of arithmetic

--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-24 11:33 --- I think this is the wrong approach really. Learning C/C++ rules for arithmetic operations and the promotion of types is not hard. Also this is not calculus but simple arithmetic operations :). -- pinskia at gcc

[Bug libobjc/36610] objc_msg_sendv is broken for targets which pass argument via registers

--- Comment #16 from ro at gcc dot gnu dot org 2010-02-24 11:56 --- Subject: Bug 36610 Author: ro Date: Wed Feb 24 11:56:10 2010 New Revision: 157035 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157035 Log: PR libobjc/36610 * objc/execute/forward-1.x: XFAIL on

[Bug c++/40059] "uninitialized" warning missed when uninitialized class member used as array index

--- Comment #2 from manu at gcc dot gnu dot org 2010-02-24 11:58 --- (In reply to comment #1) > gcc 4.3.4 doesn't complain about dereferencing uninitialized member variables > either. > Please, open a new PR, attach a self-contained testcase, add PR 24639 to the block list of the new P

[Bug c++/43163] New: gcc doesn't report uninitialized member variables

Output produced by the attached test program (as you can see, gcc doesn't warn about initializing member variable m1 with the value of the uninitialized member variable m2): $ g++ -Wall -o uninitialized-member-variable uninitialized-member-variable.cpp && ./uninitialized-member-variable a.m1 = 162

[Bug c++/43163] gcc doesn't report uninitialized member variables

--- Comment #1 from bart dot vanassche at gmail dot com 2010-02-24 12:06 --- Created an attachment (id=19945) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19945&action=view) uninitialized-member-variable.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43163

[Bug c++/40059] "uninitialized" warning missed when uninitialized class member used as array index

--- Comment #1 from bart dot vanassche at gmail dot com 2010-02-24 11:46 --- gcc 4.3.4 doesn't complain about dereferencing uninitialized member variables either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40059

[Bug debug/43161] Wrong debug info in guality/vla-1.c (f2)

--- Comment #1 from jakub at gcc dot gnu dot org 2010-02-24 12:44 --- Created an attachment (id=19946) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19946&action=view) gcc45-pr43161.patch Untested patch that fixes this. I'm not 100% sure whether it is safe to call df_analyze just

[Bug c++/19808] miss a warning about uninitialized members in constructor

--- Comment #6 from manu at gcc dot gnu dot org 2010-02-24 12:46 --- *** Bug 43163 has been marked as a duplicate of this bug. *** -- manu at gcc dot gnu dot org changed: What|Removed |Added -

[Bug c++/43163] g++ doesn't report uninitialized member variables

--- Comment #2 from manu at gcc dot gnu dot org 2010-02-24 12:46 --- OK. Now I see that this is exactly the same as PR 19808, which was not on my list. Thanks for the report. *** This bug has been marked as a duplicate of 19808 *** -- manu at gcc dot gnu dot org changed:

[Bug testsuite/32547] gnat.dg tasking tests fail on IRIX 5.3

--- Comment #3 from ro at gcc dot gnu dot org 2010-02-24 12:52 --- Subject: Bug 32547 Author: ro Date: Wed Feb 24 12:51:44 2010 New Revision: 157037 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157037 Log: PR ada/32547 * lib/gnat-dg.exp (gnat_load): Redefine.

[Bug c++/19808] miss a warning about uninitialized members in constructor

--- Comment #7 from manu at gcc dot gnu dot org 2010-02-24 12:59 --- This usage could be warned in the front-end. Specially because the SSA form looks like: S::S() (struct SD.2093 * const thisD.2102) { intD.2 D.2131; # BLOCK 2, starting at line 6 # PRED: ENTRY (fallthru) [pr198

[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors

--- Comment #8 from manu at gcc dot gnu dot org 2010-02-24 13:05 --- Related to PR 19808. (In reply to comment #6) > However -Wunitialized is taken over by the middle-end. This is That doesn't mean that you cannot produce uninitialized warnings in the front-end for clear-cut cases lik

[Bug c/43128] [4.5 Regression] c-c++-common/pr41779.c doesn't work

--- Comment #26 from manu at gcc dot gnu dot org 2010-02-24 13:09 --- Subject: Bug 43128 Author: manu Date: Wed Feb 24 13:09:37 2010 New Revision: 157040 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157040 Log: 2010-02-24 Manuel López-Ibáñez PR c/43128 *

[Bug c/43128] [4.5 Regression] c-c++-common/pr41779.c doesn't work

--- Comment #27 from manu at gcc dot gnu dot org 2010-02-24 13:10 --- It should be FIXED for GCC 4.5 -- manu at gcc dot gnu dot org changed: What|Removed |Added

[Bug c/38470] Feature request: smarter signed/unsigned warning

--- Comment #1 from manu at gcc dot gnu dot org 2010-02-24 13:16 --- We need a complete testcase. -- manu at gcc dot gnu dot org changed: What|Removed |Added

[Bug c/38470] Feature request: smarter signed/unsigned warning

--- Comment #2 from manu at gcc dot gnu dot org 2010-02-24 13:16 --- We need a complete testcase. See http://gcc.gnu.org/bugs -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470

[Bug other/42540] c++ error message [vtable undefined] is unhelpful

--- Comment #4 from manu at gcc dot gnu dot org 2010-02-24 13:25 --- Is it impossible to detect this in the compiler? Can't we put the vtable somewhere else (or break it in pieces) such triggering the error in the compiler? Otherwise, we should just close this as WONTFIX. -- manu a

[Bug middle-end/42561] missing uninitialized variable warning on simple arrays

--- Comment #5 from manu at gcc dot gnu dot org 2010-02-24 13:31 --- (In reply to comment #4) > > What would be the implementation steps to fix this issue? 1) Create a small self-contained testcase 2) Examine the dumps (-fdump-tree- options) and debug the compiler to know exactly why

[Bug middle-end/41056] ICE with -finline-limit=600 and -fwhole-file: type mismatch between an SSA_NAME and its symbol

--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-24 13:40 --- The SSA name has GFC_ARRAY_TYPE_P set on the pointer type while the var decl has not. Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41056

[Bug middle-end/42561] missing uninitialized variable warning on simple arrays

--- Comment #6 from rguenth at gcc dot gnu dot org 2010-02-24 13:46 --- Note that uninitialized warnings on memory are severely limited by design. It's not hard to improve that but it will be very costly in terms of compile-time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42561

[Bug c/38470] Feature request: smarter signed/unsigned warning

--- Comment #3 from paolo dot carlini at oracle dot com 2010-02-24 13:59 --- I think submitter ask for something like this: int f(int foo, double bar) { if (foo >= 0 && foo < sizeof(bar)) return 1; return foo; } to not warn with -Wsign-compare. -- paolo dot carlini at orac

[Bug c/38470] dataflow would improve -Wsign-compare

--- Comment #4 from manu at gcc dot gnu dot org 2010-02-24 14:03 --- (In reply to comment #3) > I think submitter ask for something like this: [snip] > to not warn with -Wsign-compare. That would be nice, but it would require moving the warning to the middle-end or some form of dataflow

[Bug c/38470] dataflow would improve -Wsign-compare

--- Comment #5 from m dot j dot thayer at googlemail dot com 2010-02-24 14:07 --- Comment 3 describes what I meant. And re comment 4, it is a "would be nice to have", obviously if it is too much pain to do then such is life. Thanks in any case. -- http://gcc.gnu.org/bugzilla/show

[Bug middle-end/41056] ICE with -finline-limit=600 and -fwhole-file: type mismatch between an SSA_NAME and its symbol

--- Comment #3 from dominiq at lps dot ens dot fr 2010-02-24 14:10 --- Created an attachment (id=19947) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19947&action=view) Reduced test case for aermod. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41056

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

--- Comment #6 from manu at gcc dot gnu dot org 2010-02-24 14:11 --- Fixing this is even more unlikely than fixing PR 23608, since the latter only asks for constant propagation, but this one requires value range propagation. -- manu at gcc dot gnu dot org changed: What

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

--- Comment #7 from manu at gcc dot gnu dot org 2010-02-24 14:12 --- (In reply to comment #5) > Comment 3 describes what I meant. And re comment 4, it is a "would be nice to > have", obviously if it is too much pain to do then such is life. Thanks in > any > case. Please, do not unde

[Bug middle-end/41056] ICE with -finline-limit=600 and -fwhole-file: type mismatch between an SSA_NAME and its symbol

--- Comment #4 from dominiq at lps dot ens dot fr 2010-02-24 14:15 --- Note that the miscompilation of linpk.f90 of comment #0 is gone since at least revision 150825. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41056

[Bug c++/23608] constant propagation (CCP) would improve -Wsign-compare

--- Comment #7 from manu at gcc dot gnu dot org 2010-02-24 14:16 --- A simpler version of PR 38470. An idea could be to do some cheap and quick ccp in the front-end like clang does. The alternative is to move this to the middle-end, which is rather difficult. -- manu at gcc dot gnu d

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

--- Comment #8 from m dot j dot thayer at googlemail dot com 2010-02-24 14:16 --- Of course. I asked this without knowing much about compiler internals, but I do have experience of users asking for "little" features which would involve somewhat more work than they would like to think :

[Bug other/42540] c++ error message [vtable undefined] is unhelpful

--- Comment #5 from rearnsha at gcc dot gnu dot org 2010-02-24 14:17 --- As suggested, there's no bug in the compiler here, and the error message comes from the linker. The linker doesn't know what the key function is, so I doubt it could issue a more accurate diagnostic. In fact, the

[Bug c/38046] 'warning: comparison between signed and unsigned' shouldn't be given for equality comparisons

--- Comment #4 from manu at gcc dot gnu dot org 2010-02-24 14:29 --- I am really sorry, I don't think we want to add an option for this particular case. As Joseph explained, there is a difference if the variables are mismatched signed/unsigned or not. For your problem, you could use a w

[Bug fortran/41056] ICE with -finline-limit=600 and -fwhole-file: type mismatch between an SSA_NAME and its symbol

--- Comment #5 from rguenth at gcc dot gnu dot org 2010-02-24 14:37 --- The error is exposed somewhen during inlining. I suppose the frontend has some unmerged types still (maybe possible to workaround in the middle-end, but for now a Fortran issue). -- rguenth at gcc dot gnu dot or

[Bug c/43164] New: ice in completely_scalarize_record, at tree-sra.c:85

prefix=r157027- --enable-languages=c,c++ Thread model: posix gcc version 4.5.0 20100224 (experimental) (GCC) -- Summary: ice in completely_scalarize_record, at tree-sra.c:85 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity:

[Bug tree-optimization/43164] [4.5 Regression] ice in completely_scalarize_record, at tree-sra.c:85

--- Comment #1 from rguenth at gcc dot gnu dot org 2010-02-24 15:34 --- That looks somewhat familiar -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug target/32693] [H8] : ICE: in gen_rtx_SUBREG, at emit-rtl.c:693

--- Comment #2 from law at redhat dot com 2010-02-24 15:34 --- Created an attachment (id=19948) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19948&action=view) Fix for assertion failure -- law at redhat dot com changed: What|Removed |Added -

[Bug java/40816] error: 'jvariant::jvariant(jbyte)' cannot be overloaded

--- Comment #4 from aph at gcc dot gnu dot org 2010-02-24 15:34 --- Subject: Bug 40816 Author: aph Date: Wed Feb 24 15:34:19 2010 New Revision: 157047 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157047 Log: 2010-02-24 Andrew Haley PR java/40816 * include/j

[Bug target/32693] [H8] : ICE: in gen_rtx_SUBREG, at emit-rtl.c:693

--- Comment #3 from law at redhat dot com 2010-02-24 15:35 --- Additional info here: http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00950.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32693

[Bug rtl-optimization/32739] ICE for H8SX when compiled with optimization

--- Comment #1 from law at redhat dot com 2010-02-24 15:36 --- *** This bug has been marked as a duplicate of 32693 *** -- law at redhat dot com changed: What|Removed |Added

[Bug target/32693] [H8] : ICE: in gen_rtx_SUBREG, at emit-rtl.c:693

--- Comment #4 from law at redhat dot com 2010-02-24 15:36 --- *** Bug 32739 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32693

[Bug c/43165] New: ice in simplify_subreg, at simplify-rtx.c:5146

mp/gcc-r157027-install --program-prefix=r157027- --enable-languages=c,c++ Thread model: posix gcc version 4.5.0 20100224 (experimental) (GCC) -- Summary: ice in simplify_subreg, at simplify-rtx.c:5146 Product: gcc Version: 4.5.0 Status: UNCON

[Bug middle-end/42859] [4.5 regression] ICE in verify_flow_info

--- Comment #9 from abel at gcc dot gnu dot org 2010-02-24 15:58 --- Created an attachment (id=19949) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19949&action=view) patch Here is the updated patch, it bootstraps and regtests fine on x86-64 linux. I'm leaving for about a week st

[Bug c/43165] [4.5 Regression] ice in simplify_subreg, at simplify-rtx.c:5146

-- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot |

[Bug target/43142] [4.5 Regression] ICE in output_505, at config/rs6000/rs6000.md:12485

--- Comment #9 from rguenth at gcc dot gnu dot org 2010-02-24 16:06 --- It works with rev. 157027. Either it's gone latent or it's fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --

[Bug other/43132] installation directory defaults do not match documentation, Coding Standards

--- Comment #6 from mmitchel at gcc dot gnu dot org 2010-02-24 16:28 --- Ralf -- I think the key question here is whether it is possible to build/install a new version of GCC, getting the same directory layout as was the default in previous versions. It's OK if it takes command-line o

[Bug fortran/41056] ICE with -finline-limit=600 and -fwhole-file: type mismatch between an SSA_NAME and its symbol

--- Comment #6 from rguenth at gcc dot gnu dot org 2010-02-24 16:31 --- Created an attachment (id=19950) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19950&action=view) further reduced testcase >From auto-reduction of the reduced testcase. Fails with -O3 -fwhole-file. -- ht

[Bug middle-end/27896] lower-gimple produces extra goto for once return functions

--- Comment #3 from steven at gcc dot gnu dot org 2010-02-24 16:34 --- Still a problem, actually worse now than before (.009t.lower dump at r156926): ;; Function foo (foo) foo () { int D.1974; D.1974 = 1; goto ; : return D.1974; } The decomposition of "return 1" shows up al

[Bug debug/43165] [4.5 Regression] ice in simplify_subreg, at simplify-rtx.c:5146

--- Comment #1 from jakub at gcc dot gnu dot org 2010-02-24 16:35 --- Created an attachment (id=19951) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19951&action=view) gcc45-pr43165.patch Untested fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43165

[Bug c++/19808] miss a warning about uninitialized members in constructor

--- Comment #8 from jason at gcc dot gnu dot org 2010-02-24 16:43 --- What else could it be than a pointer? It might be possible to mark it somehow so that the middle end knows to consider the referent uninitialized. Incidentally, perhaps we should mark the this parameter as __restrict

[Bug c++/34272] ICE with invalid template specialization

--- Comment #4 from paolo dot carlini at oracle dot com 2010-02-24 17:53 --- Unassigning, somebody else may be able to figure out more quickly a better fix. -- paolo dot carlini at oracle dot com changed: What|Removed |Added --

[Bug c++/19808] miss a warning about uninitialized members in constructor

--- Comment #9 from rguenth at gcc dot gnu dot org 2010-02-24 18:04 --- (In reply to comment #8) > What else could it be than a pointer? It might be possible to mark it somehow > so that the middle end knows to consider the referent uninitialized. > > Incidentally, perhaps we should ma

[Bug other/43132] installation directory defaults do not match documentation, Coding Standards

--- Comment #7 from Ralf dot Wildenhues at gmx dot de 2010-02-24 18:19 --- (In reply to comment #6) > I think the key question here is whether it is possible to build/install a new > version of GCC, getting the same directory layout as was the default in > previous versions. It's OK if

[Bug rtl-optimization/43058] [4.5 Regression] var-tracking uses up all virtual memory

--- Comment #9 from jakub at gcc dot gnu dot org 2010-02-24 18:25 --- It is vt_emit_notes that eats all the memory, not vt_find_locations, and the memory doesn't go into the hash tables, but for rtx allocation. I've printed ggc statistics on vt_emit_notes entry and after I left it eat an

[Bug c++/19808] miss a warning about uninitialized members in constructor

--- Comment #10 from bart dot vanassche at gmail dot com 2010-02-24 19:10 --- (In reply to comment #9) > I think there is no reasonable way to get reliable uninitialized variable > warnings for incoming pointed-to memory. The only way we can warn here > is by inlining the constructor i

[Bug target/25272] gcc fails to compile for target h8300-hitachi-hms with unrecognizable insn

--- Comment #5 from law at redhat dot com 2010-02-24 19:12 --- *** This bug has been marked as a duplicate of 29377 *** -- law at redhat dot com changed: What|Removed |Added

[Bug target/29377] Build for h8300-elf crashes on 64bit hosts due to int/HWI mismatch

--- Comment #9 from law at redhat dot com 2010-02-24 19:12 --- *** Bug 25272 has been marked as a duplicate of this bug. *** -- law at redhat dot com changed: What|Removed |Added -

[Bug debug/43166] New: [4.5 Regression] ICE in simplify_subreg on fortran code

C { dg-do compile } C { dg-options "-O -g" } SUBROUTINE FOO () INTEGER V1 COMMON // V1 END SUBROUTINE BAR () INTEGER V0,V1,V2,V3 COMMON // V1(4),V2(85,4),V3 DO V3=1,V1(1) V0=V2(V3,1) END DO END ICEs in simplify_subreg called from exp

[Bug c++/12909] ambiguity in mangling vector types

--- Comment #6 from jason at gcc dot gnu dot org 2010-02-24 19:26 --- Subject: Bug 12909 Author: jason Date: Wed Feb 24 19:26:38 2010 New Revision: 157052 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157052 Log: PR c++/12909 * mangle.c (write_type): Give -Wabi

[Bug c++/43167] New: Warnings should not be disabled when instantiating templates defined in system headers

Consider this C++ code: #include #include #include int64_t sum(const std::vector& values) { return std::accumulate(values.begin(), values.end(), 0); } I'm using mainline. When I compile this with -Wconversion I get no warning. When I compile it with -Wconversion -Wsystem-headers I get In

[Bug c++/43167] Warnings should not be disabled when instantiating templates defined in system headers

--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-24 19:35 --- There was a bug asking the opposite way IIRC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167

[Bug c++/43167] Warnings should not be disabled when instantiating templates defined in system headers

--- Comment #2 from pinskia at gcc dot gnu dot org 2010-02-24 19:37 --- PR 36760 is an example where it was asking the opposite way. I thought there was more than that bug though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167

[Bug c++/43167] Warnings should not be disabled when instantiating templates defined in system headers

--- Comment #3 from pinskia at gcc dot gnu dot org 2010-02-24 19:38 --- Found it, PR 30500 was the exact bug which changed this behavior :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167

[Bug c++/43167] Warnings should not be disabled when instantiating templates defined in system headers

--- Comment #4 from pinskia at gcc dot gnu dot org 2010-02-24 19:41 --- >This warning indicates a problem with user code. Or is it? Since long long does not exist in C++03 :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167

[Bug debug/43166] [4.5 Regression] ICE in simplify_subreg on fortran code

-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43166

[Bug c++/19808] miss a warning about uninitialized members in constructor

--- Comment #11 from manu at gcc dot gnu dot org 2010-02-24 19:44 --- (In reply to comment #8) > What else could it be than a pointer? It might be possible to mark it somehow > so that the middle end knows to consider the referent uninitialized. This is because (this) must be allocated

[Bug debug/43166] [4.5 Regression] ICE in simplify_subreg on fortran code

--- Comment #1 from jakub at gcc dot gnu dot org 2010-02-24 19:51 --- Created an attachment (id=19952) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19952&action=view) gcc45-pr43166.patch Patch that both robustifies cfgexpand and hopefully fixes Fortran FE common block handling.

[Bug libmudflap/33119] Missing mf-runtime.h after make -j2 install

--- Comment #3 from rwild at gcc dot gnu dot org 2010-02-24 20:03 --- This particular race condition should be fixed by , so it should actually be fixed in the 4.3 branch. If you can still reproduce this with 4.3.4 or newer, then

[Bug other/43168] New: internal compiler error for xgcc when building gcc for pdp11-unknown-aout

Hello, I'm trying to build a cross compiler for pdp11-aout targets. xgcc get build, but when trying to build libs, it aborts reporting internal compiler error: ../../../../gcc-4.4.3/libgcc/../gcc/libgcc2.c: In function '__mulDI3': ../../../../gcc-4.4.3/libgcc/../gcc/libgcc2.c:562: internal compil

[Bug c++/19808] miss a warning about uninitialized members in constructor

--- Comment #12 from jason at gcc dot gnu dot org 2010-02-24 20:12 --- (In reply to comment #11) > (In reply to comment #8) > > What else could it be than a pointer? It might be possible to mark it > > somehow > > so that the middle end knows to consider the referent uninitialized. >

[Bug fortran/43169] New: gfortran rejects pure procedure with select type construct

The following code fails to compile with gcc version 4.5.0-pre 20100224 (experimental) rev. 157053. However, if lines 22, 23 and 27 (i.e. 'select type(x)', 'class is (myType)', and 'end select') are removed it compiles fine and the executable gives the expected o

[Bug c++/19808] miss a warning about uninitialized members in constructor

--- Comment #13 from manu at gcc dot gnu dot org 2010-02-24 20:14 --- (In reply to comment #9) > > I'd close this one as WONTFIX or mark it as dup of a "do uninitialized > variable warnings for memory". > Please no, this perhaps could still be implemented in the C++ front-end for this

[Bug target/35455] [4.3/4.4/4.5 Regression] h8300: internal compiler error: in compute_frame_pointer_to_fb_displacement, at dwarf2out.c:10984

--- Comment #6 from law at redhat dot com 2010-02-24 20:22 --- *** Bug 42138 has been marked as a duplicate of this bug. *** -- law at redhat dot com changed: What|Removed |Added -

[Bug debug/42138] ICE on h8300 target

--- Comment #1 from law at redhat dot com 2010-02-24 20:22 --- *** This bug has been marked as a duplicate of 35455 *** -- law at redhat dot com changed: What|Removed |Added

[Bug c++/19808] miss a warning about uninitialized members in constructor

--- Comment #14 from rguenth at gcc dot gnu dot org 2010-02-24 20:22 --- (In reply to comment #11) > (In reply to comment #8) > > What else could it be than a pointer? It might be possible to mark it > > somehow > > so that the middle end knows to consider the referent uninitialized.

[Bug target/35072] h8300: ICE unwind-dw2-fde.c:650: error: unrecognizable insn

--- Comment #3 from law at redhat dot com 2010-02-24 20:29 --- Should have been fixed by: 2008-02-20 DJ Delorie * config/h8300/h8300.md (insv): Force source operand to be a register. I have been able to build libstdc++-v3 with the trunk. -- law at redhat dot com changed:

[Bug c++/19808] miss a warning about uninitialized members in constructor

--- Comment #15 from manu at gcc dot gnu dot org 2010-02-24 20:30 --- (In reply to comment #12) > Is there nothing pointed by this that could be initialized before calling the > > constructor? > > Nothing. Then for sure someone can write a generic/gimple pass that detects this case bef

[Bug fortran/38319] Memory leaks in allocatable component expressions

--- Comment #2 from pault at gcc dot gnu dot org 2010-02-24 20:31 --- I have been having trouble in recent times detecting these memory leaks. Neither FC9 nor RHEL5.2 x86_64 seem to show them with valgrind. Since I know that others still see them, I wonder are there any ideas what I ha

[Bug target/15872] h8300-hms-g++ generates wrong machine code when initializing static members of class templates

--- Comment #5 from law at redhat dot com 2010-02-24 20:31 --- Just tried this with the trunk: .file "j.C" .section .text .align 1 .global _main _main: mov.w r6,@-r7 mov.w r7,r6 mov.w @__ZN3FooIiE6foovarE:16,r2 mov.

[Bug c++/19808] miss a warning about uninitialized members in constructor

--- Comment #16 from jason at gcc dot gnu dot org 2010-02-24 20:44 --- (In reply to comment #14) > > (In reply to comment #8) > > > Incidentally, perhaps we should mark the this parameter as __restrict... > > I don't see how this would be correct (or useful). Hmm, I suppose it is possi

[Bug c++/19808] miss a warning about uninitialized members in constructor

--- Comment #17 from jason at gcc dot gnu dot org 2010-02-24 20:45 --- (In reply to comment #15) > Alternatively, the C++ front-end could create an uninitialized variable for > each member variable. Initialize those, then, at the very end of the > constructor, assigned each clone variabl

[Bug target/21745] ICE during build of h8300 cross-compiler

--- Comment #2 from law at redhat dot com 2010-02-24 20:46 --- This was fixed in late 2004 when Alex Oliva integreated H8/SX support. Basically a peephole wasn't rejecting SP as a source operand for one particular case. I've recently built libstdc++-v3 for the H8 using the trunk source

[Bug target/38091] [Patch] H8SX: Bit instructions enhancement

--- Comment #8 from law at redhat dot com 2010-02-24 20:50 --- Just a note. I'm going to make the 4.6 pending patches depend on this bug. The patches from 2008-11-12 and Jan 2010 will need updating as it should no longer be necessary to reject REGs for insv/extv on the H8/SX. See PR

[Bug c++/43167] Warnings should not be disabled when instantiating templates defined in system headers

--- Comment #5 from ian at airs dot com 2010-02-24 20:56 --- The use of long long is irrelevant here. PR 30500 appears to be about non-dependent types. So let's make this bug be about dependent types. I know that makes it harder, but it seems to me to be the right thing to do. --

[Bug middle-end/42431] [4.5 Regression] wrong code for 200.sixtrack with vectorization and -fdata-sections

--- Comment #10 from meissner at linux dot vnet dot ibm dot com 2010-02-24 21:01 --- Subject: Re: [4.5 Regression] wrong code for 200.sixtrack with vectorization and -fdata-sections On Tue, Feb 23, 2010 at 09:57:17PM -, bergner at gcc dot gnu dot org wrote: > > > --- Commen

  1   2   >