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=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
--- 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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271
Jim Wilson changed:
What|Removed |Added
CC||kito.cheng at gmail dot com
--- Comment
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
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=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
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 #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
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=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=102211
--- Comment #9 from Jim Wilson ---
Created attachment 51456
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51456=edit
proposed RISC-V backend solution
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 #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,
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
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102139
Bug ID: 102139
Summary: -O3 miscompile due to slp-vectorize on strict align
target
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101996
--- Comment #6 from Jim Wilson ---
Looking at Alpine Linux discussions, I see that it has a
--enable-autolink-libatomic configure option which links in libatomic by
default. This could break the libatomic autoconf tests that check to see if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101996
--- Comment #5 from Jim Wilson ---
A riscv-gnu-toolchain build with musl looks OK, so it looks like an Alpine
Linux problem.
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
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=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
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
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=100264
Jim Wilson changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86387
Jim Wilson changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|ASSIGNED
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=100348
Jim Wilson changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100316
Jim Wilson changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org,
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=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=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
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
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
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
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=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=99090
Bug ID: 99090
Summary: gsplit-dwarf broken on riscv64-linux
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99089
Bug ID: 99089
Summary: unnecessary zero extend before AND
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
Jim Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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=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=98596
Jim Wilson changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
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
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=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=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=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=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=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=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
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
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
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=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 =
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=97747
Bug ID: 97747
Summary: missed combine opt with logical ops after zero
extended load
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
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.
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 #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 #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
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
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
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
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
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=97409
Jim Wilson changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
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
CC||wilson at gcc dot gnu.org
--- Comment #7
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=97183
--- Comment #7 from Jim Wilson ---
Fixed on mainline and the gcc-10 branch.
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 #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,
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
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
75 matches
Mail list logo
