[Bug c/115095] New: [missed optimization] fixed processing on constant string

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115095 Bug ID: 115095 Summary: [missed optimization] fixed processing on constant string Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal

[Bug c/111025] New: attribute((malloc)) and posix_memalign() (and other functions that return newly allocated object address into an output parameter)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111025 Bug ID: 111025 Summary: attribute((malloc)) and posix_memalign() (and other functions that return newly allocated object address into an output parameter) Product: gcc

[Bug middle-end/110292] undefined value due to strict aliasing without warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110292 --- Comment #5 from Yann Droneaud --- Hi, Thanks a lot for the quick analysis of my issue. (In reply to Andrew Pinski from comment #4) > Note -Wstrict-aliasing=1 actually does warn: OK, and -Wall enables -Wstrict-aliasing which defaults to

[Bug c/110292] undefined value due to strict aliasing without warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110292 Yann Droneaud changed: What|Removed |Added CC||yann at droneaud dot fr --- Comment #1

[Bug c/110292] New: undefined value due to strict aliasing without warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110292 Bug ID: 110292 Summary: undefined value due to strict aliasing without warning Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug c/71713] "initializer element is not constant" with nested casts

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71713 Yann Droneaud changed: What|Removed |Added CC||yann at droneaud dot fr --- Comment #2

[Bug c/109828] [13/14 Regression] static compound literal with flexible array in initializer leads to invalid size and ICE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109828 --- Comment #8 from Yann Droneaud --- (In reply to Yann Droneaud from comment #7) > I've also experimented compound literal initialization at block level > instead of file level. Except in case it's not supported, it shows the same > issue at

[Bug c/109863] New: RFE: more consistent flex array initialization: lift static storage requirement in gnu2x

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109863 Bug ID: 109863 Summary: RFE: more consistent flex array initialization: lift static storage requirement in gnu2x Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug c/109828] [13/14 Regression] static compound literal with flexible array in initializer leads to invalid size and ICE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109828 --- Comment #7 from Yann Droneaud --- I've also experimented compound literal initialization at block level instead of file level. Except in case it's not supported, it shows the same issue at block level as file level.

[Bug c/109828] [13/14 Regression] C2x:static compound literal (with flexible array) in initializer leads to invalid size and ICE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109828 --- Comment #4 from Yann Droneaud --- I'm still playing with this, for example https://godbolt.org/z/dfjr8veh5, and I've noticed the size of the compound_initializer is incorrect too: struct s { char i; char c[]; }; const struct s

[Bug c/109828] C2x:static compound literal (with flexible array) in initializer leads to invalid size and ICE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109828 --- Comment #2 from Yann Droneaud --- (In reply to Yann Droneaud from comment #0) > The following code is badly compiled by GCC 13.1: > > struct s { int i; char c[]; }; > > const struct s s = { .c = "0", }; > const struct s *r =

[Bug c/109828] C2x:static compound literal (with flexible array) in initializer leads to invalid size and ICE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109828 Yann Droneaud changed: What|Removed |Added CC||yann at droneaud dot fr --- Comment #1

[Bug c/109828] New: C2x:static compound literal (with flexible array) in initializer leads to invalid size and ICE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109828 Bug ID: 109828 Summary: C2x:static compound literal (with flexible array) in initializer leads to invalid size and ICE Product: gcc Version: 13.1.0 Status: UNCONFIRMED

[Bug c/109516] warning: format '%lx' expects argument of type 'long unsigned int', but argument 2 has type 'const long unsigned int:48' [-Wformat=]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109516 --- Comment #7 from Yann Droneaud --- (In reply to Andrew Pinski from comment #6) > > > > And I failed to comprehend how unsigned long int:48 can be passed to a > > variadic function without being promoted to plain unsigned long int ... > >

[Bug c/109516] warning: format '%lx' expects argument of type 'long unsigned int', but argument 2 has type 'const long unsigned int:48' [-Wformat=]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109516 Yann Droneaud changed: What|Removed |Added CC||yann at droneaud dot fr --- Comment #4

[Bug c/109516] New: warning: format '%lx' expects argument of type 'long unsigned int', but argument 2 has type 'const long unsigned int:48' [-Wformat=]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109516 Bug ID: 109516 Summary: warning: format '%lx' expects argument of type 'long unsigned int', but argument 2 has type 'const long unsigned int:48' [-Wformat=] Product: gcc

[Bug preprocessor/109183] [regression?] since GCC 11.1, -MM -MMD generates "a-" prefixed dependency files

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109183 --- Comment #4 from Yann Droneaud --- (In reply to Alexandre Oliva from comment #3) > dump files now consistently take the base name from the output name, when > not overridden > > since in this case gcc is called for (compiling and) linking,

