otto@lonkero:~/code$ gcc bug.c -Wall bug.c: In function ‘main’: bug.c:5: error: void value not ignored as it ought to be bug.c:5: error: void value not ignored as it ought to be bug.c:5: confused by earlier errors, bailing out Preprocessed source stored into /tmp/ccoFNCjw.out file, please attach this to your bugreport. otto@lonkero:~/code$ cat /tmp/ccoFNCjw.out // /usr/lib/gcc/i486-linux-gnu/4.4.1/cc1 -quiet bug.c -D_FORTIFY_SOURCE=2 -quiet -dumpbase bug.c -mtune=generic -march=i486 -auxbase bug -Wall -fstack-protector -o - -frandom-seed=0 # 1 "bug.c" # 1 "<built-in>" # 1 "<command-line>" # 1 "bug.c" int main(void) { int a=1; if((a==1) ? (void) (0) : 1); return 0; }
Confirmed. ./cc1 -quiet t.c t.c: In function 'main': t.c:5:3: error: void value not ignored as it ought to be t.c:5:3: error: void value not ignored as it ought to be t.c:5:5: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in get_narrower, at tree.c:7832 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions.
Should be easy, this one. I like easy.
I see no reason to cgraph_finalize_compilation_unit if there were parse errors. Richi, what do you think? Index: toplev.c =================================================================== --- toplev.c (revision 167996) +++ toplev.c (working copy) @@ -582,7 +582,12 @@ what's left of the symbol table output. */ timevar_pop (TV_PARSE); - if (flag_syntax_only || flag_wpa) + /* If all we have to do is syntax checking, or if there were parse + errors, stop here. */ + if (flag_syntax_only || seen_error) + return; + + if (flag_wpa) return; ggc_protect_identifiers = false; @@ -590,9 +595,6 @@ /* This must also call cgraph_finalize_compilation_unit. */ lang_hooks.decls.final_write_globals (); - if (seen_error ()) - return; - varpool_assemble_pending_decls (); finish_aliases_2 ();
On Fri, 17 Dec 2010, steven at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44982 > > Steven Bosscher <steven at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |rguenth at gcc dot gnu.org > > --- Comment #3 from Steven Bosscher <steven at gcc dot gnu.org> 2010-12-17 21:26:45 UTC --- > I see no reason to cgraph_finalize_compilation_unit if there were parse errors. > Richi, what do you think? I think the idea was we want to preserve warnings and errors we generate from the middle-end. But the patch looks sensible to me anyway, maybe post it up for disscussion, as it would affect all frontends. Richard. > > Index: toplev.c > =================================================================== > --- toplev.c (revision 167996) > +++ toplev.c (working copy) > @@ -582,7 +582,12 @@ > what's left of the symbol table output. */ > timevar_pop (TV_PARSE); > > - if (flag_syntax_only || flag_wpa) > + /* If all we have to do is syntax checking, or if there were parse > + errors, stop here. */ > + if (flag_syntax_only || seen_error) > + return; > + > + if (flag_wpa) > return; > > ggc_protect_identifiers = false; > @@ -590,9 +595,6 @@ > /* This must also call cgraph_finalize_compilation_unit. */ > lang_hooks.decls.final_write_globals (); > > - if (seen_error ()) > - return; > - > varpool_assemble_pending_decls (); > finish_aliases_2 (); > >
4.3 branch is being closed, moving to 4.4.7 target.
4.4 branch is being closed, moving to 4.5.4 target.
GCC 4.6.4 has been released and the branch has been closed.
The 4.7 branch is being closed, moving target milestone to 4.8.4.
GCC 4.8.4 has been released.
(In reply to Richard Biener from comment #1) > Confirmed. hm, wfm, but it looks like the patch in comment 3 wasn't applied. Is there something to do here?
On Thu, 15 Jan 2015, tbsaunde at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44982 > > tbsaunde at gcc dot gnu.org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |tbsaunde at gcc dot gnu.org > > --- Comment #10 from tbsaunde at gcc dot gnu.org --- > (In reply to Richard Biener from comment #1) > > Confirmed. > > hm, wfm, but it looks like the patch in comment 3 wasn't applied. Is there > something to do here? Not sure if it was posted or tested - so maybe just do a bootstrap & regtest with all languages and if that succeeds the patch (with the testcase) is preapproved.
(In reply to rguenther@suse.de from comment #11) > On Thu, 15 Jan 2015, tbsaunde at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44982 > > > > tbsaunde at gcc dot gnu.org changed: > > > > What |Removed |Added > > ---------------------------------------------------------------------------- > > CC| |tbsaunde at gcc dot gnu.org > > > > --- Comment #10 from tbsaunde at gcc dot gnu.org --- > > (In reply to Richard Biener from comment #1) > > > Confirmed. > > > > hm, wfm, but it looks like the patch in comment 3 wasn't applied. Is there > > something to do here? > > Not sure if it was posted or tested - so maybe just do a bootstrap & > regtest with all languages and if that succeeds the patch (with the > testcase) is preapproved. there is at least a large number of c++ test cases that fail with the patch. They all seem to be what you'd expect a file has errors before the new check, and more errors or warnings are expected to be emitted after the new check. It seems like some part of this setup is crazy, but I'm not really sure what to do about it at this point.
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.
GCC 4.9.3 has been released.
This was fixed a long time ago.