https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118182
--- Comment #9 from Alexandre Oliva ---
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680824.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118182
--- Comment #8 from Alexandre Oliva ---
The problem is that the @pred_broadcast pattern expands to _zvfh insns
even when _zero or _imm would do. The scalar constant gets allocated to a
register, and vec_duplicated in the pred_broadcast insn, on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118182
--- Comment #7 from Alexandre Oliva ---
bisection with this PR's patch led me to the patch that added the late-combine
pass as the one that enables the intended result. That's all I know so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118182
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113524
--- Comment #7 from Alexandre Oliva ---
... and riscv*-elf, powerpc-elf.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119629
--- Comment #14 from Alexandre Oliva ---
ack, patch combining the patchlets in commits 7 and 9 looking good in gcc-14
ppc-elf test results.
I'll point out that this report was not so much about this specific mismatch
between ppc builtins and th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119629
--- Comment #12 from Alexandre Oliva ---
Peter, Segher, thanks for the patches and the feedback. I'll give them a try
and report back.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119629
--- Comment #11 from Alexandre Oliva ---
>> On a powerpc-elf standard build, TARGET_POWERPC64 is enabled, but
>> TARGET_64BIT isn't, and so gcc.target/powerpc/byte-in-set-2.c fails
>> to compile with an ICE (instruction not recognized) instead o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119629
--- Comment #10 from Alexandre Oliva ---
>> - instructions and expanders for these builtins don't have their conditions
>> tested, so they must necessarily follow from the builtin conditions, and
>> this case clearly isn't
> "They don't have th
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: aoliva at gcc dot gnu.org
Target Milestone: ---
cmpeqb's conditions are TARGET_P9_MISC && TARGET_64BIT, but the conditions that
enable the expansion of __builtin_scalar_by
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: aoliva at gcc dot gnu.org
Target Milestone: ---
A buggy linker script placed .got too far from .text and triggered a latent
bug.
A small leaf function that needed the got register to
|RESOLVED
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #7 from Alexandre Oliva ---
Fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118805
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #5 from Alexandr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118706
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=113524
--- Comment #6 from Alexandre Oliva ---
Also on arm-eabi, loongarch64-linux-gnu, and sparc-leon3-elf, from bug 118504.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113524
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 118504, which changed state.
Bug 118504 Summary: Bogus -Wstringop-overflow warning on simple memcpy type loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118504
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118504
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118572
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118514
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118572
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=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
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: aoliva at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
Target: arm-non-eabi
This is bug 113026, but for arm-none-eabi
|---
CC||aoliva at gcc dot gnu.org
--- Comment #9 from Alexandre Oliva ---
FYI, pr113026-1.c has never passed on arm-eabi, at torture options "-O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions&qu
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.
||2025-01-08
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Alexandre Oliva ---
Mine
|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
Ever confirmed|0 |1
Last reconfirmed||2025-01-07
--- Comment #1 from Alexandre Oliva ---
Mine. Possibly already fixed with patches pending review, specifically
https://gcc.gnu.org
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
|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Alexandre Oliva ---
Mine
|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #4 from Alexandre Oliva ---
Mine
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
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.
|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #5 from Alexandre Oliva ---
Mine
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
||2024-06-13
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #5 from Alexandre Oliva ---
Created attachment 58417
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58417&
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
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
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
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
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
1 - 100 of 1163 matches
Mail list logo