https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118514
--- Comment #5 from Alexandre Oliva ---
Interesting. Without ifcombine, we optimize the loop body to the same, but the
load from b doesn't get pulled out to the loop header. I suppose ifcombine may
need to propagate some annotation that the lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118514
Alexandre Oliva changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118504
Bug ID: 118504
Summary: Bogus -Wstringop-overflow warning on simple memcpy
type loop
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113026
Alexandre Oliva changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 113026, which changed state.
Bug 113026 Summary: Bogus -Wstringop-overflow warning on simple memcpy type loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113026
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118456
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118456
Alexandre Oliva changed:
What|Removed |Added
Attachment #60141|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118456
--- Comment #5 from Alexandre Oliva ---
Created attachment 60141
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60141&action=edit
candidate patch under testing
This may be too blunt, and the unrelated robustification may be unwelcome at
t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118456
Alexandre Oliva changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118267
--- Comment #3 from Alexandre Oliva ---
The blocks are ineligible for ifcombine because the dereferences could trap.
Some flow-dependent information could enable us to conclude that only the first
dereference could trap, and it would remain in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118409
--- Comment #25 from Alexandre Oliva ---
Created attachment 60132
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60132&action=edit
candidate patch
Here's what I'm testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118409
Alexandre Oliva changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118344
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118186
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113506
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118025
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118206
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118206
Alexandre Oliva changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118344
Alexandre Oliva changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118186
--- Comment #2 from Alexandre Oliva ---
I've just confirmed that that's the fix indeed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118344
Alexandre Oliva changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118186
Alexandre Oliva changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118206
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #11 from Alexand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118006
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118046
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118025
--- Comment #5 from Alexandre Oliva ---
The original reported problem is fixed. I'm keeping the PR open to look into
the AVR and PRU fails mentioned in comment 2, though they seem to be an
entirely different problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117915
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
--- Comment #18 from Alexandre Oliva ---
Created attachment 59915
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59915&action=edit
add options to control the new ifcombine features
This may be useful to figure out whether it's ifcombine t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117920
Alexandre Oliva changed:
What|Removed |Added
Assignee|aoliva at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117920
Alexandre Oliva changed:
What|Removed |Added
Last reconfirmed||2024-12-18
Assignee|unassig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118006
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118007
Alexandre Oliva changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113506
Alexandre Oliva changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118081
Alexandre Oliva changed:
What|Removed |Added
CC||yunboni at smail dot nju.edu.cn
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118064
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117915
Alexandre Oliva changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118025
Alexandre Oliva changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118046
Alexandre Oliva changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117723
--- Comment #8 from Alexandre Oliva ---
Yes, thanks, fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117723
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104277
--- Comment #3 from Alexandre Oliva ---
Unlikely :-( I haven't been involved with that work for over 5 years.
Without debug info consumer support, the notes are hardly useful, and AFAIK
that support is not forthcoming, so my recommendation has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #277 from Alexandre Oliva ---
Created attachment 59153
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59153&action=edit
[lra] take scratch as implicit unused output reloads
> * call_pcrel patterns: match_scratch can cause ICE f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115295
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115459
--- Comment #9 from Alexandre Oliva ---
Ditto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113719
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113719
--- Comment #16 from Alexandre Oliva ---
Ok, I'd tested the backports on gcc-13 recently, so I'm going to install both
patches in both gcc-13 and gcc-14, the latter under the assumption that if it
works in gcc-13 and trunk, it will be fine for g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95574
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115848
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from Alexandr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113719
Alexandre Oliva changed:
What|Removed |Added
Summary|[13/14/15 regression] |[13/14 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113719
Alexandre Oliva changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113681
Alexandre Oliva changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115459
Alexandre Oliva changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115295
--- Comment #4 from Alexandre Oliva ---
Created attachment 58410
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58410&action=edit
candidate patch
This patch reverts dg-additional-sources to the earlier behavior, in which
sources are added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115295
--- Comment #2 from Alexandre Oliva ---
Ugh, it looks like D deviates from one of the fundamental assumptions behind
the change, namely, that for each named source file, the compiler would attempt
to generate one (set of) output files, so when n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114803
--- Comment #16 from Alexandre Oliva ---
That macro is used within libstdc++ to avoid relying on C99 functions when the
target C library is not C99-compliant. It involves leaving out C++ standard
bits that would depend on functions that the C l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115177
--- Comment #4 from Alexandre Oliva ---
One could argue either way. As a hardened type, discouraging aliasing that
would bypass the hardening could also make sense. It was modeled after Ada,
whose aliasing is much stricter, but I guess in C it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114803
--- Comment #14 from Alexandre Oliva ---
Thanks.
The other problem the testcase in this PR evidenced was that simd_math.h and
simd_scalar.h seem to disregard _GLIBCXX_USE_C99_MATH_TR1, and on newlib-using
targets, that don't declare in math.h e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114803
--- Comment #11 from Alexandre Oliva ---
it's the first test for __clang__ in __int_for_sizeof(), that ends up returning
char() rather than _Schar().
I guess that places the problem entirely on our need for defining __clang__ :-(
Sorry about t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114803
--- Comment #10 from Alexandre Oliva ---
FWIW, I can trigger the problem on arm-eabi (and presumably also on
aarch64-elf, but I haven't tried that) with -D__clang__.
(our vxworks toolchains have to define that macro, for complicated reasons)
h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114803
--- Comment #8 from Alexandre Oliva ---
-fsigned-char works around the fail on affected targets. I couldn't trigger it
on arm-eabi, alas, not even with -funsigned-char.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114803
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112938
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112580
Alexandre Oliva changed:
What|Removed |Added
CC||danglin at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108602
Alexandre Oliva changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108602
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10153
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113660
--- Comment #1 from Alexandre Oliva ---
There's nothing specific about -fharden-control-flow-redundancy here, FWIW.
ISTM that it just adds enough EH-related stuff to the function that an EH note
gets attached to the impossible asm, a stmt then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114059
--- Comment #1 from Alexandre Oliva ---
ISTM that -fharden-control-flow-redundancy is only instrumental to trigger the
latent problem, but the real problem is in the back end: aarch64_restore_za
emits a aarch64_cbnedi1 unconditionally, but insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113777
--- Comment #1 from Alexandre Oliva ---
Eric, I think this is yours.
It fails while trying to add a reversed version of the hbool type to the
context of the struct, but the struct doesn't have children yet, and
add_child_die_after requires the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112938
--- Comment #10 from Alexandre Oliva ---
Thanks, yeah, I can duplicate the problem using the original testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114137
--- Comment #6 from Alexandre Oliva ---
Thanks for the report.
Something's very rotten here. cfrvisited is an automatic variable, why oh why
would we have GOTOFF unspecs for it?!?
I'd be interested in a preprocessed testcase that will trigger
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111935
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94988
--- Comment #10 from Alexandre Oliva ---
Reasoning that the concurrent stores invoke undefined behavior would enable us
to assume that the stores don't alias, which invalidates the reasoning in
comment 1. Alas, I don't think gimple preserves eno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94988
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113394
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113394
Alexandre Oliva changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112917
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113002
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113002
Alexandre Oliva changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113002
Alexandre Oliva changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112938
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112917
--- Comment #4 from Alexandre Oliva ---
Ok, I understand the issues now.
The problem on sparc32 is indeed the large register save area that
__strub_leave allocates, that overlaps with stack space it's expected to scrub,
and that thus doesn't ge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112917
--- Comment #2 from Alexandre Oliva ---
Nevermind, I've managed to log into the cfarm machines running solaris/sparc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112334
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112938
--- Comment #4 from Alexandre Oliva ---
Patch at https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640252.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112778
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112784
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112804
--- Comment #4 from Alexandre Oliva ---
Fixed. Thanks for the notes and testing, Andrew, here and in the mailing list.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112938
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112917
Alexandre Oliva changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112778
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112804
Alexandre Oliva changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112784
Alexandre Oliva changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112334
Alexandre Oliva changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112858
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #6 from Alexandr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112411
--- Comment #4 from Alexandre Oliva ---
yeah, its intended use case is for debugging -fcompare-debug fails, reducing
superfluous differences between rtl dumps.
In theory GCC may overflow insn uids regardless of this param, and if guarding
again
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107169
--- Comment #5 from Alexandre Oliva ---
It looks like r14-5257-g61d2b4746300a604469df15789194d0a7c73791b fixes this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110807
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111943
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
1 - 100 of 215 matches
Mail list logo