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
---
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
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
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
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
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.
|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #3 from Alexandre Oliva ---
Mine, thanks for the report, and for the reduced testcases!
|ASSIGNED
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
Last reconfirmed||2023-12-09
--- Comment #1 from Alexandre Oliva ---
Hello, Rainer,
The bulk of the documentation about strub is not at the options
|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #2 from Alexandre Oliva ---
Mine.
Patch at https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639987.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112804
Alexandre Oliva changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
|ASSIGNED
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
Last reconfirmed||2023-12-09
--- Comment #1 from Alexandre Oliva ---
Mine.
Patch at https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639985.html
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
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
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=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=111520
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||2023-10-26
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #1 from Alexandre Oliva ---
Created attachment 56315
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56315=e
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=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=111904
Alexandre Oliva changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109822
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
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=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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104852
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105224
Alexandre Oliva changed:
What|Removed |Added
URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77760
--- Comment #8 from Alexandre Oliva ---
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612198.html has a
simple-minded implementation, that should make it clear what I mean by scratch:
get() pays no regard to the incoming bits in tm, it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77760
--- Comment #5 from Alexandre Oliva ---
I'm not entirely sure what the point of testing for __clang__ is, really. Is
libstdc++ used with, or supposed to be used (say, as a system library) with
__clang__? If so, wouldn't it be useful if it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77760
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #20 from Alexandre Oliva ---
The bug is now either fixed or latent in the trunk, I'm not sure which, because
I have not got as far as figuring out why removing unnecessary address cselib
lookups in debug insns made a difference to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #17 from Alexandre Oliva ---
Created attachment 54272
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54272=edit
patch that fixes the problem for reasons not fully understood
It seems that looking up the MEM exprs in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #16 from Alexandre Oliva ---
Sorry it took me so long to react, I'd missed the question.
IIRC the scheduler was the hardest part of GCC to make work with debug insns.
The general strategy is that nondebug insns never depend on
++
Assignee: unassigned at gcc dot gnu.org
Reporter: aoliva at gcc dot gnu.org
Target Milestone: ---
Created attachment 53967
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53967=edit
working patch with SUPPORTS_ONE_ONLY, incomplete fix for !SUPPORTS_ONE_ONLY
I've attempted disabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: aoliva at gcc dot gnu.org
Target Milestone: ---
I see no reason for the difference WRT ECF_NOTHROW between
__cxa_deleted_virtual and __cxa_pure_virtual library declarations pushed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
--- Comment #18 from Alexandre Oliva ---
on x86_64 with -fPIC or -fpic, my_guard's address is indeed loaded from the GOT
with @GOTPCREL indeed
on x86_64 with -fPIE or -fpie, however, it is used just as expected by the
testcase. which should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83782
--- Comment #10 from Alexandre Oliva ---
sorry, I typoed the failing test. it's in g++.dg/ext, and it has a .C
extesion. how unfortunate that there was another test matching the lower-case
name I typoed.
||aoliva at gcc dot gnu.org
Resolution|FIXED |---
--- Comment #15 from Alexandre Oliva ---
Uroš,
stack-prot-sym.c fails on ia32 with PIC/PIE: the address/value of my_guard is
loaded from the GOT, instead of appearing as %gs:my_guard.
After being
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=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
|REOPENED
CC||aoliva at gcc dot gnu.org
--- Comment #10 from Alexandre Oliva ---
ISTM that if you have to insert an endbr over indirect_return, a call should
only be eligible for sibcall if the caller is also marked with indirect_return
|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #5 from Alexandre Oliva ---
Mine. The problem is that the undef name may appear deep in a chain of phis,
instead of appearing directly in the base expr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105455
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #2 from Alexandre Oliva ---
Created attachment 52951
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52951=edit
Candidate patch
Mine. This patch appears to cure it. Regstrapping...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105324
Alexandre Oliva changed:
What|Removed |Added
Status|REOPENED|RESOLVED
||aoliva at gcc dot gnu.org
Resolution|FIXED |---
--- Comment #5 from Alexandre Oliva ---
The from_chars overloads for floating-point types are guarded by #if
_GLIBCXX_HAVE_USELOCALE
The test fails with ugly overload resolution and template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105359
--- Comment #1 from Alexandre Oliva ---
pr82748-1.c is another victim of this issue. do_copysign_ld needs to convert
between (64-bit) long double and __ieee128 for __builtin_copysignq, and since
the expanders for these conversions are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105267
--- Comment #3 from Alexandre Oliva ---
HaoChen Gui posted a proposal for a narrower pattern here
https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593389.html
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: aoliva at gcc dot gnu.org
Target Milestone: ---
Target: rs6000
As described elsewhere, some tests fail on targets with 64-bit long double,
because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
://gcc.gnu.org/pipermail/gcc-patches/2022-April/5
92763.html
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: aoliva at gcc dot gnu.org
Blocks: 103524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105161
--- Comment #2 from Alexandre Oliva ---
Debug binds in edges was something I considered for some time, but concluded it
would be unlikely to bring useful debug information: the confluence operator
for debug-bind-capable decls during
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104564
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104975
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103302
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #2 from Alexandre Oliva ---
Created attachment 52677
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52677=e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104975
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=103302
--- Comment #16 from Alexandre Oliva ---
Created attachment 52518
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52518=edit
Candidate patch
The problem is in undo_optional_reloads. Here's a fix I'm testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104121
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103845
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104540
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103856
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103302
Alexandre Oliva changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104121
Alexandre Oliva changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104121
--- Comment #10 from Alexandre Oliva ---
and then, as I reduced it myself down to the following and compared with the
minimized test, I've finally turned on both of my neurons ;-) and it finally
hit me: "only with -mv850e2v3" didn't mean "not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104121
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=104121
--- Comment #7 from Alexandre Oliva ---
I mean, even with commit 50e8b0c9bca6cdc57804f860ec5311b641753fbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104121
--- Comment #6 from Alexandre Oliva ---
No luck, even with commit
./xgcc -B./ -O2 -g pr104121.c -mv850e2v3 -mno-app-regs -msmall-sld
-fbuilding-libgcc -fno-stack-protector
do I actually need binutils to enable something essential in GCC to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104121
--- Comment #5 from Alexandre Oliva ---
Do you still get this? I can't trigger the problem with the reduced testcase
with -O2 -g -mv850e2v3, on a cross to v850-rtems hosted on x86_64-linux-gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103845
--- Comment #5 from Alexandre Oliva ---
Confirmed. The first patch there.
I will still prepare a patch with the testcase to avoid an independent
regression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103845
Alexandre Oliva changed:
What|Removed |Added
Depends on||104263
--- Comment #4 from Alexandre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104540
--- Comment #2 from Alexandre Oliva ---
Created attachment 52459
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52459=edit
candidate patch under test
Here's a candidate fix
|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. Confirmed.
|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #2 from Alexandre Oliva ---
Mine. I can't duplicate this with a current compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103856
--- Comment #4 from Alexandre Oliva ---
Created attachment 52458
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52458=edit
candidate patch under test
Here's a proposed fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103856
Alexandre Oliva changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
1 - 100 of 1081 matches
Mail list logo
