On Tue, Jan 23, 2024 at 04:44:32PM +0800, Kewen.Lin wrote:
> > --- a/gcc/config/rs6000/rs6000-cpus.def
> > +++ b/gcc/config/rs6000/rs6000-cpus.def
> > @@ -88,6 +88,10 @@
> > | OPTION_MASK_POWER10 \
> > | OTHER_POWER10_MASKS)
On 1/24/24 5:09 PM, Richard Sandiford wrote:
Tejas Belagod writes:
The target hook aarch64_class_max_nregs returns the incorrect result for 64-bit
structure modes like V31DImode or V41DFmode etc. The calculation of the nregs
is based on the size of AdvSIMD vector register for 64-bit modes whic
Hello, Christophe,
Thanks for the patch.
On Feb 5, 2024, Christophe Lyon wrote:
> In order to save build time, our CI overrides BUILD_INFO="", which
> works when invoking 'make all' but not for 'make install' in case some
> info files need an update.
Hmm, I don't think this would be desirable
On Mon, Feb 5, 2024, 06:53 Matteo Italia wrote:
> Il 31/01/24 04:24, LIU Hao ha scritto:
> > 在 2024-01-31 08:08, Jonathan Yong 写道:
> >> On 1/24/24 15:17, Matteo Italia wrote:
> >>> Ping! That's a one-line fix, and you can find all the details in the
> >>> bugzilla entry. Also, I can provide execu
On Feb 5, 2024, Jakub Jelinek wrote:
> * test_installed: Fill in HOSTCC, HOSTCXX, HOSTCFLAGS and
> HOSTCXXFLAGS.
LGTM, thanks,
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Enginee
On 2/5/24 21:55, Marek Polacek wrote:
On Mon, Feb 05, 2024 at 09:29:08PM -0500, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
After complaining about lack of friendship, we should not try to go on and
define the defaulted comparison operator anyway.
PR c
1. The only supported TLS code sequence with ADD is
addq foo@gottpoff(%rip),%reg
Change je constraint to a memory operand in APX NDD ADD pattern with
register source operand.
2. The instruction length of APX NDD instructions with immediate operand:
op imm, mem, reg
may exceed the size
Technically, not a regression. But it's such a simple fix for such
rare code that I think we should put it in now and be done with
DR 2237.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
With a redundant inline specifier like this:
template struct S : Base {
inline
On Mon, Feb 05, 2024 at 10:14:34AM -0500, Jason Merrill wrote:
> On 2/3/24 10:24, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > I'm not certain OPT_Wc__20_extensions is the best thing for something
> > from [diff.cpp17]; would you prefer something el
On Mon, Feb 05, 2024 at 09:29:08PM -0500, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> -- 8< --
>
> After complaining about lack of friendship, we should not try to go on and
> define the defaulted comparison operator anyway.
>
> PR c++/107291
>
> gcc/cp/Chang
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
After complaining about lack of friendship, we should not try to go on and
define the defaulted comparison operator anyway.
PR c++/107291
gcc/cp/ChangeLog:
* method.cc (early_check_defaulted_comparison): Fail if not friend
在 2024/2/5 上午1:01, Xi Ruoyao 写道:
I have a question. I see that you often add compilation options in
BOOT_CFLAGS.
I also want to test it. Do you have a recommended set of compilation
options?
When I build a compiler for my system I use
{BOOT_{C,CXX,LD}FLAGS,{C,CXX,LD}FLAGS_FOR_TARGET}="-O3 -m
gcc/ChangeLog:
* config/loongarch/larchintrin.h (__movgr2fcsr): Remove redundant
symbol type conversions.
(__cacop_d): Likewise.
(__cpucfg): Likewise.
(__asrtle_d): Likewise.
(__asrtgt_d): Likewise.
(__lddir_d): Likewise.
(__ldpte_d):
gcc/ChangeLog:
* config/loongarch/larchintrin.h (__iocsrrd_h): Modify the
function return value type to unsigned short.
---
gcc/config/loongarch/larchintrin.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/loongarch/larchintrin.h
b/gcc/config/loong
On 2024/2/6 2:17, Joseph Myers wrote:
This series appears to be missing documentation for the new option in
invoke.texi.
OK, I'll add that. Thanks.
--
Best,
Lehua (RiVAI)
On 2024/2/6 0:10, Jeff Law wrote:
Just a note. I doubt this will get much traction from a review
standpoint until gcc-14 is basically out the door.
My recommendation is to continue development, bugfixing, cleanup, etc
between now and then. Consider creating a branch for the work in the
up
在 2024/2/2 下午6:01, Jakub Jelinek 写道:
On Tue, Jan 30, 2024 at 10:09:51AM +0800, Lulu Cheng wrote:
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.
This
On Mon, Feb 5, 2024 at 3:56 PM Jeff Law wrote:
>
>
>
> On 2/5/24 05:00, Christoph Müllner wrote:
> > On Sat, Feb 3, 2024 at 2:11 PM Andreas Schwab
> > wrote:
> >>
> >> On Jan 30 2024, Christoph Müllner wrote:
> >>
> >>> retested
> >>
> >> Nope.
> >
> > Sorry for this. I tested for no regressions
This patch fixes issue reported by Jeff.
Testing is running. Ok for trunk if I passed the testing with no regression ?
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (pre_vsetvl::emit_vsetvl): Fix inifinite
compilation.
(pre_vsetvl::remove_vsetvl_pre_insns): Ditto.
---
gcc/conf
Hi
As previously discussed, this version of the patch adds code to emit a
warning when a directive like this:
!$omp declare target indirect(.true.)
is encountered (i.e. a target directive containing at least one clause,
but no to/enter clause, which appears to violate the OpenMP standard). A
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
This test was fixed by the patch for PR95226, but that patch had no
testcase so let's add this one.
PR c++/109359
gcc/testsuite/ChangeLog:
* g++.dg/ext/frounding-math1.C: New test.
---
gcc/testsuite/g++.dg/ext/frounding-m
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Here we want to build a prvalue array to bind to the T reference, but we
were wrongly trying to strip cv-quals from the array prvalue, which should
be treated the same as a class prvalue.
PR c++/111286
gcc/cp/ChangeLog:
*
> On 5 Feb 2024, at 14:56, Iain Sandoe wrote:
>
> Tested on aarch64-linux,darwin and a cross from aarch64-darwin to linux,
> OK for trunk, or some alternative is needed?
Hmm.. apparently, this fails the linaro pre-commit CI for g++ with:
error: invalid conversion from 'long int*' to 'long uns
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Chinese (simplified) team of translators. The file is available at:
https://translationproject.org/latest/gcc/zh_CN.po
(This file, 'gcc-13.2.
On Mon, 5 Feb 2024, 19:07 Torbjörn SVENSSON,
wrote:
> Ok for trunk and releases/gcc-13?
>
OK, thanks
> ---
>
> When running the DejaGNU testsuite on a toolchain built for native
> Windows, the path /dev/null can't be used to open a stream to void.
> On native Windows, the resource is instead n
This libgo patch bumps the version number for the GCC 14 release.
This is for GCC PR 113668. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
7b0597eba6b29387b56b8d6a4b38f3586e6b49a5
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index ec7e2ab1
This patch to the Go frontend adds Type::message_name to print types
in ways that makes sense to users. As we move toward generics, the
error messages need to be able to refer to types in a readable manner.
Today we use this new feature in AST dumps. Bootstrapped and ran Go
testsuite on x86_64-pc
On 2/4/24 23:37, juzhe.zh...@rivai.ai wrote:
I think it just trigger a latent bug that we didn't encounter.
Hi, Robin. Would you mind give me preprocessed file to reproduce the issue ?
I suspect it triggers latent bug in VSETVL PASS.
So it looks like vsetvl has made a transformation that mak
On Mon, Feb 5, 2024 at 10:01 AM Uros Bizjak wrote:
>
> On Mon, Feb 5, 2024 at 5:43 PM H.J. Lu wrote:
> >
> > Changes in v6:
> >
> > 1. Use ix86_save_reg and accessible_reg_set in
> > x86_64_select_profile_regnum.
> > 2. Construct a complete reg name in x86_function_profiler.
> >
> > Changes in v5
Ok for trunk and releases/gcc-13?
---
When running the DejaGNU testsuite on a toolchain built for native
Windows, the path /dev/null can't be used to open a stream to void.
On native Windows, the resource is instead named "nul".
In 17_intro/tag_type_explicit_ctor.cc, the following statement woul
On Mon, Feb 5, 2024 at 10:40 AM Thiago Jung Bauermann
wrote:
>
>
> Thiago Jung Bauermann writes:
>
> > Hello Luis,
> >
> > Luis Machado writes:
> >>
> >> Approved-By: Luis Machado
> >
> > Thanks! Since this is a patch for the repository top-level, is your
> > approval sufficient to commit the p
On 2/2/2024 11:10 PM, Li, Pan2 wrote:
Hi Edwin
I believe the only problematic failures are the 5 vls calling convention
ones where only 24 ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) are found.
Does this "only 24" comes from calling-convention-1.c?
Oops sorry about that. I said I would include all the
This series appears to be missing documentation for the new option in
invoke.texi.
--
Joseph S. Myers
josmy...@redhat.com
On Mon, Feb 5, 2024 at 5:43 PM H.J. Lu wrote:
>
> Changes in v6:
>
> 1. Use ix86_save_reg and accessible_reg_set in
> x86_64_select_profile_regnum.
> 2. Construct a complete reg name in x86_function_profiler.
>
> Changes in v5:
>
> 1. Add pr113689-3.c.
> 2. Use %r10 if ix86_profile_before_prologue
On Mon, Feb 5, 2024 at 2:56 AM Uros Bizjak wrote:
>
> On Fri, Feb 2, 2024 at 11:47 PM H.J. Lu wrote:
> >
> > Changes in v5:
> >
> > 1. Add pr113689-3.c.
> > 2. Use %r10 if ix86_profile_before_prologue () return true.
> > 3. Try a callee-saved register which has been saved on stack in the
> > prol
Changes in v6:
1. Use ix86_save_reg and accessible_reg_set in
x86_64_select_profile_regnum.
2. Construct a complete reg name in x86_function_profiler.
Changes in v5:
1. Add pr113689-3.c.
2. Use %r10 if ix86_profile_before_prologue () return true.
3. Try a callee-saved register which has been sav
On 2/5/24 00:01, Lehua Ding wrote:
For SPEC INT 2017, when using upstream GCC (whitout these patches), I
get a
coredump when training the peak case, so no data yet. The cause of the
core
dump still needs to be investigated.
Typo, SPEC INT 2017 -> SPEC FP 2017
Also There is a bad news, the
On 2/5/24 06:50, Jakub Jelinek wrote:
Hi!
gcc/Makefile.in since my r0-60234 change fills in HOSTCC and HOSTCFLAGS
in site.exp and since r8-671 also HOSTCXX and HOSTCXXFLAGS.
If those variables aren't set, we get errors like:
/usr/src/gcc/contrib/test_installed --without-g++ --without-gfortran
On 2/5/24 01:15, Richard Biener wrote:
PR rtl-optimization/113255
* simplify-rtx.cc (simplify_context::simplify_binary_operation_1):
Do not re-associate a MINUS with a REG_POINTER op0.
Nasty little set of problems. I don't think we ever pondered that we could
have multiple REGNO_POIN
On Feb 05 2024, Jeff Law wrote:
> We're all aware you *can* do that. But it's never been a requirement to
> commit a patch.
It has always been a requirement that a patch does not break bootstrap.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73
On 2/5/24 08:08, Andreas Schwab wrote:
On Feb 05 2024, Jeff Law wrote:
Until such systems are common, these niggling issues are bound to show up.
It won't if you do it properly: build with a cross compiler that was
built from the same source and enable -Werror.
We're all aware you *can* do
On 2/4/24 23:37, juzhe.zh...@rivai.ai wrote:
I think it just trigger a latent bug that we didn't encounter.
Hi, Robin. Would you mind give me preprocessed file to reproduce the issue ?
I suspect it triggers latent bug in VSETVL PASS.
I've got a few minutes this morning before meetings start.
On 2/3/24 10:14, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
C++20 DR 2237 disallows simple-template-id in cdtors, so you
can't write
template
struct S {
S(); // should be S();
};
This hasn't been a problem until now b
On 2/3/24 10:24, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
I'm not certain OPT_Wc__20_extensions is the best thing for something
from [diff.cpp17]; would you prefer something else?
I think it wants its own flag, that is enabled in C++20 or by
-Wc++20-co
On Feb 05 2024, Jeff Law wrote:
> Until such systems are common, these niggling issues are bound to show up.
It won't if you do it properly: build with a cross compiler that was
built from the same source and enable -Werror.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB
Tested on aarch64-linux,darwin and a cross from aarch64-darwin to linux,
OK for trunk, or some alternative is needed?
thanks
Iain
--- 8< ---
Currently, most of the acle tests fail on the Darwin port because
DI mode is "long" and uint64 is "long long". The fix for this used
in other headers is to
On 2/5/24 05:00, Christoph Müllner wrote:
On Sat, Feb 3, 2024 at 2:11 PM Andreas Schwab
wrote:
On Jan 30 2024, Christoph Müllner wrote:
retested
Nope.
Sorry for this. I tested for no regressions in the test suite with a
cross-build and QEMU and did not do a Werror bootstrap build. I'l
On Mon, 5 Feb 2024, Tamar Christina wrote:
> > It looks like LOOP_VINFO_EARLY_BRK_STORES is "reverse"? Is that
> > why you are doing gsi_move_before + gsi_prev? Why do gsi_prev
> > at all?
> >
>
> As discussed on IRC, then how about this one.
> Incremental building passed all tests and bootstr
On Mon, 5 Feb 2024, Tamar Christina wrote:
> > > Ok for master?
> >
> > I think you need a lp64 target check for the large constants or
> > alternatively use uint64_t?
> >
>
> Ok, how about this one.
>
> Regtested on x86_64-pc-linux-gnu with -m32,-m64 and no issues.
>
> Ok for master?
OK
>
> It looks like LOOP_VINFO_EARLY_BRK_STORES is "reverse"? Is that
> why you are doing gsi_move_before + gsi_prev? Why do gsi_prev
> at all?
>
As discussed on IRC, then how about this one.
Incremental building passed all tests and bootstrap is running.
Ok for master if bootstrap and regtesting
Hi!
gcc/Makefile.in since my r0-60234 change fills in HOSTCC and HOSTCFLAGS
in site.exp and since r8-671 also HOSTCXX and HOSTCXXFLAGS.
If those variables aren't set, we get errors like:
/usr/src/gcc/contrib/test_installed --without-g++ --without-gfortran
--without-objc struct-layout-1.exp
...
ER
> > Ok for master?
>
> I think you need a lp64 target check for the large constants or
> alternatively use uint64_t?
>
Ok, how about this one.
Regtested on x86_64-pc-linux-gnu with -m32,-m64 and no issues.
Ok for master?
Thanks,
Tamar
gcc/testsuite/ChangeLog:
PR tree-optimization/11
On Sat, Feb 03, 2024 at 09:35:43PM -0700, Sandra Loosemore wrote:
> On 2/2/24 02:09, Andi Kleen wrote:
> > gcc/ChangeLog:
> >
> > * doc/extend.texi: Document [[musttail]]
> > ---
> > gcc/doc/extend.texi | 16
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/gcc/do
> -Original Message-
> From: Richard Biener
> Sent: Monday, February 5, 2024 1:22 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> Subject: Re: [PATCH]middle-end: fix ICE when moving statements to empty BB
> [PR113731]
>
> On Mon, 5 Feb 2024, Tamar Chr
On Mon, 5 Feb 2024, Tamar Christina wrote:
> Hi All,
>
> The report shows that if the FE leaves a label as the first thing in the dest
> BB then we ICE because we move the stores before the label.
>
> This is easy to fix if we know that there's still only one way into the BB.
> We would have alr
On Mon, 5 Feb 2024, Tamar Christina wrote:
> Hi All,
>
> We use gsi_move_before (&stmt_gsi, &dest_gsi); to request that the new
> statement
> be placed before any other statement. Typically this then moves the current
> pointer to be after the statement we just inserted.
>
> However it looks l
On Mon, Feb 05, 2024 at 08:57:18AM +0100, Jakub Jelinek wrote:
> Hi!
>
> finish_struct already made sure not to call build_bitint_type for
> signed _BitInt(2) : 1;
> or
> signed _BitInt(2) : 0;
> bitfields (but instead build a zero precision integral type,
> we remove it later), this patch makes s
On Mon, 5 Feb 2024, Tamar Christina wrote:
> Hi All,
>
> This just adds an additional runtime testcase for the fixed issue.
>
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
>
> Ok for master?
I think you need a lp64 target check for the large constants or
alternatively use u
Hi All,
The report shows that if the FE leaves a label as the first thing in the dest
BB then we ICE because we move the stores before the label.
This is easy to fix if we know that there's still only one way into the BB.
We would have already rejected the loop if there was multiple paths into th
Hi All,
We use gsi_move_before (&stmt_gsi, &dest_gsi); to request that the new statement
be placed before any other statement. Typically this then moves the current
pointer to be after the statement we just inserted.
However it looks like when the BB is empty, this does not happen and the CUR
po
Hi All,
This just adds an additional runtime testcase for the fixed issue.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
Thanks,
Tamar
gcc/testsuite/ChangeLog:
PR tree-optimization/113467
* gcc.dg/vect/vect-early-break_110-pr113467.c: New test.
Two libgomp tests XPASS on Solaris (any non-Linux target actually) since
their introduction:
XPASS: libgomp.c/alloc-pinned-1.c execution test
XPASS: libgomp.c/alloc-pinned-2.c execution test
The problem is that the test just prints
OS unsupported
and exits successfully, while the test is XFAILe
set_inlining_locations looks at a possible macro expansion location
when the location is in a system header but it fails to update its
counter when there's no macro involved. The following fixes that.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
This doesn't fix the observed diagnostic i
On Mon, Feb 5, 2024 at 3:53 AM H.J. Lu <> wrote:
>
> Fix the following issues:
>
> 1. Replace long with int64_t to support x32.
> 2. Replace \\(%rdi\\) with \\(%(?:r|e)di\\) for memory operand since x32
> uses (%edi).
> 3. Replace %(?:|r|e)al with %al in negb scan.
>
> * gcc.target/i386/ap
On 5 February 2024 12:30:23 CET, Christophe Lyon
wrote:
>On Fri, 2 Feb 2024 at 11:40, Christophe Lyon
>wrote:
>>
>> On Fri, 2 Feb 2024 at 11:10, wrote:
>> >
>> > On 1 February 2024 18:15:34 CET, Christophe Lyon
>> > wrote:
>> > >BUILD_INFO is currently a byproduct of checking makeinfo
>> > >
On Mon, 2024-02-05 at 09:56 +0800, YunQiang Su wrote:
> Xi Ruoyao 于2024年2月5日周一 02:01写道：
> >
> > We expanded (neg x) to (minus const0 x) for MSA FP vectors, this is
> > wrong because -0.0 is not 0 - 0.0. This causes some Python tests to
> > fail when Python is built with MSA enabled.
> >
> > Use
On Sat, Feb 3, 2024 at 2:11 PM Andreas Schwab wrote:
>
> On Jan 30 2024, Christoph Müllner wrote:
>
> > retested
>
> Nope.
Sorry for this.
I tested for no regressions in the test suite with a cross-build and
QEMU and did not do a Werror bootstrap build.
I'll provide a fix for this later today (al
Il 31/01/24 04:24, LIU Hao ha scritto:
在 2024-01-31 08:08, Jonathan Yong 写道:
On 1/24/24 15:17, Matteo Italia wrote:
Ping! That's a one-line fix, and you can find all the details in the
bugzilla entry. Also, I can provide executables built with the
affected toolchains, demonstrating the problem
Fix the following issues:
1. Replace long with int64_t to support x32.
2. Replace \\(%rdi\\) with \\(%(?:r|e)di\\) for memory operand since x32
uses (%edi).
3. Replace %(?:|r|e)al with %al in negb scan.
* gcc.target/i386/apx-ndd.c: Updated.
---
gcc/testsuite/gcc.target/i386/apx-ndd.c | 6
Hi Sebastian,
on 2024/2/5 18:38, Sebastian Huber wrote:
> Hello,
>
> On 27.12.22 11:16, Kewen.Lin via Gcc-patches wrote:
>> Hi Segher,
>>
>> on 2022/12/24 04:26, Segher Boessenkool wrote:
>>> Hi!
>>>
>>> On Wed, Oct 12, 2022 at 04:12:21PM +0800, Kewen.Lin wrote:
PR106680 shows that -m32 -mpo
On Fri, 2 Feb 2024 at 11:40, Christophe Lyon wrote:
>
> On Fri, 2 Feb 2024 at 11:10, wrote:
> >
> > On 1 February 2024 18:15:34 CET, Christophe Lyon
> > wrote:
> > >BUILD_INFO is currently a byproduct of checking makeinfo
> > >presence/version. INSTALL_INFO used to be defined similarly, but wa
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 invoking
On Fri, Feb 2, 2024 at 11:47 PM H.J. Lu wrote:
>
> Changes in v5:
>
> 1. Add pr113689-3.c.
> 2. Use %r10 if ix86_profile_before_prologue () return true.
> 3. Try a callee-saved register which has been saved on stack in the
> prologue.
>
> Changes in v4:
>
> 1. Remove pr113689-3.c.
> 2. Use df_get_
Hello,
On 27.12.22 11:16, Kewen.Lin via Gcc-patches wrote:
Hi Segher,
on 2022/12/24 04:26, Segher Boessenkool wrote:
Hi!
On Wed, Oct 12, 2022 at 04:12:21PM +0800, Kewen.Lin wrote:
PR106680 shows that -m32 -mpowerpc64 is different from
-mpowerpc64 -m32, this is determined by the way how we
ha
The following makes sure to use the correct pointer mode when
building pointer types to a non-default address-space.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-vect-data-refs.cc (vect_create_data_ref_ptr): Use
the default mode when building a pointer.
---
The following avoids different avail answers depending on how the
iteration progressed.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/113707
* tree-ssa-sccvn.cc (rpo_elim::eliminate_avail): After
checking the avail set treat out-of-regio
On Thu, 1 Feb 2024, Andre Vieira (lists) wrote:
>
>
> 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
On Mon, 5 Feb 2024, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs, because group_case_labels_stmt optimizes
> switch (a.0_7) [50.00%], case 0: [50.00%], case 2:
> [50.00%]>
> where L7 block starts with __builtin_unreachable (); to
> switch (a.0_7) [50.00%]>
> and single labe
On Mon, Feb 5, 2024 at 9:06 AM Uros Bizjak wrote:
>
> On Mon, Feb 5, 2024 at 1:24 AM Roger Sayle wrote:
> >
> >
> > This patch fixes PR target/113690, an ICE-on-valid regression on x86_64
> > that exhibits with a specific combination of command line options. The
> > cause is that x86's scalar-to
On Fri, 2 Feb 2024, Jeff Law wrote:
>
>
> On 2/1/24 07:20, Richard Biener wrote:
> > 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)
> > (re
On Wed, Jan 31, 2024 at 9:23 AM Jakub Jelinek wrote:
>
> Hi!
>
> The move of the vzeroupper pass from after reload pass to after
> postreload_cse helped only partially, CSE-like passes can still invalidate
> those notes (especially REG_UNUSED) if they use some earlier register
> holding some value
On Mon, Feb 5, 2024 at 1:24 AM Roger Sayle wrote:
>
>
> This patch fixes PR target/113690, an ICE-on-valid regression on x86_64
> that exhibits with a specific combination of command line options. The
> cause is that x86's scalar-to-vector pass converts a chain of instructions
> from TImode to V1
82 matches
Mail list logo
