https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121786
--- Comment #2 from Siddhesh Poyarekar ---
Another note from the llvm issue: minimum size expression should be wrapped in
a ptr == NULL condition, i.e. (ptr == NULL ? 0 : sz).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110470
--- Comment #1 from Siddhesh Poyarekar ---
This appears to have been fixed in gcc15 but would benefit from a gcc14
backport:
commit 1b575bb24a7a3d2b00197dd5deb4c26b313f442b
Author: Stefan Schulze Frielinghaus
Date: Tue Jul 16 10:41:41 2024 +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121786
--- Comment #1 from Siddhesh Poyarekar ---
In fact, maybe the final size expression (whenever it is not a constant) could
always be wrapped as (sz < SIZE_MAX / 2 ? sz : 0)? It's a general problem, not
specific to inputs to the allocator functio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121786
Bug ID: 121786
Summary: object size expression deduced from alloc_size should
have a SIZE_MAX/2 cap
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121288
Bug ID: 121288
Summary: [15/16] vect/pr117888-1.c fails on s390x since
introduction in r15-6097
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121286
Bug ID: 121286
Summary: [15/16] pr112325.c failing on s390x since it was
introduced in r15-919
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119293
Siddhesh Poyarekar changed:
What|Removed |Added
CC||siddhesh at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121028
Bug ID: 121028
Summary: Some tests added in r15-5785-gdfa78681851 fail with
-fstack-protector-strong
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120780
Siddhesh Poyarekar changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007
Bug ID: 121007
Summary: [Regression 15] compiler hangs when building ffpmeg
with -mcpu=power9 on ppc64le
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120929
--- Comment #21 from Siddhesh Poyarekar ---
(In reply to Richard Biener from comment #20)
> so for
>
> _1 = _2;
>
> we merge from _2. For
>
> _1 = *_2;
>
> we _also_ merge from _2. But those are semantically not the same!
Yes, it only "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120929
--- Comment #19 from Siddhesh Poyarekar ---
(In reply to Siddhesh Poyarekar from comment #17)
> (In reply to qinzhao from comment #16)
> > I feel that propagating the size through _5 = *_1 might not be correct in
> > general, we should only limi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120947
Bug ID: 120947
Summary: __builtin_object_size should understand allocations
pointed by pointers within a struct
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120780
--- Comment #22 from Siddhesh Poyarekar ---
I'm pretty confident about bootstrap-ubsan because I do that as part of testing
my objsz patches (but on x86_64) but I could wait a bit longer I guess. I'm
digging a bit into bug 120929 too, so maybe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120929
--- Comment #17 from Siddhesh Poyarekar ---
(In reply to qinzhao from comment #16)
> (In reply to Siddhesh Poyarekar from comment #12)
> > This is interesting here's the IR dump right after objsz:
> >
> > The key bit is:
> >
> > map2_4 = __b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120929
Siddhesh Poyarekar changed:
What|Removed |Added
CC||siddhesh at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120929
--- Comment #12 from Siddhesh Poyarekar ---
This is interesting here's the IR dump right after objsz:
struct magic_map * apprentice_load ()
{
unsigned int i;
char b[1024];
struct magic_ * ptr;
struct magic_map * map2;
char buf[128];
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120780
--- Comment #20 from Siddhesh Poyarekar ---
I'll backport to the gcc-15 branch after it marinates on trunk for a day or so,
allowing various CIs to test it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120780
--- Comment #18 from Siddhesh Poyarekar ---
Patch posted:
https://inbox.sourceware.org/gcc-patches/20250627114027.3078668-1-siddh...@gotplt.org/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120780
Siddhesh Poyarekar changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120780
--- Comment #13 from Siddhesh Poyarekar ---
(In reply to Jakub Jelinek from comment #12)
> (In reply to Siddhesh Poyarekar from comment #11)
> > OK, so we don't really need a FAM based reproducer either, here's one
> > without it. FAM just make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120780
--- Comment #15 from Siddhesh Poyarekar ---
(In reply to Jakub Jelinek from comment #14)
>
> So, __bdos returns something larger than that? That would be weird.
> Or do the two calls result in different results?
It's basically comment 9; __bd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120780
--- Comment #10 from Siddhesh Poyarekar ---
Minimal reproducer, I've written this independently, not reduced from the
preprocessed source, but I'm pretty sure this is essentially what it is:
typedef __SIZE_TYPE__ size_t;
struct inner
{
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120780
--- Comment #11 from Siddhesh Poyarekar ---
OK, so we don't really need a FAM based reproducer either, here's one without
it. FAM just makes this case more likely because due to it, __bdos succeeds
more often in the kernel code:
typedef __SIZE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120780
--- Comment #9 from Siddhesh Poyarekar ---
I haven't properly reduced this yet, but the key difference appears to be this:
- ifmsh_2 = &MEM[(struct ieee80211_sub_if_data *)dev_1(D) + 2624B].u.mesh;
- _6 = &MEM[(struct ieee80211_sub_if_data *)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120780
--- Comment #8 from Siddhesh Poyarekar ---
Thanks, looking into this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120781
--- Comment #1 from Siddhesh Poyarekar ---
Looks like check_sizes is not inlined when you defined DYN? I haven't built
the latest tree recently, but the only way I can get __bos to give me a valid
value (i.e. without -DDYN) is by forcibly inlin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119611
Bug ID: 119611
Summary: Function call substitution cause confusing warning
messages
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119583
--- Comment #5 from Siddhesh Poyarekar ---
Appeared since r15-3078-g6ea25c041964bf which was also backported to the gcc14
branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119583
--- Comment #3 from Siddhesh Poyarekar ---
I'm not so sure, the stack is correctly aligned here, just that it happens a
little too late and results in holding on to the frame pointer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119583
Siddhesh Poyarekar changed:
What|Removed |Added
Target|X86_64 |x86-64
--- Comment #1 from Siddhes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119583
Bug ID: 119583
Summary: -fomit-frame-pointer does not work as expected for
-mavx
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119140
--- Comment #1 from Siddhesh Poyarekar ---
How about emitting .ACCESS_WITH_SIZE for p (or in case of foo, the return
value), i.e.
const __SIZE_TYPE__ sz = sizeof (b) - i;
.ACCESS_WITH_SIZE(&p, &sz, ...)
which should survive optimizations and i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118127
Siddhesh Poyarekar changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118127
--- Comment #1 from Siddhesh Poyarekar ---
Fix posted:
https://inbox.sourceware.org/gcc-patches/20241219131655.8321-1-siddh...@gotplt.org/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118127
Bug ID: 118127
Summary: gfortran tests XPASS on ppc64le when built with
--with-long-double-format=ieee
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117912
--- Comment #17 from Siddhesh Poyarekar ---
(In reply to Siddhesh Poyarekar from comment #16)
> (In reply to Andrew Pinski from comment #15)
> > (In reply to Jakub Jelinek from comment #14)
> > > struct S { int a; int b[24]; int c[24]; int d; };
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117912
--- Comment #16 from Siddhesh Poyarekar ---
(In reply to Andrew Pinski from comment #15)
> (In reply to Jakub Jelinek from comment #14)
> > struct S { int a; int b[24]; int c[24]; int d; };
> > void bar (int *);
> >
> > __SIZE_TYPE__
> > foo (s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117355
Siddhesh Poyarekar changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77608
--- Comment #13 from Siddhesh Poyarekar ---
No worries, I'd be really surprised if volatile offsets show up in the testing
at all, let alone be significant enough to warrant the rewrite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77608
Siddhesh Poyarekar changed:
What|Removed |Added
Status|WAITING |RESOLVED
Known to fail|4.9.3,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117355
--- Comment #12 from Siddhesh Poyarekar ---
Even smaller reproducer that actually shows what's going on:
```
typedef unsigned long size_t;
#define STR "bbb"
void
gen_blr (void)
{
char line[256];
const char *p = STR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117355
Siddhesh Poyarekar changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |siddhesh at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116556
Siddhesh Poyarekar changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77608
Siddhesh Poyarekar changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #10 from Siddhe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116556
--- Comment #2 from Siddhesh Poyarekar ---
The problem here is that the expression generated is:
# t_1 = PHI <8(2), 4(3)>
p_6 = buf2_4 + t_1;
where tree-object-size then bails out because it can only handle (PTR or
ADDR_EXPR) + INTEGER_CST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #26 from Siddhesh Poyarekar ---
(In reply to Qing Zhao from comment #25)
> If (__builtin_get_counted_by (P->FAM))
> __builtin_get_counted_by (P->FAM) = COUNT;
Do we have language constructs where the existence of an identifier/exp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #15 from Siddhesh Poyarekar ---
(In reply to qinzhao from comment #14)
> If we go with the category B (as I mentioned in Comment #9), define the new
> builtin as a regular builtin,
> Then, arbitrary pointer for the 1st parameter is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #13 from Siddhesh Poyarekar ---
(In reply to qinzhao from comment #11)
> After the discussion with Kees on the major usage of this new builtin, I
> think that the above Category A might be a natural fit for this new
> __builtin_set_c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115293
Siddhesh Poyarekar changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115293
--- Comment #2 from Siddhesh Poyarekar ---
Oh, I had overlooked -Whardened; so it looks like we already do this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115293
Siddhesh Poyarekar changed:
What|Removed |Added
Version|13.0|14.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115293
Bug ID: 115293
Summary: Warn if a compiler flag downgrades protection provided
by -fhardened
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99475
Siddhesh Poyarekar changed:
What|Removed |Added
CC||siddhesh at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113514
Siddhesh Poyarekar changed:
What|Removed |Added
Last reconfirmed||2024-01-22
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113514
--- Comment #5 from Siddhesh Poyarekar ---
What seems to be happening is that early_objsz bails out since the subobject
size at that point is not a constant; I remember concluding that it's safest to
stick to constant sizes here, but I can't rem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113012
Siddhesh Poyarekar changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113012
--- Comment #11 from Siddhesh Poyarekar ---
Yes, I'll test and push the 13 backport by the end of the week if there are no
reported regressions on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113013
--- Comment #6 from Siddhesh Poyarekar ---
Sorry I misread the reproducer as void *reallocarray(void)
__attribute__((__alloc_size__(1)));
Your fix looks fine to me, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113013
Siddhesh Poyarekar changed:
What|Removed |Added
Keywords|ice-on-valid-code |ice-on-invalid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96503
--- Comment #8 from Siddhesh Poyarekar ---
(In reply to Martin Uecker from comment #7)
> For __builtin_with_access we probably only want to allow
> reducing the object size, while the 'extend_size' workaround
> used by systemd (cf comment #4) wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96503
--- Comment #6 from Siddhesh Poyarekar ---
So basically,
__builtin_with_access(void *ptr, size_t size, int access)
where access ==
-1: Unknown access semantics
0: none
1: read_only
2: write_only
3: read_write
should address both access and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96503
--- Comment #5 from Siddhesh Poyarekar ---
This could work for alloc_size, but not quite for access. pointer_with_size
(or __builtin_with_size as you suggested in that thread) would need to express
access semantics too, to be able to express eve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110763
Siddhesh Poyarekar changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110373
Bug ID: 110373
Summary: __builtin_object_size does not recognize subarrays in
multi-dimensional arrays
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
Siddhesh Poyarekar changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
--- Comment #4 from Siddhesh Poyarekar ---
(In reply to Martin Uecker from comment #3)
> I general the pointer could point to the first object of an array that has
> more elements, or to an object of a different type.
How so? p in comment 0 is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
--- Comment #2 from Siddhesh Poyarekar ---
(In reply to qinzhao from comment #0)
> I am wondering for
> p.3_1 = p;
> _2 = __builtin_object_size (p.3_1, 0);
>
> why the size of p.3_1 cannot use the TYPE_SIZE of the pointee of p when its
> size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
--- Comment #1 from Siddhesh Poyarekar ---
The __bdos call itself cannot succeed in main() because it cannot see the
allocation in store(). One way it could succeed is if store() was inlined, but
for some reason it doesn't, even if you make the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109334
--- Comment #2 from Siddhesh Poyarekar ---
That seems OK; I had added that to be conservative since I really only intended
to add support for the access attribute back then and not the implicit
attributes. Could you please post that on the ML a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104970
--- Comment #14 from Siddhesh Poyarekar ---
(In reply to Martin Uecker from comment #13)
> This fix seem too radical. It now prevents this from working even when there
> is an explicit attribute but there is also a VLA bound. Also I think it
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109334
Bug ID: 109334
Summary: tree-object-size: Improve size computation in
arguments
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109308
--- Comment #5 from Siddhesh Poyarekar ---
This kinda has happened before:
https://github.com/Perl/perl5/issues/20678
Should we keep this bug open for the message, which is obviously wrong?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109270
Siddhesh Poyarekar changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #22 from Siddhesh Poyarekar ---
(In reply to Martin Uecker from comment #20)
> > I haven't seen comments on Kees's first example, where "malloc" returns an
> > "__alloc_size" hint that's lost when "p" is returned from the function (a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108522
Siddhesh Poyarekar changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
--- Comment #16 from Siddhesh Poyarekar ---
(In reply to Qing Zhao from comment #15)
> Since S2.flex is not an “array_ref”, it’s correct for
> array_ref_fleixble_size_p to return false for it, I think.
> We might add a new utility routine to de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
--- Comment #14 from Siddhesh Poyarekar ---
(In reply to Qing Zhao from comment #13)
> >
> > The first is handled by the function just fine,
>
> No, even the first case is not recognized by the current
> “array_ref_flexible_size_p”, it’s not b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
--- Comment #12 from Siddhesh Poyarekar ---
(In reply to qinzhao from comment #7)
> (In reply to Richard Biener from comment #1)
> > GCC considered this as a flex-array.
>
> do you mean for the following example:
>
> typedef struct {
> char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108522
Siddhesh Poyarekar changed:
What|Removed |Added
See Also||https://bugzilla.redhat.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108522
Bug ID: 108522
Summary: [Regression 12/13] ICE in tree-object-size when struct
has VLA
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
--- Comment #8 from Siddhesh Poyarekar ---
(In reply to qinzhao from comment #7)
> (In reply to Richard Biener from comment #1)
> > GCC considered this as a flex-array.
>
> do you mean for the following example:
>
> typedef struct {
> char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
Siddhesh Poyarekar changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
--- Comment #7 from Siddhesh Poyarekar ---
Thanks, is that from the code in prima[1] or the Red Hat bugzilla report? The
latter is undefined as per the above discussion.
[1] https://github.com/dk/Prima/issues/78
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
--- Comment #5 from Siddhesh Poyarekar ---
Ack, I had a thinko with
unsigned steps[] = {1, 1};
because in that case too n_steps doesn't get decremented, resulting in OOB
access. I'm going to look at the original report[1] to see if the test c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
--- Comment #3 from Siddhesh Poyarekar ---
Oops, sorry I messed up the reproducer, here's the correct one. The principles
don't really change though:
unsigned steps[2];
int main(void) {
unsigned n_steps = sizeof (steps) / sizeof (unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
--- Comment #2 from Siddhesh Poyarekar ---
Yeah, I've been ping-ponging about the validity too, which is why I filed a bug
to get some consensus position. I suppose if we don't treat it as a bug, should
we try and support it in cases we can by a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
Bug ID: 108398
Summary: tree-object-size trips up with pointer arithmetic if
an intermediate result is an invalid pointer
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105043
Siddhesh Poyarekar changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105043
Siddhesh Poyarekar changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
--- Comment #5 from Siddhesh Poyarekar ---
(In reply to rguent...@suse.de from comment #4)
> Does it allow the nesting when nested in a union?
data[] cannot be nested directly in a union (i.e. union { char d; char data[];
} is invalid) but some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
--- Comment #2 from Siddhesh Poyarekar ---
The standard does not allow the nesting, but gcc supports it as an extension.
The middle end does see the array as a flex array correctly, but
tree-object-size doesn't seem to do the right thing consis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107951
Siddhesh Poyarekar changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77650
Siddhesh Poyarekar changed:
What|Removed |Added
CC||siddhesh at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
Bug ID: 107952
Summary: tree-object-size: inconsistent size for flexible
arrays nested in structs
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107951
Bug ID: 107951
Summary: Invalid flexible array use not detected in nested
structs by the C frontend
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107038
Siddhesh Poyarekar changed:
What|Removed |Added
Last reconfirmed||2022-10-07
Version|13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107038
--- Comment #8 from Siddhesh Poyarekar ---
I forgot to mention that I've been building with:
gcc/cc1 -o /dev/null ../bogus-stringop-overflow.i -O2 -Werror=stringop-overflow
-quiet
to reproduce the warning:
../bogus-stringop-overflow.i: In fun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107038
Siddhesh Poyarekar changed:
What|Removed |Added
Summary|[13 Regression] Bogus |Bogus -Wstringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107038
--- Comment #5 from Siddhesh Poyarekar ---
(In reply to Siddhesh Poyarekar from comment #4)
> (In reply to Martin Liška from comment #2)
> > > I assume this is elfutils #29614?
> >
> > Yes.
> >
> > Please take a look at the original unreduced
1 - 100 of 160 matches
Mail list logo
