http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239
--- Comment #12 from etherice ---
(In reply to Jonathan Wakely from comment #11)
> (In reply to etherice from comment #10)
> > Isn't it defeating the purpose of having a 'status' field if it's not being
> > used?
>
> What makes you think it isn't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239
--- Comment #10 from etherice ---
(In reply to Paolo Carlini from comment #9)
> By the way, much more generally, I'm under the impression that often bug
> submitters attach way too much importance to the status change unconfirmed
> -> confirmed: I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239
--- Comment #8 from etherice ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to etherice from comment #6)
> > 2) My example was complete except for needing a couple #includes [...]
>
> So it was not complete then!
>
> This bug has
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239
--- Comment #6 from etherice ---
(In reply to Jonathan Wakely from comment #4)
> Until someone analyses it and convinces themselves it's a bug.
>
> Not providing a complete testcase doesn't help. Code missing headers, even
> standard ones, is not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239
--- Comment #3 from etherice ---
Status is still unconfirmed... How long does it typically take to confirm a
bug?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57242
--- Comment #6 from etherice ---
(In reply to Richard Biener from comment #5)
> (In reply to etherice from comment #4)
> > (In reply to Andrew Pinski from comment #1)
> > > This is by design as -g changes the information produced by the front-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239
--- Comment #2 from etherice ---
(In reply to Daniel Krügler from comment #1)
> The report misses a complete example. The following is a reduced form and
> free of library stuff:
>
> //---
> ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57242
--- Comment #4 from etherice ---
(In reply to Andrew Pinski from comment #1)
> This is by design as -g changes the information produced by the front-end
> and maybe even predefines too.
I created a simpler test to demonstrate the bug. Two files:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57240
--- Comment #2 from etherice ---
(In reply to Paolo Carlini from comment #1)
> Already fixed.
>
> *** This bug has been marked as a duplicate of bug 57092 ***
Yep that's it, fixed 3 days after my April 27 version of the 4.8 branch. Looks
like th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57241
--- Comment #3 from etherice ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Paolo Carlini from comment #1)
> > In general, it's safe to say that #pragma diagnostic ignored is very buggy
> > (in C++ at least), we have got many long
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57242
--- Comment #3 from etherice ---
(In reply to Andrew Pinski from comment #1)
> This is by design as -g changes the information produced by the front-end
> and maybe even predefines too.
I think you may have read the report too quickly :)
When bu
tatus: UNCONFIRMED
Severity: normal
Priority: P3
Component: pch
Assignee: unassigned at gcc dot gnu.org
Reporter: scottbaldwin at gmail dot com
In GCC 4.7.2 and 4.8.x, precompiled headers (PCH) .gch file is ignored unless a
certain combination of '
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: scottbaldwin at gmail dot com
In GCC 4.7.2 and 4.8.x, the #pragma ignore directive for -Wmultichar has no
effect. The code below demonstrates a -Wmultichar
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: scottbaldwin at gmail dot com
GCC 4.8.x (4.8.0 and 4.8.1-20130427) have an "internal compiler error" when
decltype()'s argument is a template non-type
Version: 4.8.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: scottbaldwin at gmail dot com
GCC 4.7.2 and 4.8.x cannot handle inner/nested class templates with non-type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32204
--- Comment #10 from etherice 2012-10-27
13:39:05 UTC ---
(In reply to comment #9)
Jonathan- You're right on all counts. Thanks for clarifying (and apologies for
getting a bit off-topic).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32204
--- Comment #8 from etherice 2012-10-27
08:52:10 UTC ---
In MSVC's defense, the standard is vague (or insufficient) in this regard for
'friend class' declarations. It says:
"If a friend declaration appears in a local class (9.8) and the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32204
etherice changed:
What|Removed |Added
CC||scottbaldwin at gmail dot
18 matches
Mail list logo
