Applied this tweak to the 16-bit and 32-bit comparisons.
Johann
--
gcc/
* config/avr/constraints.md (YMM): New constraint.
* config/avr/avr.md (cmp3, *cmp3)
(cbranch4_insn): Allow YMM where M is allowed.
(cbranch4_insn): Split to a test of the
high part
I have sent the following page in February (Stage 4) and didn't want to
commit it back then. But for Stage 1, it should be fine ... I like to
commit it tomorrow, unless there are comments suggesting other.
Attached is the unchanged patch and I also added a "diff -w -U1" patch
as
perand:DWI 0 "register_operand" "=,")
> (ashift:DWI (match_operand:DWI 1 "reg_or_pm1_operand" "0n,r")
> (match_operand:QI 2 "nonmemory_operand" "c,c")))
>
> The patch fixes the mismatch between con
gcc/ChangeLog:
* common/config/i386/cpuinfo.h (get_available_features): Handle
avx10.2.
* common/config/i386/i386-common.cc
(OPTION_MASK_ISA2_AVX10_2_256_SET): New.
(OPTION_MASK_ISA2_AVX10_2_512_SET): Ditto.
(OPTION_MASK_ISA2_AVX10_1_256_UNSET):
weeks, we plan to upstream ymm rounding part first,
following by new instructions. After all of them upstreamed, we will
also upstream several patches optimizing codegen with new AVX10.2
instructions.
The patch coming next is the initial support for AVX10.2. This patch
will be the foundation of all
on x86_64-unknown-linux-gnu.
> >
> > I've CCed people messing with release_pages; This doesn't really
> > address PR114563 but I thought I post this patch anyway - the
> > actual issue we run into for the PR is the linear search of
> > G.free_pages when that list bec
also need to make sure `a`, `b` and the resulting types
> are all
> the same for the same reason as the previous patch.
>
> I updated (well added) to the testcases to make sure there are the right
> amount of
> comparisons left.
>
> Changes since v1:
> * v2: Fixed the t
t; >
> > As Andrew pointed out in PR116148, fam-in-union-alone-in-struct-2.c
> > was designed for little-endian, the recent commit r15-2403 made it
> > be tested with running on BE and PR116148 got exposed.
> >
> > This patch is to adjust the expected data for members
Hi Jerry,
looks fine to me. The change is so small that I see no harm, ok to merge.
Thanks for the patch.
- Andre
On Wed, 31 Jul 2024 09:08:54 -0700
Jerry D wrote:
> I plan to push this soon to hopefully fix some test breakage on some
> architetures. It is simple and obvious. I did n
rand:DWI 1 "reg_or_pm1_operand" "0n,r")
> (match_operand:QI 2 "nonmemory_operand" "c,c")))
>
> The patch fixes the mismatch between constraint and predicate.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for
On Thu, Aug 1, 2024 at 10:03 AM Kong, Lingling wrote:
>
>
>
> > -Original Message-
> > From: Liu, Hongtao
> > Sent: Thursday, August 1, 2024 9:35 AM
> > To: Kong, Lingling ; gcc-patches@gcc.gnu.org
> > Cc: Wang, Hongyu
> > Subject: RE: [
; > goto ; [41.00%]
> > > > else
> > > > goto ; [59.00%]
> > > >[local count: 440234144]:\
> > > > _4 = -x_3(D);
> > > >[local count: 1073741824]:
> > > > # _2 = PHI <_4(3), x_3(D)(2)>
> >
t;>> vec_test_lsbb_all_zeros built-ins are not documented in the GCC
>>> documentation file.
>>>
>>> The following patch adds missing documentation for the
>>> vec_test_lsbb_all_ones and, vec_test_ls
t; * gcc.target/riscv/pr105314-rtl.c: Skip zicond.
>>>> * gcc.target/riscv/pr105314-rtl32.c: Dotto.
>>>> * gcc.target/riscv/pr105314.c: Dotto.
>>> Why do you want to skip zicond for this test?
>> Yes, I should provide as detaile
> -Original Message-
> From: Liu, Hongtao
> Sent: Thursday, August 1, 2024 9:35 AM
> To: Kong, Lingling ; gcc-patches@gcc.gnu.org
> Cc: Wang, Hongyu
> Subject: RE: [PATCH] i386: Fix memory constraint for APX NF
>
>
>
> > -Original Message-
&
.c: Dotto.
Why do you want to skip zicond for this test?
Yes, I should provide as detailed a description as possible for each submitted
patch.
Jeff
riscv64-unknown-linux-gnu-gcc -O2 -march=rv64gc_zicond -mabi=lp64d
../gcc/testsuite/gcc.target/riscv/pr105314.c -fdump-rtl-ce1 -S -o pr105314.c.S
> -Original Message-
> From: Kong, Lingling
> Sent: Thursday, August 1, 2024 9:30 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Liu, Hongtao ; Wang, Hongyu
>
> Subject: [PATCH] i386: Fix memory constraint for APX NF
>
> The je constraint should be used for APX N
The je constraint should be used for APX NDD ADD with register source
operand. The jM is for APX NDD patterns with immediate operand.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
* config/i386/i386.md (nf_mem_constraint): Fixed the constraint
r revh.{2w,d} instructions.
This optimization is really ingenious and I have no problem.
I also haven't figured out how to generate revb.4h or revh. {2w,d}.
I think we can merge this patch first.
Pushed r15-2433.
Ok. Thanks!
FWIW I tried a naive pattern for revh.2w:
(set (match_
I wrote this support file to help me debug Tcl issues in the
testsuite.
Adding a call to:
print_stack_backtrace
somewhere in a .exp file (along with "load_lib print-stack.exp") leads
to the interpreter printing a backtrace in a form that e.g. Emacs can
consume, with filename:linenum: lines,
> Sorry for the slow review.
>
> Pengxuan Zheng writes:
> > This patch improves the Advanced SIMD popcount expansion by using SVE
> > if available.
> >
> > For example, GCC currently generates the following code sequence for V2DI:
> > cnt v31.16b
This patch improves the Advanced SIMD popcount expansion by using SVE if
available.
For example, GCC currently generates the following code sequence for V2DI:
cnt v31.16b, v31.16b
uaddlp v31.8h, v31.16b
uaddlp v31.4s, v31.8h
uaddlp v31.2d, v31.4s
However, by using SVE, we can
This patch improves the Advanced SIMD popcount expansion by using SVE if
available.
For example, GCC currently generates the following code sequence for V2DI:
cnt v31.16b, v31.16b
uaddlp v31.8h, v31.16b
uaddlp v31.4s, v31.8h
uaddlp v31.2d, v31.4s
However, by using SVE, we can
This has been approved and will be committed if there's no other comments in a
day.
ere too.
This still produces better code than the original case and in many cases (x !=
y) will
still reduce to either false or true.
With this change we also need to make sure `a`, `b` and the resulting types are
all
the same for the same reason as the previous patch.
I updated (well added) to the te
On Mon, 22 Jul 2024, Xi Ruoyao wrote:
> On Mon, 2024-05-06 at 12:45 +0800, Xi Ruoyao wrote:
> > In GCC 14.1-rc1, there are two new (comparing to GCC 13) failures if
> > the build is configured --enable-default-pie. Let's fix them.
> >
> > Tested on x86_64-linux-gnu. Ok for trunk and
0 and nanosecond < 1.
Thanks for the patch, it looks correct. The futex syscall returns
EINVAL in this case, which we don't handle, so the caller loops and
keeps calling the syscall again, which fails again the same way.
I think it would be good to mention EINVAL, e.g. "will raise an EINVAL
error
On 7/31/24 3:56 PM, Arsen Arsenović wrote:
Okay, I've reworked it, and it built and passed coroutine tests.
Regstrapping overnight. Is the following OK with you?
OK.
-- >8 --
By doing so, we can get diagnostics in template decls when we know we
can. For instance, in the
Kewen:
On 7/29/24 3:21 AM, Kewen.Lin wrote:
+@smallexample
+@exdent vector signed __int128 vec_sld (vector signed __int128,
+vector signed __int128, const unsigned int);
+@exdent vector unsigned __int128 vec_sld (vector unsigned __int128,
+vector unsigned __int128, const unsigned int);
On Sat, 13 Jul 2024, Martin Uecker wrote:
> This marks structures which include a byte array
> as typeless storage for all C language modes.
>
>
> Bootstrapped and regression tested on x86_64.
>
>
>
>
> c: Add support for byte arrays in C2Y
>
> To get correct aliasing behavior
On Wed, Jul 31, 2024 at 3:42 AM Mariam Arutunian
wrote:
>
> Gives an opportunity to execute the code on bit level,
>assigning symbolic values to the variables which don't have initial values.
>Supports only CRC specific operations.
>
>Example:
>
>uint8_t crc;
>uint8_t pol
From: Mikael Morin
Tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Add the tests covering the various cases for which we are about to implement
inline expansion of MINLOC and MAXLOC. Those are cases where the DIM
argument is not present.
PR fortran/90608
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Enable the generation of inline code for MINLOC/MAXLOC when argument ARRAY
is of integral type, DIM is not present, and MASK is present and is scalar
(only absent MASK or rank 1 ARRAY were inlined before).
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Continue the second set of loops where the first one stopped in the
generated inline MINLOC/MAXLOC code in the cases where the generated code
contains two sets of loops. This fixes a regression that was
From: Mikael Morin
The next patch will need reindenting of the array bound check generation
code. This outlines it to its own function beforehand, reducing the churn
in the next patch.
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
gcc/fortran/ChangeLog:
* tr
predicate which evolves with
the patches.
They have been generated on top of the patch:
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657959.html
Mikael Morin (8):
fortran: Add tests covering inline MINLOC/MAXLOC without DIM [PR90608]
fortran: Disable frontend passes for inlinable MINLOC
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Enable inline code generation for the MINLOC and MAXLOC intrinsic, if the
DIM argument is not present and ARRAY has rank 1. This case is similar to
the case where the result is scalar (DIM present and rank 1
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Enable generation of inline code for the MINLOC and MAXLOC intrinsic,
if the ARRAY argument is of integral type and of any rank (only the rank 1
case was previously inlined), and neither DIM nor MASK arguments
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Enable generation of inline MINLOC/MAXLOC code in the case where DIM
is not present, and either ARRAY is of floating point type or MASK is an
array. Those cases are the remaining bits to fully support
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Disable rewriting of MINLOC/MAXLOC expressions for which inline code
generation is supported. Update the gfc_inline_intrinsic_function_p
predicate (already existing) for that, with the current state of
Okay, I've reworked it, and it built and passed coroutine tests.
Regstrapping overnight. Is the following OK with you?
-- >8 --
By doing so, we can get diagnostics in template decls when we know we
can. For instance, in the following:
awaitable g();
template
task f()
{
ue.
> >
> > With this change we also need to make sure `a`, `b` and the resulting types
> > are all
> > the same for the same reason as the previous patch.
> >
> > I updated (well added) to the testcases to make sure there are the right
> > amount of
> >
Jennifer Schmitz writes:
> Thanks for the feedback! I updated the patch based on your comments, more
> detailed comments inline below. The updated version was bootstrapped and
> tested again, no regression.
> Best,
> Jennifer
>
> From 89936b7bc2de7a1e4bc55c3a1e8d5e6ac0de579
/ChangeLog:
>
>* config/aarch64/aarch64-protos.h (struct sve_vec_cost): Add
>gather_load_x32_init_cost and gather_load_x64_init_cost.
>* config/aarch64/aarch64.cc (aarch64_vector_costs): Add
>m_sve_gather_scatter_init_cost.
>(aarch64_vector_c
Jason Merrill writes:
> On 7/31/24 6:54 AM, Arsen Arsenović wrote:
>> Tested on x86_64-pc-linux-gnu. OK for trunk?
>> TIA, have a lovely day.
>> -- >8 --
>> By doing so, we can get diagnostics in template decls when we know we
>> can. For instance, in the following:
>>
the recent commit r15-2403 made it
> be tested with running on BE and PR116148 got exposed.
>
> This patch is to adjust the expected data for members in with_fam_2_v
> and with_fam_3_v by considering endianness, also update with_fam_3_v.b[1]
> from 0x5f6f7f7f to 0x5f6f7f8
Tamar Christina writes:
> @@ -289,6 +293,12 @@ struct sve_vec_cost : simd_vec_cost
>const int gather_load_x32_cost;
>const int gather_load_x64_cost;
>
> + /* Additional loop initialization cost of using a gather load instruction.
> The x32
Sorry for the trivia, but: long line.
> +
On 7/31/24 6:54 AM, Arsen Arsenović wrote:
Tested on x86_64-pc-linux-gnu. OK for trunk?
TIA, have a lovely day.
-- >8 --
By doing so, we can get diagnostics in template decls when we know we
can. For instance, in the following:
awaitable g();
template
task f()
{
Arsen Arsenović writes:
> We haven't been applying our settings to our C++. This patch fixes
> that.
>
> Sadly, it seems that the only documented way to apply settings to
> multiple modes is to repeat them. I thought that we can provide a list
> of modes to app
Kewen:
On 7/31/24 2:12 AM, Kewen.Lin wrote:
Hi Carl,
on 2024/7/27 06:56, Carl Love wrote:
GCC maintainers:
Per a report from a user, the existing vec_test_lsbb_all_ones and,
vec_test_lsbb_all_zeros built-ins are not documented in the GCC documentation
file.
The following patch adds
has the correct non-widened
mode. For the scalar variants, however, the same operand has a scalar
mode which obviously only has one unit. This makes us choose VL = 1
leaving three elements undisturbed (so potentially -1). Those end up
in the reduction causing the wrong result.
This patch adjusts
eric.h: Update.
* config/aarch64/tuning_models/generic_armv8_a.h: Update.
* config/aarch64/tuning_models/generic_armv9_a.h: Update.
* config/aarch64/tuning_models/neoverse512tvb.h: Update.
* config/aarch64/tuning_models/neoversen2.h: Update.
* config/aarch64/tunin
The testcase contains the constant:
arr2 = svreinterpret_u8(svdup_u32(0x0a0d5c3f));
which was initially hoisted by hand, but which gimple optimisers later
propagated to each use (as expected). The constant was then expanded
as a load-and-duplicate from the constant pool. Normally that load
Jonathan Wakely writes:
> On Wed, 31 Jul 2024 at 16:45, Sam James wrote:
>>
>> We already have a valid 'dg-do run' (- vs _) directive, so drop the bogus
>> one.
>>
>> libstdc++-v3/ChangeLog:
>> * testsuite/28_regex/traits/char/translate.cc: Drop bogus 'dg_do
>> run'.
>> ---
>> OK? No
I plan to push this soon to hopefully fix some test breakage on some
architetures. It is simple and obvious. I did not get any feedback on
this and I do not have access to the machines in question.
Regression tested on linux-x86-64.
Regards,
Jerry
commit
On Wed, 31 Jul 2024 at 16:45, Sam James wrote:
>
> We already have a valid 'dg-do run' (- vs _) directive, so drop the bogus
> one.
>
> libstdc++-v3/ChangeLog:
> * testsuite/28_regex/traits/char/translate.cc: Drop bogus 'dg_do run'.
> ---
> OK? No regressions in the logs but it's a bit
gt; where we'd like to e.g. value number some SF/DF/XF etc. mode loads
> > > > > and some
> > > > > subsequent loads from the same address with different mode but same
> > > > > size
> > > > > the same and replace say int or
. For the scalar variants, however, the same operand has a scalar
mode which obviously only has one unit. This makes us choose VL = 1
leaving three elements undisturbed (so potentially -1). Those end up
in the reduction causing the wrong result.
This patch adjusts the mode_idx just for the scalar variants
On Wed, Jul 31, 2024 at 3:40 PM Richard Biener wrote:
>
> The following implements the hook, excluding x87 modes for scalar
> and complex float modes.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
>
> OK this way?
>
> Thanks,
> Richard.
>
> * i386.cc
We already have a valid 'dg-do run' (- vs _) directive, so drop the bogus
one.
libstdc++-v3/ChangeLog:
* testsuite/28_regex/traits/char/translate.cc: Drop bogus 'dg_do run'.
---
OK? No regressions in the logs but it's a bit weird that it's got a proper
directive with a target specifier so
> > > >static constexpr bool foo () { return true; }
> > > > > > > };
> > > > > > >
> > > > > > > static_assert (S::foo ());
> > > > > > >
> > > > > > > somehow the template parameter mappi
eally
> address PR114563 but I thought I post this patch anyway - the
> actual issue we run into for the PR is the linear search of
> G.free_pages when that list becomes large but a requested allocation
> cannot be served from it.
>
> PR middle-end/114563
>
We haven't been applying our settings to our C++. This patch fixes
that.
Sadly, it seems that the only documented way to apply settings to
multiple modes is to repeat them. I thought that we can provide a list
of modes to apply, but that seems to not be the case (even thought it
happened
On Wed, 31 Jul 2024 at 15:42, Björn Schäpers wrote:
>
> Am 30.07.2024 um 11:13 schrieb Jonathan Wakely:
> > On Sun, 24 Mar 2024 at 21:34, Björn Schäpers wrote:
> >>
> >> From: Björn Schäpers
> >>
> >> This fixes i.e. https://github.com/msys2/MSYS2-packages/issues/1937
> >> I don't know if I
Per gccint, 'dg-require-*' must come before any
'dg-additional-sources' directives. Fix a handful of deviant cases.
* gcc.dg/tree-prof/crossmodule-indir-call-topn-1.c: Fix
dg-require-profiling
directive order.
* gcc.dg/tree-prof/crossmodule-indir-call-topn-2.c: Likewise.
Per gccint, 'dg-require-effective-target' must come before any
'dg-additional-sources' directives. Fix a handful of deviant cases.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/aapcs64/func-ret-3.c: Fix
dg-require-effective-target directive order.
*
We want 'dg-do preprocess', not 'dg-do-preprocess'. Fix that.
PR target/106828
* g++.target/loongarch/pr106828.C: Fix 'dg-do compile' typo.
---
Committed as obvious.
gcc/testsuite/g++.target/loongarch/pr106828.C | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
We want 'dg-do compile', not 'dg-do-compile'. Fix that.
PR target/69194
PR c++/92024
PR c++/110057
* c-c++-common/Wshadow-1.c: Fix 'dg-do compile' typo.
* g++.dg/tree-ssa/devirt-array-destructor-1.C: Likewise.
*
'dg-run' is not a valid dejagnu directive, 'dg-do run' is needed here
for the test to be executed.
That said, it actually seems to be executed for me anyway, presumably
a default in the directory, but let's fix it to be consistent with
other uses in the tree and in that test directory even.
Am 30.07.2024 um 11:13 schrieb Jonathan Wakely:
On Sun, 24 Mar 2024 at 21:34, Björn Schäpers wrote:
From: Björn Schäpers
This fixes i.e. https://github.com/msys2/MSYS2-packages/issues/1937
I don't know if I picked the right way to do it.
When acceptable I think the declaration should be
ping for the series?
On Thu, 11 Jul 2024 at 23:43, Christophe Lyon
wrote:
>
> Add a comment about the lack of "n" forms for floating-point nor 8-bit
> integers, to make it clearer why we use build_16_32 for MODE_n.
>
> 2024-07-11 Christophe Lyon
>
> gcc/
> *
do not keep the memory allocated, so
I left them untouched.
Re-bootstrap and regtest running on x86_64-unknown-linux-gnu.
I've CCed people messing with release_pages; This doesn't really
address PR114563 but I thought I post this patch anyway - the
actual issue we run into for the PR
Hi Jonathan,
>> agreed: while Solaris 11.4 does have a few *.ISO8859-15@euro locales
>>
>> da_DK.ISO8859-15@euro
>> en_GB.ISO8859-15@euro
>> en_US.ISO8859-15@euro
>> sv_SE.ISO8859-15@euro
>>
>> the majority (17) are not.
>
> Ah interesting, I only saw en_US.ISO8859-15@euro on cfarm216, which is
>
On Wed, 10 Jul 2024, Richard Biener wrote:
> The loop unrolling code assumes that one third of all volatile accesses
> can be possibly optimized away which is of course not true. This leads
> to excessive unrolling in some cases. The following tracks the number
> of stmts with side-effects as
eading and writing the new system register FPMR (Floating
> Point Mode
> Register) which configures the new FP8 features
>
> Tested against aarch64-unknown-linux-gnu.
>
> V1 of this patch series had "aarch64: Add march flags for +fp8 arch
> extensions" a
The following addresses another case where x87 FP loads mangle the
bit representation and thus are not suitable for a representative
in other types. VN was value-numbering a later integer load of 'x'
as the same as a former float load of 'x'.
We can use the new TARGET_MODE_CAN_TRANSFER_BITS hook
The following implements the hook, excluding x87 modes for scalar
and complex float modes.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
OK this way?
Thanks,
Richard.
* i386.cc (TARGET_MODE_CAN_TRANSFER_BITS): Define.
(ix86_mode_can_transfer_bits): New function.
---
The following adds a target hook to specify whether regs of MODE can be
used to transfer bits. The hook is supposed to be used for value-numbering
to decide whether a value loaded in such mode can be punned to another
mode instead of re-loading the value in the other mode and for SRA to
decide
x86_64-linux.
>
> And does it e.g. pass compat.exp / structure-layout-1.exp testing
> against gcc without that patch (ALT_CC_UNDER_TEST=gcc ALT_CXX_UNDER_TEST=g++)?
It doesn't. I would expect differences at least for packed structs
since TYPE_SIZE changes with MODE_SIZE.
Richard.
As discussed a couple of weeks ago, I'm going to push this.
Tested x86_64-linux (where this #else isn't even used, but I checked it
does at least compile when the #if isn't true).
-- >8 --
The linux man page for strerror says that some systems return NULL for
an unknown error number. That
need to address.
> >
> > Oh, I've just realised that the UNSUPPORTED -> PASS I observed on
> > Solaris was a build using my patch for PR 57585, which is not pushed
> > yet. I think without that all uses of dg-require-namedlocale might
> > fail on Solaris, so this change won't
96_format);
> FLOAT_MODE (TF, 16, ieee_quad_format);
> FLOAT_MODE (HF, 2, ieee_half_format);
> FLOAT_MODE (BF, 2, 0);
>
> bootstraps and tests (-m64/-m32) OK on x86_64-linux.
And does it e.g. pass compat.exp / structure-layout-1.exp testing
against gcc without that patch (ALT_CC_UNDER_TEST=gcc ALT_CXX_UNDER_TEST=g++)?
Jakub
g. value number some SF/DF/XF etc. mode loads
> > > > > > and some
> > > > > > subsequent loads from the same address with different mode but same
> > > > > > size
> > > > > > the same and replace say int or long long later load with
>
PASS, e.g.
>> 21_strings/basic_string/numeric_conversions/char/to_string_float.cc
>> It will probably also cause some to flip from UNSUPPORTED to FAIL, which
>> we'll need to address.
>
> Oh, I've just realised that the UNSUPPORTED -> PASS I observed on
> Solaris wa
tring/numeric_conversions/char/to_string_float.cc
> It will probably also cause some to flip from UNSUPPORTED to FAIL, which
> we'll need to address.
Oh, I've just realised that the UNSUPPORTED -> PASS I observed on
Solaris was a build using my patch for PR 57585, which is not pushed
yet. I
I doubt we want the @euro suffix anywhere except Glibc-based targets. We
certainly don't want to append "@euro" on Solaris, where this change
flips some tests from UNSUPPORTED to PASS, e.g.
21_strings/basic_string/numeric_conversions/char/to_string_float.cc
It will probably also cause some to flip
+ *tp = unshare_expr (DECL_VALUE_EXPR (t));
>*walk_subtrees = 0;
>return t;
> }
>
> which then makes the stmt obviously not gimple?
>
> ... except that 'return t' prevents updating other value-expr in the same
> stmt, but that can be fixed.
>
> Updated pat
Thanks for the feedback! I updated the patch based on your comments, more
detailed comments inline below. The updated version was bootstrapped and tested
again, no regression.
Best,
Jennifer
0001-AArch64-Fuse-CMP-CSEL-and-CMP-CSET-for-mcpu-neoverse.patch
Description: Binary data
> On 25
oduces better code than the original case and in many cases (x
> != y) will
> still reduce to either false or true.
>
> With this change we also need to make sure `a`, `b` and the resulting types
> are all
> the same for the same reason as the previous patch.
>
> I upd
FALSE */
>
> This still produces better code than the original case and in many cases (x
> != y) will
> still reduce to either false or true.
>
> With this change we also need to make sure `a`, `b` and the resulting types
> are all
> the same for the same reason as th
On Tue, Jul 30, 2024 at 5:25 PM Andrew Pinski wrote:
>
> The problem here is that in generic types of comparisons don't need
> to be boolean types (or vector boolean types). And fixes that by making
> sure the types of the conditions match before doing the optimization.
>
> Bootstrapped and
On Wed 2024-07-31 13:34:28, Jakub Jelinek wrote:
> On Wed, Jul 31, 2024 at 01:32:06PM +0200, Filip Kastl wrote:
> > Thanks for the feedback! Here is a second version of the patch. I've
> > tested
> > this version with
> >
> > make check RUNTESTFLAGS=&qu
On Wed, Jul 31, 2024 at 01:32:06PM +0200, Filip Kastl wrote:
> Thanks for the feedback! Here is a second version of the patch. I've tested
> this version with
>
> make check RUNTESTFLAGS="i386.exp=gcc.target/i386/switch-exp-transform-3.c
> --target_board='unix{-m32}'"
dump-times "Applying exponential index transform" 6
> "switchconv" { target { ! ia32 } } } } */
> or so?
>
> Jakub
>
Thanks for the feedback! Here is a second version of the patch. I've tested
this version with
make check RUNTESTFLAGS="i386.exp=gcc.tar
y not gimple?
... except that 'return t' prevents updating other value-expr in the
same stmt, but that can be fixed.
Updated patch attached.
Thanks for the suggestion!
Tobias
omp-offload.cc: Fix value-expr handling of 'declare target link' vars
As the PR and included testcase shows, rep
Tested on x86_64-pc-linux-gnu. OK for trunk?
TIA, have a lovely day.
-- >8 --
By doing so, we can get diagnostics in template decls when we know we
can. For instance, in the following:
awaitable g();
template
task f()
{
co_await g();
co_yield 1;
co_return
"Kewen.Lin" writes:
> Hi,
>
> As Andrew pointed out in PR116148, fam-in-union-alone-in-struct-2.c
> was designed for little-endian, the recent commit r15-2403 made it
> be tested with running on BE and PR116148 got exposed.
>
> This patch is to adjus
Gives an opportunity to execute the code on bit level,
assigning symbolic values to the variables which don't have initial
values.
Supports only CRC specific operations.
Example:
uint8_t crc;
uint8_t pol = 1;
crc = crc ^ pol;
during symbolic execution crc's value will
as that the hook would be used only for
> > > > > cases
> > > > > where we'd like to e.g. value number some SF/DF/XF etc. mode loads
> > > > > and some
> > > > > subsequent loads from the same address with different mode but same
&g
ly I cannot figure out a way to make the compiler generate
> > revb.4h or revh.{2w,d} instructions.
>
> This optimization is really ingenious and I have no problem.
>
> I also haven't figured out how to generate revb.4h or revh. {2w,d}.
> I think we can merge this
201 - 300 of 248140 matches
Mail list logo
