https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66785
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66785
--- Comment #3 from Jim Wilson ---
Created attachment 36705
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36705&action=edit
untested patch that may be wasting memory
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wilson at gcc dot gnu.org
Target Milestone: ---
Created attachment 37345
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37345&action=edit
aarch64 testcase generated with creduce, ICE at -O3
I'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69282
--- Comment #1 from Jim Wilson ---
With an aarch64-linux-gnu cross compiler:
palantir:2654$ ./xgcc -B./ -O3 -S tmp.c
tmp.c: In function 'fn1':
tmp.c:3:5: error: incorrect type of vector CONSTRUCTOR elements
int fn1(void) {
^~~
{_38, _110,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69282
--- Comment #7 from Jim Wilson ---
The simplified testcases fail on arm if you use -O3 -mfpu=neon.
I can look at fixing the arm side of things if we need an md patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69282
--- Comment #9 from Jim Wilson ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Jim Wilson from comment #7)
> > The simplified testcases fail on arm if you use -O3 -mfpu=neon.
> >
> > I can look at fixing the arm side of things if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69282
--- Comment #10 from Jim Wilson ---
(In reply to Jim Wilson from comment #9)
> (In reply to Andrew Pinski from comment #8)
> > (In reply to Jim Wilson from comment #7)
> > > The simplified testcases fail on arm if you use -O3 -mfpu=neon.
> > >
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69282
--- Comment #11 from Jim Wilson ---
(In reply to Jim Wilson from comment #10)
> Both the aarch64 and arm code looks funny to me, as the last add seems to be
> using an input register that was never set, but I don't know the aarch64 and
> arm vect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66258
--- Comment #2 from Jim Wilson ---
Author: wilson
Date: Wed Jun 3 00:46:19 2015
New Revision: 224054
URL: https://gcc.gnu.org/viewcvs?rev=224054&root=gcc&view=rev
Log:
gcc/
PR target/66258
* config/aarch64/aarch64.c (aarch64_fun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66258
--- Comment #3 from Jim Wilson ---
The patch doesn't completely fix grub, because grub is trying to compile FP
code with +nofp, which can't work without a soft-float ABI, which we don't
have. So grub gets an error instead of an ICE with the patc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66258
Jim Wilson changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66271
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66203
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66271
Jim Wilson changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932
--- Comment #12 from Jim Wilson ---
Part of the problem here is that the arm port defines PROMOTE_MODE to force
short local variables to unsigned, but arm_promote_function_mode doesn't change
signedness. So a signed short parameter and a signed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932
--- Comment #13 from Jim Wilson ---
Created attachment 35774
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35774&action=edit
Experimental patch to force out-of-ssa to use promoted subregs for phi nodes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932
--- Comment #14 from Jim Wilson ---
Created attachment 35775
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35775&action=edit
A possibly better patch, to modify ARM port to stop changing signed HI/QI to
unsigned.
This would require perform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66258
--- Comment #9 from Jim Wilson ---
Author: wilson
Date: Tue Jun 16 20:11:41 2015
New Revision: 224538
URL: https://gcc.gnu.org/viewcvs?rev=224538&root=gcc&view=rev
Log:
gcc/
Backport from mainline
2015-06-02 Jim Wilson
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65375
--- Comment #10 from Jim Wilson ---
Improved, but not completely resolved. We still get unnecessary orr
instructions, same as in comment 2. This is partly an issue with the register
allocator not handling partially overlapping register reads/wr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932
--- Comment #17 from Jim Wilson ---
I've been researching how the ARM PROMOTE_MODE reached its current state.
There are a number of issues here.
1) There is a comment that says zero extension is faster for char than signed
extension. This is o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932
--- Comment #18 from Jim Wilson ---
Ultimately, I believe that this is an ARM backend bug. PROMOTE_MODE and
TARGET_PROMOTE_FUNCTION_MODE should not behave differently. It would help if
the PROMOTE_MODE macro was merged with the TARGET_PROMOTE_F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66849
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36328
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71685
--- Comment #4 from Jim Wilson ---
The problem here is that I assumed that c_build_qualified_type would only be
called when we want to create a variant type. However, there are a number of
places that call it without checking to see if we have a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71685
--- Comment #7 from Jim Wilson ---
An early exit if type_quals is 0 does not work, as there is at least one place
that deliberately calls c_build_qualified_type with no type qualifiers to
create an unqualified type from a qualified type. Likewis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69848
--- Comment #13 from Jim Wilson ---
I think it was poc_ref_pic_reorder() in slice.c that triggered the ICE. I
don't know if the original code shows the vectorization reduction problem.
That might only be present in the reduced testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99964
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100178
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97409
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97409
Jim Wilson changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97481
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #3 from Jim Wilson ---
The basic idea here is that the movqi pattern in riscv.md currently emits RTL
for a load that looks like this
(set (reg:QI target) (mem:QI (address)))
As an experiment, we want to try changing that to somethin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #5 from Jim Wilson ---
Yes, the volatile is the problem. We need to disable some optimizations like
the combiner to avoid breaking the semantics of volatile. However, if you try
looking at other ports, like arm, you can see that the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #7 from Jim Wilson ---
That patch is basically correct. I would suggest using gen_lowpart instead of
gen_rtx_SUBREG as a minor cleanup. It will do the same thing, and is shorter
and easier to read.
There is one problem here that yo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #13 from Jim Wilson ---
The attachments show the entire riscv.c file being deleted and then readded
with your change. This is due to a line ending problem. The original file has
the unix style linefeed and the new file has the windo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #14 from Jim Wilson ---
Actually, for the SImode to DImode conversion, zero extending is unlikely to be
correct in that case. The rv64 'w' instructions require the input to be
sign-extended from 32-bits to 64-bits, so a sign-extend i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #15 from Jim Wilson ---
I tried testing your first patch. I just built unpatched/patch
rv32-elf/rv64-linux toolchains and used nm/objdump to look at libraries like
libc, libstdc++, libm.
I managed to find a testcase from glibc that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #17 from Jim Wilson ---
Yes, LOAD_EXTEND_OP is a good suggestion. We can maybe do something like
int extend = (LOAD_EXTEND_OP (mode) == ZERO_EXTEND);
temp_reg = force_reg (word_mode, convert_to_mode (word_mode, src, extend));
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #20 from Jim Wilson ---
Maybe convert_to_mode is recursively calling convert_to_mode until you run out
of stack space. You can use --save-temps to generate a .i preprocessed file
form your input testcasxe, then run cc1 under gdb. Yo
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wilson at gcc dot gnu.org
Target Milestone: ---
Consider this testcase
struct
{
unsigned int a : 1;
unsigned int b : 1;
unsigned int c : 1;
unsigned int d : 1;
unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #21 from Jim Wilson ---
I submitted my testcase as 97747 so it will get more attention.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94083
The original bug report was apparently lost in the sourceware/gcc migration
back in the spring and I didn't notice until now.
This testcase
int foo(void) {
volatile float f, g;
intn;
f = __builtin_huge_valf();
g = __builtin_h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #30 from Jim Wilson ---
Looking at your v2 patch, the first verison fails because you are passing
mismatched modes to emit_move_insn. The version with gen_lowpart solves that
problem, but fails because of infinite recursion.
The v4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #33 from Jim Wilson ---
I did say that I'm willing to fix code style issues. All major software
projects I have worked with have coding style conventions. It makes it easier
to maintain a large software base when everything is using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #35 from Jim Wilson ---
By combine issue, are you referring to the regression I mentioned in comment 3
and filed as bug 97747? We can handle that as a separate issue. It should be
uncommon. I expect to get much more benefit from th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #40 from Jim Wilson ---
If you look at riscv.opt you will see that the -mshorten-memrefs option sets
the variable riscv_mshorten_memrefs. If you grep for that, you will see that
it is used in riscv_address_cost in riscv.c. I believe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #42 from Jim Wilson ---
riscv_address_cost is a hook, so it is targetm.address_cost which is only
called from address_cost which is only called in a few places one of which is
in postreload.c so that is the one I would look at first.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98227
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98227
--- Comment #5 from Jim Wilson ---
My bootstrap with ada succeeded. I used the same configure options except for
--prefix. make check is still running.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #50 from Jim Wilson ---
The combine change is inconvenient. We can't do that in stage3, and it means
we need to make sure that this doesn't break other targets.
If the combine change is a good idea, then I think you can just modify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #51 from Jim Wilson ---
Created attachment 49773
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49773&action=edit
untested fix to use instead of levy's combine.c patch
Needs testing without Levy's patch to make sure it doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96700
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97182
--- Comment #5 from Jim Wilson ---
I see that a riscv64-linux libgomp.so has mutex calls and no obvious futex
calls. Though I find it a little curious that futex support isn't
auto-detected. There is already config/futex.m4 to detect futex supp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97183
--- Comment #3 from Jim Wilson ---
I installed Ubuntu 16.04 on an old laptop so I can directly reproduce the build
failure.
Checking for the zstd version looks like the easier patch.
Checking for specific macros and functions might be better, b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96700
Jim Wilson changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97183
--- Comment #7 from Jim Wilson ---
Fixed on mainline and the gcc-10 branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97183
Jim Wilson changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #52 from Jim Wilson ---
I did some simple testing of my patch alone. I modified the
riscv-gnu-toolchain makefile to use -Os to build all libraries, built a
rv32imac/ilp32 toolchain, and looked at library code size. I see a few cases
|NEW
Last reconfirmed||2021-01-14
CC||wilson at gcc dot gnu.org
--- Comment #1 from Jim Wilson ---
Part of the problem seems to be the use of volatile, as we disable
optimizations inside volatile operations, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98981
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98981
--- Comment #3 from Jim Wilson ---
I suppose cost model problems could explain why combine didn't do the
optimization. I didn't have a chance to look at that.
I still think there is a fundmental problem with how we represent SImode
operations,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99067
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
Jim Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Assignee: unassigned at gcc dot gnu.org
Reporter: wilson at gcc dot gnu.org
Target Milestone: ---
Given this testcase extracted from newlib
struct s
{
short s;
int i;
};
extern void sub2 (void);
extern void sub3 (void);
int
sub (struct s* t)
{
short i = t->s;
if ((i &a
Assignee: unassigned at gcc dot gnu.org
Reporter: wilson at gcc dot gnu.org
Target Milestone: ---
Enabling -gsplit-dwarf by default and trying a build hits an assert in
dw2_asm_output_delta_uleb128 because HAVE_AS_LEB128 is not defined.
The problem appears to be in output_loc_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99089
--- Comment #2 from Jim Wilson ---
I don't know if REE can do this optimization, but it is a good place to start
looking.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98981
--- Comment #4 from Jim Wilson ---
With this testcase
extern void sub2 (void);
void
sub (int *i, int *j)
{
int k = *i + 1;
*j = k;
if (k == 0)
sub2 ();
}
Compiling without the riscv_rtx_cost patch, I get
lw a5,0(a0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98981
--- Comment #5 from Jim Wilson ---
Neither of the two patches I mentioned in comment 1 can fix the problem by
themselves, as we still have a mix of SImode and DImode operations.
I looked at REE. It doesn't work because there is more than one re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94092
--- Comment #6 from Jim Wilson ---
Trying Alex's patch, it doesn't work on this testcase.
One problem is that the loop bound is unknown, so the memset size is estimated
as max 0x1fffc bytes. The code calls
default_use_by_pieces_infrastructu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99090
--- Comment #2 from Jim Wilson ---
Yes we could have partial uleb128 support. There is only a problem if at least
one label is in the code section.
There is another proposed solution to add special relaxable relocations for
uleb128 but the init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99090
--- Comment #5 from Jim Wilson ---
I tested it with a riscv-gnu-toolchain build and check. The 4 -gsplit-dwarf
testcases that fail without the patch work with the patch.
I also tried a build and check with -gsplit-dwarf enabled by default and
d
,
||wilson at gcc dot gnu.org
--- Comment #1 from Jim Wilson ---
Constant addresses are VOIDmode, and it only accepts Pmode and ptr_mode. It
should accept VOIDmode too. For instance cse_lookup_mem does this
addr_mode = GET_MODE (XEXP (x, 0));
if (addr_mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100348
Jim Wilson changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100348
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86387
Jim Wilson changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|ASSIGNED
||wilson at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #3 from Jim Wilson ---
Fixed on mainline.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98892
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98892
--- Comment #3 from Jim Wilson ---
On second thought, I don't think that there is anything wrong with
dg-*-multiline-output.
The problem is simply that the diagnostic code is left shifting the error
message by m_x_offset_display, and this left s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98892
--- Comment #4 from Jim Wilson ---
It turns out that -fmessage-length=0 doesn't work which is odd. I suspect a
latent bug in the diagnostic code.
I tried -fmessage-length=128, which should work as that is longer than the
error line, and does wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103302
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103302
--- Comment #3 from Jim Wilson ---
Maybe the register allocator should remove clobbers of pseudos, instead of
turning them into clobbers of hard register pairs. That would eliminate the
ambiguity after register allocation. It is also true that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103302
--- Comment #4 from Jim Wilson ---
See also bug 103271 which can also be fixed by adding a movti pattern.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271
--- Comment #6 from Jim Wilson ---
See also bug 103302 which can also be fixed by adding a movti pattern.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271
--- Comment #16 from Jim Wilson ---
I have a patch to add movti to the riscv port. I agree that we should be
adding this. I just unfortunately had a kitchen accident and had take some
time off before I finished it. I noticed that a comment be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271
Jim Wilson changed:
What|Removed |Added
CC||kito.cheng at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103302
--- Comment #11 from Jim Wilson ---
FYI I have a patch to re-add the movti pattern to riscv.md which should also
fix this and another bug. Kito removed the pattern in 2016 and I was hoping to
get an answer from him about why he removed it. The
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wilson at gcc dot gnu.org
Target Milestone: ---
This was originally reported here.
https://github.com/riscv/riscv-gcc/issues/289
This testcase is miscompiled at -O3 for a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102211
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102211
Jim Wilson changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102211
--- Comment #5 from Jim Wilson ---
I have a WIP fix that lets me build newlib and glibc via riscv-gnu-toolchain.
I haven't tried a bootstrap yet. I created a new predicate that uses the small
bit of deleted code I need from validate_subregs, a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102250
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102211
--- Comment #9 from Jim Wilson ---
Created attachment 51456
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51456&action=edit
proposed RISC-V backend solution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102211
--- Comment #10 from Jim Wilson ---
I attached a patch which is my proposed solution to the RISC-V backend. It
adds a new f_register_operand predicate and modifies patterns that use the f
constraint to use it instead of register_operand.
This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105733
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91602
--- Comment #14 from Jim Wilson ---
I posted a patch but didn't get a review, and then got distracted by other
stuff and failed to follow up.
https://gcc.gnu.org/pipermail/gcc-patches/2020-January/539461.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101996
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #4
301 - 400 of 402 matches
Mail list logo
