https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105665
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652
Bug 81652 depends on bug 85620, which changed state.
Bug 85620 Summary: Missing ENDBR after swapcontext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85620
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85620
Alexandre Oliva changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83782
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
Alexandre Oliva changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101454
Bug ID: 101454
Summary: debug info for unreachable var forces another var to
be output
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
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=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=111935
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
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=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=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=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=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=10153
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
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=109183
--- Comment #3 from Alexandre Oliva ---
dump files now consistently take the base name from the output name, when not
overridden
since in this case gcc is called for (compiling and) linking, and the final
output name is a.* (.out or .exe, depen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108784
--- Comment #2 from Alexandre Oliva ---
Hello, Arseny,
I have a hunch this could possibly be related with fixed bug 108573.
Is this one by any chance fixed for you?
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=108602
Alexandre Oliva changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=112938
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
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=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
--- 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 #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 #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=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 #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=111904
Alexandre Oliva changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111520
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=111942
Alexandre Oliva changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111943
Alexandre Oliva changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111520
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109411
--- Comment #2 from Alexandre Oliva ---
AFAICT there are mentions to test.h line numbers both with and without
-gstatement-frontiers, and the mentions are the same. The problem is two-fold:
- there aren't any stmt markers for the lines in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111943
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=107169
--- Comment #5 from Alexandre Oliva ---
It looks like r14-5257-g61d2b4746300a604469df15789194d0a7c73791b fixes this.
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=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=112858
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #6 from Alexandr
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=112784
Alexandre Oliva changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
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=112778
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=109822
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
Status|NEW |ASSIGNED
Assignee|unassigne
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=112784
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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=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=112334
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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=112938
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
Ever confirmed|0 |1
Status|UNCONFIRMED
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
Resolution|--- |FIXED
Status|ASSIGNED
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=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=113394
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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=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=115459
Alexandre Oliva changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
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=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=113719
Alexandre Oliva changed:
What|Removed |Added
Summary|[13/14/15 regression] |[13/14 regression]
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=95574
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
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=113719
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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=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=117723
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigne
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=118006
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|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=118344
Alexandre Oliva changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
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=113524
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
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=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=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=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=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=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=118006
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigne
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=118064
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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=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
101 - 200 of 254 matches
Mail list logo