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
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
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
||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=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|
,
||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=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.
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
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
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
|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
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.
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 #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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97182
--- Comment #3 from Jim Wilson ---
libgomp works on riscv64-linux. It would only be riscv32-linux that is broken.
The riscv32 support was only just recently added to FSF glibc, and hasn't
appeared in a release yet, so arguably, there is no ABI
: bootstrap
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-gnu-toolchain/issues/718
A build of gcc 10 on Ubuntu 16.04 with the libzstd-dev package installed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96307
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96191
--- Comment #3 from Jim Wilson ---
The location of the canary is not known to the attacker. You are not supposed
to leak the address of the canary or the value of the canary. If you leak
either, then an attacker has a chance to restore the
Assignee: unassigned at gcc dot gnu.org
Reporter: wilson at gcc dot gnu.org
Target Milestone: ---
Given a simple testcase
extern int sub (int);
int
main (void)
{
sub (10);
return 0;
}
commpiling with -O -S -fstack-protector-all -mstack-protector-guard=global
in the epilogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96026
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95760
--- Comment #2 from Jim Wilson ---
I took another look, and it turns out that the should_duplicate_loop_header_p
for size/speed is not the only issue. There is also an issue in
tree-ssa-loop-ivopts.c when computing iv costs. With speed, the +4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95760
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95685
--- Comment #1 from Jim Wilson ---
The problem with the constant isn't apparent until we reach RTL generation and
see that it requires two instructions to load. Then once in RTL optimization
passes we have mostly block local optimizations that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95632
--- Comment #4 from Jim Wilson ---
Created attachment 48737
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48737=edit
proof of concept patch for changing xor with a large constant
needs cleanup and testing to be useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95632
--- Comment #3 from Jim Wilson ---
It isn't possible to have patterns that match only in combine. If we add a
pattern to accept (xor (reg) (large constant)) then it could match in any
optimization pass, and could prevent us from optimizing away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95637
--- Comment #3 from Jim Wilson ---
People have asked about constant pools before, but as far as I know no one has
tried to implement support for them yet.
We don't have a pc-relative load, so it would be a two instruction sequence
with auipc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95632
Jim Wilson changed:
What|Removed |Added
Last reconfirmed||2020-06-12
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95637
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84553
--- Comment #7 from Jim Wilson ---
I was ia64 maintainer when I wrote the patch, but couldn't test it. I'm not
the ia64 maintainer anymore. I suggest asking the current ia64 maintainer.
Though, oops, I see we don't have one listed in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95252
--- Comment #7 from Jim Wilson ---
I've got 3 new g++ testsuite failures. So we might still need an exact list of
USEs. I hadn't thought about RVE. That will have to be checked also.
RV32/RV64 shouldn't matter, as the mode in the USEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95252
--- Comment #5 from Jim Wilson ---
Created attachment 48625
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48625=edit
add uses to gpr_save pattern
the code using MASK_SAVE_RESTORE is just for testing purposes
unfinished, adds 3 new g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95252
--- Comment #4 from Jim Wilson ---
Created attachment 48624
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48624=edit
disable reg rename when -msave-restore
the code using MASK_SAVE_RESTORE is just for testing purposes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95252
--- Comment #3 from Jim Wilson ---
I tried both. Turning off register naming works. It gives a code size
decrease of about 0.003% for the libraries I looked at which can be ignored.
This probably also reduces performance; I didn't check that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95252
Jim Wilson changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95115
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94780
Bug 94780 depends on bug 94950, which changed state.
Bug 94950 Summary: [8/9 regression] ICE in gcc.dg/pr94780.c on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94950
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94950
Jim Wilson changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94950
--- Comment #5 from Jim Wilson ---
I tested it with an rv64gc-linux cross compiler. The patch fixes these
failures:
FAIL: gcc.dg/pr94780.c (internal compiler error)
FAIL: gcc.dg/pr94780.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92008
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #21
1 - 100 of 402 matches
Mail list logo
