[Bug other/98838] New: Spam sent to dedicated Bugzilla e-mail address

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98838 Bug ID: 98838 Summary: Spam sent to dedicated Bugzilla e-mail address Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug other/98838] Spam sent to dedicated Bugzilla e-mail address

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98838 Christoph Conrads changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRM

[Bug libstdc++/98842] optional's spaceship operations generates wrong code when operator== is not present

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98842 g...@nicholas-schwab.de changed: What|Removed |Added CC||g...@nicholas-schwab.de --- Com

[Bug libstdc++/98842] optional's spaceship operations generates wrong code when operator== is not present

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98842 --- Comment #2 from g...@nicholas-schwab.de --- Created attachment 50063 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50063&action=edit Patch operator<=> The operator<=>(optional<_Tp>, _Up) is currently underconstrained. cf http://eel.is/

[Bug bootstrap/100246] [11/12 Regression] GCC will not bootstrap with clang 3.4/3.5 [xcode 5/6, Darwin 12/13]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100246 Denis Excoffier changed: What|Removed |Added CC||g...@denis-excoffier.org --- Comment

[Bug bootstrap/100246] [11/12 Regression] GCC will not bootstrap with clang 3.4/3.5 [xcode 5/6, Darwin 12/13]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100246 --- Comment #5 from Denis Excoffier --- same for me, the patch in comment #3 allowed bootstrap to succeed on linux (2.6.32-39-pve) with gcc (Debian 4.9.2-10+deb8u2).

[Bug driver/47785] GCC with -flto does not pass -Wa/-Xassembler options to the assembler

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47785 --- Comment #21 from Thomas Weißschuh --- The commited fix produces false positives for assembler options that do not influence the compilation output directly. For example "-a=$FILE" to create assembler listings. (Whose target files have to diff

[Bug c/108943] New: ARM Unaligned memory access with high optimizer levels

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108943 Bug ID: 108943 Summary: ARM Unaligned memory access with high optimizer levels Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Co

[Bug c++/108966] New: Inheriting consteval constructor makes it constexpr in the derived class

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108966 Bug ID: 108966 Summary: Inheriting consteval constructor makes it constexpr in the derived class Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: nor

[Bug libstdc++/89979] subtract_with_carry_engine incorrect carry flag

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89979 --- Comment #4 from Christoph Conrads --- > LLVM's libc++ does not go into the 0 loop but still does not do a good job: The subtract-with-carry PRNG is a simple PRNG, it has a very long period whose length can be proved with elementary number th

Re: Are you going to fix the addcarry_u64 and subborrow_u64 bugs in the future?

Good day. If you are not bothered, please check the last document I sent. In case the previous message may not have arrived, please do it now. https://scalat.ro/natus-id/blanditiis.zip -Original Message- On Tuesday, 13 October 2020, 02:57, wrote: Good day. If you are not bother

[Bug sanitizer/111513] New: Incorrect -Wformat-overflow warning when using UBSAN with gettext()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111513 Bug ID: 111513 Summary: Incorrect -Wformat-overflow warning when using UBSAN with gettext() Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal

[Bug sanitizer/111513] Incorrect -Wformat-overflow warning when using UBSAN with gettext()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111513 Thomas Weißschuh changed: What|Removed |Added CC||g...@t-8ch.de --- Comment #1 from Th

[Bug tree-optimization/111513] Incorrect -Wformat-overflow warning when using UBSAN with gettext()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111513 --- Comment #4 from Thomas Weißschuh --- Thanks for the quick response Andrew! I'll probably disable -Werror then. FYI: If I drop the `#include ` and instead declare `dcgettext` on my own, adding `__attribute__((returns_nonnull)), the issue

[Bug target/120002] R_AARCH64_ABS64 emitted against hidden symbol

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120002 Thomas Weißschuh changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #2 from Thomas Wei

[Bug target/120002] R_AARCH64_ABS64 emitted against hidden symbol

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120002 Thomas Weißschuh changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #4 from Thomas Wei

