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=edit
work in progress patches for a fix
This implements two ways to fix it, a simple way that just fails for BLKmode,
and a
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89955
Jim Wilson changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=gcc=rev
Log:
RISC-V: Move STARTFILE_PREFIX_SPEC into target OS files.
gcc/
PR
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
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
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
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
||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=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
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.
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
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
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 C target, then we are
struck, as that can't be described. And if we can't
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.
||2019-08-12
CC||wilson at gcc dot gnu.org
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91602
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #3
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.
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=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,
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
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=gcc=rev
Log:
RISC-V: Fix bad insn splits with paradoxical subregs.
Shifting by more than the
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
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
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=edit
proposed patch to fix paradoxical reg in splitter problem
I get better code size with this alternative patch. I added
||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=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
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=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=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
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
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
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 #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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91229
Jim Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91229
--- Comment #3 from Jim Wilson ---
Author: wilson
Date: Thu Aug 8 19:04:56 2019
New Revision: 274215
URL: https://gcc.gnu.org/viewcvs?rev=274215=gcc=rev
Log:
RISC-V: Fix C ABI for flattened struct with 0-length bitfield.
gcc/
|NEW
Last reconfirmed||2019-07-22
Assignee|unassigned at gcc dot gnu.org |wilson at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jim Wilson ---
There is a psABI discussion about the problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91229
--- Comment #2 from Jim Wilson ---
Created attachment 46617
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46617=edit
proposed patch to change ABI and warn for affected structs
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wilson at gcc dot gnu.org
Target Milestone: ---
This was noticed by clang development, comparing clang against gcc to verify
ABI compliance.
There is a problem with the GCC
Assignee: unassigned at gcc dot gnu.org
Reporter: wilson at gcc dot gnu.org
Target Milestone: ---
It appears that vrp isn't propagating the ranges of incoming boolean arguments.
Given this example:
unsigned char reg(_Bool b) {
union U {
unsigned char f0;
_Bool
|--- |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
--- 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=gcc=rev
Log:
RISC-V: Fix more splitters accidentally calling gen_reg_rtx.
PR
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.
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=edit
untested fix to copy i2src earlier
works for testcase but otherwise untested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92263
Jim Wilson changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #9 from Jim Wilson
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92263
--- Comment #8 from Jim Wilson ---
Author: wilson
Date: Tue Nov 5 22:34:40 2019
New Revision: 277861
URL: https://gcc.gnu.org/viewcvs?rev=277861=gcc=rev
Log:
Allow libcalls for complex memcpy when optimizing for size.
The RISC-V backend wants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92263
--- Comment #6 from Jim Wilson ---
Looking at some other targets. ARM has movcc but not 128-bit long double.
Aaarch has movcc and 128-bit long double, but has 128-bit load/store so this is
only 4 instructions. mips64, powerpc64, and sparc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92263
Jim Wilson changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wilson at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92263
Jim Wilson changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92263
--- Comment #3 from Jim Wilson ---
I did a cross compiler build and check yesterday using up-to-date sources and
did not see this failure. I've been testing regularly. I did my build on an
x86_64 Ubuntu 16.04 machine with gcc-5.4 as the system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92263
--- Comment #4 from Jim Wilson ---
OK, I get it now. You are using non-standard optimization options with a
testsuite testcase. I can reproduce when I use your compiler options. I will
take a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92263
--- Comment #5 from Jim Wilson ---
The patch adds a RISC-V movcc pattern. This causes toplev.c to enable
flag_tree_cselim. This optimization pass creates a complex long double
conditional move via a phi node.
complex long double cstore_31;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92709
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91683
Jim Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
||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 -mcmodel
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
Jim Wilson changed:
What|Removed |Added
Attachment #46919|0 |1
is obsolete|
||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
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=gcc=rev
Log:
Extend subst to simplify CONST_INT inside SIGN_EXTEND.
This addresses PR 91860
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90883
--- Comment #32 from Jim Wilson ---
The proposed patch looks OK to me. I suggest you submit it to gcc-patches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92656
--- Comment #5 from Jim Wilson ---
A rewrite using dataflow would be better of course. I'm just trying to
understand the problem with this testcase better, and maybe find a simple
solution, but I don't think that there is one. The workarounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92656
--- Comment #3 from Jim Wilson ---
Looking at this, I see that the problem occurs in record_value_for_reg where it
does
if (!insn
|| (value && rsp->last_set_table_tick >= label_tick_ebb_start))
rsp->last_set_invalid = 1;
|--- |FIXED
Assignee|unassigned at gcc dot gnu.org |wilson at gcc dot
gnu.org
--- Comment #5 from Jim Wilson ---
Was fixed in gcc 9 last year.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91602
--- Comment #10 from Jim Wilson ---
The proposed binutils patch has multiple problems and has gone through multiple
iterations. Not clear when or if we will be able to accept it.
The gcc configure patch to eliminate the call to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91602
--- Comment #11 from Jim Wilson ---
Since Marxin pinged this and got me thinking about this again, I realized that
there is a simpler fix based on Serge's second suggestion. We can just delete
the gas version number from the uleb128 gas check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93532
--- Comment #11 from Jim Wilson ---
I'm able to reproduce with the gcc-8-branch now. Maybe I made a mistake with
my earlier build. Anyways, it looks like it is going wrong here in the reload
dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93532
--- Comment #12 from Jim Wilson ---
A bisection on mainline between the gcc-8 and gcc-9 releases shows that this
testcase was fixed by a combine patch for PR87600 that stops combining hard
regs with pseudos to reduce register pressure. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93532
Jim Wilson changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wilson at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93532
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93532
--- Comment #10 from Jim Wilson ---
Created attachment 47774
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47774=edit
testcase that reproduces for me
compile with -O2 -fPIC -fstack-protector-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90883
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #29
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93532
Jim Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93532
--- Comment #20 from Jim Wilson ---
Thanks for confirming that it solves the buildroot build problem.
My gcc mainline g++ test failure turned out to be a thread related issue with
qemu cross testing. The testcase works always on hardware, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93202
--- Comment #5 from Jim Wilson ---
Jakub's patch looks OK to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93202
--- Comment #7 from Jim Wilson ---
(In reply to Luís Marques from comment #3)
> Jim Wilson: I'm not using it, I was only working on the LLVM implementation.
> Could you please clarify if following modifiers are also internal only?
>
> 'C'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93304
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
--- Comment #4 from Jim Wilson ---
I tried some cross testing with rtl checking enabled, and found another rtl
check bug with the -msave-restore support in config/riscv/riscv-sr.c where it
uses XINT to read from a CONST_INT which is wrong, as it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
Jim Wilson changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
--- Comment #3 from Jim Wilson ---
Jakub's patch looks OK, and works for the testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
Jim Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93304
Jim Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93202
--- Comment #2 from Jim Wilson ---
%h is used for the gcc internal implementation of emitting auipc. I'm
skeptical that it is useful for asms. Stripping the HIGH rtx is an internal
implementation detail, and does not apply to asms, as you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93062
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93045
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93062
Jim Wilson changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Assignee: unassigned at gcc dot gnu.org
Reporter: wilson at gcc dot gnu.org
Target Milestone: ---
Given a testcase like this
int foo(void) {
volatile float f;
intn;
f = __builtin_huge_valf();
n += 1 - (f != __builtin_huge_valf());
return n;
}
and compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94044
--- Comment #9 from Jim Wilson ---
(In reply to Jakub Jelinek from comment #8)
> So perhaps to ease reproduction, tweak the hash function in this case to
> always return 0?
Yes, that works. I just didn't have a chance to look at the hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94136
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #3
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94044
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64697
--- Comment #24 from Jim Wilson ---
Joel Sherrill offered to create a binutils bug report for this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64697
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #22
201 - 300 of 402 matches
Mail list logo
