https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71722
--- Comment #4 from Bill Schmidt ---
Another possibility is all the vperm instructions, as this is little endian and
we might expect to see vpermr on occasion. That's hard to tell without digging
deeper.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71297
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71201
Bill Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||2016-07-07
Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
Summary|ICE on invalid code in |[7 regression] ICE on
|altivec_resolve_overloaded_ |invalid code in
|builtin (rs6000-c.c:5106
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71815
--- Comment #1 from Bill Schmidt ---
Interesting. How do we enable/disable code hoisting? I don't see a documented
option for this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71815
--- Comment #3 from Bill Schmidt ---
OK. I'm busy wrapping up some things before a vacation, but I'll plan to look
into this when I get back.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71297
--- Comment #3 from Bill Schmidt ---
Author: wschmidt
Date: Fri Jul 8 15:42:47 2016
New Revision: 238168
URL: https://gcc.gnu.org/viewcvs?rev=238168&root=gcc&view=rev
Log:
[gcc]
2016-07-08 Bill Schmidt
PR target/71297
* con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71297
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71805
--- Comment #7 from Bill Schmidt ---
*** Bug 71731 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71731
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71915
Bill Schmidt changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
||2016-07-25
Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #4 from Bill Schmidt ---
Confirmed. Will have a look soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72103
--- Comment #8 from Bill Schmidt ---
Per c#3, could we please have another bug opened to track the tragic code
generation opportunity? ;)
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
Target Milestone: ---
A statement such as "v = vec_splats (1);" correctly initializes a vector.
However, a statement such as "v[1] = v[
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72747
Bill Schmidt changed:
What|Removed |Added
Target||powerpc64le-unknown-linux-g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69847
--- Comment #14 from Bill Schmidt ---
Thanks, Vlad! I'll do some benchmarking with this patch in the next few days.
Much obliged!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69847
--- Comment #16 from Bill Schmidt ---
Hi Vlad,
I need to re-run my tests one more time because I goofed up the build on a few
of them; however, I was able to verify that the degradation on 403.gcc has now
gone away (I saw a slight improvement wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69847
--- Comment #17 from Bill Schmidt ---
Vlad, the patch checks out very well on powerpc64le. 403.gcc no longer
degrades. We are seeing some very nice improvements from LRA over reload on a
few benchmarks (435.gromacs leads the way with +9.5%). E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71815
--- Comment #5 from Bill Schmidt ---
I'll note that in the case where the stride is known (slsr-35.c), SLSR is
making at least a somewhat rational decision based on cost not to
strength-reduce the phi candidate. In this case the stride is a powe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71815
--- Comment #6 from Bill Schmidt ---
Actually, it looks like a similar problem for the unknown stride case. Again
there is logic that relies on single-reached-use for determining what
expressions go dead. We need to factor in expressions that g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71815
--- Comment #7 from Bill Schmidt ---
I have a prototype that fixes this in the obvious way and it causes both
slsr-35.c and slsr-36.c to pass again without turning off code hoisting. I'll
do a regstrap and then work on some benchmark testing. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71815
--- Comment #8 from Bill Schmidt ---
Created attachment 39085
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39085&action=edit
Patch under test
Attaching a patch that passes regstrap. I want to do a little benchmarking
before submitting i
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
Target Milestone: ---
Created attachment 39091
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39091&action=edit
C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72863
--- Comment #1 from Bill Schmidt ---
Egad. How appalling. I'll have a look soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72855
--- Comment #5 from Bill Schmidt ---
(In reply to Richard Biener from comment #2)
> If we have release checking enabled then we shuould hit
>
> static void
> df_analyze_1 (void)
> {
> ...
> #ifndef ENABLE_DF_CHECKING
> if (df->changeable_flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72855
--- Comment #6 from Bill Schmidt ---
(In reply to amker from comment #4)
> It reduces compile time for powerpc-elf on x86_64 machine from 54m to 5m.
> The compiler is configured with checking. With "--enable-checking=release",
> the current tru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71815
--- Comment #9 from Bill Schmidt ---
I'm not comfortable with the results of the patch. Overall I see a slight
improvement for SPECint CPU2006 and a slightly larger degradation for SPECfp
CPU2006. But there are some individual slowdowns that ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72863
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72863
--- Comment #3 from Bill Schmidt ---
This is a phase ordering issue involving the expanders for the built-ins. In
vsx.md:
;; Explicit load/store expanders for the builtin functions
(define_expand "vsx_load_"
[(set (match_operand:VSX_M 0 "vsx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72855
--- Comment #10 from Bill Schmidt ---
Some experiments on trunk:
- Using Bin's patch, I see compile time reduced to ~14 minutes.
- Using Richi's patch, I see compile time reduced to ~9 minutes.
So both are quite helpful compared to somewhere ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72863
Bill Schmidt changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72863
--- Comment #5 from Bill Schmidt ---
Regstrap passes. I'll prepare the formal patch tomorrow. Thanks for the
report!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72855
--- Comment #12 from Bill Schmidt ---
Last night before I ran out of time, I built a debug compiler on gcc-6-branch,
and flag_checking was always 0, and I didn't have the compile time issue. So
it appears to be something that only occurs with a
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
Target Milestone: ---
For the PowerPC64 ELF V2 ABI, homogeneous aggregates of vectors (any
combination of structs and arrays containing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74585
Bill Schmidt changed:
What|Removed |Added
Target||powerpc64*-*-*
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72863
--- Comment #6 from Bill Schmidt ---
Author: wschmidt
Date: Thu Aug 11 21:39:49 2016
New Revision: 239394
URL: https://gcc.gnu.org/viewcvs?rev=239394&root=gcc&view=rev
Log:
[gcc]
2016-08-11 Bill Schmidt
PR target/72863
* vsx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72855
--- Comment #14 from Bill Schmidt ---
Oh, I should have mentioned, it passed bootstrap with no regressions, so the
patch LGTM.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72855
--- Comment #15 from Bill Schmidt ---
For your patch submission, the testing was done on
powerpc64le-unknown-linux-gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72855
--- Comment #16 from Bill Schmidt ---
Author: wschmidt
Date: Thu Aug 11 22:20:41 2016
New Revision: 239395
URL: https://gcc.gnu.org/viewcvs?rev=239395&root=gcc&view=rev
Log:
2016-08-11 Richard Biener
Bill Schmidt
PR rtl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74585
--- Comment #5 from Bill Schmidt ---
(In reply to Richard Biener from comment #1)
> The issue is not SRA pushing things to memory - it doesn't. The issue is
> that in the GIMPLE IL the parameter appears as "memory" as it is an
> aggregate type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74585
Bill Schmidt changed:
What|Removed |Added
Component|tree-optimization |rtl-optimization
Summary|SRA f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74585
--- Comment #8 from Bill Schmidt ---
FYI, adding -mcpu=power9 to the options makes it much easier to read the RTL,
as it gets rid of the extra vector swaps needed for POWER8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74585
--- Comment #9 from Bill Schmidt ---
We do optimize things well for the following:
typedef struct
{
__vector double vx0;
__vector double vx1;
__vector double vx2;
__vector double vx3;
} vdoublex8_t;
vdoublex8_t
test_vecd8_rotate_left (v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74585
--- Comment #10 from Bill Schmidt ---
The dse pass is responsible for removing all the unnecessary stack activity. I
think that we are probably confusing it because the stores are full vector
stores, but the loads are vector element loads of sma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63491
--- Comment #16 from Bill Schmidt ---
Ping...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74585
--- Comment #11 from Bill Schmidt ---
With the original test case, -mcpu=power8 is problematic because of the use of
the "swapping stores," whose RHS is a vec_select rather than a register or
subreg. This prevents us from saving the RHS of the s
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
Target Milestone: ---
Testing the release candidate, I see a regression versus the 6.1 release when
compiling the referenced test. From
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77034
Bill Schmidt changed:
What|Removed |Added
Target||powerpc64-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74585
--- Comment #12 from Bill Schmidt ---
The rest of the ugly code (once you ignore the loads/stores) is horrible
choices of register allocation. Need to understand why we're not making use of
the high floating-point registers; too much copying bac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74585
--- Comment #14 from Bill Schmidt ---
(In reply to Richard Biener from comment #13)
>
> You mean stores like the following?
>
> (insn 13 12 14 2 (set (mem/c:V4SI (plus:DI (reg/f:DI 150 virtual-stack-vars)
> (const_int 112 [0x70]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72863
--- Comment #7 from Bill Schmidt ---
Author: wschmidt
Date: Thu Aug 25 14:24:17 2016
New Revision: 239761
URL: https://gcc.gnu.org/viewcvs?rev=239761&root=gcc&view=rev
Log:
[gcc]
2016-08-25 Bill Schmidt
Backport from mainline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72863
--- Comment #8 from Bill Schmidt ---
Author: wschmidt
Date: Thu Aug 25 16:12:23 2016
New Revision: 239762
URL: https://gcc.gnu.org/viewcvs?rev=239762&root=gcc&view=rev
Log:
[gcc]
2016-08-25 Bill Schmidt
Backport from mainline (minus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72863
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77405
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #2 from Bill Schmidt ---
See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77405 which appears to be
very similar (slight difference in the error message).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #6 from Bill Schmidt ---
Backtrace info (svn r239837):
Program received signal SIGSEGV, Segmentation fault.
system.secondary_stack.ss_release (m=...) at ../rts/s-secsta.adb:479
479 To_Stack_Ptr (M.Sstk).Top := M.Sptr;
(g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #7 from Bill Schmidt ---
It does look possible that this is an LRA issue. Here's the code right before
failure:
100dae08: f8 95 22 39 addir9,r2,-27144
100dae0c: 01 00 40 39 li r10,1
100dae10: 00 00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #11 from Bill Schmidt ---
(In reply to Eric Botcazou from comment #8)
> > I'm afraid I don't know anything about Ada and how its runtime works; it
> > looks like system.secondary_stack.ss_release is called automatically somehow
> > as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #12 from Bill Schmidt ---
(In reply to Eric Botcazou from comment #10)
> > So the double-word load before the call to SS_Release should be from a
> Mark_Id object obtained from a preceding call to SS_Mark. It indeed looks
> like the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #14 from Bill Schmidt ---
Confirmed that the frame pointer dance is where the issue is. Prior to dse2:
(insn 3854 144 4133 2 (set (reg:DI 9 9 [1674])
(const_int 1208 [0x4b8]))
/home/wschmidt/gcc/gcc-mainline-base/gcc/ada/\
m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #15 from Bill Schmidt ---
Created attachment 39520
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39520&action=edit
Dumps before and after dse2
Here are the full dumps before and after dse2 in tarball form.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #16 from Bill Schmidt ---
Looks like the back end must be inserting the frame pointer adjustments, as
they aren't there at expand time. From the 218.vregs dump:
(call_insn 141 140 3128 2 (parallel [
(set (reg:TI 3 3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #18 from Bill Schmidt ---
The frame pointer adjustments are introduced in 263r.split2. I haven't yet run
down the offending split, but the pattern being split is a *vsx_movti_64bit. I
know we've had changes in the back end fairly re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #19 from Bill Schmidt ---
I'm suspicious of rs6000_split_multireg_move in rs6000.c, which appears to be
the code that gets called to split a TImode move involving a GPR pair.
In particular, this code:
else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #21 from Bill Schmidt ---
I think for the purposes of this bug we should be able to work around it by
forcing the offset register to be modified instead of the base register. Going
to try testing this:
Index: gcc/config/rs6000/rs600
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #23 from Bill Schmidt ---
Bleah, that doesn't work because offsetreg needs to contain something that's a
valid address in order to use replace_equiv_address. So something more
involved is needed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #24 from Bill Schmidt ---
This seems to work as a short-term solution (c,c++,ada bootstrap succeeds).
Need to do a full regstrap with all the languages.
Index: gcc/config/rs6000/rs6000.c
=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96825
--- Comment #3 from Bill Schmidt ---
Is this going to be addressed in GCC 11? Should this be only a P3?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57547
Bill Schmidt changed:
What|Removed |Added
Assignee|kelvin at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
Resolution|--- |FIXED
--- Comment #4 from Bill Schmidt ---
Documentation fixed today to point to the master intrinsic reference document,
which has the vec_mul omissions fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94080
--- Comment #4 from Bill Schmidt ---
Thanks, Jonathan!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #10 from Bill Schmidt ---
But it seems we would also need a new constraint that does permit PC-relative
addresses, since new code will/may not have a TOC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #12 from Bill Schmidt ---
Right...but if somebody specifies an instruction with a 'p' that is
legitimately a pc-relative instruction, we don't want to say that the memory
operand can't use PC-relative addressing, do we? I just want t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #14 from Bill Schmidt ---
I agree, Peter.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94080
--- Comment #2 from Bill Schmidt ---
Let's see, with patches from late last year, can this be closed now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98325
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #14 from Bill Schmidt ---
We should definitely not be allowing the AltiVec "& ~16" flavors into these
patterns. I'm not certain whether your fix is the best way to achieve that,
but it could well be; I'll defer to Segher on that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98734
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100809
--- Comment #2 from Bill Schmidt ---
I believe this work is pending, but the patches are still under review.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100750
--- Comment #3 from Bill Schmidt ---
Fixed the BE problem. Will look into the GCC11 report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100750
--- Comment #4 from Bill Schmidt ---
I cannot reproduce failures for powerpc64le on P10 LE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100750
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100706
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100749
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100703
Bill Schmidt changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100930
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100930
--- Comment #2 from Bill Schmidt ---
Carl Love implemented these on trunk yesterday. They will be backported to GCC
11 in a week or so, at which point we can close this.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
Target Milestone: ---
This line appears in a recent patch committed this week:
+BU_P10V_AV_2 (VCMPEQUT,"vcmpequt", CONST,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101022
Bill Schmidt changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101022
--- Comment #2 from Bill Schmidt ---
Looks like the proper pattern should be altivec_eqv1ti.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101022
--- Comment #4 from Bill Schmidt ---
Hi Carl -- while you're in there, can you please remove these?
+BU_P10_OVERLOAD_2 (VRLQ, "vrlq")
+BU_P10_OVERLOAD_2 (VSLQ, "vslq")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100866
--- Comment #10 from Bill Schmidt ---
Right, it would be a good optimization. We've stopped focusing much on P8
optimization work at this point simply because of lack of resources.
The needed transform is to recognize load-xxlnor-vperm as a gr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100866
--- Comment #11 from Bill Schmidt ---
Segher, does this fit naturally in combine?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95082
Bill Schmidt changed:
What|Removed |Added
Known to fail|11.0|
Summary|[11] LE implementatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103622
Bill Schmidt changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
Target Milestone: ---
Per the PVIPR documentation, vec_cntlz_lsbb should generate vctzlsbb for little
endian, and vclzlsbb for big endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103981
Bill Schmidt changed:
What|Removed |Added
Ever confirmed|0 |1
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81953
Bill Schmidt changed:
What|Removed |Added
Status|ASSIGNED|NEW
--- Comment #6 from Bill Schmidt ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68212
Bill Schmidt changed:
What|Removed |Added
Assignee|kelvin at gcc dot gnu.org |unassigned at gcc dot
gnu.org
1501 - 1600 of 1697 matches
Mail list logo
