Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yann at droneaud dot fr
Target Milestone: ---
Created attachment 58208
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58208=edit
source code of https://godbolt.org/z/Meqvbj8GG
I've fo
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yann at droneaud dot fr
Target Milestone: ---
Functions such as posix_memalign() don't return
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110292
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #1
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yann at droneaud dot fr
Target Milestone: ---
The following code (reduced with some help from cvise) doesn't trigger any
warning from GCC 13+
$ cat test.c
#include
struct a {
uint8_t b:6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71713
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #2
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
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yann at droneaud dot fr
Target Milestone: ---
I've noted some discrepancies in the flex array initialization support:
/* https://godbolt.org/z/9er5G9G15
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://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
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
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yann at droneaud dot fr
Target Milestone: ---
The following code is badly compiled by GCC 13.1:
struct s { int i; char c[]; };
const struct s s
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 ...
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109516
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #4
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yann at droneaud dot fr
Target Milestone: ---
I've discovered today an unexpected format related
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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109183
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #2
NCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: yann at droneaud dot fr
Target Milestone: ---
I've found a rather surprising behavior change when using GCC >= 11.1 to build
some project using
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
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
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
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: yann at droneaud dot fr
Target Milestone: ---
Created attachment 53872
--> https://gcc.gnu.org/bug
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
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yann at droneaud dot fr
Target Milestone: ---
Since GCC 12.1, compiling memtest86+ triggers the following warning:
In function 'find_rsdp',
inlined from
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 !
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82283
--- Comment #8 from Yann Droneaud ---
See also this stack overflow question
https://stackoverflow.com/questions/49081541/compound-literal-and-designated-initializer-warning-from-gcc-but-not-clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82283
--- Comment #7 from Yann Droneaud ---
See also bug #84685 which is a very likely duplicate of this one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84685
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82283
--- Comment #6 from Yann Droneaud ---
Found this one on stack overflow[1], and I find it a bit embarrassing:
struct {
struct {
int a;
int b;
} c[1];
} d = {
.c[0].a = 1,
.c[0].b = 1,
};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82283
--- Comment #5 from Yann Droneaud ---
For a full combo, here's the almost original code that trigger the two errors
above with GLibc < 2.28, only one with newer Glibc.
#define _GNU_SOURCE 1
#include
#include
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82283
--- Comment #4 from Yann Droneaud ---
Also with the ({}) GCC extension:
struct a {
int b;
int c;
};
void d(struct a *);
void e(void) {
struct a f = {
.b = ({
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82283
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82803
--- Comment #12 from Yann Droneaud ---
(In reply to Yann Droneaud from comment #8)
> Created attachment 46903 [details]
> An artificial test case for gcc to emit 17 calls to __tls_get_addr()
>
It's possible to "workaround" this issue by using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82803
--- Comment #10 from Yann Droneaud ---
Some more snippets, generated with creduce:
-8<
void a(long *);
int b(void);
void c(void);
long d(void) {
static __thread long e;
a();
if (b())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82803
--- Comment #9 from Yann Droneaud ---
This issue is also reported as bug #81501
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81501
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82803
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86647
--- Comment #5 from Yann Droneaud ---
I've reproduced the issue with
bool test(void)
{
return ((unsigned int)0 - 1) < 0;
}
See https://godbolt.org/z/b1QqIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86647
--- Comment #4 from Yann Droneaud ---
*** Bug 91685 has been marked as a duplicate of this bug. ***
||yann at droneaud dot fr
Resolution|--- |DUPLICATE
--- Comment #1 from Yann Droneaud ---
My issue is the same as bug #86647.
*** This bug has been marked as a duplicate of bug 86647 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81642
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86647
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #3
Assignee: unassigned at gcc dot gnu.org
Reporter: yann at droneaud dot fr
Target Milestone: ---
I'm was trying to implement a test for socklen_t type signedness, because on
some platform it's signed and some it's unsigned. For signed socklen_t, I
wanted to rejected negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885
--- Comment #7 from Yann Droneaud ---
The issue was noted on twitter by John Regehr, in
https://twitter.com/johnregehr/status/1139295920997068800 and following
messages.
The warning was suggest again by John Regehr in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90037
Yann Droneaud changed:
What|Removed |Added
Attachment #46138|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90037
--- Comment #3 from Yann Droneaud ---
Created attachment 46138
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46138=edit
Reduced reproducer sample
I've used creduce[1][2] to generate a smaller reproducer sample, see
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yann at droneaud dot fr
Created attachment 32498
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32498action=edit
testcase
Hi,
I'm trying to use __builtin_choose_expr
Assignee: unassigned at gcc dot gnu.org
Reporter: yann at droneaud dot fr
Current bit manipulation builtins can be found in documentation:
http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other-Builtins
GCC could benefit of more bit manipulation builtins, for example
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58872
Yann Droneaud yann at droneaud dot fr changed:
What|Removed |Added
CC||yann at droneaud
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yann at droneaud dot fr
According to System V Application Binary Interface, AMD64 Architecture
Processor Supplement, Draft Version 0.90
Aggregates and Unions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57908
--- Comment #1 from Yann Droneaud yann at droneaud dot fr ---
Additionally, for ARM target (ARMv7), it seems GCC align arrays on stack to 4
bytes boundary ... but I don't found the ABI specification that require such
alignment.
kind
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57908
--- Comment #4 from Yann Droneaud yann at droneaud dot fr ---
(In reply to Andrew Pinski from comment #2)
Your test program is not fully testing things correctly.
kind name address size alignment required
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57908
Yann Droneaud yann at droneaud dot fr changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57908
--- Comment #6 from Yann Droneaud yann at droneaud dot fr ---
Created attachment 30512
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30512action=edit
Demonstrate stack allocation of array aligned on 16 bytes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57908
--- Comment #8 from Yann Droneaud yann at droneaud dot fr ---
Using -Os show different results:
Arrays
object | u8_0 | 0x7fff9b4c05bc |1 | 4 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57908
--- Comment #10 from Yann Droneaud yann at droneaud dot fr ---
(In reply to Andrew Pinski from comment #9)
(In reply to Yann Droneaud from comment #8)
Could someone comment on which optimisation is achieved by aligning such
small arrays
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yann at droneaud dot fr
Hi
Following discussion in bug #57908, especially bug #57908 comment #1,
on ARMv7, I'm very surprised that array of bytes are aligned on 4 bytes
boundary when allocated on stack.
Using
: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yann at droneaud dot fr
Hi,
It might be of interest to have a builtin to convert a type name to a string.
Given a type or a variable, the builtin would return the type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55899
Bug #: 55899
Summary: GCC should provide built-ins in stdint.h data types
flavor/version/variation
Classification: Unclassified
Product: gcc
Version: unknown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51579
Bug #: 51579
Summary: GCC should be able report a warning for usage of
parameters marked with __attribute__((unused))
Classification: Unclassified
Product: gcc
Version: 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51579
--- Comment #2 from Yann Droneaud yann at droneaud dot fr 2011-12-16 15:25:41
UTC ---
(In reply to comment #1)
I don't think we should start warning each time an __attribute__((unused))
parameter is actually used. In my experience that's
68 matches
Mail list logo
