https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91602
--- Comment #5 from Jim Wilson ---
The wiki is wrong. Combined tree builds should not be used anymore.
Combined tree builds date back to when Cygnus was maintainer for everything.
We put everything in a single source tree, and wrote configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91602
--- Comment #6 from Jim Wilson ---
By the way, the underlying problem here is, as Andrew Waterman mentioned, that
the RISC-V linker does aggressive link time relaxations to reduce code size,
and this makes lib128 with label subtraction unsafe. T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91635
--- Comment #13 from Jim Wilson ---
I see 5 broken patterns which matches the list already given. The four
testcases are all triggering on the same splitter, which is the first
define_split, lshrsi3_zero_extend_3+1. The second define_split,
lsh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91635
--- Comment #18 from Jim Wilson ---
I was willing to write a patch, I just needed a day to catch up as I'm
hopelessly overloaded with work. But since Jakub wrote one, it looks right to
me, and I think we should use that. I'm not sure exactly wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91635
--- Comment #19 from Jim Wilson ---
I did cross toolchain builds and checks for rv32i/newlib and rv64gc/glibc.
There were no regressions.
Since the splitters exist to reduce code size, I looked at the libc and
libstdc++ sizes with and without t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91635
--- Comment #20 from Jim Wilson ---
Created attachment 46830
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46830&action=edit
proposed patch to fix paradoxical reg in splitter problem
I get better code size with this alternative patch. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91635
--- Comment #22 from Jim Wilson ---
> First of all, I think you need to use :DI instead of :GPR for the last
> define_split, as it shouldn't be iterated with.
Yes, sloppy copy paste. I will fix before committing.
> Second, doesn't this mean th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91635
--- Comment #25 from Jim Wilson ---
Author: wilson
Date: Thu Sep 5 20:32:55 2019
New Revision: 275444
URL: https://gcc.gnu.org/viewcvs?rev=275444&root=gcc&view=rev
Log:
RISC-V: Fix bad insn splits with paradoxical subregs.
Shifting by more tha
||2019-09-06
CC||wilson at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |wilson at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jim Wilson ---
Created attachment 46850
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91713
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91683
--- Comment #5 from Jim Wilson ---
(In reply to Richard Biener from comment #3)
> Hmm, but shouldn't we instead fix combine to record not the reg rtx but the
> regno for UNDO_MODE? Because nothing prevents this from happening elsewhere
> (even i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91683
--- Comment #6 from Jim Wilson ---
(In reply to Richard Biener from comment #4)
> Btw, the rtx of pseudos doesn't change, what changes is the address of the
> entry in regno_reg_rtx[] which is the pseudo-nr -> rtx map. But I don't see
> that inv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91683
--- Comment #7 from Jim Wilson ---
> Would --param=ggc-min-expand=0 and/or --param=ggc-min-heapsize=0 help to
> reproduce the issue?
I don't think so. The problem occurs in ensure_regno_capacity, which isn't
affected by frequency of garbage col
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91683
--- Comment #8 from Jim Wilson ---
(In reply to Richard Biener from comment #3)
> Hmm, but shouldn't we instead fix combine to record not the reg rtx but the
> regno for UNDO_MODE? Because nothing prevents this from happening elsewhere
> (even i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91683
--- Comment #12 from Jim Wilson ---
(In reply to Segher Boessenkool from comment #11)
> Oh lol, I finally wake up. It is called from the splitter. That isn't
> really a valid thing to do.
Right. I want to eliminate that.
> We have some limit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91683
--- Comment #14 from Jim Wilson ---
> 3) Do we want to prohibit calling gen_reg_rtx during combine? Why did
> we want it, before?
Prohibiting gen_reg_rtx calls here would have helped find the bugs I'm fixing
now. I've got a hack to do this to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91683
--- Comment #16 from Jim Wilson ---
(In reply to rguent...@suse.de from comment #15)
> I still don't understand. The rtx are not relocated. The only thing is the
> address of the slot of the regno to rtx map.
I have a debug session in comment 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91720
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85185
--- Comment #10 from Jim Wilson ---
It is the same basic problem as before, but more serious. The original
testcase uses a short variable, and can be fixed by adding a cast to int. But
the new testcase does not use any short variables.
There s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91683
--- Comment #20 from Jim Wilson ---
Author: wilson
Date: Thu Sep 19 01:19:25 2019
New Revision: 275925
URL: https://gcc.gnu.org/viewcvs?rev=275925&root=gcc&view=rev
Log:
RISC-V: Fix more splitters accidentally calling gen_reg_rtx.
PR ta
|--- |FIXED
Assignee|unassigned at gcc dot gnu.org |wilson at gcc dot
gnu.org
--- Comment #27 from Jim Wilson ---
Fixed on mainline and gcc-9 branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91683
Jim Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91860
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91860
--- Comment #2 from Jim Wilson ---
Created attachment 46919
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46919&action=edit
untested fix to copy i2src earlier
works for testcase but otherwise untested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91860
--- Comment #5 from Jim Wilson ---
The new testcase is essentially the same problem, but it is i1src this time not
i2src, so just copying i2src earlier doesn't solve the problem, we also need a
fix for i1src, or a fix elsewhere.
||2019-10-08
Assignee|unassigned at gcc dot gnu.org |wilson at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #8 from Jim Wilson ---
The third and fourth testcases are i2src problems, just like the first
testcase.
Since fixing this in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91860
Jim Wilson changed:
What|Removed |Added
Attachment #46919|0 |1
is obsolete|
||2019-10-10
CC||wilson at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Jim Wilson ---
I can reproduce using gcc-8 and gcc-9 but not mainline. I'm using gcc options:
-std=gnu11 -fgnu89-inline -mc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91691
Jim Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 91691, which changed state.
Bug 91691 Summary: Cross compiling glibc produces a false maybe-uninitialized
error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91691
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91860
--- Comment #10 from Jim Wilson ---
Author: wilson
Date: Fri Oct 11 18:41:35 2019
New Revision: 276901
URL: https://gcc.gnu.org/viewcvs?rev=276901&root=gcc&view=rev
Log:
Extend subst to simplify CONST_INT inside SIGN_EXTEND.
This addresses PR 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
--- Comment #16 from Jim Wilson ---
That referred patch was written by Eric Botcazou for PR59461 which is for
SPARC, which operates same as Itanium, the upper 32-bits of a 32-bit value in a
64-bit reg are undefined. So it does not appear to be c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
--- Comment #18 from Jim Wilson ---
SPARC defines WORD_REGISTER_OPERATIONS, and works the same as ia64. The upper
bits of a 64-bit register after a 32-bit operation are don't care bits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
--- Comment #20 from Jim Wilson ---
I don't see the distinction here. Ia64 has instructions that operate on 32-bit
values too, like cmp4.
On sparc, given this testcase
int
sub (int i, int j, int k)
{
return i + j + k;
}
the compiler generates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
Jim Wilson changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
--- Comment #29 from Jim Wilson ---
(In reply to Sergei Trofimovich from comment #28)
> 1. Is it directly visible for you from RTL dumps which bits GCC assumes as
> non-zero or you just know RTL invariants? I had to patch gcc locally to
> verify
: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: wilson at gcc dot gnu.org
Target Milestone: ---
Some of my build trees are getting allocatable_function_1 failures. Some of
them are not. Looking at this, I see in the failing trees
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89411
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89411
Jim Wilson changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89627
Jim Wilson changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89411
--- Comment #4 from Jim Wilson ---
Created attachment 45925
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45925&action=edit
work in progress patches for a fix
This implements two ways to fix it, a simple way that just fails for BLKmode,
a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89411
--- Comment #5 from Jim Wilson ---
Author: wilson
Date: Tue Mar 19 22:33:34 2019
New Revision: 269813
URL: https://gcc.gnu.org/viewcvs?rev=269813&root=gcc&view=rev
Log:
RISC-V: Fix %lo overflow with BLKmode references.
gcc/
PR t
|--- |FIXED
Assignee|unassigned at gcc dot gnu.org |wilson at gcc dot
gnu.org
--- Comment #6 from Jim Wilson ---
Fixed, with testcase added.
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: wilson at gcc dot gnu.org
Target Milestone: ---
The RISC-V port, with the just committed sifive-7-series support, with the
restore_stack_nonlocal pattern disabled, fails gcc.c-torture/execute/pr64242.c
at -O2 and
||2019-03-27
CC||wilson at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Jim Wilson ---
The RISC-V atomic support in gcc needs a major rewrite. We don't support the
RISC-V formal memory model yet, a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89955
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90015
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90109
--- Comment #2 from Jim Wilson ---
long long and long double did not exist when stabs was invented. Also, 64-bit
machines and C++ did not exist at the time. Also, unfortunately, stabs wasn't
designed to be extensible. So there is no way to des
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90109
--- Comment #5 from Jim Wilson ---
Stabs requires that we emit info for all of the base types at the start. But
if one of the base types does not exist for a 32-bit K&R C target, then we are
struck, as that can't be described. And if we can't d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- Comment #14 from Jim Wilson ---
https://wiki.debian.org/Ports/ia64
James Clarke has been active recently on the binutils and/or gcc mailing lists.
My IA-64 work has dwindled down to nothing, as RISC-V work has kept me too
busy to do anythin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- Comment #15 from Jim Wilson ---
See also PR 87338 which has a response earlier today from John Paul Adrian
Glaubitz.
||2019-05-02
CC||wilson at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #7 from Jim Wilson ---
Confirmed. Except that current sources now say
configure: error: uint64_t or int64_t not found
We have a configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63509
--- Comment #8 from Jim Wilson ---
I filed an autoconf bug
http://savannah.gnu.org/support/index.php?109676
The problem here is that autoconf only verifies that the first AC_PROG_X
compiler is working. And since we include AC_PROG_CC before
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90419
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90419
--- Comment #2 from Jim Wilson ---
I talked to Palmer. Apparently what you want to do is build multilibs for lp64
and lp64d, to test the linux multilib support. That isn't currently supported.
I would suggest applying a local patch to change t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90419
--- Comment #4 from Jim Wilson ---
GCC worked out of the box before we started upstreaming the toolchain. And it
will work out of the box again when we are done with the upstreaming. But
meanwhile, we are still in the middle of upstreaming and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90419
--- Comment #6 from Jim Wilson ---
Comment on attachment 46379
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46379
patch: disable 32bit riscv abis in gcc multilib
You are missing the g aliases. And you still have 32-bit dirnames. We hav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89955
--- Comment #5 from Jim Wilson ---
OK, sounds like we need to move STARTFILE_PREFIX_SPEC into various OS header
files then. That will require some testing. I caught a virus last week and am
behind on everything, so I haven't had a chance to try
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89955
--- Comment #6 from Jim Wilson ---
Author: wilson
Date: Thu Jun 6 23:18:48 2019
New Revision: 272021
URL: https://gcc.gnu.org/viewcvs?rev=272021&root=gcc&view=rev
Log:
RISC-V: Move STARTFILE_PREFIX_SPEC into target OS files.
gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89955
Jim Wilson changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Assignee: unassigned at gcc dot gnu.org
Reporter: wilson at gcc dot gnu.org
Target Milestone: ---
The arm/pe.h file was removed in 2012, but we still have about half a dozen
references in the arm.c file to the ARM_PE macro that was defined in that file.
The arm-symbian port uses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91041
--- Comment #1 from Jim Wilson ---
FYI I noticed this while trying to answer a question on gcc-help, otherwise I'm
not doing any arm work at present.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #35
||2018-07-03
Assignee|unassigned at gcc dot gnu.org |wilson at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #2 from Jim Wilson ---
I don't see any gcc regression. I think the psABI spec was updated without
checking gcc. Unfortun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86671
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86671
Jim Wilson changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- Comment #12 from Jim Wilson ---
I no longer have access to IA-64 hardware. I was leaving myself as maintainer
just so that there was someone responsible for answering questions. I don't
care if the port survives or not. I can resign if tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86786
--- Comment #1 from Jim Wilson ---
I no longer have access to ia64 hardware, and don't plan to do anything about
this.
||2018-08-01
Assignee|unassigned at gcc dot gnu.org |wilson at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jim Wilson ---
There is no known shipping RISC-V hardware at this time that has speculation
support.
However, we do expect
||2018-08-01
CC||wilson at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |wilson at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jim Wilson ---
This is actually a linker bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86770
Jim Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87391
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #2
||2018-09-25
Assignee|unassigned at gcc dot gnu.org |wilson at gcc dot
gnu.org
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87391
--- Comment #3 from Jim Wilson ---
Author: wilson
Date: Tue Sep 25 01:27:06 2018
New Revision: 264555
URL: https://gcc.gnu.org/viewcvs?rev=264555&root=gcc&view=rev
Log:
RISC-V: Fix problems with ilp32e ABI support.
gcc/
PR targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87391
--- Comment #5 from Jim Wilson ---
The proposed psABI change is now
https://github.com/riscv/riscv-elf-psabi-doc/issues/79
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26190
--- Comment #5 from Jim Wilson ---
I haven't done any further work on this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26190
--- Comment #7 from Jim Wilson ---
I didn't realize it was assigned to me. I changed it to unassigned.
||2018-02-16
CC||wilson at gcc dot gnu.org
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84410
--- Comment #2 from Jim Wilson ---
FYI There is a libffi port at
https://github.com/riscv/riscv-libffi
but it is for an old ABI. There are comments in issue 1 pointing at more up to
date but still not complete ports.
||2018-02-20
CC||wilson at gcc dot gnu.org
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84553
Jim Wilson changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84553
--- Comment #3 from Jim Wilson ---
Created attachment 43514
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43514&action=edit
untested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84637
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #1
||2018-03-03
CC||wilson at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jim Wilson ---
The shift count is either 0x2e or 0x2f depending on input. It gets anded with
0xf, and used in an SImode shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84660
--- Comment #2 from Jim Wilson ---
Created attachment 43553
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43553&action=edit
untested patch that works on testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84660
--- Comment #3 from Jim Wilson ---
I screwed up the logic and need to redo the patch. The basic idea is sound
though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #9
Assignee: unassigned at gcc dot gnu.org
Reporter: wilson at gcc dot gnu.org
Target Milestone: ---
The current RISC-V linux multilib support builds 4 combinations of architecture
and ABI, which is useful for an embedded linux cross compiler, but not very
useful for a native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84797
--- Comment #1 from Jim Wilson ---
Created attachment 43610
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43610&action=edit
Initial proposed patch.
Currently, this only supports rv64gc arch, and only allows ABIs in
--with-multilib-list, a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84660
--- Comment #5 from Jim Wilson ---
This is what the original patch I wrote looked like. But then I tried to
optimize it a bit to eliminate the redundant nonzero_bits call, and that is
where I screwed up. Then I got overwhelmed by work and haven
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84856
--- Comment #5 from Jim Wilson ---
Author: wilson
Date: Mon Mar 19 18:08:24 2018
New Revision: 258650
URL: https://gcc.gnu.org/viewcvs?rev=258650&root=gcc&view=rev
Log:
RISC-V: Fix bootstrap failure.
gcc/
PR bootstrap/84856
|--- |FIXED
Assignee|unassigned at gcc dot gnu.org |wilson at gcc dot
gnu.org
--- Comment #6 from Jim Wilson ---
Patch committed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84660
Jim Wilson changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wilson at gcc dot
gnu.org
||2018-04-02
CC||wilson at gcc dot gnu.org
Resolution|INVALID |---
Ever confirmed|0 |1
--- Comment #7 from Jim Wilson ---
As another person mentioned, you actually have two multilibs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84660
--- Comment #8 from Jim Wilson ---
Author: wilson
Date: Mon Apr 2 22:37:21 2018
New Revision: 259019
URL: https://gcc.gnu.org/viewcvs?rev=259019&root=gcc&view=rev
Log:
RISC-V: Fix for combine bug with shift and AND operations.
PR rtl-o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84660
Jim Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85142
--- Comment #10 from Jim Wilson ---
The main problem turns out to be your deletion of MULTILIB_REUSE. You get an
error if MULTILIB_REUSE refers to directories that aren't in MULTILIB_REQUIRED,
but deleting the whole thing is wrong, as this is re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85142
--- Comment #11 from Jim Wilson ---
Created attachment 43874
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43874&action=edit
An unofficial patch to build one lp64d multilib.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87391
Jim Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
101 - 200 of 402 matches
Mail list logo
