https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58872
--- Comment #4 from Yann Droneaud ---
(In reply to Andrew Pinski from comment #3)
> ror/rol is handled by __builtin_stdc_rotate_right/__builtin_stdc_rotate_left
> https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-
> _005f_005fbuiltin_
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
Pri
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
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 -W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110292
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #1
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
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71713
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #2 f
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 bl
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
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.
https://godbolt.org/z/vn
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 *cons
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 = &(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109828
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #1
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
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 ...
>
> O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109516
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #4
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
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, a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109183
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #2
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
Sever
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55899
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #2 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107104
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106061
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #6
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 lev
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")));
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107618
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #1
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
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 a
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
Sev
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%
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 !
33 matches
Mail list logo