On 5/29/25 5:35 AM, Segher Boessenkool wrote:
>
> Add yourself to suthors as well?
Agreed. Just add your name/email address directly under mine, like so:
2025-05-29 Peter Bergner
Jeevitha Pala
MAINTAINERS: Update my email address
2025-05-09 Peter Bergner
/
* MAINTAINERS: Update my email address and add myself to DCO.
Signed-off-by: Peter Bergner
---
MAINTAINERS | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index
On 4/11/25 1:08 PM, Alexandre Oliva wrote:
>
> gcc.target/powerpc/power11-3.c uses target_clones, that depends on
> ifunc. Require ifunc support.
This looks "obvious" to me.
The only systems we (IBM) have access to build and test on all have ifunc
support, so we clearly didn't hit this ourselve
On 4/16/25 12:27 AM, Alexandre Oliva wrote:
> Since that sort of broad change will presumably not make gcc-15 (it
> wouldn't fix a regression, not even the problem addressed by the
> upthread patch),
Yes, the patch to change powerpc64 -> powerpc64_hw is definitely a
gcc-16 patch.
> ...may I un
On 4/15/25 11:44 PM, Alexandre Oliva wrote:
> On Apr 15, 2025, Peter Bergner wrote:
>> I have verified the modified test case ICEs with the exact same
>> error as the original test case using the commit immediately
>> before the commit the fixed the ICE.
>
> Awesome,
On 4/14/25 11:30 PM, Alexandre Oliva wrote:
> On Apr 14, 2025, Peter Bergner wrote:
>
>> This is an architecture independent test case, so I'm surprised this
>> doesn't FAIL on non-powerpc targets since they don't know anything
>> about altivec.
>
&
On 4/15/25 9:36 AM, Peter Bergner wrote:
> On 4/15/25 12:01 AM, Alexandre Oliva wrote:
>> On Apr 14, 2025, Peter Bergner wrote:
>>
>>> But -mcpu= should not enable -mpowerpc64 by default for -m32 compiles.
>>
>> Oh, is that so? It seems to have been the
On 4/15/25 12:01 AM, Alexandre Oliva wrote:
> On Apr 14, 2025, Peter Bergner wrote:
>
>> But -mcpu= should not enable -mpowerpc64 by default for -m32 compiles.
>
> Oh, is that so? It seems to have been the case for quite a long time.
> I can trivially see that GCC 9 alr
On 4/14/25 11:35 PM, Alexandre Oliva wrote:
>> That said, that should be done in a separate patch.
>
> *nod*. Do you mean you're going to make that change, that I should, or
> that you hope someone else will? I'd rather avoid duplication, and this
> is likely a somewhat involved change, since th
On 4/11/25 1:05 PM, Alexandre Oliva wrote:
> Multiple tests on ilp32 get TARGET_POWERPC64 enabled by -mdejagnu-cpu
> options, but the results they expect are only attained without
> enabling it, so disable it explicitly.
[snip]
> diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-sig-
On 4/11/25 1:04 PM, Alexandre Oliva wrote:
> --- a/gcc/testsuite/gcc.target/powerpc/block-cmp-8.c
> +++ b/gcc/testsuite/gcc.target/powerpc/block-cmp-8.c
> @@ -1,6 +1,6 @@
> /* { dg-do run { target ilp32 } } */
> /* { dg-options "-O2 -mpowerpc64" } */
> -/* { dg-require-effective-target has_arch_p
On 4/11/25 1:03 PM, Alexandre Oliva wrote:
> gcc.dg/pr87600.h and gcc.dg/pr89313.c test for __powerpc__ and
> __POWERPC__ to choose ppc register names, but ppc-elf defines neither;
> it defines __PPC__, so test for that as well.
Is there a reason why powerpc-*-elf doesn't define __powerpc__ or
__P
On 4/11/25 1:01 PM, Alexandre Oliva wrote:
> Like other ppc targets, powerpc-*-elf needs -Wno-psabi to compile
> gcc.dg/ipa/ipa-sra-19.c without an undesired warning about vector
> argument passing.
>
> Regstrapped on powerpc64le-linux-gnu. Also tested with gcc-14 on
> x86_64-linux-x-powerpc-elf.
On 4/11/25 12:57 PM, Alexandre Oliva wrote:
> diff --git a/gcc/testsuite/g++.dg/pr112822.C b/gcc/testsuite/g++.dg/pr112822.C
> index a8557522467d7..9ec5707eb4c4d 100644
> --- a/gcc/testsuite/g++.dg/pr112822.C
> +++ b/gcc/testsuite/g++.dg/pr112822.C
> @@ -1,6 +1,8 @@
> /* PR tree-optimization/11282
The __builtin_scalar_byte_in_set() built-in emits the cmpeqb instruction
which produces undefined results when run in 32-bit mode. The current
selector [power9-64] enables the built-in when using -m32 -mpowerpc64.
Use the no32bit attribute to fully disable it for all -m32 compiles.
This was boot
On 4/2/25 2:57 PM, Peter Bergner wrote:
> The AIX traceback table documentation states the tbtab "lang" field for
> Cobol should be set to 7.
>
> Tested on powerpc64le-linux. There are "new" FAILs with the patch (see below)
> on the Cobol test cases, but that i
The AIX traceback table documentation states the tbtab "lang" field for
Cobol should be set to 7.
Tested on powerpc64le-linux. There are "new" FAILs with the patch (see below)
on the Cobol test cases, but that is a good thing, because without the
patch, the compiler ICEs and none of the tests are
On 3/26/25 1:34 PM, David Malcolm wrote:
> Found by dg-lint.
>
> gcc/testsuite/ChangeLog:
> * gcc.target/powerpc/pr70243.c: Fix missing trailing " }" in
> dg-do directive.
> * gcc.target/powerpc/pr91903.c: Likewise.
> ---
> gcc/testsuite/gcc.target/powerpc/pr70243.c | 2 +-
> gc
On 3/26/25 3:01 AM, Jakub Jelinek wrote:
> In any case, this flag feels like a tuning decision rather than hard
> ISA requirement and I see no problems why we couldn't inline
> even explicit -msave-toc-indirect function into -mno-save-toc-indirect
> or vice versa.
> We already ignore OPTION_MASK_P{
On 3/25/25 1:42 AM, jeevitha wrote:
> gcc/testsuite/
> PR testsuite/119382
> * gcc.target/powerpc/vsx-builtin-7.c: Add '-fno-ipa-icf' to dg-options.
>
> diff --git a/gcc/testsuite/gcc.target/powerpc/vsx-builtin-7.c
> b/gcc/testsuite/gcc.target/powerpc/vsx-builtin-7.c
> index 5095d5030
On 3/25/25 5:17 PM, Segher Boessenkool wrote:
> On Tue, Mar 25, 2025 at 03:33:59PM -0500, Peter Bergner wrote:
>> Segher, any reason you can give on why we shouldn't go the easy route to
>> "fix" (yes, these are air-quotes) this by using -fno-ipa-icf?
>
> One r
On 3/20/25 2:51 AM, Richard Biener wrote:
> On Wed, Mar 19, 2025 at 6:39 PM Matthias Klose wrote:
>>
>> For building ghdl, the compiler needs to be patched to know the "vhdl"
>> language. Could that patch be applied to the upstream GCC, so that not
>> everybody needs to patch GCC to build ghdl?
>
On 2/20/25 8:11 AM, jeevitha wrote:
> The following patch has been bootstrapped and regtested on powerpc64le-linux.
A note for the future:
1) When sending a V2, V3, ... patch, please send it as its own email
thread, meaning, don't hit reply to a previous patch version email,
since that
On 2/14/25 10:43 AM, Vladimir Makarov wrote:
> The patch is very well described and it is OK for me to commit it into the
> trunk. Thank you for working on this issue, Richard.
>
> If we have some new failures on targets I believe the hook has enough
> descriptive power to fix the failures.
Note
On 2/7/25 11:48 PM, Michael Meissner wrote:
> On Fri, Feb 07, 2025 at 05:51:19PM -0600, Peter Bergner wrote:
>> On 2/7/25 4:02 PM, Michael Meissner wrote:
>>> (define_predicate "invert_fpmask_comparison_operator"
>>> - (match_code "ne,unlt,unle"))
On 2/7/25 4:02 PM, Michael Meissner wrote:
> (define_predicate "invert_fpmask_comparison_operator"
> - (match_code "ne,unlt,unle"))
> + (ior (match_code "ne")
> + (and (match_code "unlt,unle")
> + (match_test "!HONOR_NANS (DFmode) || !TARGET_P9_VECTOR"
Is it always safe to use
I pushed the following fix as obvious after testing the build and verifying
the warning was silenced.
Peter
rs6000: Add cast to avoid pointer to integer comparison warning [PR117674]
libgcc/
PR target/117674
* config/rs6000/linux-unwind.h (ppc_backchain_fallback): Add cast to
On 2/3/25 7:14 AM, Jeff Law wrote:
> On 2/3/25 2:31 AM, H.J. Lu wrote:
>> I believe the original patch should be reverted. Then my patch isn't needed.
>
> That patch had significant improvements across the board for RISC-V.
> I wouldn't want to see it reverted without a strong explanation of why i
On 2/3/25 3:44 AM, Richard Biener wrote:
> On Mon, Feb 3, 2025 at 10:32 AM H.J. Lu wrote:
>> I believe the original patch should be reverted. Then my patch isn't needed.
>
> I'm OK with that, but it's not my call. I do wonder why the contributor did
> not
> address any of the fallout. Maybe h
On 1/29/25 6:18 AM, Siddhesh Poyarekar wrote:
> Denormal behaviour is well defined for IEEE128 long doubles, so don't
> XFAIL some gfortran tests on ppc64le when configured with the IEEE128
> long double ABI.
>
> gcc/testsuite/ChangeLog:
>
> PR testsuite/118127
> * lib/target-supports
On 1/28/25 8:04 PM, Siddhesh Poyarekar wrote:
> ...do you think this would be better off being called
> ppc_not_well_defined_denormals
> or something like that?
It's better than ppc_default_long_double_not_ieee! :-)
Peter
On 1/28/25 4:51 PM, Siddhesh Poyarekar wrote:
> So the reason why I didn't go the __LONG_DOUBLE_IEEE128__ route because
> the check would then have to be something like:
>
> powerpc*-*-* && ! ppc_default_long_double_ieee
Ah, that makes sense.
> -! { dg-do run { xfail powerpc*-*-* } }
> +! { dg
On 1/28/25 11:43 AM, Siddhesh Poyarekar wrote:
> +return [check_runtime_nocache ppc_default_long_double_ibm {
> + ! Fortran
> + program default_long_double_ibm
> +integer, parameter :: kl = selected_real_kind (precision (0.0_8) + 1)
> +if (precision (0.0_kl) /= 31) the
Thanks for working on this!
On 1/28/25 12:11 PM, Surya Kumari Jangala wrote:
> + FOR_ALL_BB_FN (bb, cfun) {
{ should be on the next line.
> +FOR_BB_INSNS (bb, insn) {
Likewise.
> + pat_code = GET_CODE (PATTERN (insn));
> + if (pat_code == ASM_INPUT || pat_code == USE || pat
Unfortunately I accidentally dropped this patch series without posting V2
after Kewen's patch review. :-( Here's V2 with the suggested changes made.
Here is the thread from the V1 patch submission:
https://inbox.sourceware.org/gcc-patches/1f32e2bf-83c2-4664-b7f3-4a6996978...@linux.ibm.com/
Chan
On 1/10/25 11:18 AM, Peter Bergner wrote:
> The loop checking for built-in constant operand restrictions was missing
> some operands due to the loop limit being too small. Fixing that exposed
> a testsuite failure which is caused by a typo in the pmxvi4ger8pp definition
> where we
On 1/13/25 3:59 PM, Peter Bergner wrote:
> rs6000: Fix ICE for invalid constants in built-in functions
>
> For invalid constant operand values used in built-in functions, return
> const0_rtx to signify an error occurred during expansion.
>
> Bootstrapped and retested on powerlc
After my other patch, I decided to write a test case with an illegal
constant operand value to a built-in to see what the results would be.
Without my other patch, we fail to catch the illegal use and emit an
invalid rtl insn and hit an unrecognizable insn ICE. With my previous
patch, we correctly
FYI, I discovered this latent bug while testing a patch I'm working on.
The loop checking for built-in constant operand restrictions was missing
some operands due to the loop limit being too small. Fixing that exposed
a testsuite failure which is caused by a typo in the pmxvi4ger8pp definition
wh
On 11/20/24 4:53 AM, Surya Kumari Jangala wrote:
> +++ b/gcc/testsuite/gcc.target/powerpc/pr107757-1.c
> @@ -0,0 +1,14 @@
> +/* { dg-do compile } */
> +/* { dg-options "-mdejagnu-cpu=power8 -mvsx -O2" } */
> +/* { dg-require-effective-target powerpc_vsx } */
The -mvsx option is implied by -mcpu=po
On 11/8/24 1:48 PM, Michael Meissner wrote:
> This patch restructures the code so that -mvsx for example will not silently
> convert the processor to power7. The user must now use -mcpu=power7 or
> higher.
> This means if the user does -mvsx and the default processor does not have VSX
> support,
On 11/8/24 1:56 PM, Michael Meissner wrote:
> This patch adds the support that can be used in developing GCC support for
> future PowerPC processors.
We used to have support for -mcpu=future. Unfortunately when we added
Power10 support, rather than adding new support for the -mcpu=power10
option,
On 11/8/24 1:57 PM, Michael Meissner wrote:
> This patch makes -mtune=future use the same tuning decision as -mtune=power11.
>
> 2024-11-06 Michael Meissner
>
> gcc/
>
> * config/rs6000/power10.md (all reservations): Add future as an
> alterntive to power10 and power11.
Obviously
On 11/8/24 1:55 PM, Michael Meissner wrote:
> Two tests used -mvsx to raise the processor level to at least power7. These
> tests were rewritten to add cpu=power7 support.
Again, this cleanup patch like the TARGET_ -> TARGET_ patches
is independent of the main patches in this series (ie, patche 1
On 11/8/24 1:49 PM, Michael Meissner wrote:
> As part of the architecture flags patches, this patch changes the use of
> TARGET_POPCNTB to TARGET_POWER5. The POPCNTB instruction was added in ISA
> 2.02
> (power5).
I like what this patch and the other related clean up patches are doing,
namely ch
On 11/8/24 5:12 PM, Segher Boessenkool wrote:
> On Fri, Nov 08, 2024 at 02:28:11PM -0600, Peter Bergner wrote:
>> On 11/8/24 1:44 PM, Michael Meissner wrote:
>>> diff --git a/gcc/config/rs6000/rs6000-arch.def
>>> b/gcc/config/rs6000/rs6000-arch.def
>>> new fi
On 11/8/24 1:44 PM, Michael Meissner wrote:
> diff --git a/gcc/config/rs6000/rs6000-arch.def
> b/gcc/config/rs6000/rs6000-arch.def
> new file mode 100644
> index 000..e5b6e958133
> --- /dev/null
> +++ b/gcc/config/rs6000/rs6000-arch.def
> @@ -0,0 +1,48 @@
> +/* IBM RS/6000 CPU architecture
On 11/5/24 1:16 PM, Segher Boessenkool wrote:
> Would it not have been better to not use -O0 at all here? -O0 is
> not realistic if you expect any reasonable optimisation!
That's what I first attempted, using -O2, but the test case still FAILed
because we optimized the code too much and failed th
back.
Tested on powerpc64le-linux and verified it's fixed.
I pushed this as obvious, since it gives us back the old behavior the
test case was expecting and the test case is now immune from any future
changes in jump table generation behavior.
Peter
2024-11-05 Peter Bergner
gcc/test
On 10/3/24 2:24 PM, Segher Boessenkool wrote:
> On Thu, Mar 21, 2024 at 06:21:48PM +0530, jeevitha wrote:
>> PTImode assists in generating even/odd register pairs on 128 bits. When the
>> user
>> specifies PTImode as an attribute, it breaks because there is no internal
>> type
>> to handle this
On 8/26/24 10:39 AM, Segher Boessenkool wrote:
> On Thu, Aug 22, 2024 at 05:39:36PM +0800, Kewen.Lin wrote:
>>> - if (ALTIVEC_OR_VSX_VECTOR_MODE (mode) || mode == TImode)
>>> + if (ALTIVEC_OR_VSX_VECTOR_MODE (mode) || mode == TImode
>>> + || mode == PTImode)
>>
>> Maybe
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
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
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
Our power8 swap optimization pass has some special handling for optimizing
swaps of TImode variables. The test case reported in bugzilla uses a call
to __atomic_compare_exchange, which introduces a variable of PTImode and
that does not get the same treatment as TImode leading to wrong code
genera
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
> second machine mode
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
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/11/24 9:42 PM, Kewen.Lin wrote:
> One difference with this change is that previously users specify -mno-vsx to
> disable all vector insns (both VMX and VSX) on Power[89], now they should
> use -mno-altivec for that purpose. I think it's better as it matches the
> behaviors on Power7?
I hope
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
On 8/9/24 12:02 PM, Vladimir Makarov wrote:
> I believe your should reverse the original patch and all the patches you
> submitted to fix the issues with the original patch.
I agree this commit should be reverted and Kyrill has pushed that already,
so bootstrap should be restored now. Thank you K
On 8/9/24 12:54 PM, Segher Boessenkool wrote:
>> --- a/gcc/config/rs6000/altivec.md
>> +++ b/gcc/config/rs6000/altivec.md
>> @@ -623,7 +623,7 @@ (define_insn "altivec_eqv1ti"
>>[(set (match_operand:V1TI 0 "altivec_register_operand" "=v")
>> (eq:V1TI (match_operand:V1TI 1 "altivec_register
On 8/9/24 4:50 AM, Kewen.Lin wrote:
> As PR116266 shows, we miss TARGET_P10_VECTOR to guard those
> Power10 related vector instructions as well as their
> according built-in functions. This patch is to introduce...
LGTM.
The only change I would suggest is s/according/associated/ in
the sentence
On 7/31/24 10:21 PM, Kewen.Lin wrote:
> on 2024/8/1 01:52, Carl Love wrote:
>> Yes, I noticed that the built-ins were defined as overloaded but only had
>> one definition. Did seem odd to me.
>>
>>> either is with "vector unsigned char" as argument type, but the
>>> corresponding instance
>>> p
On 7/30/24 10:17 AM, Carl Love wrote:
> I tried, I hope I got it right, with -m32t:
>
> /* { dg-do run { target power10_hw } } */
> /* { dg-do compile { target { ! power10_hw } } } */
> /* { dg-require-effective-target int128 } */
>
> This gives:
>
> # of unsupported tests 1
>
> The
On 7/29/24 5:21 AM, Kewen.Lin wrote:
> on 2024/7/27 06:37, Carl Love wrote:
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/powerpc/vec-shift-double-runnable-int128.c
>> @@ -0,0 +1,358 @@
>> +/* { dg-do run { target power10_hw } } */
>> +/* { dg-do link { target { ! power10_hw } } } */
>> +/* {
On 7/26/24 12:07 PM, Carl Love wrote:
> On 7/24/24 11:47 AM, Segher Boessenkool wrote:
> +/* { dg-do run { target { int128 } && { power10_hw } } } */
Everything power10 is int128 always.
>>> OK, so don't need the power10_hw. Changed to just int128 for the target:
>> No, the other way aro
On 7/24/24 12:03 PM, Segher Boessenkool wrote:
>> +/* { dg-options "-mdejagnu-cpu=power10 -save-temps" } */
>
> Why the -save-temps? Always document it if you want that for something,
> but never put it in the testcase if not. A leftover from development?
I can answer this one. :-). Since th
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")
>&
On 7/19/24 3:04 PM, Carl Love wrote:
> diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
> index 5af9bf920a2..2a18ee44526 100644
> --- a/gcc/config/rs6000/altivec.md
> +++ b/gcc/config/rs6000/altivec.md
> @@ -878,9 +878,9 @@ (define_int_attr SLDB_lr [(UNSPEC_SLDB "l")
> (def
On 7/19/24 12:34 PM, Michael Meissner wrote:
> On Thu, Jul 18, 2024 at 08:08:44AM -0500, Segher Boessenkool wrote:
>>> --- a/gcc/config/rs6000/ppc-auxv.h
>>> +++ b/gcc/config/rs6000/ppc-auxv.h
>>> @@ -47,9 +47,8 @@
>>> #define PPC_PLATFORM_PPC47612
>>> #define PPC_PLATFORM_POWER8
rs6000: Catch unsupported ABI errors when using -mrop-protect
[PR114759,PR115988]
2024-07-18 Peter Bergner
gcc/testsuite/
PR target/114759
PR target/115988
* gcc.target/powerpc/pr114759-3.c: Catch unsupported ABI errors.
---
gcc/testsuite/gcc.target/powerpc/pr114759-
On 7/18/24 9:14 AM, Peter Bergner wrote:
> On 7/18/24 4:14 AM, Kewen.Lin wrote:
>>> +/* { dg-final { scan-assembler {\.\mmachine power4\M} } } */
>>> +/* { dg-final { scan-assembler {\.\mmachine altivec\M} } } */
>>
>> Nit: Both \m looks useless and can be rem
On 7/18/24 8:23 AM, Segher Boessenkool wrote:
> Everything in gcc.target/powerpc is only run for target powerpc*-*-*
> anyway, so make this just
>
> /* { dg-do compile } */
>
> please. (Or nothing, it is the default after all, but you may want to
> have it explicit).
Personally, I do like seein
On 7/18/24 4:14 AM, Kewen.Lin wrote:
>> +/* { dg-final { scan-assembler {\.\mmachine power4\M} } } */
>> +/* { dg-final { scan-assembler {\.\mmachine altivec\M} } } */
>
> Nit: Both \m looks useless and can be removed.
Fine with me. Is that because the \. acts like a \m?
>> Ok for trunk and t
On 7/18/24 12:19 AM, Kewen.Lin wrote:
> I guess you meant "Remove" is expected to remove some code explicitly and
> can be misleading here, if so how about "Don't check TARGET_LONG_DOUBLE_128
> for FLOAT128_IEEE_P modes"?
Yeah, I think that is more clear. Thanks!
Peter
On 7/17/24 4:09 AM, Kewen.Lin wrote:
> * config/rs6000/rs6000.md (@extenddf2): Remove condition
> TARGET_LONG_DOUBLE_128 for FLOAT128_IEEE_P modes.
This all LGTM, except this ChangeLog fragment doesn't match the code changes
below. Rather than removing TARGET_LONG_DOUBLE_128, you've a
On 7/16/24 6:19 PM, Carl Love wrote:
> use __int128 types that are not supported on all platforms. The
> __int128 type is only supported on 64-bit platforms. Need to check that
> the platform is 64-bits and support the __int128 type. Add the int128 and
> lp64 flags to the target test.
The test
On 7/15/24 9:19 PM, Kewen.Lin wrote:
> on 2024/7/16 04:30, Peter Bergner wrote:
>> On 7/11/24 1:24 AM, Kewen.Lin wrote:
>>> Sorry for the confusion, I meant for most target options when we emit some
>>> error
>>> message meanwhile we also unset it,
On 7/15/24 5:43 PM, Carl Love wrote:
> -/* { dg-do run } */
> +/* { dg-do run { target { lp64 } && { int128 } } } */
Why isn't this just:
/* { dg-do run { target int128 } } */
??? The int128 test should disable this on 32-bit systems just fine.
Peter
h the ROP hash insns, but we throw an error for unsupported ABIs.
This patch treats unsupported CPUs and ABIs similarly by throwing an error
both both. This matches clang behavior and allows us to simplify our tests
in the code that generates our prologue and epilogue code.
2024-07-15 Peter Bergne
On 7/11/24 1:24 AM, Kewen.Lin wrote:
> Sorry for the confusion, I meant for most target options when we emit some
> error
> message meanwhile we also unset it, such as:
>
> if (TARGET_CRYPTO && !TARGET_ALTIVEC)
> {
> if (rs6000_isa_flags_explicit & OPTION_MASK_CRYPTO)
> error ("
ons.
Ok for trunk and the release branches after some trunk burn-in time?
Peter
2024-07-12 René Rebe
Peter Bergner
gcc/
PR target/97367
* config/rs6000/rs6000.c (rs6000_machine_from_flags): Do not consider
OPTION_MASK_ALTIVEC.
(emit_asm_machine): For
On 7/10/24 1:01 AM, Kewen.Lin wrote:
>> + if (rs6000_rop_protect)
>> +{
>> + /* Disallow CPU targets we don't support. */
>> + if (!TARGET_POWER8)
>> +error ("%<-mrop-protect%> requires %<-mcpu=power8%> or later");
>> +
>> + /* Disallow ABI targets we don't support. */
>>
case for unsupported ABIs, since I'll be
working on adding ROP support for powerpc-linux and powerpc64-linux next.
Peter
2024-06-26 Peter Bergner
gcc/
PR target/114759
* config/rs6000/rs6000.cc (rs6000_override_options_after_change):
Disallow CPUs and ABIs t
Ping * 3. [Message-ID: <1e003d78-3b2e-4263-830a-7c00a3e9d...@linux.ibm.com>]
Segher, this resolves the issues you mentioned in your review.
Peter
On 6/18/24 5:59 PM, Peter Bergner wrote:
> Updated patch. This passed bootstrap and regtesting on powerpc64le-linux
> with no regr
Ping * 2. [Message-ID: <1e003d78-3b2e-4263-830a-7c00a3e9d...@linux.ibm.com>]
Segher, this resolves the issues you mentioned in your review.
Peter
On 6/18/24 5:59 PM, Peter Bergner wrote:
> Updated patch. This passed bootstrap and regtesting on powerpc64le-linux
> with no regr
On 7/3/24 4:01 AM, Kewen.Lin wrote:
>> - if (TARGET_POWER10
>> + if (TARGET_POWER8
>>&& info->calls_p
>>&& DEFAULT_ABI == ABI_ELFv2
>>&& rs6000_rop_protect)
>
> Nit: I noticed that this is the only place to change
> info->rop_hash_size to non-zero, and ...
>
>> @@ -3277,
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
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
?
Peter
2024-06-19 Peter Bergner
gcc/
PR target/114759
* config/rs6000/rs6000-logue.cc (rs6000_stack_info): Use TARGET_POWER8.
(rs6000_emit_prologue): Likewise.
* config/rs6000/rs6000.md (hashchk): Likewise.
(hashst): Likewise.
Fix whites
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
On 6/18/24 3:38 PM, Segher Boessenkool wrote:
> From my viewpoint, -mrop-protect should not change code generation at
> all, except of course it has to emit some hash* insns :-)
Ideally, I agree with that. That said, the hash* insns only accept negative
offsets and the allowed range is rather lim
On 6/12/24 2:50 AM, Kewen.Lin wrote:
> As the recent PR115355 shows, this issue can also affect the
> behavior when users are adopting vectorization optimization,
> IMHO we should get this landed as soon as possible.
I agree we want this fixed ASAP.
> As all said above, I believe this patch is
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
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
protect when we know we
will be emitting the ROP instructions (ie, non-leaf functions).
2024-06-17 Peter Bergner
gcc/
PR target/114759
* config/rs6000/rs6000.cc (rs6000_override_options_after_change): Move
the disabling of shrink-wrapping from here
*
On 6/17/24 6:11 PM, Segher Boessenkool wrote:
> "ROP insns" are the instructions used in such exploits, not what you
> mean here :-)
>
> The instructions are called "hash*"C, so maybe call tbem "hash insns"
> or "ROP protect hash insns"?.
Ok, that bad verbiage was in the extra commentary not part
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
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
1 - 100 of 1051 matches
Mail list logo
