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

--- Comment #3 from burnus at gcc dot gnu dot org 2010-02-25 07:38 --- Paul, can you try with valgrind --leak-check=full ? Without the =full option, I also do not get any line info output but just in the summary "definitely lost: 288 bytes in 4 blocks". -- http://gcc.gnu.org/bugzil

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

--- Comment #19 from bart dot vanassche at gmail dot com 2010-02-25 07:05 --- (In reply to comment #17) > (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 >

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

--- Comment #18 from bart dot vanassche at gmail dot com 2010-02-25 07:00 --- (In reply to comment #16) > (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 corr

[Bug fortran/43155] Reading real numbers of the form "123+ 44" (with space)

--- Comment #5 from jvdelisle at gcc dot gnu dot org 2010-02-25 05:52 --- SendingChangeLog Sendingio/transfer.c Transmitting file data .. Committed revision 157060. 2010-02-24 Jerry DeLisle * io/transfer.c (require_type): Subtract one from item_count for out

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

--- Comment #2 from bangerth at gmail dot com 2010-02-25 05:12 --- I don't think we should be doing this. GCC strives to be standards-conforming and the requested feature would purposefully make us violate the standard. There is a point for extensions, but I don't think changing the mea

[Bug middle-end/28752] bootstrap comparision fails with "-ftree-vectorize -maltivec" on ppc

--- Comment #36 from meissner at gcc dot gnu dot org 2010-02-25 04:59 --- I've tested the current GCC 4.5 development branch and it builds fine now with BOOT_CFLAGS='-g -O3 -ftree-vectorize -mcpu=power5 -maltivec'. It also builds with BOOT_CFLAGS='-g -O3 -ftree-vectorize -mcpu=power7'.

[Bug target/36827] [4.3/4.4/4.5 Regression] newlib:libm/math/k_rem_pio2.c fails in reload

--- Comment #21 from law at redhat dot com 2010-02-25 00:25 --- Fixed long ago. m32c is building newlib without difficulties now. -- law at redhat dot com changed: What|Removed |Added ---

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

--- Comment #13 from ian at airs dot com 2010-02-25 00:17 --- Paolo: It is definitely a complicated case, the concern about false positives is entirely valid. This leads us to introducing more command line options, plus getting #pragma GCC diagnostic to work. I'm not sure what the best

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

--- Comment #12 from manu at gcc dot gnu dot org 2010-02-24 23:20 --- (In reply to comment #11) > Note this is much better than what it was in 4.3 where std::vector was > shown as: > std::vector > > That part looks better GCC, however, in the context information, the clang output is far

[Bug debug/42911] [4.5 Regression] huge compile time with -g -O2

--- Comment #5 from jason at gcc dot gnu dot org 2010-02-24 23:14 --- Changing component to debug. -- jason at gcc dot gnu dot org changed: What|Removed |Added C

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

--- Comment #3 from dominiq at lps dot ens dot fr 2010-02-24 23:07 --- I have seen that also (the first time at revision 156585). In these cases I clean the directory and restart. Note that I used 'make -j3' on a Core2 Duo, but switching to '-j2' did not help. > libgomp should not be a

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

--- Comment #11 from pinskia at gcc dot gnu dot org 2010-02-24 23:00 --- Note this is much better than what it was in 4.3 where std::vector was shown as: std::vector > > -- pinskia at gcc dot gnu dot org changed: What|Removed |Added --

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

--- Comment #10 from pinskia at gcc dot gnu dot org 2010-02-24 22:56 --- looks like the terminial is wrapping funny. In file included from /home/apinski/local-gcc/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/numeric:62:0, from t.cc:2: /home/api

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

--- Comment #9 from manu at gcc dot gnu dot org 2010-02-24 22:52 --- (In reply to comment #7) > I don't know about icc, but see also http://llvm.org/PR6418 . Out of curiosity. Is it really the output of g++ so messy compared with clang, or is it an artifact of copy+paste from the consol

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

--- Comment #8 from paolo dot carlini at oracle dot com 2010-02-24 22:47 --- ICC doesn't warn (emits another spurious warning, by the way, which has nothing to do with this issue). More generally, compilers using the EDG front-end, eg, Comeau, apparently do not warn at the most strict d

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

--- Comment #7 from ian at airs dot com 2010-02-24 22:33 --- I don't know about icc, but see also http://llvm.org/PR6418 . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167

[Bug other/42980] GCC parallel "make install" failures

--- Comment #10 from rwild at gcc dot gnu dot org 2010-02-24 22:22 --- Created an attachment (id=19955) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19955&action=view) Changes proposed for automake-generated files (pending upstream fix) This patch is just a diff against files gen

[Bug other/42980] GCC parallel "make install" failures

--- Comment #9 from rwild at gcc dot gnu dot org 2010-02-24 22:18 --- Created an attachment (id=19954) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19954&action=view) Fix parallel libiberty install failure This patch should fix the bulk of the failures, and is hopefully simple en

