On 11/24/23 03:34, Jakub Jelinek wrote:
On Mon, Sep 18, 2023 at 07:12:40PM +0200, Jakub Jelinek via Gcc-patches wrote:
On Tue, Aug 22, 2023 at 09:39:11AM +0200, Jakub Jelinek via Gcc-patches wrote:
The following patch implements the C++26 P2169R4 paper.
As written in the PR, the patch expects t
On 11/23/23 03:32, Jakub Jelinek wrote:
On Wed, Nov 22, 2023 at 04:53:48PM -0500, Jason Merrill wrote:
I agree it's weird to get two of the same error, but maybe instead of
duplicating the error, we could look up data only if size succeeded, and
then error once if either failed?
Here is what I
On Tue, 28 Nov 2023, Martin Jambor wrote:
> On Tue, Nov 28 2023, Richard Biener wrote:
> > On Mon, 27 Nov 2023, Martin Jambor wrote:
> >
> >> Hi,
> >>
> >> The enhancement to address PR 109849 contained an importsnt thinko,
> >> and that any reference that is passed to a function and does not
> >
Tamar Christina writes:
> Hi All,
>
> This adds an implementation for conditional branch optab for AArch64.
>
> For e.g.
>
> void f1 ()
> {
> for (int i = 0; i < N; i++)
> {
> b[i] += a[i];
> if (a[i] > 0)
> break;
> }
> }
>
> For 128-bit vectors we generate:
>
>
Hi Victor,
> -Original Message-
> From: Victor Do Nascimento
> Sent: Tuesday, November 28, 2023 3:56 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Richard Sandiford
> ; Richard Earnshaw
> ; Victor Do Nascimento
>
> Subject: [PATCH v2 3/5] aarch64: Sync `aarch64-sys-regs.def' wi
On 28/11/2023 09:22, Jakub Jelinek wrote:
> On Mon, Nov 27, 2023 at 10:58:04AM +, Alex Coplan wrote:
> > Many thanks both for the reviews, this is now pushed (with Jason's
> > above changes implemented) as g:06280a906cb3dc80cf5e07cf3335b758848d488d.
>
> The new test FAILs everywhere with GXX_T
Marc Poulhiès writes:
> Simon Wright writes:
>> gcc/ada/Changelog:
>>
>> 2023-11-22 Simon Wright
>>
>> PR ada/111909
>>
>> Can we commit this one now, please?
>
> Hello Simon,
>
> Yes we can commit this one, as both Iain and Arnaud ACKed it.
>
> I'll create a proper commit with the change
Bootstrapped and regtested on x86-64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Here we deem the array-to-pointer conversions in both calls as invalid,
but we fail to issue a diagnostic for the second call, ultimately because
cp_build_c_cast doesn't replay errors from build_const_cast_1.
This adds a sanity check to cp_parser_expression_statement similar to
the one in finish_expr_stmt added by r6-6795-g0fd9d4921f7ba2, which
effectively downgrades accepts-invalid/wrong-code bugs like this one
into ice-on-invalid/ice-on-valid ones.
PR c++/112658
gcc/cp/ChangeLog:
*
On 28/11/2023 17:03, Thomas Schwinge wrote:
> Hi!
>
> On 2023-11-17T14:50:45+, Alex Coplan wrote:
> > --- a/gcc/cp/cp-objcp-common.cc
> > +++ b/gcc/cp/cp-objcp-common.cc
>
> > +/* Table of features for __has_{feature,extension}. */
> > +
> > +static constexpr cp_feature_info cp_feature_tabl
> On Tue, 28 Nov 2023, Martin Jambor wrote:
>
> > On Tue, Nov 28 2023, Richard Biener wrote:
> > > On Mon, 27 Nov 2023, Martin Jambor wrote:
> > >
> > >> Hi,
> > >>
> > >> The enhancement to address PR 109849 contained an importsnt thinko,
> > >> and that any reference that is passed to a functio
Hi Harald,
The patch looks OK to me. Probably wait a bit for another opinion, since I’m
not that active and I may have missed something.
Thanks,
FX
On 11/28/23 03:22, Jakub Jelinek wrote:
On Mon, Nov 27, 2023 at 10:58:04AM +, Alex Coplan wrote:
Many thanks both for the reviews, this is now pushed (with Jason's
above changes implemented) as g:06280a906cb3dc80cf5e07cf3335b758848d488d.
The new test FAILs everywhere with GXX_TESTSUITE_STD
Hi!
On 2023-11-23T09:32:24+0100, Jakub Jelinek wrote:
> Here is what I've committed
> --- gcc/testsuite/g++.dg/cpp26/static_assert1.C.jj2023-11-22
> 10:17:41.340064988 +0100
> +++ gcc/testsuite/g++.dg/cpp26/static_assert1.C 2023-11-22
> 10:47:45.045848504 +0100
> @@ -0,0 +1,309 @@
>
On 11/28/23 11:03, Thomas Schwinge wrote:
Hi!
On 2023-11-17T14:50:45+, Alex Coplan wrote:
--- a/gcc/cp/cp-objcp-common.cc
+++ b/gcc/cp/cp-objcp-common.cc
+/* Table of features for __has_{feature,extension}. */
+
+static constexpr cp_feature_info cp_feature_table[] =
+{
+ { "cxx_except
On 11/28/23 12:08, Thomas Schwinge wrote:
Hi!
On 2023-11-23T09:32:24+0100, Jakub Jelinek wrote:
Here is what I've committed
--- gcc/testsuite/g++.dg/cpp26/static_assert1.C.jj2023-11-22
10:17:41.340064988 +0100
+++ gcc/testsuite/g++.dg/cpp26/static_assert1.C 2023-11-22
10:47:45.0
On Tue, Nov 28, 2023 at 04:45:41PM +, Alex Coplan wrote:
> > --- gcc/cp/cp-objcp-common.cc.jj2023-11-27 17:34:25.0 +0100
> > +++ gcc/cp/cp-objcp-common.cc 2023-11-28 08:55:18.868419864 +0100
> > @@ -145,7 +145,7 @@ static constexpr cp_feature_info cp_feat
> >{ "cxx_context
On 11/28/23 12:12, Jakub Jelinek wrote:
On Tue, Nov 28, 2023 at 04:45:41PM +, Alex Coplan wrote:
--- gcc/cp/cp-objcp-common.cc.jj2023-11-27 17:34:25.0 +0100
+++ gcc/cp/cp-objcp-common.cc 2023-11-28 08:55:18.868419864 +0100
@@ -145,7 +145,7 @@ static constexpr cp_feature_inf
> Am 28.11.2023 um 17:59 schrieb Jan Hubicka :
>
>
>>
>>> On Tue, 28 Nov 2023, Martin Jambor wrote:
>>>
>>> On Tue, Nov 28 2023, Richard Biener wrote:
On Mon, 27 Nov 2023, Martin Jambor wrote:
> Hi,
>
> The enhancement to address PR 109849 contained an importsnt thin
On Tue, Nov 28, 2023 at 02:19:36PM +0200, Manolis Tsamis wrote:
> > So, like this (so far untested)?
> >
> > Note, the earlier posted patch passed bootstrap/regtest on
> > {powerpc64le,x86_64,i686}-linux.
Testing revealed this fails miserably, artificial uses don't really
have DF_REF_INSN, so I'm
>
>
> > Am 28.11.2023 um 17:59 schrieb Jan Hubicka :
> >
> >
> >>
> >>> On Tue, 28 Nov 2023, Martin Jambor wrote:
> >>>
> >>> On Tue, Nov 28 2023, Richard Biener wrote:
> On Mon, 27 Nov 2023, Martin Jambor wrote:
>
> > Hi,
> >
> > The enhancement to address PR 109849
Manos Anagnostakis writes:
> This is an RTL pass that detects store forwarding from stores to larger loads
> (load pairs).
>
> This optimization is SPEC2017-driven and was found to be beneficial for some
> benchmarks,
> through testing on ampere1/ampere1a machines.
>
> For example, it can transf
On 11/27/23 13:52, Jakub Jelinek wrote:
On Mon, Oct 16, 2023 at 01:11:01PM -0600, Jeff Law wrote:
gcc/ChangeLog:
* Makefile.in: Add fold-mem-offsets.o.
* passes.def: Schedule a new pass.
* tree-pass.h (make_pass_fold_mem_offsets): Declare.
* common.opt: New op
On 11/28/23 10:30, Jakub Jelinek wrote:
On Tue, Nov 28, 2023 at 02:19:36PM +0200, Manolis Tsamis wrote:
So, like this (so far untested)?
Note, the earlier posted patch passed bootstrap/regtest on
{powerpc64le,x86_64,i686}-linux.
Testing revealed this fails miserably, artificial uses don't
On Tue, Nov 28, 2023 at 11:31:48AM -0500, Jason Merrill wrote:
> > + if (len)
> > + {
> > + if (data)
> > + msg = c_getstr (data);
> > + if (msg == NULL)
> > + buf = XNEWVEC (char, len);
>
> Jonathan pointed out elsewhere that t
Richard Sandiford writes:
> Tamar Christina writes:
>> Hi All,
>>
>> This adds an implementation for conditional branch optab for AArch64.
>>
>> For e.g.
>>
>> void f1 ()
>> {
>> for (int i = 0; i < N; i++)
>> {
>> b[i] += a[i];
>> if (a[i] > 0)
>> break;
>> }
>> }
>>
>
> Am 28.11.2023 um 18:38 schrieb Jan Hubicka :
>
>
>>
>>
>>
Am 28.11.2023 um 17:59 schrieb Jan Hubicka :
>>>
>>>
> On Tue, 28 Nov 2023, Martin Jambor wrote:
>
> On Tue, Nov 28 2023, Richard Biener wrote:
>> On Mon, 27 Nov 2023, Martin Jambor wrote:
>>
>>
On Tue, Nov 28, 2023 at 7:38 AM wrote:
>
> From: Ezra Sitorus
>
> Add the transform rule (T)(~A) -> ~(T)(A) for view_convert. The simplified
> result could be a single assembly instruction when chained with other
> instructions.
>
> gcc/ChangeLog:
> * match.pd: Add new transform rule.
>
On Wed, 22 Nov 2023 14:27:50 PST (-0800), jeffreya...@gmail.com wrote:
...
[Trimming everything else, as this is a big change. I'm also making it
a new subject/thread, so folks can see.]
More generally, I think I need to soften my prior statement about
deferring this to gcc-15. This code
On Fri, 17 Nov 2023 16:01:27 PST (-0800), jeffreya...@gmail.com wrote:
On 11/17/23 16:16, 钟居哲 wrote:
>> I assume this hunk is meant for riscv_output_operand in riscv.cc. We
may also need to add '^' to the punct_valid_p hook. But yes, this is
the preferred way to go when all we need to do i
Hi FX,
On 11/28/23 18:07, FX Coudert wrote:
Hi Harald,
The patch looks OK to me. Probably wait a bit for another opinion, since I’m
not that active and I may have missed something.
Thanks,
FX
thanks for having a look.
In the meantime I got an automated mail from the Linaro testers.
Accordi
On Tue, 28 Nov 2023 at 20:31, Palmer Dabbelt wrote:
>
> On Wed, 22 Nov 2023 14:27:50 PST (-0800), jeffreya...@gmail.com wrote:
> > ...
>
> [Trimming everything else, as this is a big change. I'm also making it
> a new subject/thread, so folks can see.]
>
> > More generally, I think I need to soft
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
My change for PR53220 made array to pointer decay for prvalue arrays
ill-formed to catch well-defined C code that produces a dangling pointer in
C++ due to the shorter lifetime of compound literals. This wasn't really
correct, but wasn't a
On 11/28/23 11:51, Patrick Palka wrote:
Bootstrapped and regtested on x86-64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Here we deem the array-to-pointer conversions in both calls as invalid,
but we fail to issue a diagnostic for the second call, ultimately because
cp_build_c_cast does
On 11/28/23 11:51, Patrick Palka wrote:
This adds a sanity check to cp_parser_expression_statement similar to
the one in finish_expr_stmt added by r6-6795-g0fd9d4921f7ba2, which
effectively downgrades accepts-invalid/wrong-code bugs like this one
into ice-on-invalid/ice-on-valid ones.
OK.
On 11/28/23 12:52, Jakub Jelinek wrote:
On Tue, Nov 28, 2023 at 11:31:48AM -0500, Jason Merrill wrote:
+ if (len)
+ {
+ if (data)
+ msg = c_getstr (data);
+ if (msg == NULL)
+ buf = XNEWVEC (char, len);
On 11/28/23 12:45, Palmer Dabbelt wrote:
IMO we're just stuck between a rock and a hard place here. Specifically,
this isn't just an assembly syntax change but also comes with a bunch of
behaviorial changes to the instructions in question -- I'm specifically
thinking of things like the re
>
> The amdgcn ICE I reported still exists:
Can you send a build command to reproduce ICE.
I built on x86-64, RV32/64, and did not get any faults.
On Tue, Nov 28, 2023 at 7:08 PM Andrew Stubbs wrote:
> On 28/11/2023 06:06, Jeff Law wrote:
> > - Verify we have a SUBREG before looking at SUBREG_
On 11/28/23 12:56, Philipp Tomsich wrote:
That's obviously a risky thing to do given it was sent right at the end
of the window, but it meets the rules.
Folks in the call seemed generally amenable to at least trying for 14,
so unless anyone's opposed on the lists it seems like the way to go.
This has introduced an ICE building glibc for s390x-linux-gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112753
--
Joseph S. Myers
jos...@codesourcery.com
Victor Do Nascimento writes:
> Changes from v1 -
> https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635531.html
>
> * [PATCH 4/5] - For `error_at' message, put feature name in quotes.
> * [PATCH 4/5] - For `aarch64_retrieve_sysreg' function, add
> description of new parameter to comme
Victor Do Nascimento writes:
> Given the implementation of a mechanism of encoding system registers
> into GCC, this patch provides the mechanism of validating their use by
> the compiler. In particular, this involves:
>
> 1. Ensuring a supplied string corresponds to a known system
> regis
Victor Do Nascimento writes:
> This patch defines the structure of a new .def file used for
> representing the aarch64 system registers, what information it should
> hold and the basic framework in GCC to process this file.
>
> Entries in the aarch64-system-regs.def file should be as follows:
>
>
Victor Do Nascimento writes:
> Implement the aarch64 intrinsics for reading and writing system
> registers with the following signatures:
>
> uint32_t __arm_rsr(const char *special_register);
> uint64_t __arm_rsr64(const char *special_register);
> void* __arm_rsrp(const char *spe
Victor Do Nascimento writes:
> In implementing the ACLE read/write system register builtins it was
> observed that leaving argument type checking to be done at expand-time
> meant that poorly-formed function calls were being "fixed" by certain
> optimization passes, meaning bad code wasn't being p
On Linux/x86_64,
f31a019d1161ec78846473da743aedf49cca8c27 is the first bad commit
commit f31a019d1161ec78846473da743aedf49cca8c27
Author: Jose E. Marchesi
Date: Fri Nov 24 06:30:28 2023 +0100
Emit funcall external declarations only if actually used.
caused
FAIL: gcc.c-torture/compile/lib
Victor Do Nascimento writes:
> This patch adds the `aarch64-sys-regs.def' file, originally written
> for Binutils, to GCC. In so doing, it provides GCC with the necessary
> information for teaching the compiler about system registers known to
> the assembler and how these can be used.
>
> By align
Victor Do Nascimento writes:
> Add a build-time test to check whether system register data, as
> imported from `aarch64-sys-reg.def' has any duplicate entries.
>
> Duplicate entries are defined as any two SYSREG entries in the .def
> file which share the same encoding values (as specified by its `
On 11/28/23 15:18, Jivan Hakobyan wrote:
The amdgcn ICE I reported still exists:
Can you send a build command to reproduce ICE.
I built on x86-64, RV32/64, and did not get any faults.
THe code is clearly wrong though. We need to test that we have a subreg
before we look at the subreg_b
On Tue, Nov 28, 2023 at 9:51 PM Hongyu Wang wrote:
>
> Hi,
>
> On linux x86-64, -fomit-frame-pointer was by default enabled so the
> push2pop2 tests cfi scans are based on it. On other target with
> -fno-omit-frame-pointer the cfi scan will be wrong as the frame pointer
> is pushed at first. Add -
On 11/23/23 11:34, Maciej W. Rozycki wrote:
On Sun, 19 Nov 2023, Jeff Law wrote:
As I suspect you know a big part of the problem here is that BRANCH_COST and
rtx_cost don't have any common scale and thus trying to compare BRANCH_COST to
RTX_COST doesn't have well defined meaning.
We do h
Hi, all
This patch aims to fix the wrong CPUID of USER_MSR, its correct CPUID is
(0x7, 0x1).EDX[15], But I set it as (0x7, 0x0).EDX[15]. And the patch modefied
testcase for give the user a better example.
It has been bootstrapped and regtested on x86-64-pc-linux-gnu, OK for trunk?
BR,
Lin
gcc/C
On 11/27/23 01:34, Liao Shihua wrote:
This patch add C intrinsics for scalar crypto extension.
Because of riscv-c-api
(https://github.com/riscv-non-isa/riscv-c-api-doc/pull/44/files) includes
zbkb/zbkc/zbkx's
intrinsics in bit manipulation extension, this patch only support zkn*/zks*'s
intr
On Tue, 2023-11-28 at 15:56 +0800, Li Wei wrote:
> In the r14-5547 commit, C[LT]Z_DEFINED_VALUE_AT_ZERO were defined at
> the same time, but in fact, CLZ_DEFINED_VALUE_AT_ZERO has already been
> defined, so remove the duplicate definition.
>
> gcc/ChangeLog:
>
> * config/loongarch/loongarch
On Tue, 2023-11-28 at 11:29 +0800, Jiahao Xu wrote:
> diff --git a/gcc/config/loongarch/predicates.md
> b/gcc/config/loongarch/predicates.md
> index f7796da10b2..9e9ce58cb53 100644
> --- a/gcc/config/loongarch/predicates.md
> +++ b/gcc/config/loongarch/predicates.md
> @@ -235,6 +235,10 @@ (define_p
在 2023/11/29 上午10:08, Xi Ruoyao 写道:
On Tue, 2023-11-28 at 11:29 +0800, Jiahao Xu wrote:
diff --git a/gcc/config/loongarch/predicates.md
b/gcc/config/loongarch/predicates.md
index f7796da10b2..9e9ce58cb53 100644
--- a/gcc/config/loongarch/predicates.md
+++ b/gcc/config/loongarch/predicates.md
@
On Wed, 2023-11-29 at 10:23 +0800, Jiahao Xu wrote:
>
> 在 2023/11/29 上午10:08, Xi Ruoyao 写道:
> > On Tue, 2023-11-28 at 11:29 +0800, Jiahao Xu wrote:
> > > diff --git a/gcc/config/loongarch/predicates.md
> > > b/gcc/config/loongarch/predicates.md
> > > index f7796da10b2..9e9ce58cb53 100644
> > > ---
Currently sdot_prodv*qi is available under TARGET_AVXVNNIINT8, but it
can be emulated by
vec_unpacks_lo_v32qi
vec_unpacks_lo_v32qi
vec_unpacks_hi_v32qi
vec_unpacks_hi_v32qi
sdot_prodv16hi
sdot_prodv16hi
add3v8si
which is faster than original
vect_patt_39.11_48 = WIDEN_MULT_LO_EXPR ;
v
On Wed, Nov 29, 2023 at 9:23 AM Hu, Lin1 wrote:
>
> Hi, all
>
> This patch aims to fix the wrong CPUID of USER_MSR, its correct CPUID is
> (0x7, 0x1).EDX[15], But I set it as (0x7, 0x0).EDX[15]. And the patch modefied
> testcase for give the user a better example.
>
> It has been bootstrapped and
在 2023/11/29 上午10:33, Xi Ruoyao 写道:
On Wed, 2023-11-29 at 10:23 +0800, Jiahao Xu wrote:
在 2023/11/29 上午10:08, Xi Ruoyao 写道:
On Tue, 2023-11-28 at 11:29 +0800, Jiahao Xu wrote:
diff --git a/gcc/config/loongarch/predicates.md
b/gcc/config/loongarch/predicates.md
index f7796da10b2..9e9ce58cb53
According to spec, fmv.h checks if the input operands are correctly
NaN-boxed. If not, the input value is treated as an n-bit canonical NaN.
This patch fixs the issue that operands returned by soft-fp16 libgcc
(i.e., __truncdfhf2) was not correctly NaN-boxed.
*gcc/ChangeLog:*
* config/riscv/ri
For [x]vshuf instructions, if the index value in the selector exceeds 63, it
triggers
undefined behavior on LA464, but not on LA664. To ensure compatibility of these
two
tests on both LA464 and LA664, we have modified both tests to ensure that the
index
value in the selector does not exceed 63.
loongarch_expand_vec_cond_mask_expr generates 'subreg's of 'subreg's, which are
not supported
in gcc, it causes an ICE:
ice.c:55:1: error: unrecognizable insn:
55 | }
| ^
(insn 63 62 64 8 (set (reg:V4DI 278)
(subreg:V4DI (subreg:V4DF (reg:V4DI 273 [ vect__53.26 ]) 0) 0)) -1
On 11/27/23 19:57, Fei Gao wrote:
1. In find_if_header function, I found the following piece of codes:
if (!reload_completed && noce_find_if_block(...)), and find_if_header must
be called before noce_try_cond_zero_arith().
Ah good.
2. In noce_try_strore_flag_constants, new registers are
On 11/27/23 19:32, Fei Gao wrote:
op=[PLUS, MINUS, IOR, XOR, ASHIFT, ASHIFTRT, LSHIFTRT, ROTATE, ROTATERT]
SIGN_EXTEND, ZERO_EXTEND and SUBREG has been considered
to support SImode in 64-bit machine.
Let's defer these for now. We're supposed to be wrapping up work that
was posted before sta
>> "Jose E. Marchesi" writes:
>>> There are many places in GCC where alternative local sequences are
>>> tried in order to determine what is the cheapest or best alternative
>>> to use in the current target. When any of these sequences involve a
>>> libcall, the current implementation of emit_l
From: Pan Li
The exact_div requires the exactly multiple of the divider.
Unfortunately, the condition will be broken when zve32f in
some cases. For example,
potential_ew is 8
BYTES_PER_RISCV_VECTOR * lmul1 is [4, 4]
This patch would like to ensure the precondition of exact_div
when get_vec_mode
pr112743-0.c -> pr112743-1.c for consistent.
Otherwise LGTM. No need to send V2.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-11-29 14:37
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Bugfix for ICE in block move when zve32f
From: Pan Li
Committed with the test file rename, thanks Juzhe.
Pan
From: juzhe.zh...@rivai.ai
Sent: Wednesday, November 29, 2023 2:45 PM
To: Li, Pan2 ; gcc-patches
Cc: Li, Pan2 ; Wang, Yanzhang ;
kito.cheng
Subject: Re: [PATCH v1] RISC-V: Bugfix for ICE in block move when zve32f
pr112743-0.c -> pr112743
> On Linux/x86_64,
>
> f31a019d1161ec78846473da743aedf49cca8c27 is the first bad commit
> commit f31a019d1161ec78846473da743aedf49cca8c27
> Author: Jose E. Marchesi
> Date: Fri Nov 24 06:30:28 2023 +0100
>
> Emit funcall external declarations only if actually used.
>
> caused
>
> FAIL: gcc
On Mon, 2023-11-20 at 08:47 +0800, Xi Ruoyao wrote:
> The [1/5] patch is the PR112578 fix at
> https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637097.html.
> It has been changed to remove the nearbyint pattern (because nearbyint
> should not raise FE_INEXACT even if -ffp-int-builtin-inexact
On Mon, 27 Nov 2023, Tamar Christina wrote:
> Hi All,
>
> To make code review of the updates to add multiple exit supports to
> vectorizable_live_operation easier I've extracted the refactoring part to
> its own patch.
>
> This patch is a straight extract of the function with no functional chang
On Tue, 28 Nov 2023, Jeff Law wrote:
>
>
> On 11/28/23 00:50, Richard Biener wrote:
>
> >
> > There's no way to distinguish a partial vs. non-partial MEM on RTL and
> > while without the bogus MEM_ATTR the alias oracle pieces that
> > miscompiled the original case are fended off we still see t
在 2023/11/29 下午3:12, Xi Ruoyao 写道:
On Mon, 2023-11-20 at 08:47 +0800, Xi Ruoyao wrote:
The [1/5] patch is the PR112578 fix at
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637097.html.
It has been changed to remove the nearbyint pattern (because nearbyint
should not raise FE_INEXACT
On Tue, Nov 28, 2023 at 8:54 AM liuhongt wrote:
>
> For vec_contruct, the components must be live at the same time if
> they're not loaded from memory, when the number of those components
> exceeds available registers, spill happens. Try to account that with a
> rough estimation.
> ??? Ideally, we
On Wed, Nov 29, 2023 at 07:51:15AM +0100, Jose E. Marchesi wrote:
> > FAIL: gcc.c-torture/compile/libcall-2.c -O1 (test for excess errors)
> > FAIL: gcc.c-torture/compile/libcall-2.c -O2 -flto
> > -fno-use-linker-plugin -flto-partition=none (test for excess errors)
> > FAIL: gcc.c-torture/compil
101 - 176 of 176 matches
Mail list logo
