On 7/21/16 3:26 AM, Alan Modra wrote:
On Wed, Jul 20, 2016 at 08:51:21PM -0500, Peter Bergner wrote:
This still doesn't answer David's question about what will happen if
we generate this pattern (or one of the older VSX reg+reg patterns)
when we are NOT using -mno-vsx. In t
t rewrite the comment without mentioning ppc64 or
replace it with a more general term (PowerPC?).
Peter
egtesting on powerpc64le-linux and x86_64-linux
with no regressions. Ok for trunk?
Peter
gcc/
PR tree-optimization/51513
* tree-cfg.c (gimple_unreachable_bb_p): New function.
(assert_unreachable_fallthru_edge_p): Use it.
(compress_case_label_vector):
ee whether we can fix unreachable
normal case statements too. Thanks.
Peter
iced this with a post
compilation analysis tool that had problems itself with the wild
branch (since fixed) which is why we wanted to fix this.
Peter
ink we need a fancy short names for this builtin
which will be infrequently used. The __builtin_darn name is enough.
Peter
Intel and S390 similarly,
unless someone beats me to it (hint hint :). I'd need help testing it though,
since I don't have access to Intel or S390 hardware that support HTM.
Peter
* config/rs6000/htm.md (UNSPEC_HTM_FENCE): New.
(tabort, tabortc, tabortci,
fixes his AT builds (native and cross) and I've verified that this
patch bootstraps with no regressions.
Is this ok for trunk and the GCC 6 branch?
Peter
* config.gcc (powerpc*-*-*, rs6000*-*-*): Remove setting of
INCLUDE_EXTRA_SPEC for Advance Toolchain builds.
Index
On 11/7/16 3:11 PM, Segher Boessenkool wrote:
On Mon, Nov 07, 2016 at 01:20:29PM -0600, Peter Bergner wrote:
Is this ok for trunk and the GCC 6 branch?
* config.gcc (powerpc*-*-*, rs6000*-*-*): Remove setting of
INCLUDE_EXTRA_SPEC for Advance Toolchain builds.
Okay. Thanks
alues are taken from the @command{pkg-config}
@samp{bdw-gc} module.
s/must always specified/must always be specified/
and possibly:
s/variant and take precedence/variant and they take precedence/ ???
Peter
you to catch the bug?
Assuming the test case is correct, is this ok for trunk?
Peter
gcc/
PR target/78458
* config/rs6000/rs6000.h (HARD_REGNO_CALLER_SAVE_MODE): Return MODE
if it is at least NREGS wide.
gcc/testsuite/
PR target/78458
* gcc.target
On 11/23/16 12:33 PM, Segher Boessenkool wrote:
On Wed, Nov 23, 2016 at 12:13:23PM -0600, Peter Bergner wrote:
Please put parens around NREGS and that last MODE.
[snip]
You don't need the default arguments, FWIW.
Okay for trunk. Thanks!
Ok, commited as revision 242818 with your sugges
pass the correct assembler option when using
-mcpu=powerpc64le.
This passes bootstrap/regtesting on powerpc64le-linux. Ok for mainline?
Ok for the release branches too after testing?
Peter
gcc/
PR target/68772
* config/rs6000/rs6000.h (ASM_CPU_SPEC): For -mcpu=powerp
On Tue, 2015-12-22 at 13:36 -0500, David Edelsohn wrote:
> On Tue, Dec 22, 2015 at 12:13 PM, Peter Bergner wrote:
> AIX does not support PPC64LE, so the aix53.h, aix61.h and aix71.h
> changes should not be applied.
Heh, I should know better. Thanks for catching that.
>
On Thu, 2015-12-24 at 10:15 -0800, Mike Stump wrote:
> On Dec 22, 2015, at 9:13 AM, Peter Bergner
> > gcc/testsuite/
> >PR target/68772
>
> Likewise. Please retroactively update the number in the changelog.
Wow, thanks for catching this! Fixed everywhere.
Peter
c to allow
config.gcc to set $target_header_dir which fixes the problem.
This patch passes bootstrap and regtesting on powerpc64le-linux.
Ok for mainline?
Peter
PR target/69153
* config.gcc: Set target_header_dir for --with-advance-toolchain=.
* configure.ac: Only
On Sun, 2016-01-10 at 19:28 +, Bernd Edlinger wrote:
> Hi Peter,
>
> > @@ -4167,6 +4167,7 @@
> > -d "/opt/$with_advance_toolchain/bin/." -a \
> > -d "/opt/$with_advance_toolchain/include/.";
> > then
&g
ontrol, we don't actually need __builtin_cpu_init(), but we have implemented
it anyway, to keep the same API as x86. It's just our init expands to nothing.
This passes bootstrap and regtesting with no errors. Ok for mainline?
Peter
gcc/
* config/rs6000/ppc-auxv.h: New file.
On Thu, 2016-01-14 at 21:50 -0600, Peter Bergner wrote:
> This patch adds support for __builtin_cpu_init(), __builtin_cpu_is() and
> __builtin_cpu_supports() builtins for PowerPC. We use the same API as the
> x86* builtins of the same name. These builtins uses the new GLIBC 2.23
> f
I will say I do like that second hunk for the native build, since the
native Advance Toolchain does not contain everything you'd find in a
normal /usr/include, so falling back on /usr/include if the Advance
Toolchain doesn't supply it seems wise. I guess we really should
be conditionall
On Wed, 2012-10-31 at 09:02 -0500, Peter Bergner wrote:
> On Wed, 2012-10-31 at 14:55 +0100, Jakub Jelinek wrote:
> > On Wed, Oct 31, 2012 at 08:53:31AM -0500, Peter Bergner wrote:
> > > Great. Jakub, were you going to commit your change or did you want me
> > > to
On Wed, 2012-10-31 at 21:54 -0500, Peter Bergner wrote:
> On Wed, 2012-10-31 at 09:02 -0500, Peter Bergner wrote:
> > On Wed, 2012-10-31 at 14:55 +0100, Jakub Jelinek wrote:
> > > On Wed, Oct 31, 2012 at 08:53:31AM -0500, Peter Bergner wrote:
> > > > Great. Jakub,
embler mnemonic we'll be releasing that the gcc configure script
will use to test for power6 assembler support.
Peter
On Mon, 2012-11-05 at 13:53 +0100, Jakub Jelinek wrote:
> On Mon, Nov 05, 2012 at 06:41:47AM -0600, Peter Bergner wrote:
> > I'd like to post later today (hopefully this morning) a very minimal
> > configure patch that adds the -mcpu=power8 and -mtune=power8 compiler
> >
On Mon, 2012-11-05 at 15:47 +0100, Jakub Jelinek wrote:
> On Mon, Nov 05, 2012 at 08:40:00AM -0600, Peter Bergner wrote:
> > Well we also patch config.in and configure.ac/configure. If those are
> > acceptable to be patched later too, then great. If not, the patch
>
> That
wait to commit this after stage1 (since Jakub said it was ok in another
thread) when we commit our base power8 patches?
Peter
* doc/invoke.texi (-mcpu=power8): Document.
* config.in (HAVE_AS_POWER8): New.
* config.gcc: Add cpu_type power8.
* configure.ac
g/rs6000/aix53.h: Likewise.
> > * config/rs6000/aix61.h: Likewise.
>
> This patch is okay.
Thanks, committed as revision 193307.
Peter
he code. Can't we
use some configure fragments to help remove many/most of these?
Does anyone have any thoughts on the patch? Does it look reasonable?
Peter
gcc/
* config/rs6000/rs6000.c (TARGET_ASAN_SHADOW_OFFSET): Define.
(rs6000_asan_shadow_offset): New function.
libsan
On Mon, 2012-11-19 at 15:02 +0400, Dmitry Vyukov wrote:
> I am on a conference today and tomorrow, so I will be able to
> review the patch on Wed. Where can I see the whole patch?
You can find the patch here:
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01425.html
Peter
On Mon, 2012-11-19 at 15:29 +0100, Jakub Jelinek wrote:
> On Fri, Nov 16, 2012 at 05:08:06PM -0600, Peter Bergner wrote:
> > One question that I have is that the toplev.c test for port support
> > tests for !FRAME_GROWS_DOWNWARD. The rs6000 port has FRAME_GROWS_DOWNWARD
On Fri, 2012-11-16 at 15:47 -0800, Konstantin Serebryany wrote:
> On Fri, Nov 16, 2012 at 3:08 PM, Peter Bergner wrote:
> > The lone ASAN
> > test case does fail, but it seems to be related to us using
> > _Unwind_Backtrace() and we end up with two extra frames at the
&g
LLVM tree so as to pick up your
style changes and add anything you inadvertently dropped and
commit it. Thanks.
Peter
168358&view=rev
I assume we are just waiting for someone to commit this to the GCC src,
correct? David (Miller), were you going to do that? I'd like that
change committed before I commit our ppc asan changes.
Peter
On Tue, 2012-11-20 at 17:52 +0400, Konstantin Serebryany wrote:
> On Tue, Nov 20, 2012 at 5:41 PM, Peter Bergner wrote:
> > Doing a quick peruse through your LLVM commit, I see you grabbed the
> > PopStackFrames() addition, but the asan_linux.cc changes do not include
aybe it fixes the ARM Android issue you just ran into?
Peter
diff -urpN -X /home/bergner/cvs/dontdiff
gcc-fsf-mainline-kcc/libsanitizer/asan/asan_linux.cc
gcc-fsf-mainline-asan/libsanitizer/asan/asan_linux.cc
--- gcc-fsf-mainline-kcc/libsanitizer/asan/asan_linux.cc2012-11-20
12:52:3
On Tue, 2012-11-20 at 23:24 +0400, Konstantin Serebryany wrote:
> On Tue, Nov 20, 2012 at 11:08 PM, Peter Bergner wrote:
> > diff -urpN -X /home/bergner/cvs/dontdiff
> > gcc-fsf-mainline-kcc/libsanitizer/sanitizer_common/sanitizer_stacktrace.h
> > gcc-fsf-mainl
we're interested in will always be higher
in the backtrace?
I guess I'm wondering, in this specific use case, do you think using
the CFA to compare against is safe or not?
Peter
tant, you have to err on the large side of the potential
page sizes.
I agree with David, that this has to be runtime generated value.
I'll play with his GetPageSize() suggestion and see whether it
works for us.
Peter
on calls in between the current two
ASAN function at the top of the backtrace.
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01711.html
Bah, ignore that first diff of the LAST_UPDATED file. :(
Peter
On Wed, 2012-11-21 at 20:22 +0400, Konstantin Serebryany wrote:
> On Wed, Nov 21, 2012 at 8:16 PM, Peter Bergner wrote:
> > On Wed, 2012-11-21 at 13:46 +0400, Evgeniy Stepanov wrote:
> >> Matching FP or SP also sounds good, and perhaps more reliable than
> >> just poppi
!defined(__i386__) && !defined(__x86_64__)".
Peter
Index: libsanitizer/asan/asan_linux.cc
===
--- libsanitizer/asan/asan_linux.cc (revision 193678)
+++ libsanitizer/asan/asan_linux.cc (working copy)
@@ -1
ing the PC at the
> error trigger point.
If you have a suggested change/patch that does that, let me know
and I can try it out on powerpc to make sure it works for us too.
Peter
Below are the port changes to enable building ASAN on powerpc*-linux.
The libsanitizer changes required for powerpc*-linux have already been
committed. This passes bootstrap and regtesting with no regressions
and we also pass the two ASAN test suite test cases.
Ok for mainline?
Peter
On Thu, 2012-12-06 at 09:39 -0500, David Edelsohn wrote:
> On Wed, Dec 5, 2012 at 5:34 PM, Peter Bergner wrote:
> > * config/rs6000/rs6000.c (TARGET_ASAN_SHADOW_OFFSET): Define.
> > (rs6000_asan_shadow_offset): New function.
> > * c
On Thu, 2012-12-06 at 10:50 -0500, David Edelsohn wrote:
> On Thu, Dec 6, 2012 at 9:46 AM, Peter Bergner wrote:
>
> >> That macro determines if GCC thinks -fsanitze=address is supported,
> >> which it is not on AIX. The macro probably should be defined in sysv4.h,
&g
On Thu, 2012-12-06 at 15:29 -0500, David Edelsohn wrote:
> On Thu, Dec 6, 2012 at 2:40 PM, Peter Bergner wrote:
> > * config/rs6000/sysv4.h (TARGET_ASAN_SHADOW_OFFSET): Define.
> > * config/rs6000/rs6000.c (rs6000_asan_shadow_offset): New function.
> >
g00235.html
Peter
nd, trechkpt, treclaim, tsr): Use xor
> > instead of minus.
> > * config/rs6000/vector.md (cr6_test_for_zero_reverse,
> > cr6_test_for_lt_reverse): Ditto.
>
> This is okay with me, but let me give Peter a chance to comment if
> there was a specific
ier job, and it optimises the lot
> to a copy of cr0 to some cc, and then branch on that. The RA of course
> gets rid of the copy. The extra freedom will more likely help than hurt.
>
> The simple testcase ends up as just "tbegin. 0; beqlr 0" in either case.
>
> So, okay?
No objections from me then.
Peter
ode that in turn starts a transaction; it
> simply tried to wait for the "other" transaction, not checking whether
> the current thread started the other transaction.
[snip]
> Peter and/or Andreas: Could you please check that this fixes the bug you
> see on Power/s390? Thanks.
On Wed, 2013-06-19 at 10:49 -0500, Peter Bergner wrote:
> This is due to the following in _ITM_inTransaction():
>
> 47 if (tx && (tx->nesting > 0))
> (gdb) p tx
> $2 = (GTM::gtm_thread *) 0x10901bf0
> (gdb) p tx->nesting
> $3 = 1
> (gdb) step
On Wed, 2013-06-19 at 10:57 -0500, Peter Bergner wrote:
> On Wed, 2013-06-19 at 10:49 -0500, Peter Bergner wrote:
> > This is due to the following in _ITM_inTransaction():
> >
> > 47if (tx && (tx->nesting > 0))
> > (gdb) p tx
> > $2 = (GTM::g
On Thu, 2013-06-20 at 00:51 +0200, Torvald Riegel wrote:
> On Wed, 2013-06-19 at 14:43 -0500, Peter Bergner wrote:
> >> I'm having trouble seeing why/when _ITM_inTransaction() is
> >> returning something other than inIrrevocableTransaction. I'll see if I can
>
to the value that htm_init() returns. This should do the right thing I
> suppose.
Of course you're right too. I totally missed we were already caching
that value. Ok, I removed the unneeded call to htm_available() in my
htm_transaction_active() and all is well using your second patch.
Thanks again!
Peter
;
+ "out of range", arg_num);
+ return const0_rtx;
+ }
+ op[nopnds] = copy_to_mode_reg (insn_op->mode, op[nopnds]);
+ }
If you want, I can remove the constraints and the extra error
message. Just let me know what you want.
Peter
On Mon, 2013-07-15 at 11:55 -0400, David Edelsohn wrote:
> Thanks for the explanation. Leave it in.
>
> Jakub was asking about the status of the HTM patch and support, so
> please check it in.
Ok, committed to mainline (after another bootstrap) as revision 200960.
Thanks!
Peter
s type of thing doesn't happen again? Otherwise, we
should place a comment at the definition of FIRST_PSEUDO_REGISTER
warning of it's use in DWARF_FRAME_REGISTER.
Peter
I add the associated -mno-* options to the building
of libitm?
Peter
On Mon, 2013-07-15 at 23:03 -0400, David Edelsohn wrote:
> On Mon, Jul 15, 2013 at 4:26 PM, Peter Bergner wrote:
> > David, do you prefer reverting the above hunk from the Power HTM
> > patch or should I add the associated -mno-* options to the building
> > of libitm?
>
&
On Tue, 2013-07-16 at 08:08 -0400, David Edelsohn wrote:
> Then I agree that the hunk should be reverted so that HTM does not imply
> POWER8.
Ok, I'll bootstrap and regtest just to be sure there is no unintended
fallout for such a small path before committing. Thanks.
Peter
On Tue, 2013-07-16 at 09:49 -0500, Peter Bergner wrote:
> On Tue, 2013-07-16 at 08:08 -0400, David Edelsohn wrote:
> > Then I agree that the hunk should be reverted so that HTM does not imply
> > POWER8.
>
> Ok, I'll bootstrap and regtest just to be sure there is no uni
On Mon, 2013-07-15 at 22:35 +0200, Jakub Jelinek wrote:
> On Mon, Jul 15, 2013 at 02:46:56PM -0500, Peter Bergner wrote:
> > > I'd say something like (but, untested and can't test it right now (and no
> > > access to power8 anyway)):
> >
> > Do we als
On Tue, 2013-07-16 at 11:55 -0500, Peter Bergner wrote:
> * config/rs6000/rs6000.h (FIRST_PSEUDO_REGISTERS): Mention HTM
> registers in the comment.
> (DWARF_FRAME_REGISTERS): Subtract also the 3 HTM registers.
> (DWARF_REG_TO_UNWIND_COLUMN): Use DWARF_FRA
On Tue, 2013-07-16 at 15:31 -0400, David Edelsohn wrote:
> On Tue, Jul 16, 2013 at 3:27 PM, Peter Bergner wrote:
> > On Tue, 2013-07-16 at 11:55 -0500, Peter Bergner wrote:
> >> * config/rs6000/rs6000.h (FIRST_PSEUDO_REGISTERS): Mention HTM
> >>
last November,
but the patch still hasn't been committed yet.
Peter
instructions automatically.
Peter
gcc/
* config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Add support
for new poweer8 P8V_BUILTIN_VEC_VMULESW builtin.
(P8V_BUILTIN_VEC_VMULEUW): Likewise.
(P8V_BUILTIN_VEC_VMULOSW): Likewise.
(P8V_BUILTIN_VEC_VMULOUW
On Thu, 2013-08-01 at 11:33 +0200, Paolo Carlini wrote:
> On 07/31/2013 10:01 PM, Peter Bergner wrote:
> > Can you tell me what the status of the following patch that
> > removes the pow() overload from tr1 is? Specifically:
> >
> > http://gcc.gnu.org/ml/gcc-pa
On Thu, 2013-08-01 at 14:42 -0500, Peter Bergner wrote:
> Jakub & richi,
>
> This bug also affects GCC 4.8. Is it appropriate to backport this patch
> to the FSF 4.8 branch? I can bootstrap and regtest it there too before
> committing if you think it's ok.
FYI, I tes
k into the user code. So this should be no problem.
Except that the htm_begin() routines are declared static inline functions,
so when they're inlined, you aren't protected by the semantics of a call
anymore, are you?
Peter
On Fri, 2013-08-02 at 16:26 +0200, Andreas Krebbel wrote:
> On 02/08/13 16:23, Peter Bergner wrote:
> > On Fri, 2013-08-02 at 15:16 +0200, Andreas Krebbel wrote:
> >> Since libitm implements TX begins as function calls only call-saved
> >> registers can be live across
ince day 1 when Aldy created the file.
Peter
s became dead code
as you discovered. I'll bootstrap and regtest the change
below and commit it as an obvious fix when that is done.
Thanks for spotting this.
Peter
Index: rs6000.c
===
--- rs6000.c(revision 201409)
+++
On Tue, 2013-08-06 at 22:01 -0500, Peter Bergner wrote:
> I'll bootstrap and regtest the change
> below and commit it as an obvious fix when that is done.
Everything looked as as expected. Committed.
Peter
lease branches?
Peter
gcc/
* builtins.def (BUILT_IN_FABSD32): New DFP ABS builtin.
(BUILT_IN_FABSD64): Likewise.
(BUILT_IN_FABSD128): Likewise.
* builtins.c (expand_builtin): Add support for new DFP ABS builtins.
(fold_builtin_1): Likewise.
* c
On Fri, 2013-08-16 at 19:11 +0200, Jakub Jelinek wrote:
> On Fri, Aug 16, 2013 at 12:06:56PM -0500, Peter Bergner wrote:
> > --- gcc/config/rs6000/dfp.md(revision 201779)
> > +++ gcc/config/rs6000/dfp.md(working copy)
> > @@ -135,8 +135,15 @@ (define_insn "
c64-linux and saw no degradations.
This also passed powerpc64-linux bootstrap and regtesting.
Is this Ok for mainline?
Since this is a wrong code bug, is this also ok on the 4.8 branch after
a couple of weeks, as long as no one finds any issues with it?
Peter
PR58139
On Fri, 2013-08-16 at 19:11 +0200, Jakub Jelinek wrote:
> On Fri, Aug 16, 2013 at 12:06:56PM -0500, Peter Bergner wrote:
> > --- gcc/config/rs6000/dfp.md(revision 201779)
> > +++ gcc/config/rs6000/dfp.md(working copy)
> > @@ -135,8 +135,15 @@ (define_insn "
On Fri, 2013-08-16 at 23:25 +0200, Jakub Jelinek wrote:
> On Fri, Aug 16, 2013 at 04:18:18PM -0500, Peter Bergner wrote:
> > --- gcc/config/rs6000/dfp.md(revision 201779)
> > +++ gcc/config/rs6000/dfp.md(working copy)
> > @@ -132,11 +132,14 @@ (
On Fri, 2013-08-16 at 23:25 +0200, Jakub Jelinek wrote:
> On Fri, Aug 16, 2013 at 04:18:18PM -0500, Peter Bergner wrote:
> > --- gcc/config/rs6000/dfp.md(revision 201779)
> > +++ gcc/config/rs6000/dfp.md(working copy)
> > @@ -132,11 +132,14 @@ (
On Fri, 2013-08-16 at 17:32 -0500, Peter Bergner wrote:
> Ok, updated to switch the order of the alternatives. This works...just
> like the previous one. I created two versions of the TD test case to
> test both alternatives and to make sure we get fmrs on the one and
> no fmrs
y for the 4.8 branch.
...and this as revision 201850.
Thank you Jakub and David!
Peter
I'd like to ping*2 the following backport patch for the fix for PR54537.
This did bootstrap and regtest with no regressions on powerpc64-linux.
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01148.html
Jonathan approved the library part, so I just need the front-end
change approved.
Peter
ow about something like
>
> sub get_git_config {
> my $res = `git config --get @_`;
> return undef if $?;
> chomp $res;
> return $res;
> }
I've always used a hacked up version that reads a ~/.mklog config
file for the name and email address to use. Ala:
[bergner@otta ~]$
ange to PROCESSOR_POWER8.
> (PROCESSOR_DEFAULT64): Same.
That looks good to me. Thanks.
Peter
into fprs again. The builtin
will also us to get a simple fmr(s).
This passed bootstrap and regtesting on powerpc64-linux with no regressions
and the pack0[23].c tests now pass. Ok for trunk?
Is this also ok for the 4.8/4.9 branches once my testing on those are complete?
Peter
gcc/
* confi
On Fri, 2014-05-02 at 18:34 -0500, Peter Bergner wrote:
> This passed bootstrap and regtesting on powerpc64-linux with no regressions
> and the pack0[23].c tests now pass. Ok for trunk?
>
> Is this also ok for the 4.8/4.9 branches once my testing on those are
> complete?
F
On Sun, 2014-05-04 at 17:39 -0400, David Edelsohn wrote:
> On Fri, May 2, 2014 at 7:34 PM, Peter Bergner wrote:
> > @@ -2517,6 +2518,7 @@ extern int frame_pointer_needed;
> > #define RS6000_BTM_POPCNTD MASK_POPCNTD/* Target supports ISA
> > 2.06. */
> &g
hazzards. The following patch makes use of the new __builtin_pack_longdouble
builtin to construct the long double giving us at worse, one or two fmrs.
Is this ok for mainline once my bootstrap and regtesting are complete?
Peter
libgcc/
* config/rs6000/ibm-ldouble.c (typedef union
On Mon, 2014-05-05 at 13:33 -0500, Peter Bergner wrote:
> Currently, the IBM long double routines in libgcc use a union to construct
> a long double from two double values. This causes horrific code generation
> that copies the two double from the FP registers over to GPRs and bac
instructions. It seems we don't
have test, so the following patch added a dfp_hw test that fixes
the problem.
This passed bootstrap and regtesting on powerpc64-linux with no
regressions on both power5 and power8 systems.
Ok for mainline, 4.9 and 4.8 branches to fixup the test cases
there?
Peter
On Fri, 2014-05-09 at 15:05 -0400, David Edelsohn wrote:
> On Fri, May 9, 2014 at 2:43 PM, Peter Bergner wrote:
> > gcc/testsuite/
> >
> > * lib/target-support.exp (check_dfp_hw_available): New function.
> > (is-effective-target): Check $arg for dfp_hw
saction State Failed. */
...
}
David approved this offline, so I'm committing this to mainline as revision
210486, as well as the 4.9 (210487) and 4.8 (210488) branches.
Peter
PR target/61193
* config/rs6000/htmxlintrin.h (_HTM_TBEGIN_STARTED): New define.
(_
ield, but is wrong when a mfcr instruction is used.
The following passed bootstrap and regtesting on powerpc64-linux.
Ok for trunk? Is this also ok for the 4.9 and 4.8 branches once
my bootstraps and regtesting is done there?
Peter
gcc/
* config/rs6000/htm.md (ttest): Use correct shift va
On Tue, 2014-05-20 at 16:36 -0400, David Edelsohn wrote:
> On Tue, May 20, 2014 at 3:28 PM, Peter Bergner wrote:
> > gcc/
> > * config/rs6000/htm.md (ttest): Use correct shift value to get CR0.
> >
> > gcc/testsuite/
> > * gcc.target/powerpc/htm-
- ucontext_t *ucontext = (ucontext_t*)context;
> > - *pc = ucontext->uc_mcontext.regs->nip;
> > - *sp = ucontext->uc_mcontext.regs->gpr[PT_R1];
> > - // The powerpc{,64}-linux ABIs do not specify r31 as the frame
> > - // pointer, but GCC always uses r31 when we need a fra
On Fri, 2014-05-23 at 09:25 -0500, Peter Bergner wrote:
> xagsmtp4.20140523142452.1...@vmsdvm6.vnet.ibm.com
> X-Xagent-Gateway: vmsdvm6.vnet.ibm.com (XAGSMTP4 at VMSDVM6)
>
> On Fri, 2014-05-23 at 17:45 +0400, Konstantin Serebryany wrote:
> > On Fri, May 23, 2014 at 5:41 PM, Ma
On Fri, 2014-05-23 at 11:47 -0500, Peter Bergner wrote:
> The following patch gets bootstrap working again, but there seems to
> be a large number of testsuite failures I will look into before
> submitting the patch to the LLVM mailing list.
FYI, it looks like a huge number of the fai
> On Mon, May 26, 2014 at 9:57 AM, Jakub Jelinek wrote:
> > Doesn't look like the ppc32 port would be in any worse shape than the 64-bit
> > one.
> > Peter has brought a real problem, in particular the allocator now newly
> > relying on
> > 2 x word size at
On Tue, 2014-05-27 at 20:07 +0200, Jakub Jelinek wrote:
> On Mon, May 26, 2014 at 09:25:37PM -0500, Peter Bergner wrote:
> > In one of my other posts, I asked should 32-bit ports even attempt
> > to use the 2 * word_size atomics. What is the code doing such that
> >
On Tue, 2014-05-27 at 23:50 +0200, Jakub Jelinek wrote:
> On Tue, May 27, 2014 at 04:02:08PM -0500, Peter Bergner wrote:
> > It's being called form basically two files:
> >
> > [bergner@makalu-lp1 gcc-fsf-mainline-asan-debug]$ find . -name '*.o' |
> >
601 - 700 of 2026 matches
Mail list logo
