https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #13 from Peter Bergner ---
(In reply to Rich Felker from comment #12)
> > You can work around it on older GCC by simply not using a register var
> > for more than one asm operand, I think?
>
> Nope. Making a syscall inherently requir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #17 from Peter Bergner ---
(In reply to Rich Felker from comment #16)
> long syscall6(long n, long a, long b, long c, long d, long e, long f)
> {
> register long r4 __asm__("$4") = a;
> register long r5 __asm__("$5") = b;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #18 from Peter Bergner ---
(In reply to Rich Felker from comment #16)
> long syscall6(long n, long a, long b, long c, long d, long e, long f)
[snip]
> : "ir"(n), "r"(r4), "r"(r5), "r"(r6)
...and "n" is an argument regis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #25 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #23)
> Before RA we have asm inputs
> [
> (reg/v:SI 196 [ n ])
> (reg/v:SI 4 $4 [ r4 ])
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #37 from Peter Bergner ---
(In reply to Rich Felker from comment #30)
> The code has been working for the past 8 years with the "0"(r2) input
> constraint added, and would clearly be valid if r2 were pre-initialized with
> something.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94123
Peter Bergner changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #
at gcc dot gnu.org |bergner at gcc dot
gnu.org
--- Comment #8 from Peter Bergner ---
(In reply to Richard Biener from comment #7)
> Just default rules applied - the bug is new in GCC 10. Since it's also a
> testsuite regression it woudl be nice to at least make that clea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94123
Peter Bergner changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163
--- Comment #10 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #9)
> So what causes this TF vs. IF? Cross and native should be exactly the same,
> but perhaps there is a difference in the configurations you have for the two?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163
--- Comment #11 from Peter Bergner ---
(In reply to Bill Seurer from comment #8)
> Cross:
> ;;
> ;; Full RTL generated for this function:
> ;;
> (note 1 0 4 NOTE_INSN_DELETED)
> (note 4 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
> (insn 2 4 3 2 (set (me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #17 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #16)
> Any progress?
I'm sorry, I've been swamped with other things. Even so, given this (up to now
latent) bug has been there a while, and any patch here will affec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #19 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #18)
> Yes, we want to fix it, unless you want to revert the PR93658 change even
> for GCC 10 and reapply only to 11 once this bug is fixed too.
Ok, let me take anoth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94123
Peter Bergner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91804
--- Comment #2 from Peter Bergner ---
The copy us inserted by IRA's find_moveable_pseudos() function. The problem
seems to be that the new pseudo r134 has a different preferred reg class than
the original pseudo r133.
r134: preferred VSX_R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #21 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #20)
> Have you managed to make some progress? This is one of the last 10 P1
> blockers of the release.
I'm still working on it. I have a patch that fixes the issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #22 from Peter Bergner ---
To be more specific, I have implemented the hook cannot_substitute_mem_equiv_p
for rs6000 that rejects these and: altivec addresses. The nice thing about the
patch is that it only affects rs6000, whereas a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
Peter Bergner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51513
Peter Bergner changed:
What|Removed |Added
Status|CLOSED |REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94740
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94740
--- Comment #3 from Peter Bergner ---
Here's a simpler test case that fails the same way:
int array[8];
int
foo (void)
{
return __builtin_bswap32 (array[1]);
}
So before CSE, we have:
(insn 5 2 6 2 (set (reg/f:DI 121)
(sym
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94740
--- Comment #4 from Peter Bergner ---
Removing the bswap and recompiling, the non-bswap load pattern has no problem
accepting an address like that, so this looks like a target issue with that
pattern.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94740
Peter Bergner changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94740
Peter Bergner changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94740
Peter Bergner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95952
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95952
--- Comment #5 from Peter Bergner ---
(In reply to Peter Bergner from comment #4)
> I can help you build a default32 gcc if just adding -m32 to your
> compile doesn't ICE on the test case.
I should mention, it's not as easy as just configuring w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96017
--- Comment #4 from Peter Bergner ---
To be pedantic, "val" is assigned r3, the incoming arg reg. The compiler
temporary that holds "*val" is assigned r9 which is a volatile register. The
only non-volatile in use is r31 which was assigned to ho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96017
--- Comment #6 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #5)
> But it is r31 already before
> shrink-wrapping -- we need some renaming / copying of registers (like
> in Peter's code) to get rid of it. In an example like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96017
--- Comment #7 from Peter Bergner ---
(In reply to Peter Bergner from comment #6)
> There is ira.c:split_live_ranges_for_shrink_wrap(). I'll have a look to see
> why it's not catching this test case.
So it looks like it only splits pseudos tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96017
--- Comment #8 from Peter Bergner ---
Interesting, if I rewrite the test case so that foo is a parameter and not a
global var, then we get the code we want:
extern void slowpath(int *);
int
test (int *val, int foo)
{
int ret = foo;
if (__b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96017
--- Comment #9 from Peter Bergner ---
(In reply to Peter Bergner from comment #8)
> At first, I thought that split_live_ranges_for_shrink_wrap() split this
> nicely, but what I found is that IRA assigned a volatile register to a
> pseudo that is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95952
--- Comment #11 from Peter Bergner ---
(In reply to Mikael Pettersson from comment #9)
> binutils-2.23.88.0.1-13.fc20.ppc64
>
> I can build a recent binutils release and retry the gcc-8 bootstrap with
> that tomorrow. But since gcc-9/10/11 all
ty: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
__attribute__((target("cpu=power10,mma"))) should set TARGET_MMA within the
compiler. It doesn't, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96125
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=96125
--- Comment #2 from Peter Bergner ---
Looks like some missing code in rs6000_option_override_internal() to enable
TARGET_MMA by default when -mcpu=power10 is used, similar to how we handle
-mprefix. I'm testing a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96125
--- Comment #3 from Peter Bergner ---
Actually, it's more complicated than that. We only initialize the target
builtins once, using the command line option values and not again using the
target attribute/pragma values. That means we basically h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96125
Peter Bergner changed:
What|Removed |Added
Target Milestone|--- |10.2
--- Comment #5 from Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96125
Peter Bergner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94393
--- Comment #5 from Peter Bergner ---
(In reply to Alan Modra from comment #3)
> There are two parts to fixing this PR.
> 1) We can do better in the sequences generated for some constants.
> 2) rs6000_rtx_costs needs to be accurate, so that expen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488
Peter Bergner changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #1 from Peter Bergne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87949
--- Comment #13 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #12)
> Wow, this works! Mine :-)
Hi Segher, did you ever commit anything to help here? Ie, can we mark this as
fixed or is it still an open issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488
--- Comment #3 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #2)
> Doing everything but the final conversion down in round-to-odd mode works
> correctly always. It's magic :-)
Ok, so Paul's sequence is what we want and we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488
--- Comment #4 from Peter Bergner ---
So the following pattern added to dfp.md:
+(define_insn "trunctdsd2"
+ [(set (match_operand:SD 0 "gpc_reg_operand" "=d")
+ (float_truncate:SD (match_operand:TD 1 "gpc_reg_operand" "d")))
+ (clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488
--- Comment #7 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #5)
> operands[2] needs an earlyclobber as well (it is written while some
> operands are still read later). Everything else is fine as far as I
> can see :-)
I o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488
--- Comment #8 from Peter Bergner ---
(In reply to Peter Bergner from comment #7)
> If you still want operands[2] marked early clobber, I can do that.
Segher set me straight offline on why we need that early clobber too.
I'll kick off testing wi
erity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
The __builtin_mma_disassemble_acc built-in doesn't correctly account for little
endian byte ordering of the po
||2020-07-17
Ever confirmed|0 |1
Target||powerpc64le-linux
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
--- Comment #1 from Peter Bergner ---
Mine. This is broken in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488
Peter Bergner changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
at gcc dot gnu.org |bergner at gcc dot
gnu.org
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
--- Comment #1 from Peter Bergner ---
Confirmed. I have already pushed an obvious patch to fix the test case asm
count when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96236
--- Comment #3 from Peter Bergner ---
Fixed on trunk. I will backport to the GCC 10 release branch once it reopens.
I would have set the target milestone to 10.3, but that version isn't an option
right now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96236
Peter Bergner changed:
What|Removed |Added
Target Milestone|--- |10.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96236
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95907
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=94826
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
We get an ICE when we are forced to spill an MMA accumulator that has a zero
value. We seem to be missing a alternative that accepts the value zero in the
move pattern. This is
|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
CC||dje at gcc dot gnu.org,
||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96446
--- Comment #3 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #2)
> *movpxi tries to not split xxsetaccz insns, but that one is only for
> fpr_reg_operand as operands[0], while *movpxi uses something more
> general.
As we di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96446
Peter Bergner changed:
What|Removed |Added
Target Milestone|--- |10.3
--- Comment #5 from Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96493
--- Comment #1 from Peter Bergner ---
We will want this backported to GCC 10 too, correct?
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
We ICE on the following invalid code. It's invalid because we do not support
passing __vector_quad or __vector_pair as function arguments or as function
return v
|UNCONFIRMED |ASSIGNED
Target||powerpc*-*
Ever confirmed|0 |1
Keywords||ice-on-invalid-code
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96493
Peter Bergner changed:
What|Removed |Added
Target Milestone|--- |10.3
--- Comment #4 from Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96525
--- Comment #1 from Peter Bergner ---
This is an assembler error saying it doesn't know about .machine "power10".
Are you sure you're not using an old binutils?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96525
--- Comment #2 from Peter Bergner ---
Ah, you probably are and this issue is the test case probably needs a:
/* { dg-require-effective-target power10_ok } */
To ensure we have a working power10 enabled binutils.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96525
--- Comment #3 from Peter Bergner ---
(In reply to Peter Bergner from comment #2)
> Ah, you probably are and this issue is the test case probably needs a:
>
> /* { dg-require-effective-target power10_ok } */
>
> To ensure we have a working powe
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
We need to accept typedefs of MMA types too:
typedef __vector_quad vquad_t;
void
foo (__vector_quad *dst)
{
__builtin_mma_xxsetaccz (dst);
}
void
bar (vquad_t *dst
|UNCONFIRMED |ASSIGNED
Last reconfirmed||2020-08-07
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
CC||dje at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96530
Peter Bergner changed:
What|Removed |Added
Target Milestone|--- |10.3
--- Comment #3 from Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96530
Peter Bergner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96446
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96525
--- Comment #5 from Peter Bergner ---
(In reply to Alan Modra from comment #4)
> I could make the test { do-do link } but running the test is just that
> little bit better test of the linker output, and as far as I know there
> isn't a way of say
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96525
--- Comment #7 from Peter Bergner ---
(In reply to seurer from comment #6)
> That changed the test to unsupported on the p8 where it had failed
> previously.
[snip]
> # of unsupported tests1
That is what I would expect on a syste
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95581
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96493
--- Comment #5 from Peter Bergner ---
I think this has baked on trunk enough now. Can we get this backported to GCC
10 along with the updated test case fix from PR96525? I'd like to merge this
along with some other backports I have done into th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96506
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
bergner@pike:~/$ cat bug.c
void
test (__vector_quad *dst, vector unsigned char vc)
{
__vector_quad vq[2];
__builtin_mma_xxsetaccz(&am
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96808
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=85830
Peter Bergner changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |carll at gcc dot gnu.org
Last r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96808
--- Comment #2 from Peter Bergner ---
Fixed on trunk. I'll backport the fix to GCC 10 after a little burn in on
trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96808
Peter Bergner changed:
What|Removed |Added
Target Milestone|11.0|10.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96808
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #5 from Peter Bergner ---
(In reply to seurer from comment #3)
> That said, should the dg-require-effective-target fortran_real_16 "work" on
> powerpc64?
REAL*16 is a 16 byte double, correct? Ie, our long double? Therefore, it
shou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
Peter Bergner changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97013
--- Comment #1 from Peter Bergner ---
Are you saying we now vectorize the pr80695-p8.c test case when we expected not
to? What asm code are we generating now with richi's patch?
||il/gcc-patches/2020-Septemb
||er/553661.html
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #15 from Peter Bergner ---
On POWER, we see with an unpatched compiler, where long double == IBM double
double format:
(gdb) p gfc_float128_type_node
$16 = (tree) 0x0
(gdb) p gfc_real_kinds[0]
$17 = {epsilon = {{_mpfr_prec = 24, _mp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #16 from Peter Bergner ---
I don't know why gfc_real_kinds[2].mode_precision is 127, but I guess that is
what is causing us to trigger the assert.
When I tried adding -mfloat128 -mabi=ieeelongdouble to switch us to using
IEEE128 as o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #17 from Peter Bergner ---
(In reply to Peter Bergner from comment #16)
> I don't know why gfc_real_kinds[2].mode_precision is 127, but I guess that
> is what is causing us to trigger the assert.
>
> When I tried adding -mfloat128 -m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #18 from Peter Bergner ---
(In reply to Peter Bergner from comment #17)
> const poly_uint16_pod mode_precision[NUM_MACHINE_MODES] =
> {
> ...
> { 4 * BITS_PER_UNIT }, /* SF */
> { 8 * BITS_PER_UNIT }, /* DF */
> { 126 },
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97057
--- Comment #3 from Peter Bergner ---
(In reply to seurer from comment #2)
> Sorry. I am still seeing a compilation error and bisect erroneously traced
> it here.
FYI, the actual bootstrap issue was due to one of Mike's recent patches. Alex
de
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
Created attachment 49237
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49237&action=edit
preprocessed te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97098
--- Comment #1 from Peter Bergner ---
Added richi to CC since vect_bb_slp_mark_live_stmts() is a new function he
recently added.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #3 from Peter Bergner ---
(In reply to Richard Biener from comment #2)
> Btw, with -ffast-math (or -Ofast) on x86 you get fmod inlined, I guess xlf
> -O5
> is to some extent doing -ffast-math?
Xlf at -O3, -O4 and -O5 automatically en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
Peter Bergner changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #9 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #8)
> I don't think we have an instruction for that? But we can inline the
> code we need instead of doing a library call, which is much faster.
> (We probably ca
Component: libffi
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
When building libffi with -mcpu=power10, we're seeing the following linker
error.
libtool: link: gcc -shared -fPIC -DPIC src/.libs/prep_cif.o src/.libs/types.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97166
Peter Bergner changed:
What|Removed |Added
Known to fail||10.0
--- Comment #1 from Peter Bergner
||bergner at gcc dot gnu.org
Resolution|FIXED |---
--- Comment #31 from Peter Bergner ---
(In reply to Christophe Lyon from comment #30)
> Since this was backported to gcc-8-branch, I've noticed:
> FAIL: gfortran.dg/pr51434.f90 -O2 exe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84613
Bug 84613 depends on bug 84487, which changed state.
Bug 84487 Summary: [8/9 Regression] Large rodate section increase in 465.tonto
with r254427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487
What|Removed |
1 - 100 of 1436 matches
Mail list logo
