https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82359
Aaron Ballman changed:
What|Removed |Added
CC||aaron at aaronballman dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101209
Bug ID: 101209
Summary: ICE with trailing return type on a conversion operator
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101209
--- Comment #1 from Aaron Ballman ---
> This should likely give an error about using a trailing return type for a
> function with a declared return type other than a placeholder type.
Err, that would be bad now that I think about it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102753
Bug ID: 102753
Summary: ICE on invalid use of pointer to a consteval member
function
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
--- Comment #5 from Aaron Ballman ---
(In reply to Marek Polacek from comment #4)
> But elaborated-enum-specifier is an elaborated-type-specifier, so
> [dcl.type.elab]#6 should still apply, right?
That is my understanding. Otherwise p6 doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
--- Comment #8 from Aaron Ballman ---
(In reply to M Welinder from comment #6)
> elaborated-enum-specifier can be a elaborated-type-specifier. It is in the
> "enum Hog H;" case.
>
> But elaborated-enum-specifier is NOT an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
Bug ID: 103084
Summary: Accepts invalid using enum declaration with an invalid
elaborated-type-specifier
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104187
Aaron Ballman changed:
What|Removed |Added
CC||aaron at aaronballman dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104765
--- Comment #6 from Aaron Ballman ---
(In reply to Marek Polacek from comment #4)
> My preference: prohibit any use of ({}) in default arguments.
That's my preference as well assuming it doesn't break a significant amount of
code (which I have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104765
Aaron Ballman changed:
What|Removed |Added
CC||aaron at aaronballman dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #13 from Aaron Ballman ---
Just to circle back around on this topic, these are changes recently landed in
Clang:
https://github.com/llvm/llvm-project/commit/84a3aadf0f2483dde0acfc4e79f2a075a5f35bd1
It enables the -Wvla-extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #17 from Aaron Ballman ---
(In reply to Martin Uecker from comment #16)
> I do not think -Wall should warn about GNU extensions when used with
> -std=gnu++XX in C++ and I think it is annoying that clang does it now. It
> only drives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #19 from Aaron Ballman ---
(In reply to Andrew Pinski from comment #18)
> (In reply to Aaron Ballman from comment #17)
> > In the time I opened this request, a new CVE related to VLAs came out:
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105824
Bug ID: 105824
Summary: Accepts invalid issue with implicit conversion of a
scoped enumeration type
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107980
--- Comment #9 from Aaron Ballman ---
Btw, a similar issue in this area is that GCC no longer diagnoses when the user
passes a second argument to va_start in C2x mode and the argument is not the
parameter before the ellipsis. e.g.,
```
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107980
--- Comment #11 from Aaron Ballman ---
(In reply to Jakub Jelinek from comment #10)
> That again is completely valid in C2X.
Yes, it is. And again, it's still something worth diagnosing (IMO) because it's
utter nonsense code that is invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107980
--- Comment #16 from Aaron Ballman ---
(In reply to Andrew Pinski from comment #15)
> (In reply to Aaron Ballman from comment #14)
> > Also, it was a potentially silently breaking change (if you don't mind
> > horribly contrived examples of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107980
--- Comment #8 from Aaron Ballman ---
(Sorry, I meant __VA_ARGS__ and not __VA_OPT__; C23 on the brain!)
(In reply to Andrew Pinski from comment #6)
> Maybe add a _Static_warn builtin instead which is like _Static_assert but
> instead of an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107980
--- Comment #5 from Aaron Ballman ---
(In reply to Andrew Pinski from comment #3)
> I think we should warn but how to warn is going to have to special case the
> macro I think.
I was contemplating a perhaps terrible idea of adding some new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107980
Bug ID: 107980
Summary: va_start incorrectly accepts an arbitrary number of
arguments in C2x
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107980
--- Comment #2 from Aaron Ballman ---
(In reply to Andrew Pinski from comment #1)
> Hmm from https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3054.pdf :
> ```
> 7.16.1.4 The va_start macro
> void va_start(va_list ap, ...);
>
>
> Any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107980
--- Comment #14 from Aaron Ballman ---
(In reply to jos...@codesourcery.com from comment #12)
> The standard rule about not using extra arguments means that any warnings
> would need to avoid even converting those arguments from pp-tokens to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86369
Aaron Ballman changed:
What|Removed |Added
CC||aaron at aaronballman dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86369
--- Comment #11 from Aaron Ballman ---
(In reply to Jakub Jelinek from comment #10)
> (In reply to Aaron Ballman from comment #9)
> > Doesn't [expr.eq] make it unspecified though?
>
> Will defer that answer to Jason.
> But please have a look at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108796
Aaron Ballman changed:
What|Removed |Added
CC||aaron at aaronballman dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108796
--- Comment #9 from Aaron Ballman ---
> GNU attributes are declaration specifiers *in the previous examples given
> here*, not necessarily in all other cases.
Thanks for clarifying!
> (There is then logic in GCC to handle __attribute__ that,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108796
--- Comment #10 from Aaron Ballman ---
One other reason for the Clang behavior that may be worth mentioning is that
this helps users who wish to migrate away from `__attribute__` and towards
`[[]]`. Many (most?) uses of attributes end up behind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108694
--- Comment #3 from Aaron Ballman ---
(In reply to Bruno Haible from comment #2)
> But '-Wdeprecated-non-prototype' does not exactly have the behaviour you
> want: while it warns for 'func1 (1);' and 'func3 (3);' (good!), it warns
> also for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #10 from Aaron Ballman ---
(In reply to Jonathan Wakely from comment #9)
> Personally I'd like it diagnosed in GNU modes, but this is pretty much the
> poster child for "conforming extension diagnosed with -pedantic" so I can
> see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #3 from Aaron Ballman ---
(In reply to Andrew Pinski from comment #1)
> Since VLA support has been a GNU C++ extension way before it was proposed to
> WG21, I doubt we want to enable this by default.
I think it boils down to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
Bug ID: 110848
Summary: Consider enabling -Wvla by default in C++ modes
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #6 from Aaron Ballman ---
(In reply to Andrew Pinski from comment #4)
> Maybe my issue is this has been a documented extension for 20 years now.
Which is totally fair -- we don't usually enable congratulatory diagnostics by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110977
Bug ID: 110977
Summary: Should -fms-extensions define _MSC_EXTENSIONS?
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110977
--- Comment #2 from Aaron Ballman ---
(In reply to Andrew Pinski from comment #1)
> I don't think GCC has all of MSVC extensions implemented so defining that
> might break code
Clang doesn't either, FWIW. But the point is well-taken; code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #12 from Aaron Ballman ---
(In reply to Eric Gallager from comment #11)
> How about:
>
> -std=c++XY: enabled by default (as per the proposal)
> -std=gnu++XY: enabled by -Wall and/or -Wextra (in addition to being enabled
> by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #8 from Aaron Ballman ---
(In reply to Richard Biener from comment #7)
> I think -std=c++XY should diagnose (at least with a warning) the use of GNU
> extensions. Let me alter the summary and confirm.
Thanks! I still think this
36 matches
Mail list logo
