On 3/1/18 7:45 PM, Segher Boessenkool wrote:
> On Wed, Feb 28, 2018 at 09:59:27PM -0600, Peter Bergner wrote:
>> PR target/84534
>> * gcc.target/powerpc/vec-setup-be-long.c: Add dg-xfail-run-if
>> on powerpc64le*-*-linux*.
>
> (wrong indent: should b
for trunk?
Peter
gcc/
PR target/84264
* config/rs6000/vector.md:
gcc/testsuite/
PR target/84264
* g++.dg/pr84264.C: New test.
Index: gcc/config/rs6000/vector.md
===
--- gcc/config/rs6000/vector.md
On 3/4/18 4:00 AM, Jakub Jelinek wrote:
> On Sat, Mar 03, 2018 at 10:55:28PM -0600, Peter Bergner wrote:
>> gcc/
>> PR target/84264
>> * config/rs6000/vector.md:
>
> The ChangeLog entry needs fixing.
>
> Otherwise I'll defer to powerpc maintainers
h and bootstrap & regtesting showed no
regressions. Committed to the GCC 7 branch.
Peter
On 3/5/18 8:55 AM, Segher Boessenkool wrote:
> On Sat, Mar 03, 2018 at 10:55:28PM -0600, Peter Bergner wrote:
>> The simple fix here is to just verify the memory_operand is not an altivec
>> mem operand before calling rs6000_emit_le_vsx_move.
>>
>> This passed
might not dominate the longjmp call.
Peter
t and reg+reg addresses.
This passed bootstrap and regtesting on powerpc64-linux, running the
testsuite in both 32-bit and 64-bit modes with no regressions.
Ok for trunk?
Peter
gcc/
PR target/83969
* config/rs6000/rs6000.c (rs6000_offsettable_memref_p): New prototype.
On 3/7/18 6:50 PM, Peter Bergner wrote:
> This passed bootstrap and regtesting on powerpc64-linux, running the
> testsuite in both 32-bit and 64-bit modes with no regressions.
> Ok for trunk?
FYI, this also passed bootstrap and regtesting on powerpc64le-linux
without regressions also.
Peter
On 3/9/18 1:31 PM, Segher Boessenkool wrote:
> On Wed, Mar 07, 2018 at 06:50:41PM -0600, Peter Bergner wrote:
>> This passed bootstrap and regtesting on powerpc64-linux, running the
>> testsuite in both 32-bit and 64-bit modes with no regressions.
>> Ok for trunk?
>
>
won't
be able to commit the patch until I return. Unless you want to commit
it Segher and watch for fallout. It's up to you.
Peter
PR target/83789
* config/rs6000/altivec.md (altivec_lvx__2op): Delete define_insn.
(altivec_lvx__1op): Likewise.
(al
On 3/12/18 1:55 PM, Segher Boessenkool wrote:
> On Sun, Mar 11, 2018 at 10:23:02AM -0500, Peter Bergner wrote:
>> +; The following patterns embody what lvx should usually look like.
>> +(define_expand "altivec_lvx_"
>> + [(set (match_operand:VM2 0 "register_ope
On 3/20/18 11:42 AM, Segher Boessenkool wrote:
> On Mon, Mar 19, 2018 at 09:12:08PM -0500, Peter Bergner wrote:
>> Looking at mu build dirs insn-modes.h, I don't see HAVE_V8HFmode being
>> defined on either my LE or BE builds. What am I missing?
>
> Nothing, I just was
gt; + exp, target, false);
> case ALTIVEC_BUILTIN_LVX_V4SF:
>return altivec_expand_lv_builtin (CODE_FOR_altivec_lvx_v4sf_2op,
> exp, target, false);
FYI, these hunks will need updating due to the fix for PR83789 which
I just committed to trunk.
Peter
UNSPEC_FCTIW))]
"TARGET_SF_FPR && TARGET_FPRND"
"fctiw %0,%1"
[(set_attr "type" "fp")])
Peter
* doc/extend.texi: Add four new prototypes for vec_ld.
>
> gcc/testsuite/ChangeLog:
>
> 2018-03-14 Kelvin Nilsen
>
> * gcc.target/powerpc/altivec-ld-1.c: New test.
You'll also need to add:
PR target/84760
...to both ChangeLog entries.
Peter
On 3/20/18 12:27 PM, Peter Bergner wrote:
> On 3/20/18 11:42 AM, Segher Boessenkool wrote:
>> On Mon, Mar 19, 2018 at 09:12:08PM -0500, Peter Bergner wrote:
>>> Looking at mu build dirs insn-modes.h, I don't see HAVE_V8HFmode being
>>> defined on either my LE
On 3/21/18 7:37 PM, Segher Boessenkool wrote:
> On Wed, Mar 21, 2018 at 12:47:41PM -0500, Peter Bergner wrote:
>> I'll note that GCC 7 does not need any of the changes to rs6000-p8swap.c,
>> since that file doesn't exist and doesn't need to exist in GCC 7, so
wing
patch submission and what its ChangeLog entries look like:
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01869.html
Peter
you commit the patch. If you post a patch with a date stamp
and you commit it a different day, you need to update the date stamp.
Most people leave the date stamp (not the one after the Backport from
mainline) out of their patch submissions, since they don't know ahead
of time when they will commit it.
Peter
On 3/21/18 12:47 PM, Peter Bergner wrote:
> Kaushik confirmed this is broken on GCC 7 as well. Ok to backport
> this patch to GCC 7, assuming regtesting is clean?
FYI, bootstrap and regtesting on both powerpc64le-linux and
powerpc64-linux (testsuite run in both 32-bit and 64-bit modes
their
associated documentation. The next patch will cure the remaining ICEs.
This passed bootstrap and regtesting on powerpc64-linux with no regressions.
Ok for mainline?
Do we want this backported to the open release branches too?
Peter
gcc/
PR target/84912
* config/rs6000/r
error message in the case it is not set.
This passed bootstrap and regtesting on powerpc64-linux with no regressions.
Ok for mainline?
Do we also want this backported to the open release branches too?
Peter
gcc/
PR target/84912
* config/rs6000/rs6000.h (RS6000_BTM_POWERPC64): New
On 3/22/18 6:03 PM, Segher Boessenkool wrote:
> On Wed, Mar 21, 2018 at 09:10:38PM -0500, Peter Bergner wrote:
>> If you're asking about whether we also need to backport to GCC 6, I
>> believe Kaushik said in the bugzilla that he only encountered the
>> ICE on GCC 7 and
Bill pointed out the following test case has been failing since January.
It ends up it needs the same fixup that the builtins-1-be.c test case got.
Segher approved this offline. Committed.
Peter
* gcc.target/powerpc/builtins-1-le.c: Filter out gimple folding disabled
message
d regtesting with no regressions on powerpc64-linux.
Ok for trunk?
Peter
gcc/
PR rtl-optimization/84878
* ddg.c (add_cross_iteration_register_deps): Skip over uses that do
not correspond to explicit register references.
gcc/testsuite/
PR rtl-optimization/84878
On 3/27/18 3:18 AM, Richard Biener wrote:
> On Mon, 26 Mar 2018, Peter Bergner wrote:
>>/* Create inter-loop true dependences and anti dependences. */
>>for (r_use = DF_REF_CHAIN (last_def); r_use != NULL; r_use = r_use->next)
>> {
>> + /* PR848
ower7 (or newer)", "-m64 or -mpowerpc64");
>
> This does not work for translation, and it quotes the wrong things.
> Each %qs should be for exactly one option string.
I'm confused. :-) What is it I need to do to fix this? I just cut/pasted
usage higher up in the function, so does that need fixing too or ???
Peter
mpowerpc64");
>
> I don't see other such strings that quote incorrectly?
Ah, I guess I misunderstood what you were saying. So ok for trunk
with that change then?
Peter
On 3/28/18 4:13 PM, Segher Boessenkool wrote:
> On Wed, Mar 28, 2018 at 01:57:34PM -0500, Peter Bergner wrote:
>> On 3/28/18 12:59 PM, Segher Boessenkool wrote:
>>> It should be something like
>>>
>>> +error ("builtin function %qs requires the %qs
h cause an error too on different test case:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85123#c2
I've closed PR85123 as a dup of PR84762, even though the test case
in PR84762 is failing for -m32 while the test case in PR85123 is
failing for -m64, since they're both caused by the same bug.
Peter
d an automated response saying Tamar is away on vacation
with no return date specified. That means he won't be able to revert
the patch. What do we do now?
Peter
re we generate better code than before (ie, we don't load values
into VSX registers just use a direct move them into a GPR register).
Is this ok for trunk? This is marked as a GCC7 and GCC8 regression,
so ok for GCC 7 too after it has baked on trunk for a while?
Peter
PR target/80546
On 2/8/18 2:44 PM, Peter Bergner wrote:
> I have committed the following obvious testsuite patch to fix PR81143.
> The "bug" is that __ORDER_LITTLE_ENDIAN__ is always defined for both
> little and big endian compiles. I checked and this is the only use
> of this in
On 3/28/18 7:21 PM, Segher Boessenkool wrote:
> On Wed, Mar 28, 2018 at 07:13:36PM -0500, Peter Bergner wrote:
>> Do we care enough to fix these on the release branches? If so, I
>> can backport them easily, since they're not that involved.
>> I'll leave it up to y
On 3/30/18 6:15 PM, Segher Boessenkool wrote:
> But okay (with the fixes), and okay for 7. Thanks!
Ok, committed now to trunk and GCC 7 with your suggestions. Thanks!
Peter
ething like the following what
we want?
This did pass bootstrap and regtesting with no regressions on powerpc64-linux
running the testsuite in both 32-bit and 64-bit modes.
Peter
gcc/
PR rtl-optimization/84878
* ddg.c (add_cross_iteration_register_deps): Use DF_REF_BB to deter
On 4/3/18 1:40 PM, H.J. Lu wrote:
> On Tue, Apr 3, 2018 at 11:36 AM, Peter Bergner wrote:
>> gcc/testsuite/
>> PR rtl-optimization/84878
>> * gcc.dg/pr84878.c: New test.
>
> Wrong test filename.
Ooops, thanks for spotting that! Will fix.
Peter
hen it's ready, I'll do bootstrap and regression
testing on powerpc*-linux and verify it fixes the issues we hit.
Peter
On 4/4/18 2:15 AM, Richard Biener wrote:
> On Tue, 3 Apr 2018, Peter Bergner wrote:
>
>> On 4/3/18 1:40 PM, H.J. Lu wrote:
>>> On Tue, Apr 3, 2018 at 11:36 AM, Peter Bergner wrote:
>>>> gcc/testsuite/
>>>> PR rtl-optimization/84878
>>>
On 4/4/18 10:43 AM, Peter Bergner wrote:
> On 4/4/18 2:15 AM, Richard Biener wrote:
>> On Tue, 3 Apr 2018, Peter Bergner wrote:
>>
>>> On 4/3/18 1:40 PM, H.J. Lu wrote:
>>>> On Tue, Apr 3, 2018 at 11:36 AM, Peter Bergner
>>>> wrote:
>>>
On 4/4/18 2:23 PM, Richard Biener wrote:
> On April 4, 2018 8:25:25 PM GMT+02:00, Peter Bergner
> wrote:
>>> Nobody mentioned if this was a regression or not, so I did some testing
>>> and it ICEs on GCC 7 but not on GCC 6. Is it ok to back port to GCC 7
>>>
any comments on the approach used here
to fix PR86939?
If the patches are "ok" as is, I'd like to commit PATCH 1 first and
let it bake on trunk for a little while before committing PATCH 2.
Peter
gcc/
* ira.h (copy_insn_p): New prototype.
* ira-lives.c (ignore_reg_for_conflicts): New static variable.
(make_hard_regno_dead): Don't add conflicts for register
ignore_reg_for_conflicts.
(make_object_dead): Likewise.
(copy_insn_p): New function.
gcc/
* ira-lives.c (make_hard_regno_born): Rename from this...
(make_hard_regno_live): ... to this. Remove update to conflict
information. Update function comment.
(make_hard_regno_dead): Add conflict information update. Update
function comment.
(m
use the hook.
This patch passed bootstrap and regtesting on powerpc64le-linux with
no regressions. Ok for trunk?
Peter
gcc/
PR rtl-optimization/87466
* target.def (is_reg_clobbering_setjmp_p): New target hook.
* doc/tm.texi.in (TARGET_IS_REG_CLOBBERING_SETJMP_P): New
lems caused or exposed by PATCH 1 time to
be reported. Thanks again!
Peter
FFSET_TABLE_, %ebx
> FAIL: gcc.target/i386/pr64317.c scan-assembler movl[ \\t]+c@GOTOFF[(]%ebx[)]
Can you check whether the new generated code is at least as good
as the old generated code? I'm assuming the code we generate now isn't
wrong, just different and maybe we just need to change what we expect
to see.
Peter
On 10/1/18 7:50 AM, H.J. Lu wrote:
> On Mon, Oct 1, 2018 at 5:45 AM H.J. Lu wrote:
>> You may have undone:
>>
>> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=218059
>>
>
> I opened:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87479
Thanks for checking. I'll have a look.
Peter
the special pic conflict code and it can be removed!
I'm going to update PATCH 2 to remove that pic handling code
and send it through bootstrap and regtesting.
H.J., can you confirm that the following patch not only fixes
the bug you opened, but also doesn't introduce any more?
Once I
On 10/1/18 10:52 PM, Peter Bergner wrote:
> Now that we handle conflicts at definitions and the pic hard reg
> is set via a copy from the pic pseudo, my PATCH 2 is setup to
> handle exactly this scenario (ie, a copy between a pseudo and
> a hard reg). I looked at the asm output from
On 10/2/18 10:32 AM, H.J. Lu wrote:
> On Tue, Oct 2, 2018 at 7:59 AM Peter Bergner wrote:
>> I'm currently performing bootstrap and regtesting on powerpc64le-linux and
>> x86_64-linux. H.J., could you please test this patch on i686 to verify it
>> doesn't
call in any case since it returns twice).
Ok, here is an updated patch that renames the hook using Eric's suggestion
and keeps the scanning of the SETJMP note in the callers of the hook like
Segher wanted.
This is currently bootstrapping right now, but ok for trunk assuming no
On 10/2/18 11:42 AM, Peter Bergner wrote:
> On 10/1/18 4:25 AM, Eric Botcazou wrote:
> This is currently bootstrapping right now, but ok for trunk assuming no
> regressions?
>
> gcc/
> PR rtl-optimization/87466
> * target.def (setjmp_preserves_nonvolatile_reg
On 10/2/18 1:21 PM, Segher Boessenkool wrote:
> Hi Peter,
>
> On Tue, Oct 02, 2018 at 11:42:19AM -0500, Peter Bergner wrote:
>> +/* The default implementation of
>> TARGET_SETJMP_PRESERVES_NONVOLATILE_REGS_P. */
>> +
>> +bool
>> +default_se
On 10/2/18 1:21 PM, Segher Boessenkool wrote:
> On Tue, Oct 02, 2018 at 11:42:19AM -0500, Peter Bergner wrote:
>> +/* The default implementation of
>> TARGET_SETJMP_PRESERVES_NONVOLATILE_REGS_P. */
>> +
>> +bool
>> +default_setjmp_preserves_nonvolatile_regs_
On 10/2/18 9:59 AM, Peter Bergner wrote:
> gcc/
> PR rtl-optimization/86939
> PR rtl-optimization/87479
> * ira.h (copy_insn_p): New prototype.
> * ira-lives.c (ignore_reg_for_conflicts): New static variable.
> (make_hard_regno_dead): Don't add
the following test case patch make it so that
it PASSes again?
Peter
Index: gcc/testsuite/gcc.target/i386/pr49095.c
===
--- gcc/testsuite/gcc.target/i386/pr49095.c (revision 264793)
+++ gcc/testsuite/gcc.target/i386/pr49095.c
tually. */
>> -/* { dg-final { scan-assembler-times "\\), %" 8 } } */
>> +/* { dg-final { scan-assembler-times "\\), %" 57 { target { ia32 } } } } */
>> +/* { dg-final { scan-assembler-times "\\), %" 45 { target { lp64 } } } } */
>
>
-linux,
x86_64-linux and i686-linux (Thanks H.J.!) with no regressions.
Ok for trunk?
Peter
gcc/
PR rtl-optimization/86939
PR rtl-optimization/87479
* ira.h (copy_insn_p): New prototype.
* ira-lives.c (ignore_reg_for_conflicts): New static variable
aybe we could add a few random unneeded conflicts when using reload
to push targets a little more? ;-)
> OK for the trunk.
Thank you everyone for your reviews! Patch committed.
Peter
that seems to be used elsewhere.
Peter
On 10/5/18 1:32 PM, Vladimir Makarov wrote:
> On 10/05/2018 12:40 PM, Peter Bergner wrote:
>> On 10/4/18 3:01 PM, Vladimir Makarov wrote:
>>> IMHO, the name copy_insn_p is too common and confusing (we already have
>>> functions copy_insn and copy_insn_1 in GCC). Th
On 10/5/18 4:12 PM, Vladimir Makarov wrote:
> On 10/05/2018 04:00 PM, Peter Bergner wrote:
>> How about non_conflicting_reg_copy or non_conflicting_copy_insn?
> OK. I like the first name more.
Ok, I committed the patch using the first function name.
Thank you very much for the patch
-d05_32.tcwg-d05_32-build.txt
>
> You can also see the results posted on gcc-testresults.
Sorry for the breakage. I'll try and build a cross compiler to fix the
ICEs. Hopefully all the other issues are related.
Peter
rgets that define
HONOR_REG_ALLOC_ORDER. Why shouldn't we always account for save/restore
of non-volatile reg usage? I'll note I did not change that behavior.
Thoughts on the patch below? Vlad, can you comment on some of my
questions above?
Peter
gcc/
PR rtl-optimiz
looking at REG_DEAD
notes isn't enough, I still think the majority of the time those regs
probably will be free to use, we just have to check for the special
cases like above where they are not.
Peter
On 3/9/18 4:25 PM, Peter Bergner wrote:
> On 3/9/18 1:31 PM, Segher Boessenkool wrote:
>> On Wed, Mar 07, 2018 at 06:50:41PM -0600, Peter Bergner wrote:
>>> This passed bootstrap and regtesting on powerpc64-linux, running the
>>> testsuite in both 32-bit and 64-bi
On 4/19/18 5:40 PM, Segher Boessenkool wrote:
> On Thu, Apr 19, 2018 at 01:23:51PM -0500, Peter Bergner wrote:
>> On 3/9/18 4:25 PM, Peter Bergner wrote:
>>> Technically, it is broken there too, but until trunk, we never really
>>> generated the altivec mems that tri
On 4/20/18 9:34 AM, Peter Bergner wrote:
> Neither test case fails on GCC 6, but I haven't tested on BE which is
> where the PR83969 test case was failing (-m32 BE). I'll do a build on
> BE and verify whether the tests compile there or not. If they PASS,
> I'd probabl
you are removing that explains
the folly of trying to count them.
Peter
> This {lxv} matches {lxvd2x} as well. \m\M in Tcl are like \b\b in Perl,
> or \<\> in many other regex dialects.
The target triplet of powerpc64*le-*-* isn't modified by the patch,
but the '*' in powerpc64*le seems superfluous, so can we just remove it?
Peter
On Tue, 2013-11-05 at 08:19 +0100, Jakub Jelinek wrote:
> On Mon, Nov 04, 2013 at 05:48:31PM -0800, Konstantin Serebryany wrote:
> > Hi Peter.
> > Does this also mean that asan in llvm trunk is broken for Power?
> > We'll need to fix it there too (or, in fact, first).
On Tue, 2013-11-05 at 09:57 -0600, Peter Bergner wrote:
> On Tue, 2013-11-05 at 08:19 +0100, Jakub Jelinek wrote:
> > Note, not even glibc itself includes , so the chances of that
> > header actually working for you are low. glibc instead just defines the
> > structures i
lps, but as Pat reported in the bugzilla, it still is failing.
With the following patch, we can now bootstrap on powerpc64-linux.
Is this ok for trunk?
Does this help the other architectures that are failing for the same
build error?
Peter
PR sanitizer/59009
* s
On Wed, 2013-11-13 at 18:29 +0100, Jakub Jelinek wrote:
> On Wed, Nov 13, 2013 at 11:25:06AM -0600, Peter Bergner wrote:
> > > * sanitizer_common/sanitizer_platform_limits_linux.cc: Temporarily
> > > ifdef out almost the whole source.
> > > * sanitizer_common
On Wed, 2013-11-13 at 16:42 -0600, Peter Bergner wrote:
> On Wed, 2013-11-13 at 18:29 +0100, Jakub Jelinek wrote:
> > On Wed, Nov 13, 2013 at 11:25:06AM -0600, Peter Bergner wrote:
> > > > * sanitizer_common/sanitizer_platform_limits_linux.cc:
> > > > Temp
On Wed, 2013-11-13 at 11:25 -0600, Peter Bergner wrote:
> On Wed, 2013-11-13 at 00:49 +0100, Jakub Jelinek wrote:
> > 2013-11-12 Jakub Jelinek
> >
> > * sanitizer_common/sanitizer_platform_limits_linux.cc: Temporarily
> > ifdef out almost the whole source.
On Fri, 2013-11-15 at 15:51 +0100, Jakub Jelinek wrote:
> On Fri, Nov 15, 2013 at 08:16:47AM -0600, Peter Bergner wrote:
> > Ok, Dave reported in PR59009 that my last patch still left a few build
> > problems on HPPA. Dave tested the patch below and confirmed this cleans
>
ored on the s390's transaction
failure? We don't have that attribute set on POWER's tbegin builtin
and I don't think we should since all of our registers are restored
on a transaction failure, but I'd like to know if you added that
attribute for any other reason such that POWER should have it too?
Peter
FOR_EACH_LOOP (loop, LI_ONLY_INNERMOST)
>{
> ...
> if ()
>break;
>}
I just committed the following obvious patch to fix bootstrap.
Peter
* loop-doloop.c (doloop_optimize_loops): Remove unused
loop iterator
The following patch documents the HTM built-in functions specific
to POWER. I bootstrapped and reviewed the gcc.info file and
everything looks good.
Ok for mainline?
Peter
* doc/extend.texi: Document htm builtins.
Index: gcc/doc/extend.texi
On Thu, 2013-11-21 at 16:13 -0500, David Edelsohn wrote:
> On Thu, Nov 21, 2013 at 3:41 PM, Peter Bergner wrote:
> > * doc/extend.texi: Document htm builtins.
>
> LGTM.
Thanks, committed as revision 205233.
Peter
On Fri, Oct 10, 2014 at 6:06 PM, Peter Collingbourne wrote:
> On Fri, Oct 10, 2014 at 5:33 PM, 'Ian Lance Taylor' via gofrontend-dev
> wrote:
>>
>> On Fri, Oct 10, 2014 at 1:42 PM, Richard Henderson wrote:
>> >
>> > This is awful syntax, and there
On Mon, Oct 13, 2014 at 1:10 AM, Richard Biener
wrote:
> On Sat, Oct 11, 2014 at 6:23 AM, Richard Henderson wrote:
>> On 10/10/2014 06:42 PM, Peter Collingbourne wrote:
>>> A colleague has suggested a perhaps nicer syntax:
>>>
>>> __builtin_call_chain(poin
not sure how your patch
can cause this error, but it does go away if we remove your patch
and build again.
Peter
# Enable LRA by default
Index: gcc/config/rs6000/rs6000.opt
===
--- gcc/config/rs6000/rs6000.opt(revision 21
On Fri, 2014-05-30 at 15:49 +0200, Jakub Jelinek wrote:
> On Fri, May 30, 2014 at 08:09:22AM -0500, Peter Bergner wrote:
> > On Thu, 2014-05-29 at 14:07 -0500, Peter Bergner wrote:
> > > On Wed, 2014-05-28 at 09:36 +0200, Thomas Schwinge wrote:
> > > > This is be
on the compile, then
everything works fine. Is this a test case error for not linking
-lasan before -lm or ???
Peter
++/g++.log
> and add -v to see what is passed to the linker.
> Perhaps the linker reorders the libraries?
> Or do you have LD_PRELOAD?
No LD_PRELOAD. It adds -lasan "early", but after the libraries and
object files that are explicitly added to the linker command.
Since -lm is
On Tue, 2014-06-03 at 15:21 +0200, Jakub Jelinek wrote:
> On Tue, Jun 03, 2014 at 08:06:41AM -0500, Peter Bergner wrote:
> > No LD_PRELOAD. It adds -lasan "early", but after the libraries and
> > object files that are explicitly added to the linker command.
> > S
call __builtin_pack_longdouble and
__builtin_unpack_longdouble when -mlong-double-64 is in effect.
Peter
gcc/
PR target/61415
* config/rs6000/rs6000-builtin.def (BU_MISC_1): Delete.
(BU_MISC_2): Rename to ...
(BU_LDBL128_2): ... this.
* config/rs6000/rs6000.h
On Fri, 2014-06-06 at 11:37 -0400, David Edelsohn wrote:
> On Thu, Jun 5, 2014 at 3:57 PM, Peter Bergner wrote:
> > Is this also ok for the FSF 4.9 and FSF 4.8 branches? Without the gcc/
> > changes, we hit an ICE whenever we call __builtin_pack_longdouble and
> > __buil
I'd like to ping the following patch that fixes PR57653. This did
bootstrap and regtest with no regressions on powerpc64-linux.
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01571.html
Is this ok for trunk, 4.9 and 4.8?
Peter
On Wed, 2014-06-11 at 23:07 +, Joseph S. Myers wrote:
> On Wed, 11 Jun 2014, Peter Bergner wrote:
>
> > I'd like to ping the following patch that fixes PR57653. This did
> > bootstrap and regtest with no regressions on powerpc64-linux.
> >
> > https:/
On Fri, 2014-06-06 at 11:37 -0400, David Edelsohn wrote:
> On Thu, Jun 5, 2014 at 3:57 PM, Peter Bergner wrote:
> > gcc/
> > PR target/61415
> > * config/rs6000/rs6000-builtin.def (BU_MISC_1): Delete.
> > (BU_MISC_2): Rename to ...
> >
ted without any
regressions.
The --enable-default-pie regtesting shows massive failures that I
have to look into. I'm haven't determined yet whether these are
all -m32 FAILs or -m64 FAILS or both. I'll report back with more
info after I dig into some of the failures.
Peter
On Wed, 2015-05-27 at 08:36 -0700, H.J. Lu wrote:
> On Wed, May 27, 2015 at 8:24 AM, Peter Bergner wrote:
> > On Tue, 2015-05-26 at 16:40 -0500, Bill Schmidt wrote:
> >> Ah, never mind. I guess I need to run automake first.
> >
> > I ran the patch on powerpc64-li
targets that
> is very hard and you need to disassemble, but to just find some byte in the
> call instruction.
I wrote the "pc - 4" code for powerpc* and I guess I was just
being pedantic on returning the first address of the instruction.
If using "pc - 1" works, then I'm fine with that.
Peter
On Fri, 2015-03-20 at 17:41 -0500, Peter Bergner wrote:
> On Fri, 2015-03-20 at 15:52 -0500, Segher Boessenkool wrote:
> > Maybe it would be nicer if the builtin-expansion code handled the copy
> > from cc, instead of stacking on RTL expanders.
>
> That would allow getting
On Tue, 2015-04-21 at 21:17 -0500, Segher Boessenkool wrote:
> On Tue, Apr 21, 2015 at 03:56:18PM -0500, Peter Bergner wrote:
> > This patch also fixes some issues I hit with the tabortdc[i] and
> > htm_m[ft]spr_ patterns when used with -m32 -mpowerpc64.
>
> Running the
On Wed, 2015-04-22 at 17:16 -0500, Segher Boessenkool wrote:
> On Wed, Apr 22, 2015 at 08:43:10AM -0500, Peter Bergner wrote:
> > > Maybe you can fold tabortdc with tabortwc now? Use one UNSPEC name
> > > for both, :GPR and ?
> >
> > Wouldn't that change the
301 - 400 of 1972 matches
Mail list logo
