https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99392
Peter Bergner changed:
What|Removed |Added
Target|powerpc64-linux-gnu |powerpc-linux-gnu
--- Comment #2 from Pe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #19 from Peter Bergner ---
Fixed on trunk. Needs backporting to GCC10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99041
Peter Bergner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99279
--- Comment #5 from Peter Bergner ---
Fixed in gcc10 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96264
--- Comment #16 from Peter Bergner ---
(In reply to seurer from comment #15)
> It still fails on gcc 10, though
Vlad, can we get this backported to GCC 10? Maybe in time for GCC 10.3?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99842
Bug ID: 99842
Summary: MMA test case ICEs using -O3
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99842
Peter Bergner changed:
What|Removed |Added
Target||powerpc64le-linux
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #23 from Peter Bergner ---
(In reply to Richard Biener from comment #22)
> OK, so the fix here is quite obviously to simply drop the
> build_distinct_type_copy calls:
Thanks richi, I'll put the patch through a bootstrap/regtest cycle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #24 from Peter Bergner ---
(In reply to Richard Biener from comment #22)
>tree oi_uns_type = make_unsigned_type (256);
> - vector_pair_type_node = build_distinct_type_copy (oi_uns_type);
>SET_TYPE_MODE (vector_pai
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #26 from Peter Bergner ---
(In reply to Andrew Macleod from comment #25)
> (In reply to Peter Bergner from comment #24)
> > (In reply to Richard Biener from comment #22)
> > >tree oi_uns_type = make_unsigned_type (256);
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #27 from Peter Bergner ---
(In reply to Peter Bergner from comment #26)
> (In reply to Andrew Macleod from comment #25)
> > Wonder if it was suppose to be something like:
>
> Maybe? :-) I'll report back how the build does with this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #28 from Peter Bergner ---
(In reply to Andrew Macleod from comment #25)
> Wonder if it was suppose to be something like:
>
>
>/* Vector pair and vector quad support. */
>if (TARGET_EXTRA_BUILTINS)
> {
> - tree oi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #32 from Peter Bergner ---
(In reply to Richard Biener from comment #31)
> (In reply to Andrew Macleod from comment #30)
> > On 10/19/20 6:40 PM, bergner at gcc dot gnu.org wrote:
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=973
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #34 from Peter Bergner ---
(In reply to Peter Bergner from comment #32)
> (In reply to Richard Biener from comment #31)
> > > > Is this really the correct fix?
> >
> > Yes.
>
> Just to verify, this is an approval for Andrew's patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #37 from Peter Bergner ---
Fixed on trunk. I'll let this bake a week before backporting the rs6000 part
of the fix to GCC 10 (approved by Segher).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97543
Peter Bergner changed:
What|Removed |Added
CC||amodra at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97543
--- Comment #4 from Peter Bergner ---
Created attachment 49436
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49436&action=edit
patch file
So libgcc compiles are explicitly using -mlong-double-128, which doesn't seem
right when GCC is conf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
Peter Bergner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93176
--- Comment #5 from Peter Bergner ---
Alan, didn't one of your recent patches fix this particular bug? So can we
mark this as fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
Peter Bergner changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|acsawdey at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
Peter Bergner changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #21 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #20)
> (In reply to Peter Bergner from comment #18)
> > So why don't we default to the Altivec ABI with -m32 on cpus that have
> > Altivec and VSX units???
>
> H
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97947
Peter Bergner changed:
What|Removed |Added
Assignee|acsawdey at gcc dot gnu.org|bergner at gcc dot
gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97947
--- Comment #5 from Peter Bergner ---
(In reply to Marek Polacek from comment #2)
> We crash here
>
> 1143 /* Come here only for aggregates: records, arrays, unions, complex
> numbers
> 1144 and vectors. */
> 1145 gcc_assert (code == A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97947
Peter Bergner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93176
Peter Bergner changed:
What|Removed |Added
Assignee|bergner at gcc dot gnu.org |amodra at gcc dot
gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
Bug ID: 98519
Summary: rs6000: @pcrel unsupported on this instruction error
in pveclib
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #3 from Peter Bergner ---
(In reply to Michael Meissner from comment #2)
> That fell off the plate. I imagine we are going to need a hook with asm
> that makes sure none of the memory references are PC-relative.
I guess since we can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #13 from Peter Bergner ---
We are talking inline asm here, correct? If so, the user is fully in charge of
using the correct mnemonic. It just seems to me that "m" should always mean
non pc-relative addresses for all the existing inl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #20 from Peter Bergner ---
(In reply to Alan Modra from comment #18)
> Isn't this a bug in the assembly? We've changed the ABI, there is no way
> anyone can expect all old asm to work with power10 pcrel. To support pcrel
> you need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98872
Bug ID: 98872
Summary: ICE leads to SEGV on MMA test case
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98872
Peter Bergner changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98873
Peter Bergner changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98870
--- Comment #2 from Peter Bergner ---
*** Bug 98873 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98952
Peter Bergner changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98872
--- Comment #2 from Peter Bergner ---
The problem is caused by using an uninitialized __vector_quad (or
__vector_pair) variable. In those cases, initialize_uninitialized_regs()
detects that and emits an initialization via:
emit_move_insn (reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #7 from Peter Bergner ---
I cannot recreate the ICE with a native build. I'll try building a cross and
seeing if that exposes the issue for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #8 from Peter Bergner ---
(In reply to Martin Liška from comment #2)
> I do not set any default CPU:
The default cpu on ppc64le is (should be!) POWER8.
That said, I cannot recreate the issue with a cross build using current trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #11 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #10)
> The important difference from my auto-host.h to your auto-host.h which
> causes this ICE is that you don't have HAVE_LD_LARGE_TOC defined.
> Manually commenting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #12 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #10)
> The important difference from my auto-host.h to your auto-host.h which
> causes this ICE is that you don't have HAVE_LD_LARGE_TOC defined.
> Manually commenting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
Peter Bergner changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88197
Peter Bergner changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88197
--- Comment #3 from Peter Bergner ---
Actually, this looks like a combine issue. Before combine, we have:
(insn 124 123 125 3 (set (reg:V2DF 198 [ MEM [(void *)_75] ])
(mem:V2DF (reg:DI 149 [ ivtmp.49 ]) [0 MEM [(void *)_75]+0 S16
A8]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88197
--- Comment #4 from Peter Bergner ---
(In reply to Peter Bergner from comment #3)
> Actually, this looks like a combine issue. Before combine, we have:
Bah, wrong bug. Sorry!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99041
Bug ID: 99041
Summary: combine creates invalid address which ICEs in
decompose_normal_address
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99041
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99041
--- Comment #3 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #2)
> Combiner tries to combine whatever it can and if it matches (and costs
> suggest it is beneficial) it keeps it.
> So, this looks like a target bug to me.
> In par
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99041
Peter Bergner changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #6 from Peter Bergn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99041
--- Comment #9 from Peter Bergner ---
Fixed on trunk.
I will check whether we need this on the GCC10 branch as well. I believe we
probably will.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99041
--- Comment #10 from Peter Bergner ---
(In reply to Peter Bergner from comment #9)
> Fixed on trunk.
>
> I will check whether we need this on the GCC10 branch as well. I believe we
> probably will.
Confirmed, we need this on GCC10 as well. Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #15 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #10)
> The important difference from my auto-host.h to your auto-host.h which
> causes this ICE is that you don't have HAVE_LD_LARGE_TOC defined.
> Manually commenting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #16 from Peter Bergner ---
(In reply to Bill Schmidt from comment #14)
> 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #17 from Peter Bergner ---
(In reply to Peter Bergner from comment #16)
> The question I have is, there are 2 expanders which I think we also need to
> guard with similar tests. They are vsx_load_ and vsx_store_.
> Segher, I assume
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
Peter Bergner changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98872
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98777
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98722
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96264
Peter Bergner changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96178
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99279
Bug ID: 99279
Summary: ICE in rs6000_init_builtins when compiling using
-mcpu=440
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99279
Peter Bergner changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99279
Peter Bergner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085
--- Comment #6 from Peter Bergner ---
(In reply to Steven Munroe from comment #5)
> Any progress on this?
Sorry, not yet. We've been busy with P10 items and the gcc11 release. It is
on our list for looking into.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100537
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Target|arm-linux-g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99842
Peter Bergner changed:
What|Removed |Added
Known to fail||12.0
URL|https://gcc.gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100777
Bug ID: 100777
Summary: MMA builtin usage ICEs when used in a #pragma omp
parallel and using -fopenmp
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100777
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100777
Peter Bergner changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
Peter Bergner changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100909
Peter Bergner changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100407
Peter Bergner changed:
What|Removed |Added
CC||amodra at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100998
Peter Bergner changed:
What|Removed |Added
CC||acsawdey at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100998
--- Comment #4 from Peter Bergner ---
FYI, I'll give Gordon a build without that patch to test with and see if his
issue goes away with that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100998
Peter Bergner changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |acsawdey at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100998
--- Comment #7 from Peter Bergner ---
(In reply to Peter Bergner from comment #6)
> And you guessed well! I built a mainline compiler for Gordon with Aaron's
> commit reverted and the issue goes away. Assigning this to Aaron to debug.
Talking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100998
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085
--- Comment #11 from Peter Bergner ---
(In reply to luoxhu from comment #9)
> But for __float128 to __int128 mentioned in #c4, need hack
> rs6000_modes_tieable_p
> to remove the stack operation in dse1. But I am not sure this is *LEGAL*
> since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101002
--- Comment #1 from Peter Bergner ---
Are these tests valid for long double == double? Ie, do we just need to
disable them when using -mlong-double-64 or are these real bugs? I'm guessing
the latter for most of these tests, but just checking.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100777
--- Comment #3 from Peter Bergner ---
Fixed on trunk. I'll backport the fix to gcc11 and gcc10 after baking on trunk
for a day or two.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99842
Peter Bergner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100777
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108273
Peter Bergner changed:
What|Removed |Added
CC||jskumari at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108348
--- Comment #5 from Peter Bergner ---
(In reply to Kewen Lin from comment #1)
> diff --git a/gcc/config/rs6000/rs6000-call.cc
> b/gcc/config/rs6000/rs6000-call.cc
> index 59c51fa3579..6767a1f541c 100644
> --- a/gcc/config/rs6000/rs6000-call.cc
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108415
--- Comment #3 from Peter Bergner ---
(In reply to Kewen Lin from comment #2)
> The contradictory thing is that we can have TARGET_VSX and TARGET_SOFT_FLOAT
> (!TARGET_HARD_FLOAT) together with the proposed option combination. :)
I'm not sure w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757
Bug ID: 108757
Summary: We do not simplify (a - (N*M)) / N + M -> a / N
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757
Peter Bergner changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757
--- Comment #5 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #4)
> If N is a power of two optimising this to a/N is valid, but for other values
> of N it is not (division is not the inverse of multiplication in C). It also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757
--- Comment #7 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #6)
> No? Take a=59 as counterexample:
>
> (a - (N*M)) / N + M = (59 - 2*30)/30 + 2 = ~0UL/30 + 2
For unsigned integers, isn't having a < N*M UB so we're free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80175
Peter Bergner changed:
What|Removed |Added
Assignee|acsawdey at gcc dot gnu.org|unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107949
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
Peter Bergner changed:
What|Removed |Added
CC||amodra at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109073
Bug ID: 109073
Summary: __builtin_vsx_lxvp() doesn't allow a const
__vector_pair * operand in GCC 11 & 10
Product: gcc
Version: 11.3.1
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109073
Peter Bergner changed:
What|Removed |Added
CC||chip.kerchner at ibm dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109116
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #28 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #27)
> OTOH, it makes no sense to test if we have hard float. The pack and unpack
> builtins should work (and work the same) whenever long double is
> double-do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102976
Peter Bergner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104208
Peter Bergner changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104208
--- Comment #5 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #4)
> And in a compiler that defaults to -mlong-double128,
> -mabi=ieeelongdouble
> or
> -mabi=ibmlongdouble
> would be ok, but
> -mlong-double-64 -mabi=ibmlongdouble
1 - 100 of 572 matches
Mail list logo
