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=104852
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
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 #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 wi
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=103302
Alexandre Oliva changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
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=104540
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=104121
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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&action=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=104975
Alexandre Oliva changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
|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&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103302
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
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=104564
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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 var-tracking
://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=102146
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
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 of
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
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 condition
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.
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
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 in
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: aoliva at gcc dot gnu.org
CC: nathan at gcc dot gnu.org
Blocks: 103524
Target Milestone: ---
A host whose localhost maps to 127.0.0.1 but not ::1 fails bad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104180
--- Comment #7 from Alexandre Oliva ---
I've recommended before that, without any plan to implement consumers for this
debug information, keeping it in place is mostly wasteful. AFAICT other debug
stmts issued by front-ends could hit the same i
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
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&action=edit
candidate patch under test
Here's a proposed fix
|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.
|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.
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&action=edit
candidate patch under test
Here's a candidate fix
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=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=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=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 t
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=102988
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #4 from Alexandr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103241
--- Comment #14 from Alexandre Oliva ---
Hi, Will, Jakub, Martin,
There's nothing particularly unusual about apparently empty ranges, especially
when views are enabled, since the very point of location views is to enable
multiple states to be d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102988
--- Comment #5 from Alexandre Oliva ---
Created attachment 51837
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51837&action=edit
candidate patch under test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103302
Alexandre Oliva changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #2 from Alexandre Oliva ---
Huh, weird, we skip vector types.
Aah, but only in -fharden-compares.
Thanks for the report, will fix.
|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #1 from Alexandre Oliva ---
Mine, thanks for the report. I think the underlying cause for this one is the
same as for bug 103149 (the "=g" constraint), and hopefully the fix will be the
same as well, but I'll kee
|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #3 from Alexandre Oliva ---
Mine. bug 100518 seems related, but not necessarily the same issue.
|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #3 from Alexandre Oliva ---
Mine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102988
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103302
--- Comment #5 from Alexandre Oliva ---
Hello, Jim,
Thanks for the investigation, that's useful. I guess the register allocator
shouldn't choose to coalesce registers when there's a clobber afterwards, or it
should drop the clobber, since othe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103302
--- Comment #6 from Alexandre Oliva ---
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/585963.html appears to
no longer hit this error, though I've only inspected the asm output, not tried
to run it yet; can anyone confirm?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93027
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103028
--- Comment #4 from Alexandre Oliva ---
Andrew,
asm("":"=g"(tt):"g"(t));
asm("":"=g"(ii):"g"(i));
Make it "0" for the inputs:
asm("":"=g"(tt):"0"(t));
and AFAICT if you "detach" the immediate constant, you won't get the bug.
The probl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103028
--- Comment #6 from Alexandre Oliva ---
This will probably avoid the error. valid_insn_p checks the alternatives, and
fails for the invalid cmpdi_ccu that we attempt to create. Conceivably, this
could be avoided by narrowing down the condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103302
--- Comment #9 from Alexandre Oliva ---
Thanks, this alternate testcase confirms my suspicion that the original issue
was only going latent. It's clearly a preexisting register allocation issue on
riscv, that was latent and that -fharden-compar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103024
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=103530
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=103450
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103450
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=103028
--- Comment #8 from Alexandre Oliva ---
Fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103028
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103149
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103302
--- Comment #10 from Alexandre Oliva ---
Created attachment 51947
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51947&action=edit
candidate patch under testing
Could the fix be as simple as this?
The resulting code is awful, with such s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103302
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103097
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103530
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103024
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100843
--- Comment #4 from Alexandre Oliva ---
Created attachment 51954
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51954&action=edit
candidate patch under testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100518
--- Comment #4 from Alexandre Oliva ---
Created attachment 51955
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51955&action=edit
candidate patch under testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100843
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100518
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
++
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&action=edit
working patch with SUPPORTS_ONE_ONLY, incomplete fix for !SUPPORTS_ONE_ONLY
I'
||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=105324
Alexandre Oliva changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Component|libstdc++
|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&action=edit
Candidate patch
Mine. This patch appears to cure it. Regstrapping...
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 #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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83782
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
||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
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: aoliva at gcc dot gnu.org
Target Milestone: ---
If some IPA pass replaces the only reference to a constant non-public
non-automatic variable with its initializer, namely the address
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
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
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
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
1501 - 1600 of 1710 matches
Mail list logo
