http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49116
Alexandre Oliva changed:
What|Removed |Added
CC||howarth at nitro dot
||2011.06.06 00:50:28
CC||aoliva at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |aoliva at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49270
--- Comment #10 from Alexandre Oliva 2011-06-06
13:24:41 UTC ---
Author: aoliva
Date: Mon Jun 6 13:24:39 2011
New Revision: 174697
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174697
Log:
PR bootstrap/49270
* ipa-inline-analysis.c (rea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49270
Alexandre Oliva changed:
What|Removed |Added
Resolution|DUPLICATE |FIXED
--- Comment #11 from Alexandre Ol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49270
Alexandre Oliva changed:
What|Removed |Added
CC||d.g.gorbachev at gmail dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49116
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68468
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
||2016-08-01
CC||aoliva at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Alexandre Oliva ---
Created attachment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49366
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
||aoliva at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #11 from Alexandre Oliva ---
Created attachment 39046
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39046&action=edit
Patch I'm testing to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63243
Bug 63243 depends on bug 60782, which changed state.
Bug 60782 Summary: DWARF does not represent _Atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60782
What|Removed |Added
---
||aoliva at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #4 from Alexandre Oliva ---
It appears to me that this should have long been closed, no? The patch that
implements it is in, and functional. I'm closing it; please reopen if th
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: aoliva at gcc dot gnu.org
Target Milestone: ---
// { dg-do compile }
// { dg-options "-std=c++11" }
// Make sure we don't drop ref-qualifiers...
typedef void rqft(void) con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72799
--- Comment #1 from Alexandre Oliva ---
Uhh, sorry, I pasted the error messages from a compiler with changes that
attempted to fix the problem. Here's what gcc version 5.3.1 20160406 (Red Hat
5.3.1-6) (GCC) reports:
/l/tmp/build/gcc/trunk/gcc/te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49366
--- Comment #4 from Alexandre Oliva ---
Author: aoliva
Date: Fri Aug 12 07:11:23 2016
New Revision: 239401
URL: https://gcc.gnu.org/viewcvs?rev=239401&root=gcc&view=rev
Log:
[PR49366] emit loc exprs for C++ non-virtual pmf template value parms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63240
--- Comment #2 from Alexandre Oliva ---
Author: aoliva
Date: Fri Aug 12 07:11:50 2016
New Revision: 239403
URL: https://gcc.gnu.org/viewcvs?rev=239403&root=gcc&view=rev
Log:
[PR63240] generate debug info for defaulted member functions
This impl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55641
--- Comment #12 from Alexandre Oliva ---
Author: aoliva
Date: Fri Aug 12 07:11:36 2016
New Revision: 239402
URL: https://gcc.gnu.org/viewcvs?rev=239402&root=gcc&view=rev
Log:
[PR55641] drop spurious const_type from reference_type variables
Alth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63240
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49366
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63243
Bug 63243 depends on bug 49366, which changed state.
Bug 49366 Summary: pointer-to-member-function not given value in
DW_TAG_template_value_param
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49366
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63243
Bug 63243 depends on bug 63240, which changed state.
Bug 63240 Summary: DWARF does not represent C++ defaulted methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63240
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55641
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63243
Bug 63243 depends on bug 55641, which changed state.
Bug 55641 Summary: debug info for the type of a reference declared with a
typedef has spurious 'const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55641
What|Removed
||aoliva at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #9 from Alexandre Oliva ---
Created attachment 39274
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39274&action=edit
Patch I'm testing
||aoliva at gcc dot gnu.org
--- Comment #1 from Alexandre Oliva ---
Mine. Initial, incomplete patch just posted to gcc-patches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49348
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77389
Alexandre Oliva changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
l/gcc-patches/2021-March/5
65995.html
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: aoliva at gcc dot gnu.org
Target Mile
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: aoliva at gcc dot gnu.org
Target Milestone: ---
Try to compile gimplefe-28.c from the testsuite with -mno-powerpc-gpopt or
-msoft-float on a powerpc target, and it will ICE, because it doesn't chec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95401
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99372
--- Comment #2 from Alexandre Oliva ---
I didn't mean that the testcase didn't check, I meant that the gimple parser
didn't check. It swallows the .SQRT call even though it the attempt to expand
the call will ICE because there's no usable opcode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95401
--- Comment #9 from Alexandre Oliva ---
It is definitely a problem in the dg infrastructure that compile mode doesn't
work with additional sources, but fixing that seems quite involved, more than I
can tackle right now. I've tried to duplicate t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99371
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=96078
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
CC||aoliva at gcc dot gnu.org
--- Comment #5 from Alexandre Oliva ---
Jason's patch was backported to gcc-10, but Jakub's patch AFAICT wasn't, so the
fail remains there.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: aoliva at gcc dot gnu.org
Target Milestone: ---
Target: i686-pc-linux-gnu
compile this with -O2 -mfpmath=387 -mno-sse
#include
int main() {
std::atomic a0;
std::atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504
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=97504
--- Comment #5 from Alexandre Oliva ---
Created attachment 49427
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49427&action=edit
patch that should fix the remaining s390 problem
So, the issue is already fixed on aarch64-*, powerpc*-*, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504
--- Comment #17 from Alexandre Oliva ---
Created attachment 49456
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49456&action=edit
fix for riscv targets
> Still broken
Sorry, it's the first I hear of this problem on riscv.
The fix is targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97060
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #2 from Alexandre Oliva ---
Created attachment 49751
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49751&action=edit
patch I'm testing to fix the bug
Mine. Thanks. Here's a minimal, most-conservative chan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93456
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97714
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||aoliva at gcc dot gnu.org
Assignee|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=94092
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=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 debu
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&action=edit
patch that fixes the problem for reasons not fully understood
It seems that looking up the MEM exprs in DEB
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 me
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=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 actua
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=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
901 - 1000 of 1181 matches
Mail list logo
