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&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=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 wi
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 t
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&action=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&action=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
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
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=100518
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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
--- 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
--- 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=103024
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=103097
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|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=103149
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=103028
--- Comment #8 from Alexandre Oliva ---
Fixed
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=103450
Alexandre Oliva changed:
What|Removed |Added
CC||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=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=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=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=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=93027
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
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=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=102988
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #3 from Alexandre Oliva ---
Mine
|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 #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 #2 from Alexandre Oliva ---
Huh, weird, we skip vector types.
Aah, but only in -fharden-compares.
Thanks for the report, will fix.
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
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=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
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #4 from Alexandr
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=94092
Alexandre Oliva changed:
What|Removed |Added
Assignee|aoliva at gcc dot gnu.org |unassigned at gcc dot
gnu.org
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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96078
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
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=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=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
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
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
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
||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=97714
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93456
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=96383
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
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=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=97504
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96965
--- Comment #1 from Alexandre Oliva ---
One nit: I wrote the flag-setting non-canonical compare ended up in i0, but it
actually becomes i1, with the original i1 (R) moved to i0.
Assignee: segher at gcc dot gnu.org
Reporter: aoliva at gcc dot gnu.org
Target Milestone: ---
Consider:
typedef unsigned char T;
T i[2];
int f() {
T *p = &i[0], *q = &i[1];
T c = __builtin_add_overflow(*p, 1, p);
*q += c;
}
The desired code sequence on x86_64 is:
ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96230
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720
Alexandre Oliva changed:
What|Removed |Added
Attachment #48886|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720
--- Comment #10 from Alexandre Oliva ---
Created attachment 48886
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48886&action=edit
patch that hopefully fixes the problem
Does this fix the problem in your testglue-requiring test runs?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95458
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95577
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95416
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720
--- Comment #7 from Alexandre Oliva ---
now, if it is from the board config file, maybe it had better be moved to
ldflags or libs; both of them undergo some -Wl, treatment of object files and
libs already.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720
--- Comment #6 from Alexandre Oliva ---
In case that's from some board config file, I suggest prefixing it with -Wl, so
that it doesn't count as an additional input.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720
--- Comment #5 from Alexandre Oliva ---
that's because of the second input gcc_tg.o
can you tell where that comes from?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from Alexandre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95577
Alexandre Oliva changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95416
Alexandre Oliva changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95577
--- Comment #5 from Alexandre Oliva ---
but is .dSYM ever generated when no -g is present?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95577
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87600
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95538
--- Comment #2 from Alexandre Oliva ---
More likely we've just always missed these lto dump files: IIRC they used to be
created in tmpdir, even during -save-temps builds.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95365
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95224
Alexandre Oliva changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95224
--- Comment #2 from Alexandre Oliva ---
That's not expected, but it seems highly suspicious indeed. I'll have a look.
||2020-06-08
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #2 from Alexandre Oliva ---
Created attachment 48706
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48706&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 95456, which changed state.
Bug 95456 Summary: [11 Regression] gcc/gcc.c:6035:16: runtime error: null
pointer passed as argument 2, which is declared to never be null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95456
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95456
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95456
Alexandre Oliva changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
101 - 200 of 1101 matches
Mail list logo