On 5/22/23 4:04 AM, Kewen.Lin wrote:
> on 2023/5/11 02:06, Carl Love via Gcc-patches wrote:
>> @@ -3161,12 +3161,15 @@
>>void __builtin_altivec_tr_stxvrbx (vsq, signed long, signed char *);
>> TR_STXVRBX vsx_stxvrbx {stvec}
>>
>> - void __builtin_altivec_tr_stxvrhx (vsq, signed long, si
This is not a review of the patch itself, but...
On 5/31/23 2:01 AM, Ajit Agarwal wrote:
> tree-ssa-sink: Improve code sinking pass
>
> Code Sinking sinks the blocks after call.This increases register pressure
> for callee-saved registers. Improves code sinking before call in the use
> blocks or
On 6/12/23 6:18 AM, P Jeevitha wrote:
> Bitwise xor performed on bool
> is similar to checking inequality. So changed to inequality
> operator (!=) instead of bitwise xor (^).
[snip'
> - if (swapped ^ !BYTES_BIG_ENDIAN
[snip]
> + if (swapped != !BYTES_BIG_ENDIAN
I know Andreas mentione
On 7/22/22 1:17 PM, Segher Boessenkool wrote:
> On Fri, Jul 22, 2022 at 10:22:51AM +0800, Kewen.Lin wrote:
>> on 2022/7/22 02:48, Segher Boessenkool wrote:
>> As PR106345 shows, GCC can use an explicit tune setting when it's
>> configured, even if there is one "-mdejagnu-cpu=", it doesn't
>> overri
On 7/22/22 1:53 PM, Peter Bergner wrote:
> So I think the way the code above *should* work is:
> 1) Any -mdejagnu-cpu= usage should filter out all -mcpu= and -mtune=
> options.
> 2) Any -mdejagnu-tune= usage should filter all -mtune= options.
> It should not filter out any -mcpu= options.
] c: Handle initializations of opaque types [PR106016]
On 6/17/22 11:50 PM, Peter Bergner via Gcc-patches wrote:
> The initial commit that added opaque types thought that there couldn't
> be any valid initializations for variables of these types, but the test
> case in the bug report shows that
On 7/26/22 1:57 AM, Richard Biener via Gcc-patches wrote:
>> On 6/17/22 11:50 PM, Peter Bergner via Gcc-patches wrote:
>>> The initial commit that added opaque types thought that there couldn't
>>> be any valid initializations for variables of these types, but the te
On 7/19/23 11:46 AM, jeevitha via Gcc-patches wrote:
> gcc/
> PR target/110411
> * config/rs6000/mma.md (define_insn_and_split movoo): Disallow
> AltiVec address in movoo and movxo pattern.
No need to mention movxo here, since the next change covers movxo.
And maybe better as "Di
On 8/16/23 7:19 PM, Carl Love wrote:
> +(define_insn "dfp_dquan_"
> + [(set (match_operand:DDTD 0 "gpc_reg_operand" "=d")
> +(unspec:DDTD [(match_operand:DDTD 1 "gpc_reg_operand" "d")
> + (match_operand:DDTD 2 "gpc_reg_operand" "d")
> + (match_operand:QI
On 8/2/23 8:23 AM, Vladimir Makarov wrote:
>>> gcc/
>>> PR rtl-optimization/PR110254
>>> * ira-color.cc (improve_allocation): Update array
>
> I guess you missed the next line in the changelog. I suspect it should be
> "Update array allocated_hard_reg_p."
>
> Please, fix it before commi
On 6/16/23 12:01 PM, Ian Lance Taylor via Gcc-patches wrote:
> On Fri, Jun 16, 2023 at 9:00 AM Paul E. Murphy via Gcc-patches
> wrote:
>>
>> TARGET_AIX is defined to a non-zero value on linux and maybe other
>> powerpc64le targets. This leads to unexpected behavior such as
>> dropping the .go_exp
On 6/22/23 6:37 PM, Peter Bergner via Gcc-patches wrote:
> On 6/16/23 12:01 PM, Ian Lance Taylor via Gcc-patches wrote:
>> On Fri, Jun 16, 2023 at 9:00 AM Paul E. Murphy via Gcc-patches
>> wrote:
>>>
>>> TARGET_AIX is defined to a non-zero value on linux and ma
On 6/21/23 11:20 AM, Paul E Murphy via Gcc-patches wrote:
>
>
> On 6/19/23 3:39 AM, Thomas Schwinge wrote:
>> Hi Paul!
>>
>> On 2023-06-16T11:00:02-0500, "Paul E. Murphy via Gcc-patches"
>> wrote:
>>> This was noticed when fixing the gccgo usage of the macro, the
>>> rust usage is very similar.
On 6/1/23 11:54 PM, Ajit Agarwal via Gcc-patches wrote:
>
>
> On 01/06/23 2:06 pm, Bernhard Reutner-Fischer wrote:
>> On 1 June 2023 09:20:08 CEST, Ajit Agarwal wrote:
>>> Hello All:
>>>
>>> This patch improves code sinking pass to sink statements before call to
>>> reduce
>>> register pressure
On 6/29/23 4:13 AM, Kewen.Lin wrote:
> on 2023/6/19 23:57, Carl Love wrote:
>> The following patch changes the return type of the
>> __builtin_set_fpscr_rn builtin from void to double. The return value
>> is the current value of the various FPSCR fields DRN, VE, OE, UE, ZE,
>> XE, NI, RN bit posi
On 6/22/23 10:30 PM, Ian Lance Taylor wrote:
> On Thu, Jun 22, 2023, 4: 47 PM Peter Bergner
> wrote: On 6/22/23 6: 37 PM, Peter Bergner via Gcc-patches wrote: > On 6/16/23
> >> On Fri, Jun 16, 2023 at 9:00 AM Paul E. Murphy via Gcc-patches
> >> mailto:gcc-
On 6/30/23 5:20 PM, Carl Love wrote:
> So, we have the issue that looking at the assembly gives different
> instruction counts then what
>
>dg-final { scan-assembler-times {\mxxlor\M} }
>
> comes up with???
I recommend not even counting xxlor at all, since the majority of
them come from vsx
On 6/30/23 6:50 PM, Carl Love wrote:
> With a little help from Peter and Julian Wang. Objdump decodes some of
> the xxlor instructions as xxmr instsructions. The xxmr is a new
> mnemonic which will be out in the next ISA. But objdump already
> produces it. So if you add the counts for grep xxlo
On 6/28/23 3:07 AM, Kewen.Lin wrote:
> I think the reason why we need to check common_deferred_options is at this
> time
> we can't distinguish the fixed_regs[2] is from the initialization or command
> line
> user explicit specification. But could we just update the FIXED_REGISTERS
> without
>
On 7/6/23 12:33 PM, Segher Boessenkool wrote:
> On Wed, Jul 05, 2023 at 05:21:18PM +0530, P Jeevitha wrote:
>> --- a/gcc/config/rs6000/rs6000.cc
>> +++ b/gcc/config/rs6000/rs6000.cc
>> @@ -9894,6 +9894,8 @@ rs6000_legitimate_address_p (machine_mode mode, rtx x,
>> bool reg_ok_strict)
>>
>>/*
On 6/30/23 7:58 PM, Carl Love via Gcc-patches wrote:
> rs6000, __builtin_set_fpscr_rn add retrun value
s/retrun/return/
Maybe better written as:
rs6000: Add return value to __builtin_set_fpscr_rn
> Change the return value from void to double. The return value consists of
> the FPSCR fields DR
On 7/6/23 5:54 PM, Peter Bergner wrote:
> On 6/30/23 7:58 PM, Carl Love via Gcc-patches wrote:
>> +++ b/gcc/testsuite/gcc.target/powerpc/test_fpscr_rn_builtin_2.c
>> @@ -0,0 +1,153 @@
>> +/* { dg-do run { target { powerpc*-*-* } } } */
>
> powerpc*-*-* is the default for this test directory, so yo
On 7/7/23 12:08 AM, Kewen.Lin wrote:
> on 2023/7/7 07:00, Peter Bergner wrote:
>> On 7/6/23 5:54 PM, Peter Bergner wrote:
>>> On 6/30/23 7:58 PM, Carl Love via Gcc-patches wrote:
+++ b/gcc/testsuite/gcc.target/powerpc/test_fpscr_rn_builtin_2.c
@@ -0,0 +1,153 @@
+/* { dg-do run { targ
On 7/6/23 6:28 PM, Segher Boessenkool wrote:
> On Thu, Jul 06, 2023 at 02:48:19PM -0500, Peter Bergner wrote:
>> On 7/6/23 12:33 PM, Segher Boessenkool wrote:
>>> On Wed, Jul 05, 2023 at 05:21:18PM +0530, P Jeevitha wrote:
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.c
While helping someone on the team debug an issue, I noticed some redundant
tests in a couple of our predicates which can be removed. I'm going to
commit the following as obvious once bootstrap and regtesting come back
clean.
Peter
rs6000: Remove redundant MEM_P predicate usage
The quad_memory_
On 7/10/23 2:18 PM, Carl Love wrote:
> + /* Get the current FPSCR fields, bits 29:31 (DRN) and bits 56:63 (VE, OE,
> UE,
> + ZE, XE, NI, RN) from the FPSCR and return them. */
The 'Z' above should line up directly under the 'G' in Get.
> - /* Insert new RN mode into FSCPR. */
> -
On 7/10/23 11:47 AM, Peter Bergner wrote:
> While helping someone on the team debug an issue, I noticed some redundant
> tests in a couple of our predicates which can be removed. I'm going to
> commit the following as obvious once bootstrap and regtesting come back
> clean.
>
> Peter
>
>
> rs60
On 6/29/23 4:31 AM, Kewen.Lin via Gcc-patches wrote:
> This is okay for trunk (no backports needed btw), this fix can even be
> taken as obvious, thanks!
>
>>
>> 2023-06-07 Jeevitha Palanisamy
>>
>> gcc/
>> PR target/106907
>
> One curious question is that this PR106907 seemed not to repo
PR109073 shows a problem where GCC 11 and GCC 10 do not accept a const
__vector_pair pointer operand to some MMA builtins, which GCC 12 and later
correctly accept. Fixed here by initializing the builtins to accept const
pointers.
This patch was tested in both GCC 11 and GCC 10 on powerpc64le-linu
On 3/9/23 8:55 AM, Segher Boessenkool wrote:
> On Thu, Mar 09, 2023 at 05:30:53PM +0800, Kewen.Lin wrote:
>> on 2023/3/9 07:01, Peter Bergner via Gcc-patches wrote:
>>> This patch was tested in both GCC 11 and GCC 10 on powerpc64le-linux and
>>> showed no regressions.
On 5/5/23 4:42 PM, Jakub Jelinek wrote:
> On Thu, May 04, 2023 at 02:29:34PM -0500, Peter Bergner wrote:
>> Merged from upstream libffi commit: 464b4b66e3cf3b5489e730c1466ee1bf825560e0
>>
>> 2023-05-03 Dan Horák
>>
>> libffi/
>> PR libffi/109447
>> * src/powerpc/ffi_linux64.c (ffi_prep_
On 5/9/23 3:50 PM, Andreas Schwab wrote:
> On Mai 09 2023, Peter Bergner via Gcc-patches wrote:
>
>> It's almost as if the top level build machinery
>> adds a LD_LIBRARY_PATH=...
>
> See how the toplevel Makefile sets LD_LIBRARY_PATH (via RPATH_ENVVAR) if
> gcc-bo
On 5/10/23 2:34 AM, Andreas Schwab wrote:
> On Mai 09 2023, Peter Bergner via Gcc-patches wrote:
>> I'm sorry to be dense, but can you point to the specific line? In my
>> $GCC_BUILD/Makefile, the only mention of LD_LIBRARY_PATH is:
>>
>> RPATH_ENVVAR = LD_LIB
On 5/18/23 6:16 AM, Ajit Agarwal via Gcc-patches wrote:
> -/* { dg-final { scan-assembler-times {\mrldicl\M} 7 { target { le } } } } */
> +/* { dg-final { scan-assembler-times {\mrldicl\M} 5 { target { le } } } } */
> /* { dg-final { scan-assembler-times {\mrldicl\M} 4 { target { lp64 && be }
> }
On 5/10/23 1:06 PM, Carl Love wrote:
> - void __builtin_altivec_tr_stxvrhx (vsq, signed long, signed int *);
> + void __builtin_altivec_tr_stxvrhx (vsq, signed long, signed short *);
> TR_STXVRHX vsx_stxvrhx {stvec}
>
> - void __builtin_altivec_tr_stxvrwx (vsq, signed long, signed short *
On 5/23/23 12:24 AM, Kewen.Lin wrote:
> on 2023/5/23 01:31, Carl Love wrote:
>> The builtins were requested for use in GLibC. As of version 2.31 they
>> were added as inline asm. They requested a builtin so the asm could be
>> removed.
>
> So IMHO we also want the similar support for mffscrn, tha
On 5/24/23 10:20 AM, Carl Love wrote:
> Extending the builtin to pre Power 9 is straight forward and I agree
> would make good sense to do.
>
> I am a bit concerned on how to extend __builtin_set_fpscr_rn to add the
> new functionality. Peter suggests overloading the builtin to either
> return vo
On 1/28/21 1:47 PM, Segher Boessenkool wrote:
> On Thu, Jan 28, 2021 at 02:30:56PM -0500, Michael Meissner wrote:
>> The second patch I want you to review is:
>
> "This patch replaces the following three patches:"
>
> Please send a patch that modifies *current* code, and that is *tested*
> with t
Adding Richard since he's reviewed the generic opaque mode code in
the past and this patch contains some more eneric support.
GCC handles pseudos that are used uninitialized, by emitting a
(set (reg: ) CONST0_RTX(regmode)) before their uninitialized
pseudo usage. Currently, CONST0_RTX(mode) is NU
The LLVM and GCC teams agreed to rename the __builtin_mma_assemble_pair and
__builtin_mma_disassemble_pair built-ins to __builtin_vsx_assemble_pair and
__builtin_vsx_disassemble_pair respectively. It's too late to remove the
old names, so this patch adds support for creating compatibility built-in
On 2/4/21 3:16 PM, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Feb 04, 2021 at 02:40:20PM -0600, Peter Bergner wrote:
>> The LLVM and GCC teams agreed to rename the __builtin_mma_assemble_pair and
>> __builtin_mma_disassemble_pair built-ins to __builtin_vsx_assemble_pair and
>> __builtin_vsx_disas
On 2/5/21 4:28 AM, Florian Weimer wrote:
> * Peter Bergner via Gcc-patches:
>
>> The LLVM and GCC teams agreed to rename the __builtin_mma_assemble_pair and
>> __builtin_mma_disassemble_pair built-ins to __builtin_vsx_assemble_pair and
>> __builtin_vsx_disassemble_pair
The mma_assemble_input_operand predicate is too lenient on the memory
operands it will accept, leading to an ICE when illegitimate addresses
are passed in. The solution is to only accept memory operands with
addresses that are valid for quad word memory accesses. The test case
is a minimized test
The rs6000_emit_le_vsx_* functions assume they are not passed an Altivec
style "& ~16" address. However, some of our expanders and splitters do
not verify we do not have an Altivec style address before calling those
functions, leading to an ICE. The solution here is to guard the expanders
and spl
On 2/8/21 7:29 AM, Segher Boessenkool wrote:
>> I think we should either add a new rtx code for constant opaque modes
>> or make init-regs just emit the clobber for opaque modes (and not emit
>> the move).
>
> Thanks for looking Richard. That last option sounds good to me as well.
Ok, guarding t
On 2/12/21 4:21 PM, Peter Bergner wrote:
> rtl-optimization: Fix uninitialized use of opaque mode variable ICE [PR98872]
>
> The initialize_uninitialized_regs function emits (set (reg:) (CONST0_RTX))
> for all uninitialized pseudo uses. However, some modes (eg, opaque modes)
> may not have a CONS
On 2/15/21 6:25 AM, Richard Sandiford wrote:
> Peter Bergner writes:
>> 2021-02-12 Peter Bergner
>>
>> gcc/
>> PR rtl-optimization/98872
>> * init-regs.c (initialize_uninitialized_regs): Skip initialization
>> if CONST0_RTX is NULL.
>>
>> gcc/testsuite/
>> PR rtl-optimizatio
On 2/5/21 12:28 PM, Segher Boessenkool wrote:
> On Fri, Feb 05, 2021 at 04:11:30PM +0100, Florian Weimer wrote:
>> * Peter Bergner:
>>> On 2/5/21 4:28 AM, Florian Weimer wrote:
Maybe add a check that the compatibility builtins are flagged as
availble using __has_builtin?
>>>
>>> Do you me
On 2/23/21 4:53 PM, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Feb 23, 2021 at 04:00:42PM -0600, Peter Bergner wrote:
>> (mma_assemble_pair): Add compatibility built-in.
> s/Add/New/ is better (it makes clear you do not add something to the
> (already existing) mma_assemble_pair, that it is
The initialization of compat builtins assumes the builtin we are creating
a compatible builtin for exists and ICEs if it doesn't. However, there are
valid reasons why some builtins are disabled for a particular compile.
In this case, the MMA builtins are disabled for -mcpu=440 (and other cpus),
so
On 2/25/21 7:08 PM, David Edelsohn wrote:
> On Thu, Feb 25, 2021 at 8:05 PM Peter Bergner wrote:
>>
>> The initialization of compat builtins assumes the builtin we are creating
>> a compatible builtin for exists and ICEs if it doesn't. However, there are
>> valid reasons why some builtins are dis
PR101849 shows we ICE on a test case when we pass a non __vector_pair *
pointer to the __builtin_vsx_lxvp and __builtin_vsx_stxvp built-ins
that is cast to __vector_pair *. The problem is that when we expand
the built-in, the cast has already been removed from gimple and we are
only given the base
On 8/12/21 1:20 PM, David Edelsohn wrote:
> On Tue, Aug 10, 2021 at 7:37 PM Peter Bergner wrote:
>> gcc/
>> PR target/101849
>> * config/rs6000/rs6000-call.c (rs6000_gimple_fold_mma_builtin): Cast
>> pointer to __vector_pair *.
>>
>> gcc/testsuite/
>> PR target/1018
On 8/13/21 12:15 PM, Bill Schmidt wrote:
> Honestly, I don't see how it matters. So far as I can tell, all you've done
> here is hand-inlined what build_simple_mem_ref would do. So I guess I have
> a slight preference for your original patch (but with the new test case,
> of course).
Ok, I ended
Fwprop will happily optimize two xxsetaccz instructions into one xxsetaccz
by propagating the results of the first to the uses of the second.
We really don't want that to happen given the late priming/depriming of
accumulators. I fixed this by making the xxsetaccz source operand an
unspec volatile
> rs6000_is_valid_shift_mask handles this already (but it requires you to
> pass in the shift needed). rs6000_is_valid_mask will handle it.
> rs6000_is_valid_and_mask does not get a shift count parameter, so cannot
> use rldic currently.
After talking with you off line, I changed to using rs6000_
On 9/15/20 1:38 PM, Alexandre Oliva wrote:
>> +case SFmode:
>> +case DFmode:
>
> gcc110 (ppc64) in the build farm didn't like this. The bootstrap
> compiler barfs on these expressions, because of some constexpr issue I
> haven't really looked into.
>
> I'm testing this patch. I'll check
On 9/24/20 6:22 PM, Segher Boessenkool wrote:
>> + result [(__N & 0b)] = __D;
>
> Hrm, GCC supports binary constants like this since 2007, so okay. But I
> have to wonder if this improves anything over hex (or decimal even!)
> The parens are superfluous (and only hinder legibility), fwiw.
+
I forgot to CC the gcc-patches mailing list on the original patch submission.
Adding it in now. Sorry.
On 3/14/22 8:24 PM, Segher Boessenkool wrote:
>> gcc/
>> PR target/104923
>> * config/rs6000/predicates.md (mma_disassemble_output_operand):
>> Restrict acceptable MEM addresses.
>
On 3/14/22 10:06 PM, Peter Bergner wrote:
> On 3/14/22 8:24 PM, Segher Boessenkool wrote:
>> You might want to name that common expression, "rtx addr = XEXP (op, 0);"
>> or something. Dunno what is best
>
> Will do.
>
>
>> Please put that new MEM_P code first, followed by a blank line, and only
On 3/4/22 8:14 PM, Peter Bergner wrote:
> On 3/4/22 11:33 AM, Peter Bergner wrote:
>>> Ok pushed to trunk. I haven't determined yet whether we need this on GCC
>>> 11 yet.
>>> I'll check on that and report back. Thanks!
>>
>> I've confirmed that GCC 11 fails the same way and that the backported
On 3/16/22 7:33 AM, Segher Boessenkool wrote:
> On Tue, Mar 15, 2022 at 02:49:39PM -0500, Peter Bergner wrote:
>> The trunk patch has been confirmed to fix the glibc build errors and no
>> issues
>> with the patch has surfaced, so ok for the GCC11 and GCC10 release branches?
>
> If you can confir
This patch updates the POWER testsuite test cases using -mcpu= and -mtune=
to use the preferred -mdejagnu-cpu= and -mdejagnu-tune= options. This also
obviates the need for the dg-skip-if directive, since the user cannot
override the -mcpu= value being used to compile the test case.
This passed re
On 3/25/22 4:08 PM, Segher Boessenkool wrote:
> On Fri, Mar 25, 2022 at 02:51:38PM -0500, Peter Bergner wrote:
>> This patch updates the POWER testsuite test cases using -mcpu= and -mtune=
>> to use the preferred -mdejagnu-cpu= and -mdejagnu-tune= options. This also
>> obviates the need for the dg
On 4/1/22 3:50 PM, will schmidt wrote:
> Is there a testcase, new or existing, that illustrates this error path?
Well, the already existsing test case pr101849.c is where the issue was seen,
but only when compiled by hand outside of the test harness and using only the
-maltivec option and not the
Before PCREL in POWER10, we were not allowed to perform sibcalls to longcall
functions since callee's return would skip the TOC restore in the caller.
However, with PCREL we can now safely perform a sibling call to longcall
functions. The problem with the current code in rs6000_sibcall_aix is that
On 4/5/22 5:32 PM, Segher Boessenkool wrote:
> On Tue, Apr 05, 2022 at 05:06:50PM -0500, Peter Bergner wrote:
>>
>> + /* Handle longcall attributes. */
>> + if ((INTVAL (cookie) & CALL_LONG) != 0
>> + && GET_CODE (func_desc) == SYMBOL_REF)
>
> Don't say "!= 0" here please.
>
> if (INT
On 4/5/22 10:33 PM, Peter Bergner via Gcc-patches wrote:
> On 4/5/22 5:32 PM, Segher Boessenkool wrote:
>> On Tue, Apr 05, 2022 at 05:06:50PM -0500, Peter Bergner wrote:
>>>
>>> + /* Handle longcall attributes. */
>>> + if ((INTVAL (cookie) & CALL_LONG
On 4/11/22 4:13 PM, Segher Boessenkool wrote:
> On Wed, Apr 06, 2022 at 02:33:52PM -0500, Peter Bergner wrote:
>> On 4/5/22 10:33 PM, Peter Bergner via Gcc-patches wrote:
>>> On 4/5/22 5:32 PM, Segher Boessenkool wrote:
>>>> On Tue, Apr 05, 2022 at 05:06:50PM -0500,
On 4/20/22 11:01 AM, Michael Meissner wrote:
> Ping patch.
>
> | Date: Tue, 12 Apr 2022 21:14:55 -0400
> | From: Michael Meissner
> | Subject: [PATCH, V4] Eliminate power8 fusion options, use power8 tuning, PR
> target/102059
> | Message-ID:
>
> I feel this is an important patch. Please look
On 2/4/22 12:03 PM, Segher Boessenkool wrote:
> On Fri, Feb 04, 2022 at 04:43:53PM +0100, Andreas Schwab wrote:
>> On Feb 04 2022, Michael Meissner via Gcc-patches wrote:
>>> If the user did not specify a default long double format when configuring
>>> GCC, use the long double default from the host
On 2/4/22 4:26 PM, Segher Boessenkool wrote:
> As I said before, I didn't even read the patch, just the one line
> summary was enough for a NAK. If the patch in fact does something else,
> then it is still incorrect, and needs a very different subject and
> summary.
>
> I hope you see how "using
The HTM tbegin. instruction can fail intermittently due to many reasons.
This can lead to the htm-1.c testsuite test case FAILing from time to time.
The solution is to allow retrying the instruction a few times before aborting.
Bill has seen this fail a 1-2 times per 1 runs. With the change b
On 2/15/22 3:54 PM, Segher Boessenkool wrote:
> On Tue, Feb 15, 2022 at 01:03:09PM -0600, Peter Bergner wrote:
>> The HTM tbegin. instruction can fail intermittently due to many reasons.
>
> Just a few really. But, if the transaction fails it will appear as if
> the tbegin. had an error as well,
On 2/17/22 1:04 PM, Robin Dapp via Gcc-patches wrote:
>> Please send patches as plain text, not as base64.
>
> It seems like Thunderbird does not support this anymore since later
> versions, grml. Probably need to look for another mail client.
I use Thunderbird with no problems. I use the Quick
Sorry for dropping the ball on testing the patch from the bugzilla!
The following patch fixes the ICE reported in the bugzilla on the pre-existing
gcc testsuite test case, bootstraps and shows no testsuite regressions
on powerpc64le-linux. Ok for trunk?
Peter
For -ftrivial-auto-var-init=*, ski
On 11/30/21 2:37 AM, Richard Biener wrote:
> On Mon, Nov 29, 2021 at 11:56 PM Qing Zhao wrote:
> I think that's inconsistent indeed. Peter, what are "opaque"
> registers? rs6000-modes.def suggests
> that there's __vector_pair and __vector_quad, what's the GIMPLE types
> for those? It seems they
On 11/30/21 11:51 AM, Qing Zhao wrote:
> So, looks like that the variable with OPAQUE_TYPE cannot be all explicitly
> initialized even at source code level.
>
> The only way to initialize such variable (only __vector_quad, not for
> __vector_pairs) at source code level is through call to
> __b
On 11/30/21 1:50 PM, Qing Zhao via Gcc-patches wrote:
>> void
>> bar (__vector_pair *dst, __vector_pair *src)
>> {
>> __vector_pair pair;
>> pair = *src;
>> ...
>> }
>
> However, even with the above, the memory pointed by “src” still need to
> be initialized somewhere. How to provide the initia
On 11/30/21 2:44 PM, Qing Zhao via Gcc-patches wrote:
> Sorry for the confusing…
> My major question is:
>
> for a variable of type __vector_pair, could it be in a register?
Yes. To be pedantic, it will live in a vector register pair.
> If it could be in a register, can we initialize this r
On 12/1/21 9:06 AM, Qing Zhao wrote:
>> On Dec 1, 2021, at 3:01 AM, Richard Biener
>> wrote:
>> Given all this I suggest to exempt OPAQUE_TYPE from is_var_need_auto_init
>> instead of fixing up things at expansion time.
>
> Agreed.
>
> So, Peter, will you update the routine “is_var_need_auto_i
On 12/1/21 3:01 AM, Richard Biener wrote:
> Given all this I suggest to exempt OPAQUE_TYPE from is_var_need_auto_init
> instead of fixing up things at expansion time.
The following fixes the ICE. The bootstrap/regtesting is still running though.
Peter
diff --git a/gcc/gimplify.c b/gcc/gimplify
On 12/1/21 1:07 PM, Richard Biener wrote:
> On December 1, 2021 6:42:21 PM GMT+01:00, Peter Bergner
> wrote:
>> On 12/1/21 3:01 AM, Richard Biener wrote:
>>> Given all this I suggest to exempt OPAQUE_TYPE from is_var_need_auto_init
>>> instead of fixing up things at expansion time.
>>
>> The foll
I'd like to ping the following patch.
The test case in the previously OK'd fix for PR101324 depends on this change,
so I've had to hold off committing it until this is in. Thanks.
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584208.html
Peter
Message-ID:
This patch adds a new
On 12/2/21 5:15 PM, Segher Boessenkool wrote:
>> Tested on powerpc64le*-linux with no regressions. Ok for mainline?
>
> What can "*" be there other than the empty string? Which valuse of "*"
> did you test? :-)
Heh, too used to typing powerpc64*-linux. Yeah, in this case * == "".
> Okay fo
On 10/29/21 4:45 PM, Segher Boessenkool wrote:
> On Wed, Oct 27, 2021 at 10:17:39PM -0500, Peter Bergner wrote:
>> 2021-10-27 Martin Liska
>>
>> gcc/
>> PR target/101324
>> * config/rs6000/rs6000.c (rs6000_option_override_internal): Move the
>> disabling of shrink-wrapping when us
On 12/3/21 2:39 PM, Peter Bergner wrote:
> On 10/29/21 4:45 PM, Segher Boessenkool wrote:
>> On Wed, Oct 27, 2021 at 10:17:39PM -0500, Peter Bergner wrote:
>>> 2021-10-27 Martin Liska
>>>
>>> gcc/
>>> PR target/101324
>>> * config/rs6000/rs6000.c (rs6000_option_override_internal): Move t
On 12/3/21 3:27 PM, Peter Bergner wrote:
> On 12/3/21 2:39 PM, Peter Bergner wrote:
>> On 10/29/21 4:45 PM, Segher Boessenkool wrote:
>>> On Wed, Oct 27, 2021 at 10:17:39PM -0500, Peter Bergner wrote:
2021-10-27 Martin Liska
gcc/
PR target/101324
* config/rs6000/rs
On 12/2/21 9:46 PM, Kewen.Lin via Gcc-patches wrote:
> on 2021/11/30 上午12:57, Segher Boessenkool wrote:
>> On Wed, Sep 01, 2021 at 02:55:51PM +0800, Kewen.Lin wrote:
>>> This patch is to fix the inconsistent behaviors for non-LTO mode
>>> and LTO mode. As Martin pointed out, currently the function
On 12/2/21 4:24 PM, Segher Boessenkool wrote:
> On Thu, Dec 02, 2021 at 10:43:24AM -0600, Bill Schmidt wrote:
>> The new built-in infrastructure is now enabled!
>
> Congratulations, and thanks for all the work!
A big +1!
Peter
On 12/6/21 3:35 AM, Martin Liška wrote:
> On 12/4/21 00:23, Peter Bergner wrote:
>> I thought Martin and richi mentioned that target attribute options
>> are treated as if they are appended to the end of the command line
>> options, so they can potentially override earlier options, but they
>> don'
On 12/6/21 7:06 AM, Segher Boessenkool wrote:
> On Fri, Dec 03, 2021 at 11:46:53AM +0800, Kewen.Lin wrot
>> Without this fix, bar inlines foo but get the error as below:
>>
>> In function ‘foo’,
>> inlined from ‘bar’ at test.c:8:8:
>> test.c:3:9: error: ‘__builtin_ttest’ requires the ‘-mhtm’ op
The new rop_ok effective target test doesn't correctly compute its expression
result. Solution is to wrap the test within a expr {} statement.
This has been verified to work on both powerpc64le-linux and powerpc64-linux.
The original test case accidentally worked on LE, but failed on BE. Now we
On 12/7/21 12:20 PM, Peter Bergner wrote:
> proc check_effective_target_rop_ok { } {
> -return [check_effective_target_power10_ok]
> - && [check_effective_target_powerpc_elfv2]
> +return [expr { [check_effective_target_power10_ok]
> +&& [check_effective_target_power
On 8/23/22 6:49 AM, Surya Kumari Jangala wrote:
> sched1: Fix -fcompare-debug issue in schedule_region [PR105586]
>
> In schedule_region(), a basic block that does not contain any real insns
> is not scheduled and the dfa state at the entry of the bb is not copied
> to the fallthru basic block. Ho
When we expand an MMA disassemble built-in with C++ using a pointer that
is casted to a valid MMA type, the type isn't passed down to the expand
machinery and we end up using the base type of the pointer which leads to
an ICE. This patch enforces we always use the correct MMA type regardless
of th
GCC incorrectly disables conversions between MMA pointer types, which
are allowed with clang. The original intent was to disable conversions
between MMA types and other other types, but pointer conversions should
have been allowed. The fix is to just remove the MMA pointer conversion
handling cod
On 8/27/22 4:37 PM, Segher Boessenkool wrote:
> Such conversions are explicitly allowed in C, even (6.3.2.3/7).
Yeah, I think I just got a little carried away disabling them originally. :-(
>> The fix is to just remove the MMA pointer conversion
>> handling code altogether.
>
> Okay for trunk a
On 8/27/22 7:47 PM, Peter Bergner via Gcc-patches wrote:
> On 8/27/22 4:37 PM, Segher Boessenkool wrote:
>>> The fix is to just remove the MMA pointer conversion
>>> handling code altogether.
>>
>> Okay for trunk and all backports. Thanks!
>
> Ok, pushed t
I'd like to ping the following patch.
Peter
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600451.html
Message-ID:
>When we expand an MMA disassemble built-in with C++ using a pointer that
>is casted to a valid MMA type, the type isn't passed down to the expand
>machinery and we e
1 - 100 of 298 matches
Mail list logo
