On Tue, 2011-03-29 at 13:20 -0700, Mike Stump wrote:
> On Mar 29, 2011, at 5:14 AM, Peter Bergner wrote:
> > Mike and David, I assume the updated patch below is ok for mainline?
>
> Ok. I applied it for you... I'm assuming you don't have write after yet...
> Th
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
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
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
y the Contributed by
Richard Kenner line? Cut/paste error?
Peter
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
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
patch.
I'll refrain from reviewing the rest of the patch, as it will obviously
change by moving it to a preparatory patch.
Peter
e to power10 and power11.
Obviously, this patch will just follow whatever we decide to do for the
other -mcpu=future 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
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
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
Hi all,
Pinginghttps://gcc.gnu.org/pipermail/gcc-patches/2024-September/662590.html for
a review if anyone has a moment.
Many thanks,
Peter
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
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
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
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
Ping https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672568.html
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"))
; * gfortran.dg/large_real_kind_form_io_2.f90: Likewise.
LGTM, although I cannot approve it.
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
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
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
he countdown loop. How about the following instead?
for (int j = 0; j < hard_regno_nregs (hard_regno, mode); j++)
Peter
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.
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
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
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
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
ix the failures.
Note that H.J. pushed the other target hook, so we'll need to revert
that before pushing this change.
Peter
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.
---
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
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
). 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
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
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
-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
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
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
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
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
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
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,
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
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/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.
>
&
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
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
__powerpc__ or
__POWERPC__ like we do for other powerpc* targets?
That said, I think this probably falls under the "obvious" rule too.
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
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
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
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
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?
> From: Christophe Lyon
> Date: Tue, 3 Oct 2023 15:20:39 +0200
> The patch passed almost all our CI configurations, except arm-eabi when
> testing with
> -mthumb/-march=armv6s-m/-mtune=cortex-m0/-mfloat-abi=soft/-mfpu=auto
> where is causes these failures:
> FAIL: 29_atomics/atomic_flag/clear/1.
> From: Christophe Lyon
> Date: Tue, 3 Oct 2023 15:20:39 +0200
> Maybe we need a new variant of dg-require-thread-fence ?
Yes: many of the dg-require-thread-fence users need
something stronger. Tested arm-eabi together with the next
patch (2/2) with
RUNTESTFLAGS=--target_board=arm-sim/-mthumb/-
> From: Christophe Lyon
> Date: Tue, 3 Oct 2023 15:20:39 +0200
> The patch passed almost all our CI configurations, except arm-eabi when
> testing with
> -mthumb/-march=armv6s-m/-mtune=cortex-m0/-mfloat-abi=soft/-mfpu=auto
> where is causes these failures:
> FAIL: 29_atomics/atomic_flag/clear/1.
> From: Jonathan Wakely
> Date: Wed, 4 Oct 2023 09:29:43 +0100
> The new dg-require proc checks for __atomic_exchange, which is not the
> same as compare-exchange, and not the same as test-and-set on
> atomic_flag. Does it just happen to be true for arm that the presence
> of __atomic_exchange al
> From: Hans-Peter Nilsson
> Date: Wed, 4 Oct 2023 17:15:28 +0200
> New version coming up.
Using pointer-sized int instead of int,
__atomic_compare_exchange instead of __atomic_exchange,
renamed to atomic-cmpxchg-word from atomic-exchange, and
updating a comment that already seemed r
s/atomic-exchange/atomic-cmpxchg-word/g.
Tested as v1.
Ok to commit?
-- >8 --
These tests actually use a form of atomic compare and exchange
operation, not just atomic loading and storing. Some targets (not
supported by e.g. libatomic) have atomic loading and storing, but not
compare and exchange
Ping.
> From: Hans-Peter Nilsson
> Date: Wed, 4 Oct 2023 19:04:55 +0200
>
> > From: Hans-Peter Nilsson
> > Date: Wed, 4 Oct 2023 17:15:28 +0200
>
> > New version coming up.
>
> Using pointer-sized int instead of int,
> __atomic_compare_exchange ins
Ping.
> From: Hans-Peter Nilsson
> Date: Wed, 4 Oct 2023 19:08:16 +0200
>
> s/atomic-exchange/atomic-cmpxchg-word/g.
> Tested as v1.
>
> Ok to commit?
> -- >8 --
> These tests actually use a form of atomic compare and exchange
> operation, not just atomic l
> From: Vineet Gupta
> Date: Thu, 28 Sep 2023 14:43:41 -0700
Please forgive my daftness, but...
> ```
> foo2:
> sext.w a6,a1 <-- this goes away
> beq a1,zero,.L4
> li a5,0
> li a0,0
> .L3:
> addwa4,a2,a5
> addwa5,a3,a5
>
> Date: Fri, 29 Sep 2023 16:37:21 -0600
> From: Jeff Law
> So this ends up looking a lot like the bits that I had to revert several
> weeks ago :-)
>
> The core issue we have is given an INSN the generic code will cost the
> SET_SRC and SET_DEST and sum them. But that's far from ideal on a RI
On Thu, 23 Jun 2022, Alexandre Oliva via Gcc-patches wrote:
> +proc check_effective_target_two_plus_gigs { } {
> +return [check_no_compiler_messages two_plus_gigs executable {
> + int dummy[0x8000];
Don't you mean "char" as in "char dummy[0x8000]"?
Or else the effective predicate
On Mon, 27 Jun 2022, Xi Ruoyao via Gcc-patches wrote:
> egrep has been deprecated in favor of grep -E for a long time, and the
> next GNU grep release (3.8 or 4.0) will print a warning if egrep is used.
> Unfortunately, old hosts with non-GNU grep may lack the support for -E
> option. Use AC_PROG_
On Fri, 1 Jul 2022, Dimitrije Milosevic wrote:
> Fix kernel_stat structure size for non-Android 32-bit Mips.
> LLVM currently has this value for the kernel_stat structure size,
> as per compiler-rt/lib/sanitizer-common/sanitizer_platform_limits_posix.h.
> This also resolves one of the build issues
On Sat, 9 Jul 2022, Xi Ruoyao wrote:
> On Fri, 2022-07-08 at 21:42 -0400, Hans-Peter Nilsson wrote:
> > On Fri, 1 Jul 2022, Dimitrije Milosevic wrote:
> >
> > > Fix kernel_stat structure size for non-Android 32-bit Mips.
> > > LLVM currently has this value f
On Tue, 12 Jul 2022, Dimitrije Milosevic wrote:
> Hi Hans-Peter,
> You're right, this is not ok for the O32 ABI. Your change however, broke the
> functionality
> for the N32 ABI.
That's just not true. There was no mips support for ASAN in
gcc, hence nothing to br
On Mon, 1 May 2023, Jeff Law wrote:
>
> Spurred by Segher's RFC, I went ahead and tested several ports with LRA
> enabled. Not surprisingly, many failed, but a few built their full set of
> libraries successful and of those a few even ran their testsuites with no
> regressions. In fact, enablin
Since the change r14-383-gfaf8bea79b6256 "Enable LRA on
several ports", mmix has been broken building libstdc++-v3:
libtool: compile: /obj/./gcc/xgcc -shared-libgcc -B/obj/./gcc
-nostdinc++ -L/obj/mmix/libstdc++-v3/src
-L/obj/mmix/libstdc++-v3/src/.libs
-L/obj/mmix/libstdc++-v3/libsupc++/.libs -no
When LRA is in progress, it can try and validate insns
half-way through frame-pointer (FP) to stack-pointer (SP)
elimination. Operands have then been substituted where the
offset is from the SP elimination but the register is the
(hard) frame-pointer:
lra-eliminations.cc:lra_eliminate_regs_1:370:
After fixing the one problem for MMIX, there's just one
test-case regressing between reload and LRA.
-- 8< --
* config/mmix/mmix.cc: Re-enable LRA.
---
gcc/config/mmix/mmix.cc | 3 ---
1 file changed, 3 deletions(-)
diff --git a/gcc/config/mmix/mmix.cc b/gcc/config/mmix/mmix.cc
index 51
This is just a mechanical update.
It fixes no observed problems for LRA.
* config/mmix/predicates.md (mmix_address_operand): Use
lra_in_progress, not reload_in_progress.
---
gcc/config/mmix/predicates.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/confi
On Tue, 30 May 2023, HAO CHEN GUI via Gcc-patches wrote:
> +++ b/gcc/config/rs6000/rs6000.md
> @@ -7891,6 +7891,36 @@ (define_insn "*mov_internal2"
> (set_attr "dot" "yes")
> (set_attr "length" "4,4,8")])
>
> +(define_peephole2
> + [(set (match_operand:CC 2 "cc_reg_operand" "")
> + (
On Thu, 15 Jun 2023, Manolis Tsamis wrote:
> This is a new RTL pass that tries to optimize memory offset calculations
> by moving them from add immediate instructions to the memory loads/stores.
> For example it can transform this:
>
> addi t4,sp,16
> add t2,a6,t4
> shl t3,t2,1
> ld a
On Sun, 9 Jul 2023, Hans-Peter Nilsson wrote:
> On Thu, 15 Jun 2023, Manolis Tsamis wrote:
>
> > This is a new RTL pass that tries to optimize memory offset calculations
> > by moving them from add immediate instructions to the memory loads/stores.
> It punts on all "u
> From: Thomas Schwinge
> Date: Thu, 19 Oct 2023 12:42:26 +0200
> It's just GCC and Binutils/GDB, or are the top-level files also shared
> with additional projects?
Not sure if that counts as "shared", but I regularly drop
in* newlib to build simulator targets (*-elf, *-newabi).
That's git://sou
> From: Richard Sandiford
> Date: Tue, 24 Oct 2023 11:14:20 +0100
> reload and constrain_operands had some old code to look through unary
> operators. E.g. an operand could be (sign_extend (reg X)), and the
> constraints would match the reg rather than the sign_extend.
>
> This was previously u
On Fri, 24 Feb 2023, Christoph Muellner wrote:
> diff --git a/gcc/config/riscv/thead.md b/gcc/config/riscv/thead.md
> index 158e9124c3a..2c684885850 100644
> --- a/gcc/config/riscv/thead.md
> +++ b/gcc/config/riscv/thead.md
> @@ -29,3 +29,14 @@ (define_insn "*th_addsl"
>"th.addsl\t%0,%3,%1,%2"
On Sun, 26 Feb 2023, Jonathan Yong via Gcc-patches wrote:
> Patch OK for master branch? I did not see any obvious issues to exclude LLP64
> specifically.
I see "lp64 || lp64" in that patch (which should preferably have
been sent inline, as it's harder to quote an attached patch,
QED). Sending
On Mon, 27 Feb 2023, Jonathan Yong via Gcc-patches wrote:
> This test is for LP64 only, exclude LLP64 too.
> Patch OK?
I may be confused, but you're not making use of the "llp64"
effective target, there instead excluding/including lp64 /
ilp32 in sets that not obviously mean "exclude LLP64".
On Tue, 28 Feb 2023, Jonathan Yong wrote:
> On 2/28/23 03:06, Hans-Peter Nilsson wrote:
> >
> > On Mon, 27 Feb 2023, Jonathan Yong via Gcc-patches wrote:
> >
> > > This test is for LP64 only, exclude LLP64 too.
> > > Patch OK?
> >
> > I may b
On Tue, 28 Feb 2023, Christoph Müllner wrote:
> On Sun, Feb 26, 2023 at 12:42 AM Hans-Peter Nilsson wrote:
> >
> > On Fri, 24 Feb 2023, Christoph Muellner wrote:
> > > diff --git a/gcc/config/riscv/thead.md b/gcc/config/riscv/thead.md
> > > index 158e9124c3
On Fri, 26 Feb 2021, Thiago Macieira via Gcc-patches wrote:
> ints can be used in futexes. chars can't.
Shouldn't that be an atomic type instead of a bare int then?
> ---
> libstdc++-v3/include/std/barrier | 21 -
> 1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff --
On Fri, 26 Feb 2021, Thiago Macieira via Gcc-patches wrote:
> On Friday, 26 February 2021 11:31:00 PST Andreas Schwab wrote:
> > On Feb 26 2021, Thiago Macieira wrote:
> > > On Friday, 26 February 2021 10:14:42 PST Andreas Schwab wrote:
> > >> On Feb 26 2021, Thiago Macieira via Gcc-patches wro
On Wed, 3 Mar 2021, Jonathan Wakely wrote:
> For int, there shouldn't be any need to force the alignment. I don't
> think any ABI supported by GCC allows int members to be aligned to
> less than __alignof__(int).
(sizeof(int) last)
The CRIS ABI does as in default packed, and ISTR there was some
o
A simulator can easily spend more than 10 minutes running this
test-case, and the default timeout is at 5 minutes. Better allow
even slower machines; use 4 as the factor.
Regarding relative runtime numbers (very local; mmixware simulator for
mmix-knuth-mmixware): test01 and test05 finish momentari
On Thu, 24 Sep 2020, Tom de Vries wrote:
> Hi,
>
> With the nvptx target, we run into:
> ...
> FAIL: gcc.dg/pr94600-1.c scan-rtl-dump-times final "\\(mem/v" 6
> FAIL: gcc.dg/pr94600-1.c scan-rtl-dump-times final "\\(set \\(mem/v" 6
> FAIL: gcc.dg/pr94600-3.c scan-rtl-dump-times final "\\(mem/v" 1
On Wed, 30 Sep 2020, Tom de Vries wrote:
> [ was: Re: [committed][testsuite] Require non_strict_align in
> pr94600-{1,3}.c ]
>
> On 9/30/20 4:53 AM, Hans-Peter Nilsson wrote:
> > On Thu, 24 Sep 2020, Tom de Vries wrote:
> >
> >> Hi,
> >>
> >> Wit
On Thu, 1 Oct 2020, Tom de Vries wrote:
> [ was: Re: [committed][testsuite] Re-enable pr94600-{1,3}.c tests for arm ]
>
> On 10/1/20 7:38 AM, Hans-Peter Nilsson wrote:
> > On Wed, 30 Sep 2020, Tom de Vries wrote:
> >> I've analyzed the compilation on strict-a
Please excuse a comment from the gallery:
On Mon, 28 Sep 2020, will schmidt via Gcc-patches wrote:
> On Fri, 2020-09-04 at 12:52 -0300, Raoni Fassina Firmino via Gcc-patches
> wrote:
> > 2020-08-13 Raoni Fassina Firmino
> >
> > gcc/ChangeLog:
> > * config/rs6000/rs6000.md (fegetroundsi):
On Thu, 3 Feb 2022, David Seifert via Gcc-patches wrote:
> On Thu, 2022-02-03 at 12:50 +0100, Jakub Jelinek wrote:
> > On Thu, Feb 03, 2022 at 12:30:11PM +0100, David Seifert wrote:
> > > * `-Werror` can cause issues when a more recent version of GCC
> > > compiles
> > > ? an older version:
> > >
801 - 900 of 2382 matches
Mail list logo
