On Sun, Dec 10, 2023 at 4:00 PM xndcn wrote:
>
> Hi, I am a newbie in GCC, and I do not have access to git repo.
>
> I found some misleading error messages in verify_gimple_assign_single
> function of tree-cfg.cc. It prompt error "invalid RHS for gimple memory
> store: ", but it checks lhs in
On 12/11/23 03:09, juzhe.zh...@rivai.ai wrote:
> + if (shuffle_series (d))
> + return true;
>
>
> Could you rename it into shuffle_series_patterns ?
>
> Just to make naming consistent.
Done, going to push with that change in a while.
Regards
Robin
LGTM, thanks.
Regards
Robin
On Sun, Dec 10, 2023 at 10:30 AM Xi Ruoyao wrote:
>
> On Sun, 2023-12-10 at 01:21 -0800, Andrew Pinski wrote:
> > diff --git a/gcc/expr.cc b/gcc/expr.cc
> > index 6da51f2aca2..4686cacd22f 100644
> > --- a/gcc/expr.cc
> > +++ b/gcc/expr.cc
> > @@ -10209,8 +10209,9 @@ expand_expr_real_2 (sepops
On Sun, Dec 10, 2023 at 10:21 AM Andrew Pinski wrote:
>
> After r14-1655-g52c92fb3f40050 (and the other commits
> which touch zero_one_valued_p), we end up with a with
> `bool * a` but where the bool is an SSA name that might not
> have non-zero bits set on it (to 0x1) even though it
> does the
On Sat, 9 Dec 2023, Richard Sandiford wrote:
> Tamar Christina writes:
> > Hi All,
> >
> > What do people think about having the ability to force only the latch
> > connected
> > exit as the exit as a param? I.e. what's in the patch but as a param.
> >
> > I found this useful when debugging
On Sat, Dec 9, 2023 at 8:05 AM Alexandre Oliva wrote:
>
> Scratch the previous one, the "slightly different version" I had before
> it was not entirely broken due to unnecessary, suboptimal and incorrect
> use of ctz. Here I have yet another implementation of that loop that
> should perform
On Sat, Dec 9, 2023 at 3:25 AM Alexandre Oliva wrote:
>
>
> smallest_int_mode_for_size may abort when the requested mode is not
> available. Call int_mode_for_size instead, that signals the
> unsatisfiable request in a more graceful way.
>
> Regstrapped on x86_64-linux-gnu. Ok to install?
>
>
>
Hi Max!
Could you please consider to merge patch 1 and patch 3?
Along with https://sourceware.org/pipermail/binutils/2023-July/128478.html
Regards,
Alexey
This patch fixes the following ICE in VSETVL PASS:
bug.c:39:1: internal compiler error: Segmentation fault
39 | }
| ^
0x1ad5a08 crash_signal
../../../../gcc/gcc/toplev.cc:316
0x7f7f55feb90f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x218d7c7
On Wed, Nov 22, 2023 at 11:45 PM Jason Merrill wrote:
>
> Tested x86_64-pc-linux-gnu, OK for trunk?
OK
> -- 8< --
>
> -Waddress-of-packed-member, in addition to the documented warning about
> taking the address of a packed member, also warns about casting from
> a pointer to a TYPE_PACKED type
On Sat, Dec 9, 2023 at 3:09 AM Alexandre Oliva wrote:
>
> On Dec 7, 2023, Alexandre Oliva wrote:
>
> > Thanks for raising the issue. Maybe there should be at least a comment
> > there, and perhaps some asserts to check that pointer and reference
> > types don't make to indirect_parms.
>
>
> > >
> > > Hmm, but we're visiting them then? I wonder how you get along
> > > without doing adjustmens on the uses if you consider
> > >
> > > _1 = a < b;
> > > _2 = c != d;
> > > _3 = _1 | _2;
> > > if (_3 != 0)
> > > exit loop;
> > >
> > > thus a combined condition like
> since you are looking at TYPE_PRECISION below you want
> VECTOR_INTIEGER_TYPE_P here as well? The alternative
> would be to compare TYPE_SIZE.
>
> Some of the checks feel redundant but are probably good for
> documentation purposes.
>
> OK with using VECTOR_INTIEGER_TYPE_P
Actually, the data
Ping again.
On Fri, 2023-12-01 at 13:44 +0800, Xi Ruoyao wrote:
> Ping.
>
> On Fri, 2023-11-24 at 17:09 +0800, Xi Ruoyao wrote:
> > With -fno-fp-int-builtin-inexact, trunc is not allowed to raise
> > FE_INEXACT and it should produce an integral result (if the input is not
> > NaN or Inf). Thus
On 12/10/23 20:07, Jiufu Guo wrote:
I'm having a bit of a hard time convincing myself this is correct
though. I can't see how rewriting the load to read the source of the
prior store is unsafe. If that fixes a problem, then it would seem
like we've gone wrong before here -- perhaps failing
On 12/10/23 21:01, Fei Gao wrote:
On 2023-12-11 04:43 Jeff Law wrote:
On 12/5/23 01:12, Fei Gao wrote:
op=[ASHIFT, ASHIFTRT, LSHIFTRT, ROTATE, ROTATERT]
Conditional op, if zero
rd = (rc == 0) ? (rs1 op rs2) : rs1
-->
czero.nez rd, rs2, rc
op rd, rs1, rd
Conditional op, if non-zero
rd
On 12/10/23 15:38, Alexandre Oliva wrote:
On Dec 10, 2023, Jeff Law wrote:
On 12/8/23 19:25, Alexandre Oliva wrote:
On aarch64 -milp32, and presumably on other such targets, ptr can be
in a different mode than ptr_mode in the testcase. Cope with it.
Regstrapped on x86_64-linux-gnu, also
On 12/5/23 01:12, Fei Gao wrote:
SIGN_EXTEND, ZERO_EXTEND and SUBREG has been considered
to support SImode in 64-bit machine.
Co-authored-by: Xiao Zeng
gcc/ChangeLog:
* ifcvt.cc (noce_cond_zero_binary_op_supported): add support for
extension
On 12/5/23 01:12, Fei Gao wrote:
op=[PLUS, MINUS, IOR, XOR, ASHIFT, ASHIFTRT, LSHIFTRT, ROTATE, ROTATERT, AND]
Co-authored-by: Xiao Zeng
gcc/ChangeLog:
* ifcvt.cc (noce_cond_zero_shift_op_supported): check if OP is shift
like operation
> diff --git a/gcc/testsuite/g++.dg/tree-ssa/pr83518.C
> b/gcc/testsuite/g++.dg/tree-ssa/pr83518.C
> index b8a2bd1ebbd..6f2fc56c82c 100644
> --- a/gcc/testsuite/g++.dg/tree-ssa/pr83518.C
> +++ b/gcc/testsuite/g++.dg/tree-ssa/pr83518.C
> @@ -24,4 +24,4 @@ unsigned test()
>return sum;
> }
>
>
2023-12-11 13:05 Kito Cheng wrote:
>I am happy with this change now, however I didn't see any place call avail
>function yet? Do I miss something? Are you planning to send follow up
>patches to add that?
>If so, LGTM.
Yes, the crypto vector will determine whether to register the
LGTM
On Mon, Dec 11, 2023 at 1:19 PM Juzhe-Zhong wrote:
>
> This patch fixes multiple ICEs in full coverage testing:
>
> cc1: internal compiler error: in riscv_legitimize_poly_move, at
> config/riscv/riscv.cc:2456^M
> 0x1fd8d78 riscv_legitimize_poly_move^M
>
This patch fixes multiple ICEs in full coverage testing:
cc1: internal compiler error: in riscv_legitimize_poly_move, at
config/riscv/riscv.cc:2456^M
0x1fd8d78 riscv_legitimize_poly_move^M
../../../../gcc/gcc/config/riscv/riscv.cc:2456^M
0x1fd9518 riscv_legitimize_move(machine_mode,
On 12/5/23 01:12, Fei Gao wrote:
Take the following case for example.
CFLAGS: -march=rv64gc_zbb_zicond -mabi=lp64d -O2
long
test_AND_ceqz (long x, long y, long z, long c)
{
if (c)
x = y & z;
else
x = y;
return x;
}
Before patch:
and a2,a1,a2
czero.eqz a0,a2,a3
I am happy with this change now, however I didn't see any place call avail
function yet? Do I miss something? Are you planning to send follow up
patches to add that?
If so, LGTM.
On 2023-12-11 04:43 Jeff Law wrote:
>
>
>
>On 12/5/23 01:12, Fei Gao wrote:
>> op=[ASHIFT, ASHIFTRT, LSHIFTRT, ROTATE, ROTATERT]
>>
>> Conditional op, if zero
>> rd = (rc == 0) ? (rs1 op rs2) : rs1
>> -->
>> czero.nez rd, rs2, rc
>> op rd, rs1, rd
>>
>> Conditional op, if non-zero
>> rd = (rc !=
Hi,
For constant building e.g. r120=0x, which does not fit 'li or lis',
'pli' is used to build this constant via 'emit_move_insn'.
While for a complicated constant, e.g. 0xULL, when using
'rs6000_emit_set_long_const' to split the constant recursively, it fails to
use
Hi,
Trunk gcc supports more constants to be built via two instructions:
e.g. "li/lis; xori/xoris/rldicl/rldicr/rldic".
And then num_insns_constant should also be updated.
Function "rs6000_emit_set_long_const" is used to build complicated
constants; and "num_insns_constant_gpr" is used to compute
Hi,
Thanks again for your kind review!
Jeff Law writes:
> On 12/8/23 00:18, Jiufu Guo wrote:
>>
>> Hi,
>>
>> Jeff Law writes:
>>
>>> On 12/6/23 02:27, Jiufu Guo wrote:
Hi,
The issue mentioned in PR112525 would be able to be handled by
updating dse.cc to treat
Hi,
This patch cleans up pre-checking of expand_block_compare. It does
1. Assert only P7 above can enter this function as it's already guard
by the expand.
2. Return false when optimizing for size.
3. Remove P7 CPU test as only P7 above can enter this function and P7
LE is excluded by
On Sun, Dec 10, 2023 at 10:19 AM Jason Merrill wrote:
>
> On 12/7/23 00:11, Ken Matsui wrote:
> > This patch series optimizes type traits compilation performance by
> > implementing built-in type traits and using them in libstdc++.
> >
> > Changes in v26:
> >
> > * Rebased on top of trunk.
On 12/10/23 21:04, Nathaniel Shead wrote:
On Sat, Dec 09, 2023 at 03:40:44PM -0500, Jason Merrill wrote:
On 11/27/23 06:07, Nathaniel Shead wrote:
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2023-October/634626.html.
I've been made aware since constructing this patch of CWG2820, which
+ if (shuffle_series (d))
+ return true;
Could you rename it into shuffle_series_patterns ?
Just to make naming consistent.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-12-09 21:18
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
On Sat, Dec 09, 2023 at 03:40:44PM -0500, Jason Merrill wrote:
> On 11/27/23 06:07, Nathaniel Shead wrote:
> > Ping for https://gcc.gnu.org/pipermail/gcc-patches/2023-October/634626.html.
> >
> > I've been made aware since constructing this patch of CWG2820, which has
> > a proposed resolution
Hi,
The patch corrects the definition of
TARGET_EFFICIENT_OVERLAPPING_UNALIGNED and change its name to a
comprehensible name.
Bootstrapped and tested on x86 and powerpc64-linux BE and LE with no
regressions. Is this OK for trunk?
Thanks
Gui Haochen
ChangeLog
rs6000: Correct definition of
On 12/4/23 00:36, Jakub Jelinek wrote:
On Fri, Dec 01, 2023 at 10:43:57AM -0700, Sandra Loosemore wrote:
On 12/1/23 10:33, Jakub Jelinek wrote:
Shall we tweak that somehow? If the argument names are unimportant, perhaps
it is fine to leave that out, but shouldn't we always use @var{...}
FYI. I have the some failures as juzhe mentioned, with the emulator qemu
version qemu-riscv64 version 8.1.93 (v8.2.0-rc3). The entire log may look like
below:
Executing on host:
/home/box/panli/riscv-gnu-toolchain/build-gcc-newlib-stage2/gcc/xgcc
Patch v3: Fix typo and remove the modification of rvv.exp.
Patch v2: Using variadic macro and add the dependency into t-riscv.
In order to add other extension about vector,this patch add
unsigned int (*avail) (void) into function_group_info to determine
whether to register the intrinsic based on
Hi David,
On Fri, Dec 08, 2023 at 06:35:56PM -0500, David Malcolm wrote:
> On Tue, 2023-11-21 at 23:43 +, Joseph Myers wrote:
> > On Tue, 21 Nov 2023, Tobias Burnus wrote:
> >
> > > On 21.11.23 14:57, David Malcolm wrote:
> > > > On Tue, 2023-11-21 at 02:09 +0100, Hans-Peter Nilsson wrote:
>
On Sun, Dec 10, 2023 at 2:38 PM Alexandre Oliva wrote:
>
> On Dec 10, 2023, Jeff Law wrote:
>
> > On 12/8/23 19:25, Alexandre Oliva wrote:
> >> On aarch64 -milp32, and presumably on other such targets, ptr can be
> >> in a different mode than ptr_mode in the testcase. Cope with it.
> >>
On Dec 10, 2023, Jeff Law wrote:
> On 12/8/23 19:25, Alexandre Oliva wrote:
>> On aarch64 -milp32, and presumably on other such targets, ptr can be
>> in a different mode than ptr_mode in the testcase. Cope with it.
>> Regstrapped on x86_64-linux-gnu, also tested the new test on
>> aarch64-elf.
> "Jakub" == Jakub Jelinek writes:
Jakub> LGTM for GCC (but it needs a ChangeLog entry).
Oops, yeah -- I am out of the habit of writing those.
I'll add one before I push this.
Tom
On 12/5/23 01:12, Fei Gao wrote:
op=[ASHIFT, ASHIFTRT, LSHIFTRT, ROTATE, ROTATERT]
Conditional op, if zero
rd = (rc == 0) ? (rs1 op rs2) : rs1
-->
czero.nez rd, rs2, rc
op rd, rs1, rd
Conditional op, if non-zero
rd = (rc != 0) ? (rs1 op rs2) : rs1
-->
czero.eqz rd, rs2, rc
op rd, rs1, rd
On Sat, Dec 09, 2023 at 01:56:53PM -0700, Tom Tromey wrote:
> I've reimplemented the .debug_names code in GDB -- it was quite far
> from being correct, and the new implementation is much closer to what
> is specified by DWARF.
>
> However, the new writer in GDB needs to emit some symbol
From: Andrew Pinski
The check for the type seems unnecessary and gets in the way sometimes.
Also with a patch I am working on for match.pd, it causes a failure to happen.
Before my patch the IR was:
_1 = BIT_FIELD_REF ;
_2 = _1 & 1;
_3 = _2 != 0;
_4 = (int) _3;
__analyzer_eval (_4);
This patch set fixes PR 111972 and the fallout from it.
The first patch is a fix for -fanalyzer which I had implemented with
a different version of the 2nd patch while I was working at Marvell.
And the 2nd patch fixes the issue by having the following as
canonical forms:
* `a ^ 1` is the
When I moved two_value to match.pd, I removed the check for the {0,+-1}
as I had placed it after the {0,+-1} case for cond in match.pd.
In the case of {0,+-1} and non boolean, before we would optmize those
case to just `(convert)a` but after we would get `(convert)(a != 0)`
which was not handled
Multi-register svread_za and svwrite_za are implemented using one
pattern per register count, with the register contents being bitcast
on entry (for writes) or return (for reads). Previously we relied
on subregs for this, with the subreg for reads being handled by
target-independent code. But
VNx16QI (the SVE register byte mode) is the only SVE mode for which
LD1 and LDR result in the same register layout for big-endian. It is
therefore the only mode for which we allow LDR and STR to be used for
big-endian SVE moves.
The SME support sometimes needs to use LDR and STR to save and
The z0_z23 tests rely on being able to propagate:
(1) set of double-register z0-z1
(2) copy of z0 to z28
(3) use of z28
to a use of z0. On LE targets it's regcprop that does this.
But regcprop punts on (2) because of:
https://gcc.gnu.org/pipermail/gcc-patches/2002-July/081990.html
Big-endian targets need to save Z8-Z15 in the same order as
the registers would appear for D8-D15, because the layout is
mandated by the EH ABI. BE targets therefore use ST1D instead
of the normal STR for those registers (but not for others).
That difference is already tested elsewhere and isn't
The .cfi scans in these tests failed for *-elf targets because
those targets don't enable .eh_frame info by default.
Tested on aarch64-linux-gnu and aarch64_be-elf, pushed to trunk.
Richard
gcc/testsuite/
* gcc.target/aarch64/sme/call_sm_switch_1.c: Add -funwind-tables.
*
On 11/30/23 10:46, Patrick Palka wrote:
On Fri, 27 Oct 2023, Patrick Palka wrote:
On Fri, 27 Oct 2023, Jason Merrill wrote:
On 10/27/23 15:55, Patrick Palka wrote:
With the previous two patches in place, we can now extend our
deletedness diagnostic to note the other considered candidates,
On 11/30/23 16:36, Marek Polacek wrote:
On Thu, Nov 30, 2023 at 10:30:44PM +0100, Jakub Jelinek wrote:
On Thu, Nov 30, 2023 at 10:27:33PM +0100, Florian Weimer wrote:
* Jakub Jelinek:
On Thu, Nov 30, 2023 at 04:15:26PM -0500, Marek Polacek wrote:
On Thu, Nov 30, 2023 at 10:11:31PM +0100,
On 12/10/23 10:22, waffl3x wrote:
On Friday, December 8th, 2023 at 12:25 PM, Jason Merrill
wrote:
On 12/6/23 02:33, waffl3x wrote:
Here is the next version, it feels very close to finished. As before, I
haven't ran a bootstrap or the full testsuite yet but I did run the
explicit-obj tests
On 11/23/23 08:40, Nathaniel Shead wrote:
Sorry, I just noticed I hadn't actually filled in the changelog. It
should say "Clear DECL_UNINSTANTIATED_TEMPLATE_FRIEND_P."
OK with that change.
On Thu, Nov 23, 2023 at 11:54 PM Nathaniel Shead
wrote:
Bootstrapped and regtested on
On 12/10/23 05:22, Richard Biener wrote:
Am 09.12.2023 um 21:13 schrieb Jason Merrill :
On 11/2/23 21:18, Nathaniel Shead wrote:
Bootstrapped and regtested on x86-64_pc_linux_gnu.
I'm not entirely sure if the change I made to have destructors clobber with
CLOBBER_EOL instead of CLOBBER_UNDEF
On 12/8/23 00:18, Jiufu Guo wrote:
Hi,
Jeff Law writes:
On 12/6/23 02:27, Jiufu Guo wrote:
Hi,
The issue mentioned in PR112525 would be able to be handled by
updating dse.cc to treat arg_pointer_rtx similarly with frame_pointer_rtx.
On 12/7/23 00:11, Ken Matsui wrote:
This patch series optimizes type traits compilation performance by
implementing built-in type traits and using them in libstdc++.
Changes in v26:
* Rebased on top of trunk.
* Moved is_function_v under is_const_v.
* Isolated patches
On 12/8/23 19:25, Alexandre Oliva wrote:
On aarch64 -milp32, and presumably on other such targets, ptr can be
in a different mode than ptr_mode in the testcase. Cope with it.
Regstrapped on x86_64-linux-gnu, also tested the new test on
aarch64-elf. Ok to install?
for gcc/ChangeLog
On 12/8/23 19:48, Alexandre Oliva wrote:
Comply with dubious doc warning that after an @xref there must be a
comma or a period, not a close parentheses.
Build-testing on x86_64-linux-gnu now. Ok to install?
for gcc/ChangeLog
* doc/invoke.texi (multiflags): Add period after
On 12/10/23 07:56, Roger Sayle wrote:
I'd like to ping my patch for PR rtl-optimization/112380.
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636203.html
Sorry, I'd hoped Segher would chime in. The first simple patch &
testcase are OK and can go in immediately. It'll take more
This patch adds uaddv/usubv support on the H8 port to speed up those
pesky builtin-overflow tests. It's a variant of something I'd been
running for a while -- the major change between the old approach I'd
been using and this patch is this version does not expose the CC
register until after
Inspired by Roger's work on the ARC port, this patch provides a
define_and_split pattern to optimize sign extended bitfields starting at
position 0 using an approach that doesn't require shifting.
It then builds on that to provide another define_and_split pattern to
support arbitrary signed
Various approaches are used to optimize extracting a sign extended
single bit bitfield. The length computation of 10 bytes was
conservatively correct, but inaccurate.
In particular when the bit we want is in the low half word we don't need
the move high half to low half instruction.
This fixes the length computation for logical shifts on the H8/SX.
The H8/SX has a richer set of logical shifts compared to early parts in
the H8 family. It has special 2 byte instructions for shifts by power
of two immediate values as well as a special 4 byte shift by other
immediate
> Am 10.12.2023 um 12:21 schrieb Alexander Monakov :
>
>
> On Sun, 10 Dec 2023, Richard Biener wrote:
>
>>> It seems wrong to me: CLOBBER_EOL is documented to mean that the storage is
>>> expiring at that point as well, which a (pseudo-)destructor does not imply;
>>> it's perfectly valid to
On 12/5/23 06:59, Roger Sayle wrote:
This patch improves the code generated for bitfield sign extensions on
ARC cpus without a barrel shifter.
Compiling the following test case:
int foo(int x) { return (x<<27)>>27; }
with -O2 -mcpu=em, generates two loops:
foo:mov lp_count,27
gcc/ChangeLog:
* tree-cfg.cc (verify_gimple_assign_single): Fix misleading error, from
"invalid LHS ..." to "invalid RHS ..."
Signed-off-by: xndcn
---
gcc/tree-cfg.cc | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/gcc/tree-cfg.cc b/gcc/tree-cfg.cc
index
Sorry about the attachment, re-paste here
On Friday, December 8th, 2023 at 12:25 PM, Jason Merrill
wrote:
>
>
> On 12/6/23 02:33, waffl3x wrote:
>
> > Here is the next version, it feels very close to finished. As before, I
> > haven't ran a bootstrap or the full testsuite yet but I did run the
> > explicit-obj tests which completed
Hi, I am a newbie in GCC, and I do not have access to git repo.
I found some misleading error messages in verify_gimple_assign_single
function of tree-cfg.cc. It prompt error "invalid RHS for gimple memory
store: ", but it checks lhs in fact.
From 72fc4abe635c3e35ac31457aeba92b528f0574fe Mon Sep
I'd like to ping my patch for PR rtl-optimization/112380.
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636203.html
For those unfamiliar with the (clobber (const_int 0)) idiom used by
combine, I'll explain a little of the ancient history...
Back before time, in the prehistory of
Thanks for the patch and sorry for the slow review.
I can only comment on the usage of SVE, rather than on the scaffolding
around it. Hopefully Jonathan or others can comment on the rest.
The main thing that worries me is:
#if _GLIBCXX_SIMD_HAVE_SVE
constexpr inline int
Victor Do Nascimento writes:
> In the Linux kernel, u64/s64 are [un]signed long long, not [un]signed
> long. This means that when the `arm_neon.h' header is used by the
> kernel, any use of the `uint64_t' / `in64_t' types needs to be
> correctly cast to the correct `__builtin_aarch64_simd_di' /
On Sat, 25 Nov 2023 at 13:52, Cassio Neri wrote:
>
> The following invoke signed integer overflow (UB) [1]:
>
> month + months{MAX} // where MAX is the maximum value of months::rep
> month + months{MIN} // where MIN is the maximum value of months::rep
> month - months{MIN} // where MIN
The following invoke signed integer overflow (UB) [1]:
month + months{MAX} // where MAX is the maximum value of months::rep
month + months{MIN} // where MIN is the maximum value of months::rep
month - months{MIN} // where MIN is the minimum value of months::rep
weekday + days {MAX}
On Sun, 10 Dec 2023, Richard Biener wrote:
> > It seems wrong to me: CLOBBER_EOL is documented to mean that the storage is
> > expiring at that point as well, which a (pseudo-)destructor does not imply;
> > it's perfectly valid to destroy an object and then create another in the
> > same
> Am 09.12.2023 um 21:13 schrieb Jason Merrill :
>
> On 11/2/23 21:18, Nathaniel Shead wrote:
>> Bootstrapped and regtested on x86-64_pc_linux_gnu.
>> I'm not entirely sure if the change I made to have destructors clobber with
>> CLOBBER_EOL instead of CLOBBER_UNDEF is appropriate, but
On Sun, 2023-12-10 at 01:21 -0800, Andrew Pinski wrote:
> diff --git a/gcc/expr.cc b/gcc/expr.cc
> index 6da51f2aca2..4686cacd22f 100644
> --- a/gcc/expr.cc
> +++ b/gcc/expr.cc
> @@ -10209,8 +10209,9 @@ expand_expr_real_2 (sepops ops, rtx target,
> machine_mode tmode,
> /* Expand X*Y as
After r14-1655-g52c92fb3f40050 (and the other commits
which touch zero_one_valued_p), we end up with a with
`bool * a` but where the bool is an SSA name that might not
have non-zero bits set on it (to 0x1) even though it
does the non-zero bits would be 0x1.
The case of coremarks, it is only
> Yes, GCC/nvptx ICEs gone with that, thanks!
And on darwin as well, test results are back to the same state as before.
Thanks!
FX
The problem here is when f16 is enabled, movbf_aarch64 accepts `Ufc`
as a constraint:
[ w, Ufc ; fconsts , fp16 ] fmov\t%h0, %1
But that is for fmov values and in this case fmov represents f16 rather than
bfloat16 values.
This means we would get the wrong value in the register.
84 matches
Mail list logo