[Bug other/42980] GCC parallel "make install" failures

--- Comment #8 from rwild at gcc dot gnu dot org 2010-02-24 22:17 --- Created an attachment (id=19953) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19953&action=view) properly propagate (parallel) make flags in libgcc install rule -- http://gcc.gnu.org/bugzilla/show_bug.cgi?i

[Bug other/42980] GCC parallel "make install" failures

--- Comment #7 from rwild at gcc dot gnu dot org 2010-02-24 22:15 --- Thank you very much for the logs, and the note that install-target-libiberty alone wasn't sufficient to provoke a race, that provided the needed clue. Please try the following three patches (split up because they're l

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

--- Comment #11 from bergner at vnet dot ibm dot com 2010-02-24 22:08 --- Subject: Re: [4.5 Regression] wrong code for 200.sixtrack with vectorization and -fdata-sections On Wed, 2010-02-24 at 21:01 +, meissner at linux dot vnet dot ibm dot com wrote: > > --- Comment #10 fro

[Bug other/43171] build: target modules Makefiles have broken rebuild rules (multilib issue)

-- rwild at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priori

[Bug other/43171] New: build: target modules Makefiles have broken rebuild rules (multilib issue)

This PR mainly exists as a reminder for myself, I have been bitten by this a couple of times while testing an unrelated patch and getting stumped by apparent major breakage. Inside the build tree, for each $module and $MULTIDIR, the files $target/$module/Makefile and probably also $target/$MULTIDI

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

--- Comment #2 from hal at oz dot net 2010-02-24 22:06 --- The only configure option was --enable-languages=c,c++,fortran. The configure and build were done in a clean, empty directory. Make was invoked with "make -j4". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170

[Bug target/25113] [m68k] lshiftrt and some other insns are conservative on cc0

--- Comment #2 from law at redhat dot com 2010-02-24 22:02 --- This was fixed by the cond-optab merge. The redundant tst instruction is no longer generated. -- law at redhat dot com changed: What|Removed |Added

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-24 21:55 --- Did you build in a clean directory? How did you configure GCC and how did you invoke make? libgomp should not be a target library in stage2 anyways. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170

[Bug target/37905] m68k coldfire uses bad mode when extending to long long

--- Comment #3 from law at redhat dot com 2010-02-24 21:54 --- Fixed by: 2008-11-25 Maxim Kuvyrkov * config/m68k/m68k.md (extendsidi2, extendsidi2_mem): Merge, clean up. Disable unsupported alternative for ColdFire, add new alternative that ColdFire can handl

[Bug bootstrap/43170] New: gcc 4.5 20100218 bootstrap compare fails on os x 10.6

The gcc 4.5 20100218 snapshot bootstrap fails when built on os x 10.6 with the current Apple build tools. The problem is still present at svn revision 157053: $ svn info Path: . URL: svn://gcc.gnu.org/svn/gcc/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961

[Bug target/26415] [4.3/4.4/4.5 regression] m68k-linux bootstrap error during stage2

--- Comment #18 from law at redhat dot com 2010-02-24 21:49 --- Fixed by: 2007-09-18 Roman Zippel * config/m68k/m68k.md (beq, bne, bgt, blt, bge, ble, bordered, bunordered, buneq, bunge, bungt, bunle, bunlt, bltgt, beq_rev, bne_rev, bgt_rev, blt_rev, bge_rev, b

[Bug c/42557] gcc no compile for m68k(coff/elf)

--- Comment #5 from law at redhat dot com 2010-02-24 21:45 --- 1. m68k-coff support was removed from gas and isn't realistically supported by GCC anymore either. 2. In-tree builds haven't been supported for ages -- law at redhat dot com changed: What|Removed

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

--- Comment #6 from paolo dot carlini at oracle dot com 2010-02-24 21:43 --- Out of curiosity: what happens with ICC? (normally installed with the system libstdc++ as C++ run-time)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167

[Bug target/35018] [m68k-elf] Gcc ouputs invalid asm when compiling with -O2 or higher

--- Comment #8 from law at redhat dot com 2010-02-24 21:40 --- Fixed long ago. Holding it open because the patch wasnt' backported to an old branch is rather silly. -- law at redhat dot com changed: What|Removed |Added --

[Bug rtl-optimization/9240] weird scheduling on v850 unless -fno-sched-spec specified

--- Comment #8 from law at redhat dot com 2010-02-24 21:20 --- This was fixed at some point; I don't know if it was the patch referenced in comment #6, or some other patch or some combination thereof. You can see that probabilities are being propagated down through to the scheduler by l

[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

[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 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 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 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 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 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 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 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 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 #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 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 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 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 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 #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 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 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 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 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

-- 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++/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 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 #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 #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] 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++/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 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 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 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 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 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 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 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 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 #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 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 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 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 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 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 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 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] 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 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 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 #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 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 #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 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 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 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/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 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/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 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 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/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 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 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] 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 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] 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 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 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 #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 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

  1   2   >