[Bug preprocessor/109183] [regression?] since GCC 11.1, -MM -MMD generates "a-" prefixed dependency files

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109183 Yann Droneaud changed: What|Removed |Added CC||yann at droneaud dot fr --- Comment #2

[Bug preprocessor/109183] New: [regression?] since GCC 11.1, -MM -MMD generates "a-" prefixed dependency files

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109183 Bug ID: 109183 Summary: [regression?] since GCC 11.1, -MM -MMD generates "a-" prefixed dependency files Product: gcc Version: unknown Status: UNCONFIRMED

[Bug tree-optimization/108398] tree-object-size trips up with pointer arithmetic if an intermediate result is an invalid pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398 --- Comment #10 from Yann Droneaud --- (In reply to Jakub Jelinek from comment #8) > -fsanitize=undefined with no diagnostics doesn't mean code is UB free. This is a pity, it would have help users do diagnose the issue in their code.

[Bug tree-optimization/108398] tree-object-size trips up with pointer arithmetic if an intermediate result is an invalid pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398 Yann Droneaud changed: What|Removed |Added CC||yann at droneaud dot fr --- Comment #6

[Bug other/55899] GCC should provide built-ins in data types flavor/version/variation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55899 Yann Droneaud changed: What|Removed |Added CC||yann at droneaud dot fr --- Comment #2

[Bug c++/107104] semantics of __builtin_constant_p within static_assert and return value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107104 Yann Droneaud changed: What|Removed |Added CC||yann at droneaud dot fr --- Comment #3

[Bug ipa/106061] [13 Regression] during GIMPLE pass: einline ICE: verify_cgraph_node failed (edge points to wrong declaration) with -Og since r13-1204-gd68d366425369649

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106061 Yann Droneaud changed: What|Removed |Added CC||yann at droneaud dot fr --- Comment #6

[Bug tree-optimization/107618] Incorrect diagnostics when using -Og, builtin_expect(), and function attribute "warning" or "error"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107618 --- Comment #6 from Yann Droneaud --- (In reply to Richard Biener from comment #5) > Should be fixed for GCC 13, it doesn't seem to be a regression. I've tested with a fresh rebuild of GCC's trunk, and the warning is no more reported at -Og

[Bug middle-end/107618] Incorrect diagnostics when using -Og, builtin_expect(), and function attribute "warning" or "error"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107618 --- Comment #2 from Yann Droneaud --- I was wondering what GCC expects __builtin_object_size(0, 0) to be, and used the following: void a_1 (void) __attribute__((__warning__("-1"))); void a0 (void) __attribute__((__warning__("0")));

[Bug middle-end/107618] Incorrect diagnostics when using -Og, builtin_expect(), and function attribute "warning" or "error"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107618 Yann Droneaud changed: What|Removed |Added CC||yann at droneaud dot fr --- Comment #1

[Bug other/107618] New: Incorrect diagnostics when using -Og, builtin_expect(), and function attribute "warning" or "error"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107618 Bug ID: 107618 Summary: Incorrect diagnostics when using -Og, builtin_expect(), and function attribute "warning" or "error" Product: gcc Version: unknown

[Bug middle-end/99578] [11 Regression] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 --- Comment #43 from Yann Droneaud --- (In reply to Jakub Jelinek from comment #37) > Fixed on the trunk so far, temporarily by differentiating between < 4KB > addresses which are still handled like GCC 11 did for warning purposes, and > >= 4KB

[Bug c/106699] New: Since gcc 12, deferencing constant literal addresses triggers -Warray-bounds warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106699 Bug ID: 106699 Summary: Since gcc 12, deferencing constant literal addresses triggers -Warray-bounds warning Product: gcc Version: 12.0 Status: UNCONFIRMED

[Bug rtl-optimization/81501] mulitple calls to __tls_get_addr() with -fPIC

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81501 --- Comment #7 from Yann Droneaud --- (In reply to Roy Jacobson from comment #6) > We recently upgraded our toolchain from GCC9 to GCC11, and we're seeing > __tls_get_addr take up to 10% of total runtime under some workloads, where > it was 1-2%

[Bug c/82283] Wrong warning with -Wmissing-field-initializers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82283 --- Comment #16 from Yann Droneaud --- (In reply to Marek Polacek from comment #13) > I have a patch which fixes all the testcases here. I've checked my test cases using godbolt gcc trunk, and, yeah, thanks a lot !