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
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 #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=105736
Siddhesh Poyarekar changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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=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 #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=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=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=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=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 #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
Siddhesh Poyarekar changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassi
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=105566
Siddhesh Poyarekar changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRM
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=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=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 #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
Assignee|unassigned at gcc dot gnu.org |siddhesh at gcc dot
gnu.org
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=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
--- 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=104964
Siddhesh Poyarekar changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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
--- 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
Siddhesh Poyarekar changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #10 from Sidd
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=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=104969
Siddhesh Poyarekar changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
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
--- 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=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=104941
Siddhesh Poyarekar changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104942
Siddhesh Poyarekar changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
1 - 100 of 126 matches
Mail list logo
