https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35968
--- Comment #13 from Anders Kaseorg ---
(In reply to Patrick J. LoPresti from comment #12)
> I am familiar with the usual algorithmic complexity definitions.
>
> So, just to be clear... Your assertion is that the C++ standards committee
> adopte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35968
Anders Kaseorg changed:
What|Removed |Added
CC||andersk at mit dot edu
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79301
--- Comment #5 from Anders Kaseorg ---
(In reply to Jakub Jelinek from comment #4)
> (In reply to Anders Kaseorg from comment #3)
> > (In reply to Jakub Jelinek from comment #2)
> > > I think right now you need to use
> > > #ifdef __has_cpp_attri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79301
--- Comment #3 from Anders Kaseorg ---
(In reply to Jakub Jelinek from comment #2)
> I think right now you need to use
> #ifdef __has_cpp_attribute
> # if __has_cpp_attribute(fallthrough) >= __cplusplus
> [[fallthrough]];
Surely you intended
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andersk at mit dot edu
Target Milestone: ---
One would expect code like this to silence the new -Wimplicit-fallthrough
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65307
Anders Kaseorg changed:
What|Removed |Added
CC||andersk at mit dot edu
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61964
--- Comment #17 from Anders Kaseorg ---
Thanks. I verified that GCC 4.8 r213405 fixes my test case and the original
Kerberos problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61964
--- Comment #4 from Anders Kaseorg ---
Another bisect between 4.7 and 4.8 shows that the bug appeared with r189321
(bug 52009).
My test case has triggers the bug in more versions than Kerberos does: as far
as I can tell, Kerberos was unaffected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61964
--- Comment #3 from Anders Kaseorg ---
(In reply to Richard Biener from comment #1)
> The testcase is violating strict-aliasing rules as you access a struct head
> as struct node here:
Agree with ghudson here: n->prev points to &heads[2], not &h
Severity: major
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: andersk at mit dot edu
Kerberos is miscompiled by gcc-4.8. The impact is detailed at
https://bugs.launchpad.net/bugs/1347147, but here is a reduced test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56137
Bug #: 56137
Summary: std::initializer_list accepts invalid designated
initializers
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47901
--- Comment #7 from Anders Kaseorg 2012-04-23 21:31:18
UTC ---
That’s a _much_ higher-level style decision than assumed by any of the other
-Wall warnings (or indeed any other warning switches at all), and a
questionable one at that. -Wall shoul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47901
--- Comment #5 from Anders Kaseorg 2012-04-23 20:22:20
UTC ---
I’m not sure ("%s", "") is a suitable replacement in general. Maybe this is a
far-fetched example, but what the purpose of custom_printf is to shell-quote
all its arguments, so that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47901
--- Comment #4 from Anders Kaseorg 2012-04-23 20:10:22
UTC ---
Yes, I understand what -Wall is supposed to mean.
I don’t have a problem with -Wall warning about ‘if (foo = 3)’ when I probably
intended ‘if (foo == 3)’ and I could have written ‘if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50093
Anders Kaseorg changed:
What|Removed |Added
Known to work||4.5.3
Known to fail|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50093
Bug #: 50093
Summary: [4.6 Regression] STL containers of
non-default-constructible classes fail under
-std=c++0x
Classification: Unclassified
Product: gcc
Ver
16 matches
Mail list logo
