ChangeLog/
* MAINTAINERS: Update my e-mail address.
---
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9d92be1f301..b47e0465852 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -100,7 +100,7 @@ msp430 port Nick
On 2/1/24 18:24, Greg McGary wrote:
On 1/18/24 9:24 AM, Jeff Law wrote:
On 1/17/24 20:53, Greg McGary wrote:
While the code comment is true, perhaps it obscures the primary intent,
which is recognition that the pattern (SIGN_EXTEND (mem ...) ) is
destined
to expand into a single
Hi Edwin,
Just rerun the newlib and there is no ICE but still 160 dump failures as below.
Pan
-Original Message-
From: Li, Pan2
Sent: Friday, February 2, 2024 11:57 AM
To: Edwin Lu ; juzhe.zh...@rivai.ai; gcc-patches
Cc: Robin Dapp ; kito.cheng ;
jeffreyalaw ; palmer ; vineetg
;
gcc/ChangeLog:
* config/riscv/riscv-cores.def: Add sifive-p450, sifive-p670.
* doc/invoke.texi (RISC-V Options): Add sifive-p450,
sifive-p670.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/mcpu-sifive-p450.c: New test.
* gcc.target/riscv/mcpu-sifive-p670.c:
Add sifive p400 series scheduler module. For more information
see https://www.sifive.com/cores/performance-p450-470.
gcc/ChangeLog:
* config/riscv/riscv.md: Include sifive-p400.md.
* config/riscv/sifive-p400.md: New file.
* config/riscv/riscv-cores.def (RISCV_TUNE): Add
Sorry, it seems the log was eliminated by my cleanup script(s). Let me know
rerun one newlib for commit id 23cd2961bd2ff63583f46e3499a07bd54491d45c.
Pan
-Original Message-
From: Edwin Lu
Sent: Friday, February 2, 2024 1:43 AM
To: Li, Pan2 ; juzhe.zh...@rivai.ai; gcc-patches
Cc:
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Here, because we don't build a CONSTRUCTOR for an empty base, we were
wrongly marking the Foo CONSTRUCTOR as complete after initializing the Empty
member. Fixed by checking empty_base here as well.
PR c++/112439
gcc/cp/ChangeLog:
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
When we added variable templates, we didn't extend the VAR_HAD_UNKNOWN_BOUND
handling for class template static data members to handle them as well.
PR c++/113638
gcc/cp/ChangeLog:
* cp-tree.h: Adjust comment.
*
LGTM!
Thanks!
在 2024/2/2 上午5:54, Xi Ruoyao 写道:
When bootstrapping GCC 14 --with-build-config=bootstrap-lto, an ODR
violation is detected:
../../gcc/config/loongarch/loongarch-opts.cc:57: warning:
'abi_minimal_isa' violates the C++ One Definition Rule [-Wodr]
57 |
Committed, thanks Jeff.
Pan
-Original Message-
From: Jeff Law
Sent: Thursday, February 1, 2024 9:39 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; Wang, Yanzhang ;
kito.ch...@gmail.com
Subject: Re: [PATCH v1] RISC-V: Cleanup the comments for the psabi
On
Pushed to r14-8723.
在 2024/1/24 下午5:19, Jiahao Xu 写道:
gcc/ChangeLog:
* config/loongarch/larchintrin.h
(__frecipe_s): Update function return type.
(__frecipe_d): Ditto.
(__frsqrte_s): Ditto.
(__frsqrte_d): Ditto.
gcc/testsuite/ChangeLog:
*
This patch fixes the following:
vsetvli a5,a1,e32,m1,tu,ma
sllia4,a5,2
sub a1,a1,a5
vle32.v v2,0(a0)
add a0,a0,a4
vadd.vv v1,v2,v1
bne a1,zero,.L3
vsetivlizero,1,e32,m1,ta,ma
vmv.s.x v2,zero
This FAIL was introduced from r14-6908. The reason is that when merging
constant vector permutation implementations, the 128-bit matching situation
was not fully considered. In fact, the expansion of 128-bit vectors after
merging only supports value-based 4 elements set shuffle, so this time is a
Ping?
在 2024/1/30 上午10:09, Lulu Cheng 写道:
From: chenguoqi
libsanitizer/ChangeLog:
* configure.tgt: Enable tsan and lsan for loongarch64.
* tsan/Makefile.am: Add tsan_rtl_loongarch64.S to
EXTRA_libtsan_la_SOURCES.
* tsan/Makefile.in: Regenerate.
---
On 1/18/24 9:24 AM, Jeff Law wrote:
On 1/17/24 20:53, Greg McGary wrote:
While the code comment is true, perhaps it obscures the primary intent,
which is recognition that the pattern (SIGN_EXTEND (mem ...) ) is
destined
to expand into a single memory-load instruction and no simplification
Pushed to r14-8722.
在 2024/1/26 下午4:41, Li Wei 写道:
We found that when only 128-bit vectorization was enabled, 549.fotonik3d_r
failed to vectorize effectively. For this reason, we adjust the cost of
128-bit vector_stmt that match the multiply-add pattern to facilitate 128-bit
vectorization.
The
Pushed to r14-8717...r14-8721.
在 2024/1/29 下午4:21, Lulu Cheng 写道:
When cmodel=extreme, since the symbol address is obtained through four
instructions,
errors may occur in some cases during linking. Xi Ruoyao fixes this problem.
On Thu, Feb 1, 2024 at 8:42 AM Richard Sandiford
wrote:
>
> Tamar Christina writes:
> >> -Original Message-
> >> From: Richard Sandiford
> >> Sent: Thursday, February 1, 2024 2:24 PM
> >> To: Andrew Pinski
> >> Cc: Tamar Christina ; gcc-patches@gcc.gnu.org; nd
> >> ; Richard Earnshaw ;
Pushed to r14-8716.
在 2024/1/30 下午3:55, Lulu Cheng 写道:
Modify address calculation logic from (((a x C) + fp) + offset) to ((fp +
offset) + a x C).
Thereby modifying the register dependencies and optimizing the code.
The value of C is 2 4 or 8.
The following is the assembly code before and
On Jan 24, 2024, at 1:01 AM, Rainer Orth wrote:
>
> gcc.target/i386/pr70321.c FAILs on 32-bit Solaris/x86 since its
> introduction in
>
> commit 43201f2c2173894bf7c423cad6da1c21567e06c0
> Author: Roger Sayle
> Date: Mon May 30 21:20:09 2022 +0100
>
>PR target/70321: Split double word
On Jan 24, 2024, at 1:12 AM, Rainer Orth wrote:
>
> gcc.target/i386/avx512vl-stv-rotatedi-1.c FAILs on 32-bit Solaris/x86
> since its introduction in
>
> commit 4814b63c3c2326cb5d7baa63882da60ac011bd97
> Author: Roger Sayle
> Date: Mon Jul 10 09:04:29 2023 +0100
>
>i386: Add AVX512
On Jan 30, 2024, at 2:30 AM, Iain Sandoe wrote:
>
> tested on i686, x86_64 (and aarch64) Darwin, x86_64, aarch64 Linux,
> OK for trunk?
Ok. If asan people want to chime in...
On Jan 30, 2024, at 2:31 AM, Iain Sandoe wrote:
>
> tested on i686, x86_64 (and aarch64) Darwin, x86_64, aarch64 Linux,
> OK for trunk?
Ok. If the ubsan people want to review this, certainly, happy to have them
chime in.
On Jan 28, 2024, at 7:03 AM, Iain Sandoe wrote:
>
> Tested on i686, x86_64, aarch64 Darwin, x86_64, aarch64 Linux,
> OK for trunk?
Ok. If you discover needed updates, please feel free to drop them in.
On Thu, Feb 1, 2024 at 10:32 AM Jakub Jelinek wrote:
>
> On Thu, Feb 01, 2024 at 10:15:30AM -0800, H.J. Lu wrote:
> > --- a/gcc/config/i386/i386.cc
> > +++ b/gcc/config/i386/i386.cc
> > @@ -22749,6 +22749,31 @@ current_fentry_section (const char **name)
> >return true;
> > }
> >
> > +/*
Changes in v2:
1. Add int_parameter_registers to machine_function to track integer
registers used for parameter passing.
2. Update x86_64_select_profile_regnum to try %r10 first and use an
caller-saved register, which isn't used for parameter passing.
---
2 scratch registers, %r10 and %r11, are
On Tue, Jan 30, 2024 at 07:33:10AM -, Roger Sayle wrote:
+ wide_int bits = wide_int::from (tree_nonzero_bits (rhs),
+ prec,
I'm going to push this as obvious.
-- >8 --
gcc/ChangeLog:
* doc/extend.texi (Common Type Attributes): Fix typo in
description of hardbool.
---
gcc/doc/extend.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
On 2/1/24 16:23, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
aarch64-unknown-linux-gnu now bootstraps.
-- >8 --
My recent -Wdangling-reference change to not warn on std::span-like classes
unfortunately caused a new warning: extending
Andre Vieira writes:
> This patch finalizes adding support for the generation of SVE simd clones when
> no simdlen is provided, following the ABI rules where the widest data type
> determines the minimum amount of elements in a length agnostic vector.
>
> gcc/ChangeLog:
>
> *
When bootstrapping GCC 14 --with-build-config=bootstrap-lto, an ODR
violation is detected:
../../gcc/config/loongarch/loongarch-opts.cc:57: warning:
'abi_minimal_isa' violates the C++ One Definition Rule [-Wodr]
57 | abi_minimal_isa[N_ABI_BASE_TYPES][N_ABI_EXT_TYPES];
> >
> > If the above is correct then I think I understand what you're saying and
> > will update the patch and do some Checks.
>
> Yes, I think that's what I wanted to say.
>
As discussed:
Bootstrapped Regtested on aarch64-none-linux-gnu and x86_64-pc-linux-gnu no
issues.
Also checked both
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
aarch64-unknown-linux-gnu now bootstraps.
-- >8 --
My recent -Wdangling-reference change to not warn on std::span-like classes
unfortunately caused a new warning: extending reference_like_class_p also
opens the door to new warnings
This commit is specifically targeting enhancements in
Nix support for GCC development. This initiative stems
from the recognized need within our community for a more
streamlined and efficient development process when using Nix.
Please not that in this case the Nix tool is used to define
what
Hi Eli,
Yeah sorry I forgot to tag with -v2, so I am creating a -v3, after a while that
I do not use email to send patches I get a little bit rusty.
Thanks for your useful feedback, I am sending the v3 now.
Cheers,
Vincent.
On Wed, Jan 31, 2024 at 11:19 PM Eli Schwartz wrote:
>
> On
The fix for PR70321 introduced a splitter that split a doubleword
comparison into a pair of XORs followed by an IOR to set the (zero)
flags register. To help the reload, splitter forced SUBREG pieces of
double-word input values to a pseudo, but this regressed
gcc.target/i386/pr82580.c
int f0 (U
On Wed, 3 Jan 2024, Hans-Peter Nilsson wrote:
> > > Hmm. I think it would be more correct to emphasize that the
> > > existing dg-timeout-factor affects both the tool execution *and*
> > > the test execution, whereas your new dg-test-timeout-factor only
> > > affects the test execution. (And
On Thu, Feb 01, 2024 at 07:58:29PM +, Iain Sandoe wrote:
> Thanks, looks silly pasto that somehow managed to survive default testing
> options.
>
> Tested x86_64-darwin (along with the warning suppression patch) and
> tested for ftrampoline-impl={heap,stack} and {static,shared}-libgcc.
> On 1 Feb 2024, at 08:51, Richard Biener wrote:
>
> On Thu, Feb 1, 2024 at 9:23 AM Jakub Jelinek wrote:
>>
>> On Wed, Jan 31, 2024 at 01:04:20PM +0100, Jakub Jelinek wrote:
>>> On Sun, Jan 28, 2024 at 11:02:33AM +, Iain Sandoe wrote:
* config/aarch64/heap-trampoline.c: Rename
> On 1 Feb 2024, at 08:22, Jakub Jelinek wrote:
>
> On Wed, Jan 31, 2024 at 12:59:27PM +0100, Jakub Jelinek wrote:
>> On Sun, Jan 28, 2024 at 02:07:32PM +, Iain Sandoe wrote:
>>> --- a/libgcc/config/aarch64/t-heap-trampoline
>>> +++ b/libgcc/config/aarch64/t-heap-trampoline
>>> @@ -16,4
> From: Jonathan Wakely
> Date: Thu, 1 Feb 2024 19:24:49 +
> I think I'd prefer to keep the reserved bits together, but a simpler
> way to avoid 'unsigned long' making a difference for
> PCC_BITFIELD_TYPE_MATTERS targets would be to use no more than 16 bits
> but do:
>
>unsigned
On Thu, 1 Feb 2024 at 17:22, Jonathan Wakely wrote:
>
> On Thu, 1 Feb 2024 at 16:34, Andreas Schwab wrote:
> >
> > On Feb 01 2024, Jonathan Wakely wrote:
> >
> > > This will result in an ABI change for targets that use 1-byte alignment
> > > for all integral types, e.g. cris-elf.
> >
> > Or
Tested on hppa-unknown-linux-gnu. Committed to trunk.
Dave
---
Set num_threads to 50 on 32-bit hppa in two libgomp loop tests
We support a maximum of 50 threads on 32-bit hppa.
2024-02-01 John David Anglin
libgomp/ChangeLog:
* testsuite/libgomp.c++/loop-3.C: Set num_threads to 50
Tested on hppa-unknown-linux-gnu. Committed to trunk.
Dave
---
xfail gnat.dg/trampoline3.adb scan-assembler-not check on hppa*-*-*
We still require an executable stack for trampolines on hppa*-*-*.
2024-02-01 John David Anglin
gcc/testsuite/ChangeLog:
* gnat.dg/trampoline3.adb:
Tested on hppa-unknown-linux-gnu. Committed to trunk.
Dave
---
hppa: Fix bug in atomic_storedi_1 pattern
The first alternative stores the floating-point status register
in the destination. It should store zero. We need to copy %fr0
to another floating-point register to initialize it to
On Thu, Feb 01, 2024 at 10:15:30AM -0800, H.J. Lu wrote:
> --- a/gcc/config/i386/i386.cc
> +++ b/gcc/config/i386/i386.cc
> @@ -22749,6 +22749,31 @@ current_fentry_section (const char **name)
>return true;
> }
>
> +/* Return an unused caller-saved register at entry for profile. */
> +
>
Wilco Dijkstra writes:
> The new RTL introduced for LDP/STP results in regressions due to use of
> UNSPEC.
> Given the new LDP fusion pass is good at finding LDP opportunities, change the
> memcpy, memmove and memset expansions to emit single vector loads/stores.
> This fixes the regression and
2 scratch registers, %r10 and %r11, are available at function entry for
large model profiling. But %r10 may be used by stack realignment and we
can't use %r10 in this case. Add x86_64_select_profile_regnum to find
a scratch register for large model profiling and sorry if we can't find
one.
gcc/
On Thu, Feb 01, 2024 at 02:32:33PM +, Alex Coplan wrote:
> On 31/01/2024 15:53, Marek Polacek wrote:
> > On Wed, Jan 31, 2024 at 07:44:41PM +, Alex Coplan wrote:
> > > Hi Marek,
> > >
> > > On 30/01/2024 13:15, Marek Polacek wrote:
> > > > On Thu, Jan 25, 2024 at 10:13:10PM -0500, Jason
On 1/31/2024 11:05 PM, juzhe.zh...@rivai.ai wrote:
Sorry again. I just realized you have reverted your patches that's why I
can pass the testing now.
I checkout your latest patch commit:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=23cd2961bd2ff63583f46e3499a07bd54491d45c
On 1/31/2024 11:29 PM, Li, Pan2 wrote:
I can somehow reproduce the failures on commit id
23cd2961bd2ff63583f46e3499a07bd54491d45c, configurations as below.
./configure --prefix=${install_dir} \
--with-arch=rv64imafdcv \
--with-abi=lp64d \
--with-isa-spec=20191213 \
--with-sim=qemu
make -j
On Thu, 1 Feb 2024, Marek Polacek wrote:
> On Wed, Jan 31, 2024 at 11:39:56PM -0800, Andi Kleen wrote:
> > > This will run the test only once with -std=c++11. We'll get better
> > > coverage
> > > with dropping the line above and using
> > >
> > > /* { dg-do compile { target { tail_call && { c
Wilco Dijkstra writes:
> Hi Richard,
>
>>> That tune is only used by an obsolete core. I ran the memcpy and memset
>>> benchmarks from Optimized Routines on xgene-1 with and without LDP/STP.
>>> There is no measurable penalty for using LDP/STP. I'm not sure why it was
>>> ever added given it does
On Thu, 1 Feb 2024, 17:23 Jonathan Wakely, wrote:
> On Thu, 1 Feb 2024 at 16:34, Andreas Schwab wrote:
> >
> > On Feb 01 2024, Jonathan Wakely wrote:
> >
> > > This will result in an ABI change for targets that use 1-byte alignment
> > > for all integral types, e.g. cris-elf.
> >
> > Or 2-byte
Wilco Dijkstra writes:
> (follow-on based on review comments on
> https://gcc.gnu.org/pipermail/gcc-patches/2024-January/641913.html)
>
>
> Remove the tune AARCH64_EXTRA_TUNE_NO_LDP_STP_QREGS since it is only
> used by an old core and doesn't properly support -Os. SPECINT_2017
> shows that
On Thu, 1 Feb 2024 at 16:34, Andreas Schwab wrote:
>
> On Feb 01 2024, Jonathan Wakely wrote:
>
> > This will result in an ABI change for targets that use 1-byte alignment
> > for all integral types, e.g. cris-elf.
>
> Or 2-byte alignment as on m68k.
Ah yes.
In fact it's a change for everybody,
On Thu, 1 Feb 2024 at 17:08, Hans-Peter Nilsson wrote:
>
> > From: Hans-Peter Nilsson
> > Date: Thu, 1 Feb 2024 17:16:47 +0100
>
> > Not speaking for other platforms with default-packed layout
> > or where ABI structure layout alignment implies a change due
> > to PCC_BITFIELD_TYPE_MATTERS and
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
Here when streaming in the fields of the as-base version of
_Formatting_scanner we end up clobbering ANON_AGGR_TYPE_FIELD
of the anonymous union type, since it turns out this type is shared
between the original FIELD_DECL and
Richard Ball writes:
> When using LTO, handling the pragma for sme before the pragma
> for the neon-sve-bridge caused the following error on svset_neonq,
> in the neon-sve-bridge.c test.
>
> error: ACLE function '0' can only be called when SME streaming mode is
> enabled.
>
> Handling the
BUILD_INFO is currently a byproduct of checking makeinfo
presence/version. INSTALL_INFO used to be defined similarly, but was
removed in 2000 (!) by commit 17db658241d18cf6db59d31bc2d6eac96e9257df
(svn r38141).
In order to save build time, our CI overrides BUILD_INFO="", which
works when
> From: Hans-Peter Nilsson
> Date: Thu, 1 Feb 2024 17:16:47 +0100
> Not speaking for other platforms with default-packed layout
> or where ABI structure layout alignment implies a change due
> to PCC_BITFIELD_TYPE_MATTERS and the "unsigned long"
> bitfield type.
>
> That last one may matter
On 01/02/2024 07:19, Richard Biener wrote:
On Wed, 31 Jan 2024, Andre Vieira (lists) wrote:
The patch didn't come with a testcase so it's really hard to tell
what goes wrong now and how it is fixed ...
My bad! I had a testcase locally but never added it...
However... now I look at it and
Hi,
Jonathan Wakely writes:
> I am undecided about pushing this PATCH 2/2 to trunk. PATCH 1/2 needs to
> be done now due to the ABI impact on cris-elf. This one could wait for
> stage 1. (HP, this one probably isn't of interest to you, but I don't
> know how to tell git-send-email to only CC
Richard Ball writes:
> Adds a check to ensure that the input vector arguments
> to a function are not variable length. Previously, only the
> output vector of a function was checked.
>
> The ICE in question is within the neon-sve-bridge.c test,
> and is related to
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Thursday, February 1, 2024 2:24 PM
>> To: Andrew Pinski
>> Cc: Tamar Christina ; gcc-patches@gcc.gnu.org; nd
>> ; Richard Earnshaw ; Marcus
>> Shawcroft ; Kyrylo Tkachov
>>
>> Subject: Re: [PATCH]AArch64:
On Feb 01 2024, Jonathan Wakely wrote:
> This will result in an ABI change for targets that use 1-byte alignment
> for all integral types, e.g. cris-elf.
Or 2-byte alignment as on m68k.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3
When using LTO, handling the pragma for sme before the pragma
for the neon-sve-bridge caused the following error on svset_neonq,
in the neon-sve-bridge.c test.
error: ACLE function '0' can only be called when SME streaming mode is enabled.
Handling the pragmas the other way around fixes this.
> From: Jonathan Wakely
> Cc: Hans-Peter Nilsson
> Date: Thu, 1 Feb 2024 15:36:50 +
> I plan to push this to trunk soon.
>
> CC HP for visibility of the change affecting cris-elf. In practice it
> shouldn't make any difference to any sensible code. It only affects
> C++20 mode (and
Adds a check to ensure that the input vector arguments
to a function are not variable length. Previously, only the
output vector of a function was checked.
The ICE in question is within the neon-sve-bridge.c test,
and is related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111268
I am undecided about pushing this PATCH 2/2 to trunk. PATCH 1/2 needs to
be done now due to the ABI impact on cris-elf. This one could wait for
stage 1. (HP, this one probably isn't of interest to you, but I don't
know how to tell git-send-email to only CC you on the first patch).
I'd like to do
I plan to push this to trunk soon.
CC HP for visibility of the change affecting cris-elf. In practice it
shouldn't make any difference to any sensible code. It only affects
C++20 mode (and later), and only changes the size of std::formatter
objects which are typically only created by the library
Realize in recent benchmark evaluation (coremark-pro zip-test):
vid.v v2
vmv.v.i v5,0
.L9:
vle16.v v3,0(a4)
vrsub.vxv4,v2,a6 ---> LICM failed to hoist it outside the
loop.
The root cause is:
(insn 56 47 57 4 (set (subreg:DI (reg:HI 220) 0)
On 2/1/24 15:25, Jakub Jelinek wrote:
On Thu, Feb 01, 2024 at 03:55:51PM +0100, Jakub Jelinek wrote:
No, besides the formatting being incorrect both in ChangeLog and in the
patch, this pessimizes ILP32 hosts unnecessarily.
So like this instead?
2024-02-01 Jakub Jelinek
* hwint.h
Tested x86_64-linux. Pushed to trunk.
-- >8 --
These line markers are not needed, because searching
for a macro name works fine. Removing them means that small changes to
do not result in large diffs to
because of all the changed line numbers.
libstdc++-v3/ChangeLog:
*
Tested x86_64-linux. Pushed to trunk.
-- >8 --
We no longer hit a __builtin_unreachable() in these tests, so we need to
update the dg-error patterns to match _Error_formatter::_M_error().
We can also remove some dg-prune-output directives matching notes saying
"in 'constexpr' expansion" because
Tested x86_64-linux. Pushed to trunk.
-- >8 --
In C++20 it's deprecated for a [=] lambda capture to capture the 'this'
pointer. Using resize_and_overwrite with a lambda seems like overkill to
write three chars to the string anyway. Just resize the string and
overwrite the end of it directly.
On Thu, Feb 01, 2024 at 03:55:51PM +0100, Jakub Jelinek wrote:
> No, besides the formatting being incorrect both in ChangeLog and in the
> patch, this pessimizes ILP32 hosts unnecessarily.
So like this instead?
2024-02-01 Jakub Jelinek
* hwint.h (GCC_PRISZ, fmt_size_t,
On Wed, Jan 31, 2024 at 11:39:56PM -0800, Andi Kleen wrote:
> > This will run the test only once with -std=c++11. We'll get better coverage
> > with dropping the line above and using
> >
> > /* { dg-do compile { target { tail_call && { c || c++11 } } } } */
> >
> > but here it may not matter.
>
On Thu, Feb 1, 2024 at 3:18 PM Richard Biener wrote:
>
> The following avoids re-using a register holding a pointer (and
> thus might be REG_POINTER) for the result of a pointer difference
> computation. That might confuse heuristics in (broken) RTL alias
> analysis which relies on REG_POINTER
On Thu, Feb 01, 2024 at 02:53:47PM +, Jonathan Yong wrote:
> On 2/1/24 14:33, Xi Ruoyao wrote:
> >
> > I mean if you are casting it to unsigned HOST_WIDE_INT, you should use
> > HOST_WIDE_INT_PRINT_UNSIGNED, If you are casting it to size_t you
> > cannot use it (as Jakub has explained).
> >
On Thu, Feb 01, 2024 at 02:13:11PM +0100, Jakub Jelinek wrote:
> Or hwint.h could define PRIusize_t etc. macros and some corresponding type
> to be used in casts, something like
> #if SIZE_MAX == LONG_LONG_MAX
> #define PRIusize_t HOST_LONG_LONG_FORMAT "u"
> #define fmt_size_t unsigned long long
>
On 2/1/24 14:33, Xi Ruoyao wrote:
I mean if you are casting it to unsigned HOST_WIDE_INT, you should use
HOST_WIDE_INT_PRINT_UNSIGNED, If you are casting it to size_t you
cannot use it (as Jakub has explained).
When you use printf-like things you have to keep the correspondence
between format
On Thu, 1 Feb 2024, Thomas Schwinge wrote:
> Hi!
>
> On 2024-01-26T10:45:10+0100, Richard Biener wrote:
> > On Fri, 26 Jan 2024, Richard Biener wrote:
> >> On Wed, 24 Jan 2024, Andrew Stubbs wrote:
> >> > [...] is enough to get gfx1100 working for most purposes, on top of the
> >> > patch that
On 01/02/2024 13:49, Thomas Schwinge wrote:
Hi!
On 2018-12-12T11:52:52+, Andrew Stubbs wrote:
This patch contains the major part of the GCN back-end. [...]
--- /dev/null
+++ b/gcc/config/gcn/gcn.c
+void
+gcn_hsa_declare_function_name (FILE *file, const char *name, tree)
+{
+ /*
Hi!
On 2024-01-26T10:45:10+0100, Richard Biener wrote:
> On Fri, 26 Jan 2024, Richard Biener wrote:
>> On Wed, 24 Jan 2024, Andrew Stubbs wrote:
>> > [...] is enough to get gfx1100 working for most purposes, on top of the
>> > patch that Tobias committed a week or so ago; there are still some
On Thu, 2024-02-01 at 14:55 +0100, Jakub Jelinek wrote:
> On Thu, Feb 01, 2024 at 01:42:03PM +, Jonathan Yong wrote:
> > On 2/1/24 13:06, Xi Ruoyao wrote:
> > > On Thu, 2024-02-01 at 14:01 +0100, Jakub Jelinek wrote:
> > > > On Thu, Feb 01, 2024 at 12:45:31PM +, Jonathan Yong wrote:
> > >
On 31/01/2024 15:53, Marek Polacek wrote:
> On Wed, Jan 31, 2024 at 07:44:41PM +, Alex Coplan wrote:
> > Hi Marek,
> >
> > On 30/01/2024 13:15, Marek Polacek wrote:
> > > On Thu, Jan 25, 2024 at 10:13:10PM -0500, Jason Merrill wrote:
> > > > On 1/25/24 20:36, Marek Polacek wrote:
> > > > >
> -Original Message-
> From: Richard Sandiford
> Sent: Thursday, February 1, 2024 2:24 PM
> To: Andrew Pinski
> Cc: Tamar Christina ; gcc-patches@gcc.gnu.org; nd
> ; Richard Earnshaw ; Marcus
> Shawcroft ; Kyrylo Tkachov
>
> Subject: Re: [PATCH]AArch64: update vget_set_lane_1.c test
Andrew Pinski writes:
> On Thu, Feb 1, 2024 at 1:26 AM Tamar Christina
> wrote:
>>
>> Hi All,
>>
>> In the vget_set_lane_1.c test the following entries now generate a zip1
>> instead of an INS
>>
>> BUILD_TEST (float32x2_t, float32x2_t, , , f32, 1, 0)
>> BUILD_TEST (int32x2_t, int32x2_t, ,
The following avoids re-associating
(minus:DI (reg/f:DI 119)
(minus:DI (reg/f:DI 120)
(reg/f:DI 114)))
into
(minus:DI (plus:DI (reg/f:DI 114)
(reg/f:DI 119))
(reg/f:DI 120))
as that possibly confuses the REG_POINTER heuristics of RTL
alias analysis. This happens to
The following avoids re-using a register holding a pointer (and
thus might be REG_POINTER) for the result of a pointer difference
computation. That might confuse heuristics in (broken) RTL alias
analysis which relies on REG_POINTER indicating that we're
dealing with one.
This alone doesn't fix
On Thu, Feb 01, 2024 at 01:42:03PM +, Jonathan Yong wrote:
> On 2/1/24 13:06, Xi Ruoyao wrote:
> > On Thu, 2024-02-01 at 14:01 +0100, Jakub Jelinek wrote:
> > > On Thu, Feb 01, 2024 at 12:45:31PM +, Jonathan Yong wrote:
> > > > Attached patch OK? Copied inline for review convenience.
> > >
On Wed, 31 Jan 2024 at 17:20, xndcn wrote:
>
> Thanks!
>
> > Why not just use -latomic unconditionally here?
> testsuites of libstdc++ seems to have some tricks to find and link
> libatomic.a by using "dg-add-options libatomic", which do nothing for
> x86 target. In previous email, we decide not
Hi!
On 2018-12-12T11:52:52+, Andrew Stubbs wrote:
> This patch contains the major part of the GCN back-end. [...]
> --- /dev/null
> +++ b/gcc/config/gcn/gcn.c
> +void
> +gcn_hsa_declare_function_name (FILE *file, const char *name, tree)
> +{
> + /* Determine count of sgpr/vgpr registers
The new RTL introduced for LDP/STP results in regressions due to use of UNSPEC.
Given the new LDP fusion pass is good at finding LDP opportunities, change the
memcpy, memmove and memset expansions to emit single vector loads/stores.
This fixes the regression and enables more RTL optimization on
On 2/1/24 13:06, Xi Ruoyao wrote:
On Thu, 2024-02-01 at 14:01 +0100, Jakub Jelinek wrote:
On Thu, Feb 01, 2024 at 12:45:31PM +, Jonathan Yong wrote:
Attached patch OK? Copied inline for review convenience.
No, I think e.g. AIX doesn't support the z modifier.
I don't see %zd or %zu used
On 1/30/24 18:54, pan2...@intel.com wrote:
From: Pan Li
This patch would like to cleanup some comments which are out of date or
incorrect.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_get_arg_info): Cleanup comments.
(riscv_pass_by_reference): Ditto.
On Thu, Feb 1, 2024 at 7:24 AM Rainer Orth
wrote:
>
> Hi Lewis,
>
> > On Fri, Jan 26, 2024 at 04:16:54PM -0500, Jason Merrill wrote:
> >> On 12/5/23 20:52, Lewis Hyatt wrote:
> >> > Hello-
> >> >
> >> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608
> >> >
> >> > There are two related
On Thu, Feb 01, 2024 at 02:01:17PM +0100, Jakub Jelinek wrote:
> On Thu, Feb 01, 2024 at 12:45:31PM +, Jonathan Yong wrote:
> > Attached patch OK? Copied inline for review convenience.
>
> No, I think e.g. AIX doesn't support the z modifier.
> I don't see %zd or %zu used anywhere except in
On Thu, 2024-02-01 at 14:01 +0100, Jakub Jelinek wrote:
> On Thu, Feb 01, 2024 at 12:45:31PM +, Jonathan Yong wrote:
> > Attached patch OK? Copied inline for review convenience.
>
> No, I think e.g. AIX doesn't support the z modifier.
> I don't see %zd or %zu used anywhere except in gcc/jit/
1 - 100 of 129 matches
Mail list logo
