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 a
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 #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 #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
Siddhesh Poyarekar changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFI
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=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 {
> char
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 #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=108522
Siddhesh Poyarekar changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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=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 ol
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
--- 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,
> simil
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
That'
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
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104941
Siddhesh Poyarekar changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassi
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=104964
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=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 sho
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
gnu.org
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=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
> ma
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|NEW |ASSIGNED
--- Comment #10 from Sidd
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 an
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 s
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 #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
hea
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
pa
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=105217
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=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=105217
Siddhesh Poyarekar changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comme
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=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 witho
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 elfutils
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
Summary|[13 Regression] Bogus |Bogus -Wstringop-overflow
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
Last reconfirmed||2022-10-07
Version|13.0
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=77608
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
Status|NEW |ASSIGNED
--- Comment #7 from Siddhe
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
gnu.org
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=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 related
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: t
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
gnu.org
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=103456
Siddhesh Poyarekar changed:
What|Removed |Added
CC|siddhesh at redhat dot com |
Status|NEW
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=103522
Siddhesh Poyarekar changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at
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
Componen
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
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103646
Siddhesh Poyarekar changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103759
Siddhesh Poyarekar changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassi
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=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=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=77650
Siddhesh Poyarekar changed:
What|Removed |Added
CC||siddhesh at gcc dot gnu.org
--- Com
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=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=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=105043
Siddhesh Poyarekar changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassi
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=70090
Siddhesh Poyarekar changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105566
Siddhesh Poyarekar changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRM
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 comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105736
Siddhesh Poyarekar changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassi
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 str
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 verifiab
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 us
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
> -fstr
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 TV4
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 ra
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 -fstrict-fl
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 t
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=110763
Siddhesh Poyarekar changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=109270
Siddhesh Poyarekar changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
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=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=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
--- 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=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=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 #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
Siddhesh Poyarekar changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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=115293
Siddhesh Poyarekar changed:
What|Removed |Added
Version|13.0|14.0
CC|
1 - 100 of 133 matches
Mail list logo