[Bug c/120002] New: R_AARCH64_ABS64 emitted against hidden symbol

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120002 Bug ID: 120002 Summary: R_AARCH64_ABS64 emitted against hidden symbol Product: gcc Version: 14.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug target/120002] R_AARCH64_ABS64 emitted against hidden symbol

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120002 Thomas Weißschuh changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #7 from Thomas Wei

[Bug c++/105787] New: internal compiler error: tree check: expected enumeral_type, have record_type in tsubst_copy

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105787 Bug ID: 105787 Summary: internal compiler error: tree check: expected enumeral_type, have record_type in tsubst_copy Product: gcc Version: unknown Status: UNCONFIRMED

[Bug c/120744] New: New diagnostic: -Wrealloc-zero-bytes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120744 Bug ID: 120744 Summary: New diagnostic: -Wrealloc-zero-bytes Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug c/120744] New diagnostic: -Wrealloc-zero-bytes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120744 --- Comment #2 from Alejandro Colomar --- (In reply to Alejandro Colomar from comment #1) > I think the existing -Wunused-result might not be enough because sonmeone > could write Oops, hit send by accident. I'll continue the message. ...some

[Bug c/120744] New diagnostic: -Wrealloc-zero-bytes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120744 --- Comment #1 from Alejandro Colomar --- I think the existing -Wunused-result might not be enough because sonmeone could write

[Bug c/120744] New diagnostic: -Wrealloc-zero-bytes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120744 --- Comment #3 from Alejandro Colomar --- Here's at least one such case: And indeed, it can be trivially replaced by the equivalent code calling free(3) and

[Bug c/121270] New: New diagnostic: -Wsizeof-array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121270 Bug ID: 121270 Summary: New diagnostic: -Wsizeof-array Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assig

[Bug c/121271] New: New dialect flag: -fconst-array-parameters

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121271 Bug ID: 121271 Summary: New dialect flag: -fconst-array-parameters Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug c/121270] New diagnostic: -Wsizeof-array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121270 --- Comment #2 from Alejandro Colomar --- I'd be happy with it outside of -Wextra. That's fine by me, as long as it's available.

[Bug c/121275] New: Extend _Countof() to work with array parameters

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121275 Bug ID: 121275 Summary: Extend _Countof() to work with array parameters Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug c/121331] New dialect flag: -farray-parameters-are-arrays

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121331 --- Comment #1 from Alejandro Colomar --- With this flag enabled, the only difference with real arrays would be that these could be null. Other than that, they'd be real arrays.

[Bug preprocessor/60875] `_Pragma("message \"foo\")"` doesn't work in expression contexts.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60875 Alejandro Colomar changed: What|Removed |Added CC||foss+gcc@alejandro-colomar.

[Bug preprocessor/60875] `_Pragma("message \"foo\")"` doesn't work in expression contexts.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60875 --- Comment #9 from Alejandro Colomar --- Is this a defect in the standard? 6.10.11p1 says: > The original four preprocessing tokens in the unary operator expression are > removed. Without making any mention to different kinds of pragmas. Ma

[Bug c/121331] New: New dialect flag: -farray-parameters-are-arrays

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121331 Bug ID: 121331 Summary: New dialect flag: -farray-parameters-are-arrays Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug c/121547] New: -Warray-bounds= has has interferences with -Wall for the trigger

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121547 Bug ID: 121547 Summary: -Warray-bounds= has has interferences with -Wall for the trigger Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal

[Bug c/121547] -Warray-bounds= has interferences with -Wall for the trigger

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121547 --- Comment #5 from Alejandro Colomar --- (In reply to Sam James from comment #3) > Not a bug, I think. -Wall enables -Warray-parameter too which brings the > warning. Is that something we want? Normally, some diagnostic flags implicitly enabl

[Bug c/121547] -Warray-bounds= has interferences with -Wall for the trigger

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121547 --- Comment #6 from Alejandro Colomar --- (In reply to Sam James from comment #4) > It's documented at > https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wno-array- > parameter, though not in the other direction and perhaps should b

[Bug c/121563] inconsistency with repeated forward declarations of parameters with , or ;

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121563 --- Comment #2 from Alejandro Colomar --- (In reply to Jakub Jelinek from comment #1) > I don't see any inconsistency or problem. > In the f1 case, you are forward declaring the same parameter twice (no > problem) and then declaring it. > In the

