--- Comment #1 from amodra at gmail dot com 2010-09-07 21:59 ---
Confirmed on powerpc-linux 4.6.0 20100905
$ ~/build/ppc/gcc-curr/gcc/g++ -B ~/build/ppc/gcc-curr/gcc/ -I
~/build/ppc/gcc-curr/powerpc-linux/libstdc++-v3/include/powerpc-linux -I
~/build/ppc/gcc-curr/powerpc-linux/libstdc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45807
Summary: Lying eh_frame r2 save info causes crashes with static
libgcc_eh and libstdc++
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45807
Alan Modra changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45807
--- Comment #4 from Alan Modra 2010-09-30 23:52:29
UTC ---
Caught out by sign extension rules.
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c(revision 1648
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46030
Summary: registers trashed with -Os
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
,
||powerpc64-linux
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2010.10.15 00:48:46
AssignedTo|unassigned at gcc dot |amodra at gmail dot com
|gnu.org |
Ever
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46221
Summary: huge number of c++ testsuite failures, libstdc++.so
alias missing
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46221
--- Comment #1 from Alan Modra 2010-10-29 05:38:59
UTC ---
Created attachment 22197
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22197
locale-inst.s 20101028
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46221
--- Comment #2 from Alan Modra 2010-10-29 05:40:02
UTC ---
Created attachment 22198
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22198
locale-inst.s 20101014
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46221
--- Comment #3 from Alan Modra 2010-10-29 13:01:34
UTC ---
I poked at this a little today. remove_unreachable_alias_pairs prunes the
alias_pair we need for some reason. I don't know my way around the cgraph code
well enough to figure out why..
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46221
--- Comment #4 from Alan Modra 2010-10-30 04:37:38
UTC ---
The one thing that makes the missing alias different from other aliases is that
its target is itself an alias. Hmm, that suggests a reduced C testcase might
be easy.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46221
--- Comment #5 from Alan Modra 2010-10-30 04:41:54
UTC ---
Created attachment 22203
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22203
aliases.i reduced C testcase
This reduced testcase shows lack of "wobbly" alias when compiled with gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46221
Alan Modra changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #6 fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46030
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46556
Summary: Code size regression in struct access
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46556
--- Comment #1 from Alan Modra 2010-11-21 23:09:13
UTC ---
I believe this code size regression is due to the fix for #32698. Before that
change, gcc calculated the offset for accessing the array elements as
n*4
64+n*4
128+n*4
After, we get
n*4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46556
Alan Modra changed:
What|Removed |Added
Status|NEW |UNCONFIRMED
Ever Confirmed|1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46556
--- Comment #4 from Alan Modra 2010-11-22 10:47:24
UTC ---
But within a loop gcc-4.2 looked quite reasonable too..
Don't we have a pass ordering problem if fwprop is to rewrite addresses? We
currently have cse1, fwprop1, loop passes, cse2, fwpr
gmail dot com
GCC target triplet: powerpc*-*-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44075
--
amodra at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |amodra at gmail dot com
|dot org
--- Comment #8 from amodra at gmail dot com 2010-05-20 04:31 ---
FWIW, Jakub's patch looks a reasonable fix to me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44199
: P3
Component: target
AssignedTo: amodra at gmail dot com
ReportedBy: amodra at gmail dot com
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44266
--
amodra at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
--- Comment #1 from amodra at gmail dot com 2010-05-25 13:42 ---
Created an attachment (id=20742)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20742&action=view)
fairly obvious fix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44266
--- Comment #2 from amodra at gmail dot com 2010-05-25 13:45 ---
Created an attachment (id=20743)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20743&action=view)
alternate fix using emit_library_call machinery
this one hasn't finished bootstrapping yet
--
http:/
--- Comment #3 from amodra at gmail dot com 2010-05-26 02:49 ---
and it contained a typo too. superceded by the patch in the patch url
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44266
--- Comment #2 from amodra at gmail dot com 2010-05-26 13:22 ---
I think this testcase may invoke undefined behaviour. Section 6.5.2.2 of the
ISO C spec says of function calls without a prototype that if "the types of the
arguments after promotion are not compatible with those o
--- Comment #12 from amodra at gmail dot com 2010-05-28 02:28 ---
This problem can be seen on powerpc-linux-gcc with the options -O1 -fPIC
-ftls-model=initial-exec -misel.
The error occurs between 172r.ira and 174r.postreload, not at 186r.dce as
previously reported.
--
amodra at
--- Comment #13 from amodra at gmail dot com 2010-05-28 02:31 ---
Created an attachment (id=20765)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20765&action=view)
ok at this point
--
amodra at gmail dot com changed:
What|Removed
--- Comment #14 from amodra at gmail dot com 2010-05-28 02:32 ---
Created an attachment (id=20766)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20766&action=view)
broken here, see insn 27
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44169
--
amodra at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |amodra at gmail dot com
|dot org
--- Comment #15 from amodra at gmail dot com 2010-05-28 13:16 ---
Created an attachment (id=20768)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20768&action=view)
gcc-4.4 patch
The underlying problem is that the load_toc_v4_PIC_1b rtl doesn't properly
describe tha
--- Comment #19 from amodra at gmail dot com 2010-06-03 03:26 ---
Fixed all active branches
--
amodra at gmail dot com changed:
What|Removed |Added
Status
--- Comment #6 from amodra at gmail dot com 2010-06-04 03:03 ---
Fixed mainline.
--
amodra at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from amodra at gmail dot com 2010-06-04 04:59 ---
fixed
--
amodra at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #19 from amodra at gmail dot com 2010-06-06 14:11 ---
Confirmed.
Regarding O1test.c:
Wierd set of gcc options, particularly -fno-dce and -fcaller-saves. I can't
see any sane reason why you would use those options on powerpc, unless you were
deliberately stress testin
--- Comment #20 from amodra at gmail dot com 2010-06-06 14:52 ---
My guess is that tc-lossings-floats.c hits an ira related problem, but I'm not
particularly familiar with that area of the compiler so won't look further
myself.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #1 from amodra at gmail dot com 2010-06-07 02:19 ---
First testcase in pr44364 tickles this bug on mainline too. Looks like we need
the following.
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000
--- Comment #1 from amodra at gmail dot com 2010-06-07 02:21 ---
*** This bug has been marked as a duplicate of 44067 ***
--
amodra at gmail dot com changed:
What|Removed |Added
--- Comment #2 from amodra at gmail dot com 2010-06-07 02:21 ---
*** Bug 44419 has been marked as a duplicate of this bug. ***
--
amodra at gmail dot com changed:
What|Removed |Added
--- Comment #22 from amodra at gmail dot com 2010-06-07 04:41 ---
Adding the following to config/rs6000/e500.h will likely fix the bug.
Testing..
#define HARD_REGNO_CALLER_SAVE_MODE(REGNO, NREGS, MODE) \
(TARGET_E500_DOUBLE && ((MODE) == DFmode || (MODE) =
--- Comment #4 from amodra at gmail dot com 2010-06-07 06:57 ---
Actually, that's the wrong patch. The correct one stops
rs6000_split_multireg_move being called in this case, by modifying
define_mode_iterator DIFD in rs6000.md.
--
amodra at gmail dot com changed:
--- Comment #25 from amodra at gmail dot com 2010-06-07 09:53 ---
Yes it seems the patch is not sufficient on 4.4. On mainline the code looks
good by inspection. (I don't have e500 hardware to run tests on.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #26 from amodra at gmail dot com 2010-06-07 10:29 ---
Doh! No, it's still broken on mainline too. I wasn't testing what I thought I
was...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #28 from amodra at gmail dot com 2010-06-07 17:05 ---
Please bootstrap and test this addition to e500.h
/* When setting up caller-save slots (MODE == VOIDmode) ensure we
allocate space for DFmode. Save gprs in the correct mode too. */
#define
--- Comment #5 from amodra at gmail dot com 2010-06-07 17:25 ---
Created an attachment (id=20859)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20859&action=view)
fix pr42427 fallout
Would someone with e500 hardware please bootstrap and regression test this
patch? I&#x
--- Comment #8 from amodra at gmail dot com 2010-06-07 23:33 ---
Reassigning since Edmar's identical patch predates mine.
--
amodra at gmail dot com changed:
What|Removed |
--- Comment #11 from amodra at gmail dot com 2010-06-09 00:29 ---
Fixed
--
amodra at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #41 from amodra at gmail dot com 2010-06-09 13:26 ---
Created an attachment (id=20877)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20877&action=view)
e500.h and caller-save.c patch
The ICE in #38 is due to a bug in caller-save.c
--
http://gcc.gnu.org/b
--- Comment #12 from amodra at gmail dot com 2010-06-16 03:14 ---
testsuite/gcc.dg/vect/pr44507.c is invalid on LP64. This:
curVal = *((unsigned long *)(&pArray[index]));
loads 8 bytes, ie. the last time around the loop this loads 4 bytes past the
end of the array. On big-en
--- Comment #3 from amodra at gmail dot com 2010-06-16 05:59 ---
Confirmed on powerpc-linux. check_fa tail calls check_fa_mid, ignoring the
fact that check_fa_mid is passed the address of a check_fa local var.
1510 :
1510: 94 21 ff e0 stwur1,-32(r1)
1514
--- Comment #6 from amodra at gmail dot com 2010-06-17 04:13 ---
Hmm. Well, perhaps the thing to do is ensure we don't get a tail call by
making the same change as in
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01726.html
Index: gcc/testsuite/gcc.c-torture/execute/frame-addr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49383
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #4 from
gcc dot |amodra at gmail dot com
|gnu.org |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49383
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
URL|
||2011.07.07 06:51:19
CC||amodra at gmail dot com
AssignedTo|unassigned at gcc dot |amodra at gmail dot com
|gnu.org |
Ever Confirmed|0 |1
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49665
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|NEW
AssignedTo|amodra at gmail dot
||2011.07.11 02:55:49
CC||amodra at gmail dot com
Ever Confirmed|0 |1
--- Comment #2 from Alan Modra 2011-07-11 02:55:49
UTC ---
Confirmed with powerpc64 20110706
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49941
Summary: segmentation fault in redirect_jump_2
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49941
Alan Modra changed:
What|Removed |Added
Priority|P1 |P3
Target Milestone|4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49941
--- Comment #2 from Alan Modra 2011-08-02 15:29:57
UTC ---
So, rebuild_jump_labels doesn't add back this JUMP_LABEL, because
mark_jump_label does as its comment says:
If INSN is a JUMP_INSN and there is at least one
CODE_LABEL referenced in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49941
--- Comment #5 from Alan Modra 2011-08-03 01:29:54
UTC ---
Bernd, that looks very similar to the patch I started to write. Then I saw the
comment in mark_jump_label_1
/* Do not change a previous setting of JUMP_LABEL. If the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49941
--- Comment #6 from Alan Modra 2011-08-03 02:43:18
UTC ---
Bernd, with your patch applied, bootstrap dies here:
In file included from
/home/amodra/src/gcc-virgin/libgcc/../libdecnumber/decQuad.c:140:0:
/home/amodra/src/gcc-virgin/libgcc/../libde
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49941
--- Comment #7 from Alan Modra 2011-08-03 03:07:13
UTC ---
The lurking problem being that copy_rtx_if_shared_1 needs to leave RETURN
shared, and I guess mark_used_flags doesn't need to do anything with RETURN
too.
||2011.08.03 10:44:10
CC|bernds at codesourcery dot |
|com |
AssignedTo|unassigned at gcc dot |amodra at gmail dot com
|gnu.org |
Ever Confirmed|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49941
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
gcc dot |amodra at gmail dot com
|gnu.org |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49972
Summary: Invalid .gcc_except_table with
-freorder-blocks-and-partition
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49972
--- Comment #1 from Alan Modra 2011-08-04 10:08:58
UTC ---
Created attachment 24913
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24913
faulty assembly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49972
--- Comment #2 from Alan Modra 2011-08-04 10:34:27
UTC ---
Entries in the call-site table for start of the instructions for the current
call site, and the pointer to the landing pad for this sequence of
instructions, are byte offsets from the lan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282
--- Comment #15 from Alan Modra 2011-08-05 16:23:04
UTC ---
Created attachment 24922
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24922
belt and braces fix for rs6000.c
This fix goes overboard to guard against possible future compiler cha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282
--- Comment #16 from Alan Modra 2011-08-05 16:29:02
UTC ---
Created attachment 24923
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24923
minimal rs6000.c fix
This fix just ensures we have a stack tie at the ABI_V4 stack reset. Note that
o
||amodra at gmail dot com
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
--- Comment #4 from Alan Modra ---
Comment #3 isn't showing any real problem. Where things go wrong is in ira
where the first strcpy call gets a bad REG_RETURNED note.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71709
--- Comment #5 from Alan Modra ---
Created attachment 38802
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38802&action=edit
fix
Cures the error in find_call_crossed_cheap_reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71709
--- Comment #7 from Alan Modra ---
find_call_crossed_cheap_reg is certainly confusing. On looking at it again
this morning, I can't see why it uses reg_overlap_mentioned_p to break out of
the loop. Who cares if the reg is referenced (except aut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71709
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||2016-07-05
CC||amodra at gmail dot com
Ever confirmed|0 |1
--- Comment #1 from Alan Modra ---
Confirmed. This long-standing reload problem won't be fixed until something
like https://gcc.gnu.org/ml/gcc-pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71763
--- Comment #4 from Alan Modra ---
Created attachment 38833
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38833&action=edit
output reloads on jump insns
Revised https://gcc.gnu.org/ml/gcc-patches/2004-12/msg00739.html
It's surprising how
||amodra at gmail dot com
Resolution|--- |FIXED
Target Milestone|7.0 |6.2
--- Comment #8 from Alan Modra ---
Fixed for gcc-7 and gcc-6.
||2016-07-26
CC||amodra at gmail dot com
Ever confirmed|0 |1
--- Comment #2 from Alan Modra ---
So, we are dealing with reloads for this insn:
(insn 488 206 406 31 (set (reg:DI 317)
(unspec:DI
gmail dot com|
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72103
Alan Modra changed:
What|Removed |Added
Keywords||ice-on-valid-code, patch
URL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72103
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71680
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71680
--- Comment #9 from Alan Modra ---
lra doesn't load in SFmode due to the following condition in
lra-constraints.c:simplify_operand_subreg
/* If we change address for paradoxical subreg of memory, the
address might violate the necessary al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72103
--- Comment #9 from Alan Modra ---
I looked, and decided there wasn't much we could do. So the main nastiness in
the sequence is the mem store/load, but that is just reload running out of regs
and spilling. Yes, it looks really dumb when viewin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71680
--- Comment #10 from Alan Modra ---
Arseny, I could not reproduce the problem using your testcase, and I tried a
dozen or so revisions around 20160626 buiding powerpc-e500v2-linux-gnuspe
cross-compilers on an x86_64-linux host. Please specify th
|ASSIGNED
URL||https://gcc.gnu.org/ml/gcc-
||patches/2016-08/msg00113.ht
||ml
Assignee|unassigned at gcc dot gnu.org |amodra at gmail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71680
--- Comment #13 from Alan Modra ---
The e500 issue is quite different, and is not fixed by my lra patch. From the
lra dump,
Creating newreg=436, assigning class NO_REGS to save r436
536: r192:SI=0x1
REG_EQUAL 0x1
Add reg<-save
||2016-08-04
CC|amodra at gcc dot gnu.org |amodra at gmail dot com
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
Ever confirmed|0 |1
--- Comment #1 from Alan Modra ---
"o" constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72802
--- Comment #3 from Alan Modra ---
wY is using mem_operand_gpr which is designed for gpr loads/stores. When -m32,
mem_operand_gpr does not enforce multiple-of-4 offsets.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71680
--- Comment #14 from Alan Modra ---
Created attachment 39056
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39056&action=edit
save SImode regs in SImode
Arseny, you might like to try this. I don't have the means at the moment to
properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72771
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #4
gcc dot gnu.org |amodra at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72771
--- Comment #5 from Alan Modra ---
> I'm wondering why this pattern even has a Z alternative
It would be nice to be able to edit bugzilla entries, to remove dumb comments
like that one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72771
Alan Modra changed:
What|Removed |Added
CC|amodra at gcc dot gnu.org, |
|amodra at gmail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72802
Alan Modra changed:
What|Removed |Added
CC|amodra at gmail dot com|
--- Comment #7 from Alan Modra
||2016-08-09
CC||amodra at gmail dot com
Ever confirmed|0 |1
--- Comment #1 from Alan Modra ---
combine goes into infinite recursion inside this call:
newpat = subst (newpat, i0dest, i0src, 0, 0, 0);
The args of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72802
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72853
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #5
701 - 800 of 872 matches
Mail list logo
