https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103456
Siddhesh Poyarekar changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103759
Siddhesh Poyarekar changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103759
--- Comment #2 from Siddhesh Poyarekar ---
I've posted a candidate fix:
https://patchwork.sourceware.org/project/gcc/patch/20211217212347.72617-1-siddh...@gotplt.org/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89748
Siddhesh Poyarekar changed:
What|Removed |Added
CC||siddhesh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70090
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=77608
Siddhesh Poyarekar changed:
What|Removed |Added
CC||siddhesh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103456
Siddhesh Poyarekar changed:
What|Removed |Added
CC|siddhesh at redhat dot com |
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103613
Bug ID: 103613
Summary: microblaze: ICE in reload pass when building PIE
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103646
Bug ID: 103646
Summary: gcc driver breaks asm ("ebp")
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103646
Siddhesh Poyarekar changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103522
Siddhesh Poyarekar changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101941
--- Comment #29 from Siddhesh Poyarekar ---
(In reply to Andrew Pinski from comment #28)
> (In reply to Martin Liška from comment #26)
> > that started with r12-6030-g422f9eb7011b76c1.
>
> Please file that bug separately and it might be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104009
Siddhesh Poyarekar changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |siddhesh at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104009
Bug ID: 104009
Summary: r12-6030-g422f9eb7011b76c1 breaks kernel build
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104009
Siddhesh Poyarekar changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103961
Siddhesh Poyarekar changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |siddhesh at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103961
--- Comment #16 from Siddhesh Poyarekar ---
Should be fixed with that patch. May I close this or wait for confirmation
from the reporter?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77608
--- Comment #8 from Siddhesh Poyarekar ---
The test case for pr 103961 exposed a flaw in my patch, where assuming
wholesize isn't always safe or at least would need more careful consideration.
I need to think this through some more.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104942
Siddhesh Poyarekar changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104941
Siddhesh Poyarekar changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104941
Siddhesh Poyarekar changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104942
Siddhesh Poyarekar changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |siddhesh at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964
Siddhesh Poyarekar changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |siddhesh at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104854
--- Comment #6 from Siddhesh Poyarekar ---
(In reply to Martin Sebor from comment #5)
> It would be useful to separate these warnings into multiple levels: level 1
> for invalid code, and higher levels for suspicious (or pointless) code,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104854
--- Comment #8 from Siddhesh Poyarekar ---
(In reply to Martin Sebor from comment #7)
> Moving warnings into the analyzer and scaling it up to be able to run by
> default, during development, sounds like a good long-term plan. Until that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104854
Siddhesh Poyarekar changed:
What|Removed |Added
Summary|-Wstringop-overread should |-Wstringop-overread should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104854
Bug ID: 104854
Summary: [11 Regression] -Wstringop-overread should not warn
for strnlen and strndup
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104854
--- Comment #2 from Siddhesh Poyarekar ---
(In reply to David Malcolm from comment #1)
> Compiler Explorer link for the above (with -fanalyzer -Wall
> -Wstringop-overread -O2; -O2 seems to be needed to trigger it):
Ah yes, sorry, I pasted an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104970
--- Comment #8 from Siddhesh Poyarekar ---
(In reply to Martin Sebor from comment #7)
> The dollar sign in the internal attr_access string implies a VLA bound and
> the attr_access::vla_bounds() function queries the VLA bounds. That should
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964
--- Comment #13 from Siddhesh Poyarekar ---
It's not really a regression AFAICT, it's only more visible with __bdos because
non-constant offsets don't stop it. Also the problem is only with subobjects
(hence limited to _FORTIFY_SOURCE > 1 for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104970
Siddhesh Poyarekar changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964
Siddhesh Poyarekar changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105078
--- Comment #5 from Siddhesh Poyarekar ---
(In reply to Martin Liška from comment #4)
> Note the libQt6 version of the function looking approximately like this:
>
This doesn't warn anymore (and doesn't crash either) because objsz cannot get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105078
--- Comment #1 from Siddhesh Poyarekar ---
With gcc12:
Computing maximum subobject size for _11:
Visiting use-def links for _11
Visiting use-def links for _10
Computing maximum object size for header_12:
Visiting use-def links for header_12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104969
Siddhesh Poyarekar changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105078
Siddhesh Poyarekar changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964
Siddhesh Poyarekar changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #10 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964
--- Comment #11 from Siddhesh Poyarekar ---
(In reply to Siddhesh Poyarekar from comment #10)
> OK, I have a representative reproducer, which TBH is not too different from
> the one you posted, just that it succeeds with __builtin_object_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77608
Siddhesh Poyarekar changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105217
Siddhesh Poyarekar changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105217
Siddhesh Poyarekar changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |siddhesh at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105217
--- Comment #2 from Siddhesh Poyarekar ---
OK, taking a closer look, it looks like clang simply fails to fortify fread
(probably due to https://reviews.llvm.org/D109967 or something similar).
Modifying the code to use __fread_chk directly:
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)
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
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=105217
--- Comment #5 from Siddhesh Poyarekar ---
(In reply to Jakub Jelinek from comment #4)
> Then there is the case where we can clearly see that the pointer from malloc
> is passed to realloc or can trace it to such easily. I'd say in that case
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104969
--- Comment #2 from Siddhesh Poyarekar ---
(In reply to Martin Liška from comment #0)
> The original code is defective a bit as it wrongly assumes that
> (char*)str + (2 * i) is at maximum 'len' big. It's actually len - (2 * i)
> big. But it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104970
Siddhesh Poyarekar changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |siddhesh at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105736
Siddhesh Poyarekar changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #7 from Siddhesh Poyarekar ---
I couldn't work on -fstrict-flex-arrays then, sorry. I do have it in my plan
for gcc 13, but I'll admit it's not on the very top of my list of things to do
this year. If you or anyone else needs a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105736
--- Comment #2 from Siddhesh Poyarekar ---
OK, so the fix is pretty straightforward; error_mark_node escapes through as a
return in ADDR_EXPR object size computations. I want to get a reproducer
independent of ubsan though so that it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105709
--- Comment #9 from Siddhesh Poyarekar ---
>From a quick check of non-reduced-qt.cxx, clang appears to fail to fortify the
readlink function, which may explain why you see the failure with gcc but not
clang. Also the reduced reproducer in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #22 from Siddhesh Poyarekar ---
(In reply to Kees Cook from comment #21)
> How about "-fnot-flex-arrays=N" to mean "trailing arrays with N or more
> elements will NOT be treated like a flex array"?
>
> Then code with sockaddr can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105736
--- Comment #3 from Siddhesh Poyarekar ---
Here we go, I'll put it into builtin-dynamic-object-size-0.c, bootstrap and
post a patch.
struct TV4
{
__attribute__((vector_size (sizeof (int) * 4))) int v;
};
struct TV4 val3;
int *
f1 (struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97185
--- Comment #1 from Siddhesh Poyarekar ---
While the missed optimization ought to be fixed, what's the value of
-Wstringop-* warning on an impossible range, i.e. when low > high? Shouldn't
it just bail out silently if it detects an impossible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #23 from Siddhesh Poyarekar ---
(In reply to Siddhesh Poyarekar from comment #22)
> An arbitrary N will only make it abuse-friendly and potentially mask bugs.
> IMO if we choose to make multiple levels here it should only be
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #26 from Siddhesh Poyarekar ---
(In reply to qinzhao from comment #25)
> So, based on all the discussion so far, how about the following:
>
> ** add the following gcc option:
>
> -fstrict-flex-arrays=[0|1|2|3]
>
> when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97185
--- Comment #3 from Siddhesh Poyarekar ---
(In reply to Martin Sebor from comment #2)
> There's a heuristic for ranges of allocation sizes to exclude zero
> (size_range_flags) that comes into play here. The actual range isn't
> "impossible" in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105736
Siddhesh Poyarekar changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105566
Siddhesh Poyarekar changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70090
Siddhesh Poyarekar changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107038
--- Comment #1 from Siddhesh Poyarekar ---
recvd is uninitialized and it seems to be preventing optimization of the
fortify macro one way or for some reason. I can take a look at why the
condition does not get folded away but a reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107038
--- Comment #4 from Siddhesh Poyarekar ---
(In reply to Martin Liška from comment #2)
> > I assume this is elfutils #29614?
>
> Yes.
>
> Please take a look at the original unreduced testcase I attached here.
That looks like unpatched
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107038
Siddhesh Poyarekar changed:
What|Removed |Added
Last reconfirmed||2022-10-07
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
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=105043
Siddhesh Poyarekar changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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=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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77650
Siddhesh Poyarekar changed:
What|Removed |Added
CC||siddhesh at gcc dot gnu.org
---
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=105043
Siddhesh Poyarekar changed:
What|Removed |Added
Status|NEW |ASSIGNED
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
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
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
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:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
Siddhesh Poyarekar changed:
What|Removed |Added
Resolution|--- |INVALID
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=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=108522
Siddhesh Poyarekar changed:
What|Removed |Added
See Also||https://bugzilla.redhat.com
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 {
>
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
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
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=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
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=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
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
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
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
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=108522
Siddhesh Poyarekar changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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
1 - 100 of 107 matches
Mail list logo
