Thanks for the review, much appreciated. Agreed on all those points,
I'll remove it from -Wextra and just leave it as a standalone warning,
and I'll add those tests you suggested.
On 02/06/2025 19:08, Joseph Myers wrote:
On Sun, 1 Jun 2025, Peter Frost wrote:
Ping https://g
Ping https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672568.html
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
The 6.7 version is what's in Debian 11. I'll commit this as
obvious in a few hours.
-- >8 --
Commit r16-833-gfbb7f1cb5d3c8b appears to have broken builds with
makeinfo from texinfo 6.7 (Debian: 6.7.0.dfsg.2-6) - but not 6.8
(6.8-6+b1). With 6.7, I see (linebreaks manually added):
if [ xinfo = x
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
Random-typo-spotting-mode activated:
On Sat, 19 Apr 2025, Andrew Pinski wrote:
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/calloc-10.c
> +/* zeroing out via a CONSTRUCTOR should be treated similarly as a msmet and
"memset"
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/calloc-11.c
> b/gcc/testsuite/gc
Ping https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672568.html
Missed the version 15 freeze with the last ping, I believe the project
is open for general development again now?
attribute function
Add test checking parameter is placed in correct register
Co-Authored-By: NightStrike
Signed-off-by: Peter Damianov
---
v2: Remove superflous \[ in regex
gcc/testsuite/gcc.target/i386/amd64-abi-9.c | 38 ++---
1 file changed, 33 insertions(+), 5 deletions
> 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
rly didn't hit this ourselves. I know we have other
test cases that use target_clones that should probably get this update
too. Not for you to worry about, I'll add that to my teams TODO once
stage1 reopens.
Peter
st case
and the "has_arch_ppc64" test we're using is clearly a compile time only test
and the "powerpc64" is the correct hw test to check for 64-bit instruction
support on the test system.
If it were me, I'd give Segher and the others a couple of days to disagree
and not hearing any objections, I'd push it under the "obvious" rule.
Peter
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,
> 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
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
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
ewhat involved change, since the string powerpc64 appears
> all over gcc/testsuite/, with various meanings other than a dejagnu
> effective target.
Sorry. I meant to say I'll have someone from my team do this follow-on patch.
Yes, it will probably hit quite a few test cases. No need for you to worry
about that.
Peter
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
rep
ARCH_PPC64
bergner@perch:~/$
...but here we can see that is does, when the -mcpu=CPU has
OPTION_MASK_POWERPC64
as one of its masks. That looks like a bug to me. I'm not sure why atm we
don't
see that happening on Linux when compiling with -m32.
I think if we fix this bug, then we won't need to modify the test cases
as you're doing here.
Peter
hate the name "powerpc64" and it should probably be
renamed to "powerpc64_hw" to be more clear about what it's testing.
That said, that should be done in a separate patch.
Peter
__powerpc__ or
__POWERPC__ like we do for other powerpc* targets?
That said, I think this probably falls under the "obvious" rule too.
Peter
inux-x-powerpc-elf. Ok to install?
>
>
> for gcc/testsuite/ChangeLog
>
> * gcc.dg/ipa/ipa-sra-19.c: Add -Wno-psabi on ppc-elf too.
If you really see a warning with powerpc-*-elf, then I'd consider this
falls under the obvious rule.
Peter
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. I'd think the following fix should help them too.
Peter
diff --git a/gcc/testsuite/g++.dg/pr112822.C b/gcc/testsui
This test was failing because it was checking that eax was being cleared. For
sysv abi, eax contains the number of XMM registers used in the call, but msabi
just passes the float arguments twice, both in xmm and general purpose
registers.
This patch adds tests for both sysv and msabi functions be
> 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: 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:
> >
-in time?
Peter
gcc/
PR target/119629
* config/rs6000/rs6000-logue.cc (__builtin_scalar_byte_in_set): Use
the no32bit attribute.
gcc/testsuite/
PR target/119629
* gcc.target/powerpc/byte-in-set-2.c (dg-error): Update acceptable
error messages
> 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
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
ill push it
tomorrow unless someone has an objection.
Peter
gcc/
PR target/119308
* config/rs6000/rs6000-logue.cc (rs6000_output_function_epilogue):
Handle GCC COBOL for the tbtab lang field.
diff --git a/gcc/config/rs6000/rs6000-logue.cc
b/gcc/config/rs6000/rs6000-logu
dg-do compile */
> +/* { dg-do compile } */
> /* { dg-options "-mdejagnu-cpu=power8 -mvsx" } */
> /* { dg-require-effective-target powerpc_vsx } */
>
I consider these obvious, so you should just push them.
Peter
ignore OPTION_MASK_P{8,10}_FUSION which are also more
> like tuning flags.
I agree this is more a tuning decision and not an ISA requirement,
so we should treat -m{no-,}save-toc-indirect similarly to the
fusion options.
LGTM, but I cannot approve it.
Peter
here, they're pretty fragile to changes in
the compiler.
That said, I'm not sure it's really worth splitting this older Power7
test case up, so I guess adding -fno-ipa-icf is probably the best/easiest
of all of the bad options.
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?
Peter
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
estion of reworking this to just default
to i = 0 for C and all unknown languages is probably the best solution.
Segher, do you agree?
Peter
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
No problem, created PR119054 with a reproducer and some details.
Cheers,
Peter
On Thu, 27 Feb 2025 at 20:45, Jerry D wrote:
>
> On 2/27/25 12:33 PM, Peter Hill wrote:
> > On Thu, 27 Feb 2025 at 18:09, Jerry D wrote:
> >>
> >> On 2/27/25 7:38 AM, Pe
On Thu, 27 Feb 2025 at 18:09, Jerry D wrote:
>
> On 2/27/25 7:38 AM, Peter Hill wrote:
> > Dear all,
> >
> > The attached patch fixes an ICE in gfc_resolve_code when passing an
> > optional array to an elemental procedure with `-pedantic` enabled.
> > PR95446
). The ICE is present since 11.1, so this could be
backported?
Cheers,
Peter
gcc/fortran/Changelog
* resolve.cc (resolve_elemental_actual): When checking other
actual arguments to elemental procedures, don't check
attributes of literals and function calls
gcc/test
new functions." line, rather than
8 consecutive spaces.
> * gcc.target/powerpc/amo6.c: Likewise.
> * gcc.target/powerpc/amo7.c: Likewise.
Both of these test cases have multiple 8 consecutive spaces that should
be converted to tabs too.
Otherwise, LGTM. We just need Segher's approval now.
Peter
POSIX says that sin and cos should set errno to EDOM when infinity is passed to
them. Make sure this is accounted for in builtins.def, and add tests.
gcc/
PR middle-end/80042
* builtins.def: (sin|cos)(f|l) can set errno.
gcc/testsuite/
* gcc.dg/pr80042.c: New testcase.
---
POSIX says that sin and cos should set errno to EDOM when infinity is passed to
them. Make sure this is accounted for in builtins.def, and add tests.
gcc/
PR middle-end/80042
* builtins.def: (sin|cos)(f|l) can set errno.
gcc/testsuite/
* gcc.dg/pr80042.c: New testcase.
---
ix the failures.
Note that H.J. pushed the other target hook, so we'll need to revert
that before pushing this change.
Peter
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"))
udp\M|\mfcmpu\M} 1 } } */
I think this would be safer if we split this into two test cases, one with
each of the functions. I'm worried that if we were to somehow accidentally
swap the results of your new code, we'd still produce one each of the
instructions above and we wouldn't notice. I think it's safer to have one
test case for each function here (ordered and normal) and explicitly look
for the insns you want, while at the same time using scan-assembler-not for
the insns you don't want to see.
Peter
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
Ping https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672568.html
a strong explanation of why it was
> wrong.
In my opinion, the patch is not wrong, but rather has exposed latent issues
that need to be worked on and fixed. Ive asked Surya to continue working on
the fallout (see her other patches), but help from others is always appreciated.
Peter
; address any of the fallout. Maybe he's gone? Peter?
Surya (she) is working on the fallout. In fact, one patch earlier this year
was committed and reverted due to some aarch64 fallout. That said, Andrew
mentioned on IRC that he was interested in getting that patch back in for
aarch6
; * gfortran.dg/large_real_kind_form_io_2.f90: Likewise.
LGTM, although I cannot approve it.
Peter
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
t_ieee or some such.
Maybe the following would work???
#if defined(__LONG_DOUBLE_IEEE128__)
#error "__LONG_DOUBLE_IEEE128__ is defined"
#endif
If not that, then we could test for either __LONG_DOUBLE_IBM128__ or
__SIZEOF_LONG_DOUBLE__ == 8.
Peter
s would also return true for a long double == double build
(ie, -mlong-double-64). Maybe we should instead have a positive test
ppc_default_long_double_ieee and xfail using ! ppc_default_long_double_ieee?
If we go the ppc_default_long_double_ieee route, you can check for the
existence of __LONG_DOUBLE_IEEE128__.
Peter
he countdown loop. How about the following instead?
for (int j = 0; j < hard_regno_nregs (hard_regno, mode); j++)
Peter
raries team has confirmed that performance
of their tests improved when using this patch.
This passed bootstrap and regtesting with no regressions on powerpc64le-linux
and powerpc64-linux. Ok for trunk?
Peter
gcc/
PR target/109116
* config/rs6000/mma.md (unspec): Delete UNS
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
gnify an error occurred during expansion.
Bootstrapped and retested on powerlc64le-linux with no regressions.
Ok for trunk and backports after some trunk burn-in time?
Peter
gcc/
* config/rs6000/rs6000-builtin.cc (rs6000_expand_builtin): Return
const0_rtx when there is an error.
ition
where we had made the PMASK field too small.
Bootstrapped and retested on powerpc64le-linux with no regressions.
Ok for trunk and backports after some trunk burn-in time?
Peter
gcc/
* config/rs6000/rs6000-builtin.cc (rs6000_expand_builtin): Use correct
array size for the
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
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
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
v3 Patch:
* adds documentation
* fixes formatting
* minor code cleanup
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 doe
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
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
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
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
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
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
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
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 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
> 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
> 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
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
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
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
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
ption is implied by -mcpu=power8, so it not needed.
Please remove it.
> +++ b/gcc/testsuite/gcc.target/powerpc/pr107757-2.c
> @@ -0,0 +1,13 @@
> +/* { dg-do compile } */
> +/* { dg-options "-mdejagnu-cpu=power8 -mvsx -O2" } */
Likewise.
The rest LGTM.
Peter
patch.
I'll refrain from reviewing the rest of the patch, as it will obviously
change by moving it to a preparatory patch.
Peter
ding a useless isa flag which would require a user
visible -m, correct? I'd prefer this go in before the arch flags
patch too, but I also don't want to add another -m patch to
do it, so I'm undecided on this. Segher, do you have a preference on
before or after?
Peter
e to power10 and power11.
Obviously, this patch will just follow whatever we decide to do for the
other -mcpu=future patch.
Peter
c.target/powerpc/pr115688.c
> b/gcc/testsuite/gcc.target/powerpc/pr115688.c
> index 5222e66ef17..00c7c301436 100644
> --- a/gcc/testsuite/gcc.target/powerpc/pr115688.c
> +++ b/gcc/testsuite/gcc.target/powerpc/pr115688.c
> @@ -7,7 +7,8 @@
>
> /* Verify there is no ICE under 32 bit env. */
>
> -__attribute__((target("vsx")))
> +/* cpu=power7 must be used to enable VSX. */
> +__attribute__((target("cpu=power7,vsx")))
> int test (void)
> {
>return 0;
Same question as above. Why the need for adding -mvsx here?
Peter
x27;m speaking of patches 4/11, 5/11. 7/11 and 8/11. I don't see a
6/11. Did you forget to email that? Was that for changing TARGET_FOO
to TARGET_POWER6? If so, then that should be handled like patches
4 thru 8.
Peter
Hi all,
Pinginghttps://gcc.gnu.org/pipermail/gcc-patches/2024-September/662590.html for
a review if anyone has a moment.
Many thanks,
Peter
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
y the Contributed by
Richard Kenner line? Cut/paste error?
Peter
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 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 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
and failed the asm scan. It worked
with -O1, but that just points to the test case being a little fragile
wrt optimization, so I deemed it safer to go with the -fjump-tables option,
which mimics the old behavior exactly.
Peter
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
Ping https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662590.html
Please use {} quoting, and no backslashes. Also use \m and \M.
>
> Or something like
> scan-assembler { \mstq .*[02468], }
> (you do not have to match the things you don't care about, and you only
> need to look at the last digit to see if a number is even).
I think a better idea is to change this to a { dg-do assemble } test case,
since the assembler will verify that the register number is even and will
also verify the offset is valid too. Then the dg-final can be just:
/* { dg-final { scan-assembler {\mstq\M} } } */
Peter
FWIW, I see "typedef char mask;" also for bionic and
openbsd. Tested for cris-elf.
Ok to commit?
-- >8 --
There are 100+ regressions when running the g++ testsuite for newlib
targets (probably excepting ARM-based ones) e.g cris-elf after commit
r15-3859-g63a598deb0c9fc "libstdc++: #ifdef out #pr
Only because I wrote earlier that I'd do this patch.
Committed as obvious. Sanity-checked by running the test in
a native tree as "make check-gcc-fortran
RUNTESTFLAGS=dg.exp=open_errors_2.f90"
-- >8 --
Now that fort.N files are removed by the testsuite
framework, remove this single "manual" file
1 - 100 of 1108 matches
Mail list logo
