I'd love for (something like) gcc-testresults@ to be usefully
searchable (it can be done but... lacks), so please allow me:
On Fri, 13 Sep 2024, Frank Ch. Eigler wrote:
> diff --git a/contrib/test_summary b/contrib/test_summary
> index 5760b053ec27..867ada4d6b81 100755
> --- a/contrib/test_summar
Here's a general approach to handle PR116701. I considered
adding manual deletions as quoted below and mentioned in the
PR, but seeing the handling of "integer 8" in
fortran-torture-execute I decided to follow that example:
better scan the source for open-statements than relying on
manual annotati
> Date: Wed, 25 Sep 2024 13:51:07 +0200
> From: Andre Vehreschild
> Hi Hans-Peter,
>
> preface: I am not a testsuite nor an m4 expert.
Neither am I. Luckily, this has nothing to do with m4, and
not really that much to do with tcl or dejagnu either, being
just basic code, no la
On November 6, 2024 10:15:13 AM PST, Jakub Jelinek wrote:
>On Wed, Nov 06, 2024 at 10:03:25AM -0800, H. Peter Anvin wrote:
>> The issue is that we want the frame pointer chain to be maintained, even
>> across alternatives.
>
>If the current function doesn't have frame po
On November 6, 2024 7:27:51 AM PST, Uros Bizjak wrote:
>On Wed, Nov 6, 2024 at 11:57 AM Jakub Jelinek wrote:
>>
>> On Wed, Nov 06, 2024 at 10:44:54AM +0100, Uros Bizjak wrote:
>> > After some more thinking and considering all recent discussion
>> > (thanks!), I am convinced that a slightly simpli
On November 6, 2024 8:31:53 AM PST, Uros Bizjak wrote:
>On Wed, Nov 6, 2024 at 5:23 PM Jakub Jelinek wrote:
>>
>> On Wed, Nov 06, 2024 at 05:05:54PM +0100, Uros Bizjak wrote:
>> > Please see [1]:
>> >
>> > /*
>> > * This output constraint should be used for any inline asm which has a
>> > "call
On Sat, 16 Nov 2024, Lewis Hyatt wrote:
> The size of struct gimple increases by 8 bytes with the change in size of
> location_t from 32- to 64-bit
Half-way scrolling through the patches, this seems a good time
for a possibly disruptive comment from the side-line: ;-)
For the size-critical types
On Wed, 20 Nov 2024, Feng Wang wrote:
> This patch fix the wrong condition for RVVMF2BF. It should be
> TARGET_VECTOR_ELEN_BF_16.
> gcc/ChangeLog:
>
> PR target/117669
> * config/riscv/vector-iterators.md:
>
> Signed-off-by: Feng Wang
There's missing text after the ":", where one w
Forcing a fail and marking as xfail is IMHO better than
passing --param=logical-op-non-short-circuit=0 or #pragma
GCC unroll, making the test pass. To wit, this makes it
observable when it's fixed.
Ok to commit?
-- >8 --
This is expected fallout from r15-5646-gd1cf0d7a0f27fd as
described by that
> From: Sam James
> Date: Sun, 08 Dec 2024 19:06:12 +
> Hans-Peter Nilsson writes:
>
> > v2: oops, typo: component is tree-optimization, not tree-ssa.
> > Resent for the benefit of autotesters that don't yet
> > understand natural language.
> >
&
v2: oops, typo: component is tree-optimization, not tree-ssa.
Resent for the benefit of autotesters that don't yet
understand natural language.
Forcing a fail and marking as xfail is IMHO better than
passing --param=logical-op-non-short-circuit=0 or #pragma
GCC unroll, making the test pass. To wi
On Sat, 30 Nov 2024, Jeff Law wrote:
>
>
> On 11/28/24 5:26 AM, Alexey Merzlyakov wrote:
> > This patch adds optimization of the following patterns:
> >
> >(zero_extend:M (subreg:N (not:O==M (X:Q==M ->
> >(xor:M (zero_extend:M (subreg:N (X:M)), mask))
> >... where the mask is GE
> From: Richard Biener
> Date: Mon, 9 Dec 2024 10:06:49 +0100
> As Andrew said the fix the testcase was written for was targeting
> --param logical-op-non-short-circuit=1 it makes more sense to force
> that so we continue to check it works.
'k, that's a valid argument.
> We should simply track
I could probably assume that this is what you had in mind,
but anyway: Ok to commit?
-- >8 --
PR117973 covers the aspect of
non-LOGICAL_OP_NON_SHORT_CIRCUIT targets for PR111456, for
which the test-case gcc.dg/tree-ssa/pr111456-1.c started
failing as described in PR117954.
* gcc.dg/tree-s
Regtested native x86_64-linux. Also tested mmix-knuth-mmixware,
where it fixes ONE testcase, but one which is a regression on
master. The PR component is currently ipa, changed from the
original middle-end. IIUC this bug-fix doesn't fit the ipa
category IMHO, but rather more general tree-opt
All this started with belated MMIX regression patrol in observance of
the holidays, looking at gcc.dg/Wstringop-overflow-27.c as a
regression for target mmix. That's because of a single message not
matched, where there is "note: destination object 'vla::22'" instead
of the expected "note: destinat
Also tested that the pattern also matches a TARGET_CALLEE_COPIES-false target.
-- >8 --
With the dump now emitting "privatized symbols" in the default
"%s.%lu" format also for MMIX, there's still a difference for MMIX.
This time it's because numbers have changed (copies introduced before
this poin
v2: With Jonathan Wakely's feedback, centering the simulator range on
days(0). Different changes than v1, but supposedly minimally intrusive.
Committed after testing native x86_64-linux and cross to mmix.
-- >8 --
These two long-running tests happened to fail for me when
run in parallel (nprocs
This commit fixes a MMIX C23 (...)-handling bug; failing
gcc.dg/c23-stdarg-[46789].c execution tests. But, this
isn't about a missing "|| arg.type != NULL_TREE" in the
PORT_setup_incoming_varargs function like most other
PR114175 port bugs exposed by the gcc.dg/c23-stdarg-6.c
.. -9.c tests; the M
I can't think of a straightforward way to prune these two
similar tests to a more meaningful subset: there's no easy
pruning to each Nth iteration instead of every iteration.
Hopefully exiting the loop after a million runs at the
beginning of the tested range of dates, will catch the gist
of the te
On Sat, 28 Dec 2024, Hans-Peter Nilsson wrote:
> Hopefully exiting the loop after a million runs ...
Correction, FAOD: that'd be "a hundred thousand" for the value
in the patch.
brgds, H-P
Committed.
An alternative would have been to restrict the
scan-tree-dump-times lines in the tests to a list of known
targets, but that's more of a testsuite maintainer-level
change (not actually a valid excuse).
CC to m68k maintainers, who might want to check that 300
fits and add m68k to the lis
I could do it just for target mmix, but that wouldn't help other
simulator targets. Using different primes is deliberate.
Ok to commit?
-- >8 --
Running tests in parallel on my 4.5y+ old laptop made this
test time out: the test itself runs in 9m20s, the timeout
being 10 minutes with the 2x facto
Not many newlib targets (IIRC the only targets where
int32_t is a typedef of long int) build libgfortran.
Building and testing fortran testsuite is usually a cheap
way to get additional coverage for a port, except that a
couple of times a year, there are these silly type-related
breakages.
Maybe
On Thu, 19 Dec 2024, Georg-Johann Lay wrote:
> This patch adds a new target hook that allows the backend to asm output
> a variable definition in its own way. This hook is needed because
> varasm.cc imposes a very restrictive layout for all variable definitions
> which will be basically ELF style
Not many newlib targets (AFAIK the only targets where
GFC_INTEGER_4 alias int32_t is a typedef of long int)
build libgfortran.
These breaks happen from time to time. I wish there was a
method to stop int32_t (and its typedef-alias GFC_INTEGER_4)
being type-compatible with int. The commit message
On Thu, 13 Mar 2025, Konstantinos Eleftheriou wrote:
> Testcases for match.pd patterns
> `((a ^ b) & c) cmp d | a != b -> (0 cmp d | a != b)` and
> `(a ^ b) cmp c | a != b -> (0 cmp c | a != b)` were failing on some targets,
> like PowerPC.
>
> This patch adds an implemenetation for the optimizati
On Wed, 12 Mar 2025, Jakub Jelinek wrote:
> On Tue, Mar 11, 2025 at 10:06:27PM -0500, Robert Dubner wrote:
> On Linux at least when not cross-compiling, exit(1) (or this
> STOP RUN ERROR 1) will work as well, I believe the reason is for some
> bare metal targets which just don't propagate return
> From: Christophe Lyon
> Date: Thu, 10 Apr 2025 15:21:23 +0200
Not sure why I'm CC:ed on this one, not being a maintainer
of the testsuite or targets where gcov tests are exercised,
but FWIW: LGTM except for the two nits:
> ping?
>
> On Tue, 1 Apr 2025 at 22:37, Christophe Lyon
> wrote:
> >
> From: Christophe Lyon
> Date: Thu, 10 Apr 2025 15:38:48 +0200
> On Thu, 10 Apr 2025 at 15:29, Hans-Peter Nilsson wrote:
> >
> > > From: Christophe Lyon
> > > Date: Thu, 10 Apr 2025 15:21:23 +0200
> >
> > Not sure why I'm CC:ed on this o
> From: Alexandre Oliva
> Date: Mon, 31 Mar 2025 20:59:23 -0300
> On Mar 31, 2025, Jeff Law wrote:
>
> >> PR tree-optimization/110628
> >> * gcc.dg/tree-ssa/update-threading.c: XFAIL on riscv.
> > ?!? This is passing on my tester:
>
> Indeed, despite the lack of any activity in the PR that cou
> From: Christophe Lyon
> Date: Wed, 16 Apr 2025 14:41:17 +0200
> ping?
Since you directed it at me and CC:ed the list; in case that
was deliberate: I can only repeat "still ok", but I don't
have approval rights to the testsuite parts.
>
> On Thu, 10 Apr 202
> From: Richard Sandiford
> Date: Tue, 15 Apr 2025 09:23:21 +0100
> > Ok to commit?
>
> OK, thanks.
Thanks!
Though, I noticed another "cheaper" in the function header.
Fixing that one was a more obvious correction (thus
committed as such), as per the commit message: what the
function determine
On Tue, 8 Apr 2025, Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14?
It's not mentioned very often, but is a general rule:
Pretty please, add new files for new tests, don't just edit
existing files. (For one: if they start failing, they look like
regressio
Noticed while investigating a regression for cris-elf with
r15-9239-g4d7a634f6d4102 "combine: Allow 2->2 combinations,
but with a tweak [PR116398]" (to-be-reported).
The comment was introduced when breaking out the
combine_validate_cost function, in r0-59417-g64b8935d4809f3.
I thought about words
he built-in machinery, mapping them to either the int * built-in or
the long long * built-in depending on -m32 or -m64. Again, this limitation
is no limited to __builtin_altivec_tr_stx* built-ins, but others as well,
so I was kind of hoping for a general solution that would fix them all.
I'm not sure of that's possible though.
Peter
x27;t forget to add "PR tree-optimization/81953" to both sections
of the ChangeLog entries.
Peter
geLog
entry needs to be updated slightly since we're no longer testing for
inequality.
Peter
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
I'd like to ping the following patch. Segher has approved the
test case change, so I just need a review for the expr.cc change.
Peter
Message-ID: <009c391d-3994-8755-0d22-9e80faf91...@linux.ibm.com>
Date: Fri, 17 Jun 2022 23:50:35 -0500
To: GCC Patches
Subject: [PATCH
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
above.
I cannot approve it, but it looks good to me with the above bits fixed.
Peter
and:SI 3 "immediate_operand" "i")]
> + UNSPEC_DQUAN))]
> + "TARGET_DFP"
> + "dquai %1,%0,%2,%3"
> + [(set_attr "type" "dfp")
> + (set_attr "size" "")])
operand 1 refers to the TE operand field and that is a 5-bit signed operand.
For that, I think we should be using the s5bit_cint_operand predicate,
rather than const_int_operand.
Peter
d_hard_reg_p."
>
> Please, fix it before committing the patch.
Is this a fix we want backported?
Peter
c [TARGET_AIX]: Rename and update usage to
>> TARGET_AIX_OS.
>> * go-lang.cc: Likewise.
>
> This is OK.
>
> Thanks.
>
> Ian
I pushed this to trunk for Paul.
Peter
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
hich is where this GCC/Rust code has been copied from, so I suggest
>> you push both patches at once.
>>
>>
>> Grüße
>> Thomas
>
> Hi Thomas,
>
> Thank you for reviewing. I do not have commit access, so I cannot push this
> myself. If this is OK, could one of the rust maintainers push this patch?
>
> Thanks,
> Paul
I pushed this to trunk for Paul.
Peter
_p (gsi_start_phis (new_best_bb))
&& gimple_bb (use) != early_bb
&& !is_gimple_call (use)
&& dominated_by_p (CDI_POST_DOMINATORS, new_best_bb, gimple_bb (use))
&& dominated_by_p (CDI_DOMINATORS, new_best_bb, early_bb)
&& !def_use_same_block (use))
return new_best_bb;
return best_bb;
Either works.
Peter
d via the same conditions that the built-in itself
is enabled. Look at my addition of the __TM_FENCE__ macro that let the
user know our HTM insn patterns were fixed to now act as memory barriers.
Peter
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-
other tests and it has to be as small as possible and compiled with
a fair amount of optimization. Even then you may get some copies.
So I'd recommend just removing the xxlor counts altogether.
Peter
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 cou
crel } */
>
> Do we have some environment combination which supports powerpc_pcrel but not
> power10_ok? I'd expect that only powerpc_pcrel is enough.
I think I agree testing for powerpc_pcrel should be enough.
Peter
diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/
bler as well! If you *really* want this you
> use "dg-do assemble", but you shouldn't.
For test cases checking for ICEs, we don't need to assemble, so I agree,
we just need to remove the -S option, which is implied by this being a
dg-do compile test case (the default for this test directory).
Peter
eplacement
> + for the original version. This test is for the original version of the
> + builtin and should work exactly as before. */
Ditto.
> +++ 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 you can drop that,
but you need to disable this test for soft-float systems, so you probably want:
/* { dg-do run { target powerpc_fprs } } */
I know you didn't write it, but test_fpscr_rn_builtin_1.c should be changed to
use the same dg-do run test above as well.
Peter
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
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
>>>&
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
>&
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
e register allocator's freedom.
I know the old code did it, but since you're changing the line, you
might as well use a new temp.
I cannot approve it, but it LGTM with those fixed.
Peter
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
>
question is that this PR106907 seemed not to report this issue,
> is there another PR reporting this? Or do I miss something?
I think Jeevitha just ran cppcheck by hand and noticed the "new" warnings
and added them to the list of things to fixup. Yeah, it would be nice to
add the new warnings to the PR for historical reasons.
Peter
-linux and
showed no regressions. Ok for backports?
Peter
gcc/
PR target/109073
* config/rs6000/rs6000-call.c (mma_init_builtins): Accept const pointer
operands for lxvp, stxvp and disassemble builtins.
gcc/testsuite/
PR target/109073
* gcc.target/powerpc
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/109
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
p64 && be }
> } } } */
Can you please check whether the big-endian count needs updating too?
Thanks.
Peter
g * versions where they could/should accept
them. Can you double-check whether there are other built-ins that
need similar changes and if so, please post a separate patch to fix
those as well? Thanks.
Peter
he built-in machinery can see that the usage is expecting a return value
or not and for the pre-P9 code, can skip generating the ending mffs if
we don't want the return value.
Peter
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
it does seem to
be against current code and he did say he tested it and there is some
explanation given, just not in a commit message form. Is it just a nice
commit message you're looking for now?
Peter
et to think
hard about what their CONST0_RTX values should be for each mode.
This passed bootstrap and regtesting on x86_64-linux and powerpc64le-linux
with no regressions. Ok for mainline?
Peter
gcc/
PR target/98872
* config/rs6000/mma.md (*movoo): Accept zero const
trunk for a little while?
Peter
gcc/
* gcc/config/rs6000/rs6000-builtin.def (BU_COMPAT): Add support macro
for defining compatibility built-ins.
(vsx_assemble_pair): Add compatibility built-in.
* gcc/config/rs6000/rs6000-call.c (struct builtin_compatibi
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_
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
. Committed and pushed.
Peter
gcc/
PR target/99041
* config/rs6000/predicates.md (mma_assemble_input_operand): Restrict
memory addresses that are legal for quad word accesses.
gcc/testsuite/
PR target/99041
* g++.target/powerpc/pr99041.C: New test.
diff --git a/gcc
regtests there are clean?
Peter
2021-02-12 Peter Bergner
gcc/
PR target/98959
* config/rs6000/rs6000.c (rs6000_emit_le_vsx_permute): Add an assert
to ensure we do not have an Altivec style address.
* config/rs6000/vsx.md (*vsx_le_perm_load_): Disable if passed
g the initialization
if there is no CONST0_RTX defined for the mode.
This following patch fixes the ICE and is currently regtesting.
Ok for trunk if the bootstrap and regtesting come back clean?
Peter
2021-02-12 Peter Bergner
gcc/
PR rtl-optimization/98872
* init-regs.c (initi
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)
>
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 NU
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
>>>> av
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_asse
0, so we'll
need this fix to go along with it.
Peter
2021-02-25 Peter Bergner
gcc/
PR target/99279
* config/rs6000/rs6000-call.c (rs6000_init_builtins): Replace assert
with an "if" test.
diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000
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
>> val
, so
ok there too after it has baked on trunk for a few days?
Peter
gcc/
PR target/101849
* config/rs6000/rs6000-call.c (rs6000_gimple_fold_mma_builtin): Cast
pointer to __vector_pair *.
gcc/testsuite/
PR target/101849
* gcc.target/powerpc/pr101849.c: New
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 *.
>>
>&
gt; of course).
Ok, I ended up pushing the original patch then with the expanded test case.
I'll let this bake on trunk for a bit before back porting. Thanks everyone.
Peter
too after
some trunk burn in time?
GCC10 suffers from the same issue, but since the code is different, I'll
have to determine a different solution which I'll post as a separate
patch.
Peter
gcc/
* config/rs6000/mma.md (unspec): Delete UNSPEC_MMA_XXSETACCZ.
(unspecv):
when using {}?
\d is any digit? Yeah, that would be better. Gotta find a manpage or ???
that describes what regex patterns are allowed.
This all said, Alan's rtx_costs patch touches this same area and he talked
about removing a similar splitter, so I think I will wait for his code to
be committed and then rework this on top of his changes.
Peter
>
> I'm testing this patch. I'll check it in when I'm done.
>
>
> use E_*mode instead of just *mode
Bill's nightly testing on one of our old systems just hit this too.
Thanks for fixing and testing the fix!
Peter
nder legibility), fwiw.
+1 for using hex constants when using them with logical ops like '&'.
Peter
. Thanks.
> Btw. A good cleanup would be to have mma_assemble_input_operand written
> like this, too?
Ok, I'll have a look at doing that as part of a separate change.
Peter
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_
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 confirm
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 bran
regression testing with no regressions on powerpc64le-linux.
Ok for trunk?
Peter
gcc/testsuite/
* g++.dg/pr65240-1.C: Use -mdejagnu-cpu=. Remove dg-skip-if.
* g++.dg/pr65240-2.C: Likewise.
* g++.dg/pr65240-3.C: Likewise.
* g++.dg/pr65240-4.C: Likewise.
* g
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
>> obvi
the -mcpu=power10 that the test case uses.
That said, I agree, pr101849.c should probably be copied into another test case
file (pr103353.c) that uses options that trigger the issue so we can be sure the
fix won't regress.
Peter
1801 - 1900 of 2382 matches
Mail list logo