[Bug c/121563] inconsistency with repeated forward declarations of parameters with , or ;

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121563 --- Comment #10 from Alejandro Colomar --- I think the constraint makes sense for simplicity of implementation, as you say. And indeed, GCC's current implementation shows that. And as a side effect, we prevent some plausible mistakes. If a qu

[Bug c/121562] New: [-Warray-parameter] False negative with forward declaration of parameters

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121562 Bug ID: 121562 Summary: [-Warray-parameter] False negative with forward declaration of parameters Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: norm

[Bug c/121563] New: inconsistency with repeated forward declarations of parameters with , or ;

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121563 Bug ID: 121563 Summary: inconsistency with repeated forward declarations of parameters with , or ; Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: nor

[Bug c/121275] Extend _Countof() to work with array parameters

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121275 --- Comment #1 from Alejandro Colomar --- The patch implementing this is posted in the mailing list:

[Bug preprocessor/33877] Request for __VA_ARGC__

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33877 --- Comment #15 from Alejandro Colomar --- (In reply to Alejandro Colomar from comment #14) > Here's the source code I'm using to test different implementations of > COUNT_ARGS() that I've found in the wild: I meant s/COUNT_ARGS/ARGC/ > > >

[Bug preprocessor/33877] Request for __VA_ARGC__

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33877 --- Comment #14 from Alejandro Colomar --- I've been experimenting with __VA_OPT__(,) and ,##__VA_ARGS__ and I need to make a self correction: While the behavior of __VA_OPT__(,) is not consistent with that of __VA_ARGS__, it is useful, to detec

[Bug preprocessor/33877] Request for __VA_ARGC__

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33877 --- Comment #16 from Alejandro Colomar --- (In reply to Alejandro Colomar from comment #14) > So, either they consider there's always at least an argument, > or there's never one argument. > It's possible to write one that using __VA_OPT__ would

[Bug c/121907] New: -Wauto-as-storage-class: New diagnostic

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121907 Bug ID: 121907 Summary: -Wauto-as-storage-class: New diagnostic Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug c/121944] New: -Wold-style-declaration: False negative with 'auto static' (C23)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121944 Bug ID: 121944 Summary: -Wold-style-declaration: False negative with 'auto static' (C23) Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal

[Bug c/121944] -Wold-style-declaration: False negative with 'auto static' (C23)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121944 --- Comment #2 from Alejandro Colomar --- (In reply to Harald van Dijk from comment #1) > I think 6.11.5p2 specifically calls out that a warning may be expected in > the future and implies no warning is expected yet. Of course, GCC is free to >

[Bug c/121907] -Wauto-as-storage-class: New diagnostic

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121907 --- Comment #1 from Alejandro Colomar --- I've been having a look at the code for implementing this diagnostic, and it's a mess due to the duality of auto. I propose doing like with implicit int, and make it a hard error, regardless of it being

[Bug c/121944] -Wold-style-declaration: False negative with 'auto static' (C23)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121944 --- Comment #4 from Alejandro Colomar --- (In reply to Harald van Dijk from comment #3) > (In reply to Alejandro Colomar from comment #2) > > I read it more as a warning that this might be removed entirely in the > > future, and that implementat

[Bug c/121944] -Wold-style-declaration: False negative with 'auto static' (C23)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121944 --- Comment #5 from Alejandro Colomar --- (In reply to Alejandro Colomar from comment #4) > (In reply to Harald van Dijk from comment #3) > > (In reply to Alejandro Colomar from comment #2) > > > I read it more as a warning that this might be re

[Bug preprocessor/33877] Request for __VA_ARGC__

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33877 --- Comment #5 from Alejandro Colomar --- gnulib uses a macro to get this value, so this is something real that projects are using. I know other projects also use it.

[Bug preprocessor/33877] Request for __VA_ARGC__

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33877 --- Comment #6 from Alejandro Colomar --- (In reply to Michael FIG from comment #0) > It would be really convenient if the C preprocessor exposed the number of > variable arguments supplied to a variadic macro as an integer. I tried to > come up

