On 8/9/24 4:43 PM, Segher Boessenkool wrote:
> On Fri, Aug 09, 2024 at 03:50:50PM -0500, Peter Bergner wrote:
>> I'm fine with the TARGET_P10_* macro, since it's more readable than saying
>> TARGET_POWER10 && TARGET_ALTIVEC && TARGET_VSX, especially when
n Power7?
I hope there are no users out there thinking that -mno-vsx disables all
vector, since that just has never been true. The -mno-altivec option has
always been the correct method for disabling all vector type instructions
(for -mcpu=XXX cpus that support vector).
Peter
Ping * 3. [Message-ID: <1e003d78-3b2e-4263-830a-7c00a3e9d...@linux.ibm.com>]
Segher, this resolves the issues you mentioned in your review.
This was on the top of your patch review queue before, so maybe
we have queue overflow? ;-)
Peter
On 6/18/24 5:59 PM, Peter Bergner wrote:
>
On 8/12/24 11:03 AM, Segher Boessenkool wrote:
> On Mon, Aug 12, 2024 at 10:59:01AM -0500, Peter Bergner wrote:
>> Ping * 3. [Message-ID:
>> <1e003d78-3b2e-4263-830a-7c00a3e9d...@linux.ibm.com>]
>>
>> Segher, this resolves the issues you mentioned in your revie
rs6000 patches should CC the rs6000 port maintainers. I've CC'd them on
this note.
Peter
On 8/15/24 3:44 AM, Victor Do Nascimento wrote:
> Following the migration of the dot_prod optab from a direct to a
> conversion-type optab, ensure all back-end patterns incorporate the
releases branches after some
bake-in time on trunk?
Peter
gcc/
PR target/116415
* config/rs6000/rs6000-p8swap.cc (rs6000_analyze_swaps): Handle PTImode
identically to TImode.
gcc/testsuite/
PR target/116415
* gcc.target/powerpc/pr116415.c: New test.
diff --git
On 8/22/24 4:39 AM, Kewen.Lin wrote:
> on 2024/8/21 21:14, Peter Bergner wrote:
>> - if (ALTIVEC_OR_VSX_VECTOR_MODE (mode) || mode == TImode)
>> + if (ALTIVEC_OR_VSX_VECTOR_MODE (mode) || mode == TImode
>> + || mode == PTImode)
>
> Maybe
On 8/22/24 8:48 PM, Peter Bergner wrote:
> On 8/22/24 4:39 AM, Kewen.Lin wrote:
>> OK for trunk and all active release branches with/without these nits tweaked,
>> but please give others two days or so to comment, thanks!
>
> I'll make the suggested changes and push the
Currently the behaviour of Wmissing-field-initializers is inconsistent
between C and C++. The C warning assumes that missing designated
initializers are deliberate, and does not warn. The C++ warning does warn
for missing designated initializers.
This patch changes the behaviour of Wmissing-field
I consider this one obvious, so I plan on pushing this soonish.
Peter
The ELFv2 stack frame layout comment in rs6000-logue.cc shows the ROP
hash save slot in the wrong location. Update the comment to show the
correct ROP hash save location in the frame.
gcc/
* config/rs6000/rs6000
. The fix is to compute the ROP hash save location for all
compiles.
This passed bootstrap and regtesting on powerpc64le-linux.
Ok for trunk and backports after some burn-in time?
Peter
gcc/
PR target/115389
* config/rs6000/rs6000-logue.cc (rs6000_stack_info): Compute
d get depending
on the options used.
I've verified this test case PASSes on all scenarios where the three possible
instructions are generated. Ok for trunk?
Peter
2024-06-12 Peter Bergner
gcc/testsuite/
PR testsuite/115262
* gcc.target/powerpc/pr66144-3.c: Add -fno-unrol
On 6/12/24 3:00 PM, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Jun 12, 2024 at 02:49:40PM -0500, Peter Bergner wrote:
>> testsuite: Fix pr66144-3.c test to accept multiple equivalent insns.
>> [PR115262]
>
> ("rs6000:", not "testsuite")
Done.
Ping.
On 6/7/24 11:06 PM, Peter Bergner wrote:
> We currently only compute the offset for the ROP hash save location in
> the stack frame for Altivec compiles. For non-Altivec compiles when we
> emit ROP mitigation instructions, we use a default offset of zero which
> corres
tect -mno-vsx
>> -mno-altivec -mabi=no-altivec -save-temps" } */
>
> I'd expect -mabi=no-altivec is default for -mno-altivec, but specifying it
> explicitly
> looks fine to me. :)
That's what I expected too! :-) However, I was surprised to learn that
-mno-altivec
does *not* disable TARGET_ALTIVEC_ABI. I had to explicitly use the -mabi=
option to
expose the bug.
Peter
On 6/13/24 9:26 PM, Kewen.Lin wrote:
> on 2024/6/13 21:24, Peter Bergner wrote:
>> On 6/13/24 12:35 AM, Kewen.Lin wrote:
>>>> @@ -826,7 +826,14 @@ rs6000_stack_info (void)
>>>> info->ehrd_offset -= info->rop_hash_size;
>>>>
removed -mvsx, since that is implied by -mcpu=power8 and no
need for dg-additional-options. Maybe we want to add -O2 as well?
Thoughts?
Peter
On 6/13/24 10:26 PM, Peter Bergner wrote:
> On 6/13/24 9:26 PM, Kewen.Lin wrote:
>>>> I understand this is just copied from the if arm, but if I read this
>>>> right, it can be
>>>> simplified as:
>>>
>>> Ok, I'll retest with that
/* { dg-do run { target vmx_hw } } */
/* { dg-do compile { target { ! vmx_hw } } } */
/* { dg-require-effective-target powerpc_altivec_ok } */
/* { dg-options "-O2 -mdejagnu=power7" } */
...makes more sense? Ke Wen & Segher, thoughts on that?
Ke Wen, should powerpc_altivec_ok be powerpc_altivec here???
Peter
On 6/16/24 9:10 PM, Kewen.Lin wrote:
> on 2024/6/15 01:05, Peter Bergner wrote:
>> That said, the --with-cpu=power5 build without fortran did bootstrap and
>> regtest with no regressions, so the build did test that code path and
>> exposed no problems.
>
> OK, nice! T
On 6/16/24 9:40 PM, Kewen.Lin wrote:
> on 2024/6/17 10:31, Peter Bergner wrote:
>> On 6/16/24 9:10 PM, Kewen.Lin wrote:
>>> on 2024/6/15 01:05, Peter Bergner wrote:
>>>> That said, the --with-cpu=power5 build without fortran did bootstrap and
>>>> regtest
this test
on BE, we'd get an UNSUPPORTED using the rop_ok check, but if we removed it,
we'd see a FAIL.
As we discussed offline, the plan is to eventually enable emitting the ROP
protect
hash insns on other ABIs, but until then, I think we want to keep the rop_ok
check
so as to keep Bill's CI builder from flagging it as a FAIL.
Peter
ap and regtesting on powerpc64le-linux with no
regressions, with the unpatched build FAILing the new test case and the
patched build PASSing the new test case.
Ok for trunk?
Peter
rs6000: ROP - Do not disable shrink-wrapping for leaf functions [PR114759]
Only disable shrink-wrapping when using -mrop-
On 6/17/24 7:57 PM, Segher Boessenkool wrote:
> On Mon, Jun 17, 2024 at 06:49:18PM -0500, Peter Bergner wrote:
>> On 6/17/24 6:11 PM, Segher Boessenkool wrote:
>> Yeah, I didn't write that, I only moved it, but I can try to come up with
>> an explanation of why we nee
On 6/18/24 8:20 AM, Segher Boessenkool wrote:
> On Mon, Jun 17, 2024 at 08:54:46PM -0500, Peter Bergner wrote:
>> So we should be able to shrink-wrap in the presence of the ROP protection.
[snip]
> But do we want to? And, how far, in what cases not?
My answer to the above would be &q
us) that cleans those all up???
Otherwise, LGTM (although I can't approve it).
Peter
rather limited, so from a practical standpoint,
we might have to modify the prologue code slightly to satisfy the restrictions
those insns have.
Peter
why rop_ok is needed.
Peter
rs6000: ROP - Do not disable shrink-wrapping for leaf functions [PR114759]
Only disable shrink-wrapping when using -mrop-protect when we know we
will be emitting the ROP-protect hash instructions (ie, non-leaf functions).
2024-06-17 Peter Bergner
gcc/
PR
utils accepts hashst and hashchk back to Power8, so change GCC to emit
them for Power8 and later. This matches clang's behavior.
This patch is independent of the ROP shrink-wrap fix submitted earlier.
This passed bootstrap and regtesting on powerpc64le-linux with no regressions.
Ok for trunk
Ping. [Message-ID: <1e003d78-3b2e-4263-830a-7c00a3e9d...@linux.ibm.com>]
Peter
On 6/18/24 5:59 PM, Peter Bergner wrote:
> Updated patch. This passed bootstrap and regtesting on powerpc64le-linux
> with no regressions. Ok for trunk?
>
> Changes from v1:
> 1. M
Ping.[Message-ID: <1a420e3e-3285-4e0b-87bd-6714fedc0...@linux.ibm.com>]
Peter
On 6/19/24 4:14 PM, Peter Bergner wrote:
> We currently only emit the ROP-protect hash* insns for Power10, where the
> insns were added to the architecture. We want to emit them for earlier
> c
egister_operand" "v")
> (match_operand:QI 3 "const_0_to_12_operand" "n")]
>VSHIFT_DBL_LR))]
>"TARGET_POWER10"
I know the old code used the register_operand predicate for the vector
operands, but those really should be changed to altivec_register_operand.
Peter
On 7/24/24 12:06 PM, Segher Boessenkool wrote:
> On Tue, Jul 23, 2024 at 04:26:43PM -0500, Peter Bergner wrote:
>> On 7/19/24 3:04 PM, Carl Love wrote:
>>> (define_insn "vsdb_"
>>> - [(set (match_operand:VI2 0 "register_operand" "=v")
>&
wer this one. :-). Since these are dg-do run/link tests,
we need the -save-temps to keep the assembler files around for Carl's
scan-assembler tests at the end of the test case.
Peter
ning 0 for
> unix/-m32
>is-effective-target: power10_hw 0
>
> Looks like the power10_hw is sufficient to prevent the test from running.
> Don't need to explicitly check for int128 as well.
That's only because you're testing on LE where -m32 is a not supported
configuration. If you tested on BE, you'd probably see a FAIL for -m32.
I think your initial target tests with int128 and power10_hw is actually
correct. We have an internal Power10 partition (ltcd97-lp7) running a
BE distro you can test this on.
Peter
g-do link { target { ! power10_hw } } } */
>> +/* { dg-require-effective-target power10_ok } */
>
> As Peter pointed out in another thread, you need int128 effective target
> check as well,
> otherwise it will fail with power10 -m32.
>
> Another nit: power10_hw should already guarantee po
Power10 test, so if the above works, then great!
Peter
ur intention (to support both signed and unsigned) and
we just
had a bug so only unsigned was supported?
CC'ing Steve since he noticed the missing documentation when we was trying to
use the built-ins. Steve, do you see a need to also support vector signed char
with these built-ins?
Peter
Log:
PR diagnostics/102061
* langhooks.cc (lhd_print_error_function): Follow DECL_ORIGIN
link
Signed-off-by: Peter Damianov
---
I struggled to write a testcase for this, as none of the real world cases I
tried reduced to anything nice. Hopefully it's okay to skip it
ons "-mdejagnu-cpu=power8 -mvsx -O2" } */
>
> Nit: -O2 looks useless and can be dropped?
Ok, I'll drop it.
I'll make the changes above, modulo leaving the option name unchanged until
we hear from Segher on that and report back on the LE and BE testing.
Thanks!
Peter
On 4/11/24 11:23 PM, Peter Bergner wrote:
> I'll make the changes above, modulo leaving the option name unchanged until
> we hear from Segher on that and report back on the LE and BE testing.
I made all of the requested changes and went with -mpower8-internal since
Segher was fin
'-truncate'
The motivation for adding this is PR110710. It is used by lto-wrapper to
truncate files in a shell-independent manner.
Signed-off-by: Peter Damianov
---
gcc/common.opt | 5 +
gcc/gcc.cc | 13 +
2 files changed, 18 insertions(+)
diff --git a/gcc/common
blem only manifested when calling gcc from cmd.exe, and having no
sh.exe present on the PATH. The Windows port of GNU Make searches the PATH for
an sh.exe, and uses it if present.
I have tested this in environments with and without sh.exe on the PATH and
confirmed it works as expected.
Signed-off-by: Pet
'-truncate'
The motivation for adding this is PR110710. It is used by lto-wrapper to
truncate files in a shell-independent manner.
Signed-off-by: Peter Damianov
---
v2: moved truncation to driver::final_actions
v2: moved handling of OPT_truncate to be in alphabetic order
gcc/common.opt | 6 +
blem only manifested when calling gcc from cmd.exe, and having no
sh.exe present on the PATH. The Windows port of GNU Make searches the PATH for
an sh.exe, and uses it if present.
I have tested this in environments with and without sh.exe on the PATH and
confirmed it works as expected.
Signed-off-by: Pet
blem only manifested when calling gcc from cmd.exe, and having no
sh.exe present on the PATH. The Windows port of GNU Make searches the PATH for
an sh.exe, and uses it if present.
I have tested this in environments with and without sh.exe on the PATH and
confirmed it works as expected.
Signed-off-by: Pet
'-truncate'
The motivation for adding this is PR110710. It is used by lto-wrapper to
truncate files in a shell-independent manner.
Signed-off-by: Peter Damianov
---
gcc/common.opt | 6 ++
gcc/gcc.cc | 14 ++
2 files changed, 20 insertions(+)
diff --git a/gcc/common
Signed-off-by: Peter Damianov
---
Fixes these warnings:
../../gcc/gcc/../libgcc/libgcov-util.c: In function 'void tag_counters(unsigned
int, int)':
../../gcc/gcc/../libgcc/libgcov-util.c:214:59: warning: 'void* calloc(size_t,
size_t)' sizes specified with 'sizeof
libgcc/
* libgcov-util.c (tag_counters): Swap order of arguments to xcalloc.
(topen_to_memory_representation): Likewise.
Signed-off-by: Peter Damianov
---
libgcc/libgcov-util.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libgcc/libgcov-util.c b
On 4/12/24 3:36 PM, Peter Bergner wrote:
> Testing was clean on both LE and BE, so I pushed the changes.
> I'll let things bake on trunk for a bit before pushing the backports.
The backports all tested clean, so I pushed them. Fixed everywhere.
Thanks everyone!
Peter
pe to bool.
(have_O): Change type to bool.
(have_E): Change type to bool.
(have_S): New global variable.
(driver_handle_option): Assign have_S
Signed-off-by: Peter Damianov
---
gcc/gcc.cc | 29 ++---
1 file changed, 26 insertions(+), 3 deletion
pe to bool.
(have_O): Change type to bool.
(have_E): Change type to bool.
(have_S): New global variable.
(driver_handle_option): Assign have_S
Signed-off-by: Peter Damianov
---
v2: use strrchr instead of lrealpath and strchr
gcc/gcc.cc | 28 +-
Signed-off-by: Peter Damianov
---
gcc/diagnostic-color.cc | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/gcc/diagnostic-color.cc b/gcc/diagnostic-color.cc
index f01a0fc2e37..0a4845406f5 100644
--- a/gcc/diagnostic-color.cc
+++ b/gcc/diagnostic-color.cc
or.cc (auto_enable_urls): Don't hardcode to return
false on mingw hosts.
Signed-off-by: Peter Damianov
---
gcc/diagnostic-color.cc | 4
1 file changed, 4 deletions(-)
diff --git a/gcc/diagnostic-color.cc b/gcc/diagnostic-color.cc
index 0a4845406f5..e9183bb293d 100644
--- a/gcc/
s
if
the console has ENABLE_VIRTUAL_TERMINAL_PROCESSING.
Signed-off-by: Peter Damianov
---
gcc/pretty-print.cc | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/gcc/pretty-print.cc b/gcc/pretty-print.cc
index eb59bf424b7..98b6410d6e4 100644
--- a/gcc/pretty-print.cc
+++
Signed-off-by: Peter Damianov
---
gcc/diagnostic-color.cc | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/gcc/diagnostic-color.cc b/gcc/diagnostic-color.cc
index f01a0fc2e37..3af198654af 100644
--- a/gcc/diagnostic-color.cc
+++ b/gcc/diagnostic-color.cc
return
false on mingw hosts.
* diagnostic-color.cc (auto_enable_urls): Return true if console
supports ansi escape sequences.
Signed-off-by: Peter Damianov
---
gcc/diagnostic-color.cc | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a
s
if
the console has ENABLE_VIRTUAL_TERMINAL_PROCESSING.
Signed-off-by: Peter Damianov
---
gcc/pretty-print.cc | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/gcc/pretty-print.cc b/gcc/pretty-print.cc
index eb59bf424b7..98b6410d6e4 100644
--- a/gcc/pretty-print.cc
+++
Signed-off-by: Peter Damianov
---
Forgot to add -v2 to git send-email the first time I sent. Sorry for the spam.
gcc/diagnostic-color.cc | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/gcc/diagnostic-color.cc b/gcc/diagnostic-color.cc
index f01a0fc2e37
return
false on mingw hosts.
* diagnostic-color.cc (auto_enable_urls): Return true if console
supports ansi escape sequences.
Signed-off-by: Peter Damianov
---
v2: auto_enable_urls should check if the console supports ansi escape sequences
gcc/diagnostic-color.cc | 19 +
s
if
the console has ENABLE_VIRTUAL_TERMINAL_PROCESSING.
Signed-off-by: Peter Damianov
---
gcc/pretty-print.cc | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/gcc/pretty-print.cc b/gcc/pretty-print.cc
index eb59bf424b7..98b6410d6e4 100644
--- a/gcc/pretty-print.cc
+++
ot that large that it would justify dropping support for such a large
> > userbase.
> >
> > Removing Solaris 11.3 support might make sense in the future when SPARC
> > support in Illumos has matured enough that people can switch over their
> > machines.
> >
> > Thanks,
> > Adrian
> >
> > --
> > .''`. John Paul Adrian Glaubitz
> > : :' : Debian Developer
> > `. `' Physicist
> > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
>
>
--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
or executable output
(driver::maybe_run_linker): Rename output_file_temp to output_file if
the linker ran successfully
Signed-off-by: Peter Damianov
---
gcc/gcc.cc | 50 +-
1 file changed, 33 insertions(+), 17 deletions(-)
diff --git a/gcc
or executable output
(driver::maybe_run_linker): Rename output_file_temp to output_file if
the linker ran successfully
Signed-off-by: Peter Damianov
---
v2: Make sure temp file is removed in the case of a compiler error
gcc/gcc.cc | 51 +++
or executable output
(driver::maybe_run_linker): Rename output_file_temp to output_file if
the linker ran successfully
Signed-off-by: Peter Damianov
---
v3: don't attempt to create temp files -> rename for -o /dev/null
gcc/gcc.cc | 53 +
On 8/26/24 10:45 AM, Segher Boessenkool wrote:
> On Thu, Aug 22, 2024 at 08:48:19PM -0500, Peter Bergner wrote:
>> I agree, there probably is code in the backend that currently handles TImode
>> that should probably be changed to handle both by using your new macro.
>
> That
acro, the
number of uses should increase as we clean up the other areas than should
handle PTImode too.
Currently, I think the only time PTImode shows up is through use of the
__atomic* intrinsics, but when Jeevitha's patch that allows the kernel
to use an attribute to create PTImode variables so they can have higher
alignment requirements, the number of PTImode uses we see will probably
increase.
Peter
Ping https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661510.html
v2 Patch:
* adds proper changelog text
* fixes typo in c.opt
Currently the behaviour of Wmissing-field-initializers is inconsistent
between C and C++. The C warning assumes that missing designated
initializers are deliberate, and does not warn. The C++ warning does warn
for missin
this patch on Intel to
make sure we don't regress you? Thanks.
Peter
fy XFmode is returned for fp regs.
Peter
tion, coalescing
and other optimizations on them just like normal pseudos to reduce the
amount of spill code generated.
Peter
need reloads. */
Was this supposed to read:
Call insn might have references of pseudos besides those in
CALL_INSN_FUNCTION_USAGE, but we don't count them in insn_bitmap
of the corresponding lra_reg_info as they don't need reloads.
???
Peter
ng we do now that power7 has been released
for a while now.
Peter
GEs.
Sure, that's better. Thanks.
Peter
, you can now do that. Mainline gas and ld are now fixed.
Now that gas and ld are fixed, can we use a configure time check to
see whether we're using a fixed gas/ld or not before we disable them?
Peter
ing that and ends
up segv'ing. I'd like to backport Richard's patch below to the 4.7 branch.
The patch bootstrapped and regtested on powerpc64-linux with no regressions.
Is it ok for the 4.7 branch?
Peter
Backport from mainline
2012-0
On Tue, 2012-10-30 at 11:58 -0500, Peter Bergner wrote:
> I'm hitting the same bug as in PR53708 when compiling GLIBC's dlfcn.c when
> vectorization is enabled on powerpc64-linux. A reduced test case is:
>
> bergner@bns:~/gcc/BUGS> cat foo.i
> static void
On Tue, 2012-10-30 at 19:55 +0100, Jakub Jelinek wrote:
> On Tue, Oct 30, 2012 at 01:43:33PM -0500, Peter Bergner wrote:
> > Commenting on Richard's question from the bugzilla:
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53708#c10
> >
> > I sup
On Tue, 2012-10-30 at 20:37 +0100, Jakub Jelinek wrote:
> On Tue, Oct 30, 2012 at 02:03:44PM -0500, Peter Bergner wrote:
> > Ok, then I'll bootstrap and regtest your suggested change while we
> > wait for richi to comment. I'm fine with whatever you and richi
> >
On Wed, 2012-10-31 at 10:12 +0100, Richard Biener wrote:
> On Tue, Oct 30, 2012 at 9:23 PM, Peter Bergner wrote:
> > On Tue, 2012-10-30 at 20:37 +0100, Jakub Jelinek wrote:
> >> On Tue, Oct 30, 2012 at 02:03:44PM -0500, Peter Bergner wrote:
> >> > Ok, then I
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 do that?
>
> I haven't tested it, you did, so please do that yours
seems to be that the RHEL6 system I am on, the linux/types.h
kernel header file doesn't define ino_t like it does on newer systems
which leads to the undefined type errors. Digging through the other kernel
header files, I'm not really seeing another header file I can include
to get it either. :(
Peter
On Mon, 2013-11-04 at 17:48 -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).
I'm not sure. Bill, can you fire off a quick LLVM trunk build on
powerpc64-li
On Wed, 2016-01-20 at 15:15 -0500, David Edelsohn wrote:
> On Thu, Jan 14, 2016 at 10:50 PM, Peter Bergner wrote:
> > gcc/
> > * config/rs6000/ppc-auxv.h: New file.
> > * config/rs6000/rs6000-builtin.def (cpu_init): Add new builtin.
> >
When the test case derived_constructor_comps_6.f90 was backported to
the FSF 5 branch, a '}' on the dg-additional-options was dropped
causing the test case to fail. I have added it back and committed
it as obvious.
Peter
PR fortran/61831
* gfortran.dg/derived_construct
linux (which doesn't support -m32)
when I encountered the missing '}', so I only fixed the bug I saw.
I'll leave it to you or someone else to fix the -m32 bug, since
I'm not seeing it on my system.
Peter
On Mon, 2016-01-25 at 18:51 +0100, Paul Richard Thomas wrote:
> On 25 January 2016 at 18:33, Peter Bergner wrote:
>> I'll leave it to you or someone else to fix the -m32 bug, since
>> I'm not seeing it on my system.
>
> Neither am I :-(
I have a powerpc64-linux (ie
aps reg+reg, or I don't see it.
commutative_operand_precedence gives registers that hold pointers
a higher precedence than registers that don't hold pointers, so
it can swap reg+reg if the second reg holds a pointer.
We did this as part of PR28690.
Peter
Adhemerval noticed that the _TEXASR_INSTRUCTION_FETCH_CONFLICT and
_TEXASRU_INSTRUCTION_FETCH_CONFLICT HTM macros were misspelled.
I committed the following patch as obvious to fix them.
Peter
* config/rs6000/htmintrin.h (_TEXASR_INSTRUCTION_FETCH_CONFLICT): Fix
typo in macro
f 'addr r155' + 8 is equal to 'addr r167 + 40', so I think
that we should preffer to take the new addr, technically will be profitable
???
Brs,
Peter Xu.
-
Dying in the sun.
--
View this message in context:
http://gcc.1065356.n5.nabble.com/A-question-about-forward
After Jakub changed i?386/x86_64 to use SWITCHABLE_TARGET, he asked me to
look at changing rs6000 too. Here's the rs6000 patch, which is basically
identical to the i386.[hc] change Jakub made. This passed bootstrap and
regtesting on powerpc64-linux with no regressions. Ok for mainline?
thread...
The rs600 patch was submitted here:
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00675.html
Peter
d that the ICE seen
when compiling the test case with only my patch in:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58269#c2
is fixed when we add Honza's patch. Ok for 4.8?
Peter
Backport from mainline
2013-09-06 Jan Hubicka
* config/i386/i386.c (ix86_har
k for
them once bootstrapping and regtesting are complete on them?
Peter
gcc/
* config/rs6000/htm.md (tabort.): Restrict the source operand to
using a base register.
gcc/testsuite/
* gcc.target/powerpc/htm-tabort-no-r0.c: New test.
Index: gcc/confi
On Mon, 2015-08-03 at 16:27 -0400, David Edelsohn wrote:
> On Mon, Aug 3, 2015 at 3:39 PM, Peter Bergner wrote:
> > This has passed bootstrapping and regtesting on trunk. Ok for mainline?
> >
> > I'd like to also backport this to the release branches. Is this ok for
&
s_back_edges ();
>
> - reorder_basic_blocks_software_trace_cache ();
> + if (1)
> +reorder_basic_blocks_software_trace_cache ();
> + else
> +reorder_basic_blocks_simple ();
Did you write the code this way because you're thinking of allowing
either reorder function to be called in the future?
Peter
27;s
work schedule for our team.
I haven't had a chance to look into the other ICE or wrong code gen issue yet,
but will eventually will get to those.
Peter
On Tue, 2015-09-29 at 09:27 -0500, Peter Bergner wrote:
> The first ICE seems to be due to a conversion to long double and LRA ends
> up going into a infinite loop spilling things until it hits a threshold and
> quits with an ICE. I haven't spent enough time to determine whether t
Ping.
Torvald, David approved the code portion of the patch.
How does the documentation part look to you?
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00315.html
Peter
101 - 200 of 1910 matches
Mail list logo