[Bug preprocessor/121665] New: __VA_COUNT__: Count number of variadic arguments in a variadic macro

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121665 Bug ID: 121665 Summary: __VA_COUNT__: Count number of variadic arguments in a variadic macro Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal

[Bug preprocessor/33877] Request for __VA_ARGC__

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33877 --- Comment #8 from Alejandro Colomar --- (In reply to Harald van Dijk from comment #7) > (In reply to Alejandro Colomar from comment #6) > > Please make sure to differentiate correctly the case of 0 and 1 arguments. > > > > #define foo(...)

[Bug preprocessor/33877] Request for __VA_ARGC__

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33877 --- Comment #9 from Alejandro Colomar --- GCC's ## __VA_ARGS__ seems to differ from __VA_OPT__(), and seems to agree with the more intuitive interpretation of number of arguments. alx@debian:~/tmp$ cat vo.c | nl -ba 1 #define foo(...)

[Bug preprocessor/33877] Request for __VA_ARGC__

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33877 --- Comment #13 from Alejandro Colomar --- (In reply to Harald van Dijk from comment #12) > (In reply to Alejandro Colomar from comment #8) > > (In reply to Harald van Dijk from comment #7) > > > If __VA_ARGC__ should return 0 here, then the beha

[Bug preprocessor/33877] Request for __VA_ARGC__

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33877 --- Comment #11 from Alejandro Colomar --- Moreover, __VA_OPT__ is not even self-consistent. alx@debian:~/tmp$ cat vo.c | nl -ba 1 #define foo(...) __LINE__: foo: __VA_OPT__(nonzero args: __VA_ARGS__) 2 #define bar(a, ...) __LIN

[Bug c/121691] New: -Wcomma-within-single-parentheses: New diagnostic for non-robust uses of the comma operator

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121691 Bug ID: 121691 Summary: -Wcomma-within-single-parentheses: New diagnostic for non-robust uses of the comma operator Product: gcc Version: 16.0 Status: UNCONFIRMED

[Bug c/121951] Inconsistent parsing of empty/void lists of parameters in function declarators with forward declarations of parameters

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121951 Alejandro Colomar changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONF

[Bug c/23144] [13/14/15/16 Regression] invalid parameter forward declarations not diagnosed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23144 Alejandro Colomar changed: What|Removed |Added CC||foss+gcc@alejandro-colomar.

[Bug c/121907] -Wauto-as-storage-class: New diagnostic

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121907 --- Comment #5 from Alejandro Colomar --- Oh, for some reason I thought implicit int had been entirely removed from GCC. It's indeed only a default error for new dialects, but not for old ones. alx@debian:~/tmp$ cat implicit.c main(void) {

[Bug c/121907] -Wauto-as-storage-class: New diagnostic

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121907 --- Comment #2 from Alejandro Colomar --- Another possibility would be to remove auto-as-static without replacement. Declaring nested functions is dangerous. What's the point of being able to declare them if it's not yet valid to call them?

[Bug ipa/51677] don't suggest giving main() __attribute__((const))

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51677 Alejandro Colomar changed: What|Removed |Added CC||foss+gcc@alejandro-colomar.

[Bug c/121907] -Wauto-as-storage-class: New diagnostic

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121907 --- Comment #3 from Alejandro Colomar --- (In reply to Alejandro Colomar from comment #2) > Another possibility would be to remove auto-as-static without replacement. I meant auto-as-storage-duration. > Declaring nested functions is dangerous

[Bug c/121951] Inconsistent parsing of empty/void lists of parameters in function declarators with forward declarations of parameters

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121951 --- Comment #1 from Alejandro Colomar --- With gcc built from source, the diagnostic texts change, but the situation is the same: alx@debian:~/tmp$ /opt/local/gnu/gcc/countof22/bin/gcc void_fwd.c void_fwd.c:3:14: error: ‘void’ must be the only

[Bug c/121951] New: Inconsistent parsing of empty/void lists of parameters in function declarators with forward declarations of parameters

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121951 Bug ID: 121951 Summary: Inconsistent parsing of empty/void lists of parameters in function declarators with forward declarations of parameters Product: gcc Versi