On Tue, 21 May 2024, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled, because -fsanitize=bool,enum
> creates a MEM_REF without propagating there address space qualifiers,
> so what should be normally loaded using say %gs:/%fs: segment prefix
> isn't. Together with asan it th
On Tue, 21 May 2024, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled because
> strlen_pass::count_nonzero_bytes_addr doesn't handle correctly
> the !si->full_string_p case.
> If si->full_string_p, it correctly computes minlen and maxlen as
> minimum and maximum length of the
From: Pan Li
This patch would like to support the branch form for unsigned
SAT_ADD. For example as below:
uint64_t
sat_add (uint64_t x, uint64_t y)
{
return (uint64_t) (x + y) >= x ? (x + y) : -1;
}
Different to the branchless version, we leverage the simplify to
convert the branch version
>> Hard to find a default value satisfying all testcases.
>> some require loop unroll with 7 insns increment, some don't want loop
>> unroll w/ 5 insn increment.
>> The original 2/3 reduction happened to meet all those testcases(or the
>> testcases are constructed based on the old 2/3).
>> Can we d
Ping ?
On 13/05/2024 06:33, François Dumont wrote:
libstdc++: [_Hashtable] Fix some implementation inconsistencies
Get rid of the different usages of the mutable keyword except in
_Prime_rehash_policy where it is preserved for abi compatibility
reason.
Fix comment to explain that
Hi,
on 2024/5/21 11:04, Alexandre Oliva wrote:
> On May 8, 2024, "Kewen.Lin" wrote:
>
How about the generic one "longdouble64"? I did a grep and found it has
one
use, I'd expect it can work here. :)
>>>
>>> ... since this and longdouble128 exist, maybe we can fix it and leave
>
Hi,
on 2024/2/26 13:43, jeevitha wrote:
> Hi All,
>
> The following patch has been bootstrapped and regtested on powerpc64le-linux.
>
> PR110040 exposes an issue concerning moves from vector registers to GPRs.
> There are two moves, one for upper 64 bits and the other for the lower
> 64 bits. I
Hi Carl,
on 2024/5/22 08:13, Carl Love wrote:
> Kewen:
>
> On 5/13/24 19:54, Kewen.Lin wrote:
>> Hi,
>>
>> on 2024/4/20 05:17, Carl Love wrote:
>>> rs6000, add overloaded vec_sel with int128 arguments
>>>
>>> Extend the vec_sel built-in to take three signed/unsigned int128 arguments
>>> and retur
On 5/21/24 21:55, Patrick Palka wrote:
On Tue, 21 May 2024, Jason Merrill wrote:
On 5/21/24 17:27, Patrick Palka wrote:
On Tue, 21 May 2024, Jason Merrill wrote:
On 5/21/24 15:36, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
Alternati
> -Original Message-
> From: Uros Bizjak
> Sent: Tuesday, May 21, 2024 9:04 PM
> To: Jiang, Haochen
> Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao
> Subject: Re: [PATCH v3] i386: Disable ix86_expand_vecop_qihi2
> when !TARGET_AVX512BW
>
> On Tue, May 21, 2024 at 11:01 AM Haochen Jiang
> w
This patch is a follow-up of r15-697-ga2e4fe5a53cf75 to also fold vget_high_*
intrinsics to BIT_FILED_REF and remove the vget_high_* definitions from
arm_neon.h to use the new intrinsics framework.
PR target/102171
gcc/ChangeLog:
* config/aarch64/aarch64-builtins.cc (AARCH64_SIMD
According to IEEE standard, for conversions from floating point to
integer. When a NaN or infinite operand cannot be represented in the
destination format and this cannot otherwise be indicated, the invalid
operation exception shall be signaled. When a numeric operand would
convert to an integer ou
On Tue, 21 May 2024, Jason Merrill wrote:
> On 5/21/24 17:27, Patrick Palka wrote:
> > On Tue, 21 May 2024, Jason Merrill wrote:
> >
> > > On 5/21/24 15:36, Patrick Palka wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > > OK for trunk?
> > > >
> > > > Altern
From: Pan Li
This patch would like to support the __builtin_add_overflow branch form for
unsigned SAT_ADD. For example as below:
uint64_t
sat_add (uint64_t x, uint64_t y)
{
uint64_t ret;
return __builtin_add_overflow (x, y, &ret) ? -1 : ret;
}
Different to the branchless version, we lever
Committed, thanks.
xu...@eswincomputing.com
From: Robin Dapp
Date: 2024-05-21 22:58
To: juzhe.zh...@rivai.ai; Li Xu; gcc-patches
CC: rdapp.gcc; kito.cheng; palmer; tamar.christina; Richard Biener;
richard.sandiford; zhengyu; pan2.li
Subject: Re: [PATCH] RISC-V: Enable vectorization for
vect-
Kewen:
On 5/13/24 19:54, Kewen.Lin wrote:
> Hi,
>
> on 2024/4/20 05:17, Carl Love wrote:
>> rs6000, add overloaded vec_sel with int128 arguments
>>
>> Extend the vec_sel built-in to take three signed/unsigned int128 arguments
>> and return a signed/unsigned int128 result.
>>
>> Extending the vec_
> I see. I do wonder how we should deal with the inherent
> dependence on optimization for [[musttail]] to work then? "Solve"
> the problem with good documentation?
For now that's good enough I think. If it's a significant problem
it can always be improved later.
> Offer a -fignore-musttail
> o
On 5/21/24 17:27, Patrick Palka wrote:
On Tue, 21 May 2024, Jason Merrill wrote:
On 5/21/24 15:36, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
Alternatively, I considered fixing this by incrementing
comparing_specializations around the
On Tue, 2024-05-21 at 15:13 +, Qing Zhao wrote:
> Thanks for the comments and suggestions.
>
> > On May 15, 2024, at 10:00, David Malcolm
> > wrote:
> >
> > On Tue, 2024-05-14 at 15:08 +0200, Richard Biener wrote:
> > > On Mon, 13 May 2024, Qing Zhao wrote:
> > >
> > > > -Warray-bounds is a
On Tue, 21 May 2024, Patrick Palka wrote:
> On Tue, 21 May 2024, Jason Merrill wrote:
>
> > On 5/21/24 15:36, Patrick Palka wrote:
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > OK for trunk?
> > >
> > > Alternatively, I considered fixing this by incrementing
> > >
On Tue, 21 May 2024, Jason Merrill wrote:
> On 5/21/24 15:36, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > OK for trunk?
> >
> > Alternatively, I considered fixing this by incrementing
> > comparing_specializations around the call to comp_except_s
On 5/21/24 15:36, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
Alternatively, I considered fixing this by incrementing
comparing_specializations around the call to comp_except_specs in
cp_check_qualified_type, but generally for types whose
Hi!
The following testcase is miscompiled because
strlen_pass::count_nonzero_bytes_addr doesn't handle correctly
the !si->full_string_p case.
If si->full_string_p, it correctly computes minlen and maxlen as
minimum and maximum length of the '\0' terminated stgring and
clears *nulterm (ie. makes su
Tested x86_64-linux. Committed as obvious.
I'll backport it too.
-- >8 --
The correct dialect for std::to_address is cxx20 not cxx11.
gcc/cp/ChangeLog:
PR libstdc++/107800
* cxxapi-data.csv : Change dialect to cxx20.
* std-name-hint.gperf: Regenerate.
* std-name
Hi!
The following testcase is miscompiled, because -fsanitize=bool,enum
creates a MEM_REF without propagating there address space qualifiers,
so what should be normally loaded using say %gs:/%fs: segment prefix
isn't. Together with asan it then causes that load to be sanitized.
Fixed thusly, boo
On 5/19/24 12:37 AM, pan2...@intel.com wrote:
From: Pan Li
After we support branchless __builtin_add_overflow unsigned SAT_ADD from
the middle end. Add more tests case to cover the functionarlities.
The below test suites are passed.
* The rv64gcv fully regression test.
gcc/testsuite/Chang
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
Alternatively, I considered fixing this by incrementing
comparing_specializations around the call to comp_except_specs in
cp_check_qualified_type, but generally for types whose identity
depends on whether comparing_spe
Richard Biener writes:
> The following avoids splitting store dataref groups during SLP
> discovery but instead forces (eventually single-lane) consecutive
> lane SLP discovery for all lanes of the group, creating VEC_PERM
> SLP nodes merging them so the store will always cover the whole group.
>
Hi Paul,
Am 20.05.24 um 11:06 schrieb Paul Richard Thomas:
Hi All,
I don't think that this PR is really a regression although the fact that it
is marked as such brought it to my attention :-)
The fix turned out to be remarkably simple. It was found after going down a
silly number of rabbit hol
Hello Alex:
On 21/05/24 10:22 pm, Alex Coplan wrote:
> Hi Ajit,
>
> I've left some more comments below. It's getting there now, thanks for
> your patience.
>
> On 21/05/2024 20:32, Ajit Agarwal wrote:
>> Hello Alex/Richard:
>>
>> All comments are addressed.
>>
>> Move pair fusion pass from aarc
Richard Biener writes:
> When change_vec_perm_layout runs into a permute combining two
> nodes where one is invariant and one internal the partition of
> one input can be -1 but the other might not be. The following
> supports this case by simply ignoring inputs with input partiton -1.
>
> I'm no
Am 13.05.24 um 22:27 schrieb Harald Anlauf:
Dear all,
the attached patch does two things:
- it fixes a bogus array bounds check when deep-copying a class component
of a derived type and the class component has rank > 1, the reason being
that the previous code compared the full size of one
On 5/17/24 12:05, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/14?
OK for both.
-- >8 --
After the tsubst_copy removal r14-4796-g3e3d73ed5e85e7 GCC 14 ICEs during
fold_non_dependent_expr for 'e1 | e2' ultimately because we no longer exit
On 5/21/24 07:36, Rainer Orth wrote:
gcc.dg/pr115066.c currently FAILs on Solaris/SPARC with the native as:
FAIL: gcc.dg/pr115066.c scan-assembler .bytet0xbt# Define macro strx
Instead of the expected
.byte 0xb ! Define macro strx
the assembler output contains
On 5/14/24 19:23, Andi Kleen wrote:
You need a template testcase; I expect it doesn't work in templates with the
current patch. It's probably enough to copy it in tsubst_expr where we
currently propagate CALL_EXPR_OPERATOR_SYNTAX.
I tried it with the appended test case, everything seems to wor
This is continuing on the prev patch in function epilogue expansion.
Broken out of easy of review.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_expand_epilogue): Handle offset
being sum of two S12.
Tested-by: Patrick O'Neill # pre-commit-CI #1569
Signed-off-by: Vineet Gupta
---
On 5/20/24 5:01 AM, pan2...@intel.com wrote:
From: Pan Li
After we support branch form unsigned SAT_ADD from the
middle end. Add more tests case to cover the functionarlities.
The below test suites are passed.
* The rv64gcv fully regression test.
gcc/testsuite/ChangeLog:
* gcc.ta
On 5/20/24 5:32 PM, Vineet Gupta wrote:
This is testsuite clean however there's a dwarf quirk which I want to
run by the experts. The test that was tripping CI has following
fragment:
Before patch| After Patch
--
If the constant used for stack offset can be expressed as sum of two S12
values, the constant need not be materialized (in a reg) and instead the
two S12 bits can be added to instructions involved with frame pointer.
This avoids burning a register and more importantly can often get down
to be 2 ins
On 5/20/24 5:32 PM, Vineet Gupta wrote:
Changes since v2:
- Broke out the hunk corresponding to alloca in epilogue expansion in
a seperate patch.
---
If the constant used for stack offset can be expressed as sum of two S12
values, the constant need not be materialized (in a reg) and i
On 5/21/24 4:53 AM, pan2...@intel.com wrote:
From: Pan Li
After we support __builtin_add_overflow branch form unsigned SAT_ADD
from the middle end. Add more tests case to cover the functionarlities.
The below test suites are passed.
* The rv64gcv fully regression test.
gcc/testsuite/Chan
When change_vec_perm_layout runs into a permute combining two
nodes where one is invariant and one internal the partition of
one input can be -1 but the other might not be. The following
supports this case by simply ignoring inputs with input partiton -1.
I'm not sure this is correct but it avoid
Hi Ajit,
I've left some more comments below. It's getting there now, thanks for
your patience.
On 21/05/2024 20:32, Ajit Agarwal wrote:
> Hello Alex/Richard:
>
> All comments are addressed.
>
> Move pair fusion pass from aarch64-ldp-fusion.cc to middle-end
> to support multiple targets.
>
> C
On Tue, May 21, 2024 at 6:21 PM Jeff Law wrote:
>
>
>
> On 5/21/24 8:02 AM, Paul Koning wrote:
> >
> >
> >> On May 21, 2024, at 9:57 AM, Jeff Law wrote:
> >>
> >>
> >>
> >> On 5/21/24 12:05 AM, Richard Biener via Gcc wrote:
> >>> On Mon, May 20, 2024 at 4:45 PM Gerald Pfeifer wrote:
>
> >>>
On Tue, May 21, 2024 at 3:35 PM Andi Kleen wrote:
>
> > I can't see how this triggers on the IL above, the loop should have
> > ignored both the return and the clobber and when recursing to
> > the predecessor stop before the above check when runnig into the
> > call?
>
> Yes, I tracked that down
On 5/21/24 8:02 AM, Paul Koning wrote:
On May 21, 2024, at 9:57 AM, Jeff Law wrote:
On 5/21/24 12:05 AM, Richard Biener via Gcc wrote:
On Mon, May 20, 2024 at 4:45 PM Gerald Pfeifer wrote:
On Wed, 5 Jul 2023, Joern Rennecke wrote:
I haven't worked with these targets in years and ca
On 5/20/24 20:54, Jeff Law wrote:
> On 5/20/24 5:32 PM, Vineet Gupta wrote:
>> This is testsuite clean however there's a dwarf quirk which I want to
>> run by the experts. The test that was tripping CI has following
>> fragment:
>>
>> Before patch| After Patch
>>
Thanks for the comments and suggestions.
> On May 15, 2024, at 10:00, David Malcolm wrote:
>
> On Tue, 2024-05-14 at 15:08 +0200, Richard Biener wrote:
>> On Mon, 13 May 2024, Qing Zhao wrote:
>>
>>> -Warray-bounds is an important option to enable linux kernal to
>>> keep
>>> the array out-of-b
Hello Alex:
On 21/05/24 6:50 pm, Alex Coplan wrote:
> On 20/05/2024 21:50, Ajit Agarwal wrote:
>> Hello Alex/Richard:
>>
>> Move pair fusion pass from aarch64-ldp-fusion.cc to middle-end
>> to support multiple targets.
>>
>> Common infrastructure of load store pair fusion is divided into
>> target
Hello Alex:
On 21/05/24 6:02 pm, Alex Coplan wrote:
> On 21/05/2024 16:02, Ajit Agarwal wrote:
>> Hello Alex:
>>
>> On 21/05/24 1:16 am, Alex Coplan wrote:
>>> On 20/05/2024 18:44, Alex Coplan wrote:
Hi Ajit,
On 20/05/2024 21:50, Ajit Agarwal wrote:
> Hello Alex/Richard:
>
>
Wilco Dijkstra writes:
> Hi Andrew,
>
> A few comments on the implementation, I think it can be simplified a lot:
FWIW, I agree with Wilco's comments, except:
>> +++ b/gcc/config/aarch64/aarch64.h
>> @@ -700,8 +700,9 @@ constexpr auto AARCH64_FL_DEFAULT_ISA_MODE =
>> AARCH64_FL_SM_OFF;
>> #defi
The patch is OK from the riscv side. generic-ooo includes fast unaligned
access.
Regards
Robin
Enable the tailcall optimization for non optimizing builds,
but in this case only checks calls that have the musttail attribute set.
This makes musttail work without optimization.
This is done with a new late musttail pass that is only active when
not optimizing. The pass must be after ehcleanup.
gcc/ChangeLog:
* doc/extend.texi: Document [[musttail]]
---
gcc/doc/extend.texi | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index e290265d68d3..f3df7688edf1 100644
--- a/gcc/doc/extend.texi
+++ b/gc
When musttail is set, make tree-tailcall to give error messages
when it cannot handle a call. This avoids vague "other reasons"
error messages later at expand time.
This doesn't always work, for example when find_tail_call
walking gives up because the control flow is too complicated
then it won't
Mostly adopted from the existing C musttail plugin tests.
gcc/testsuite/ChangeLog:
* c-c++-common/musttail1.c: New test.
* c-c++-common/musttail2.c: New test.
* c-c++-common/musttail3.c: New test.
* c-c++-common/musttail4.c: New test.
* c-c++-common/musttai
It does nothing currently since statement attributes are handled
directly in the parser.
gcc/c-family/ChangeLog:
* c-attribs.cc (handle_musttail_attribute): Add.
* c-common.h (handle_musttail_attribute): Add.
---
gcc/c-family/c-attribs.cc | 15 +++
gcc/c-family/c-comm
- Give error messages for all causes of non sibling call generation
- When giving error messages clear the musttail flag to avoid ICEs
- Error out when tree-tailcall failed to mark a must-tail call
sibcall. In this case it doesn't know the true reason and only gives
a vague message.
PR8332
Implement a C23 clang compatible musttail attribute similar to the earlier
C++ implementation in the C parser.
PR83324
gcc/c/ChangeLog:
* c-parser.cc (struct attr_state): Define with musttail_p.
(c_parser_statement_after_labels): Handle [[musttail]]
(c_parser_std_
This patch implements a clang compatible [[musttail]] attribute for
returns.
musttail is useful as an alternative to computed goto for interpreters.
With computed goto the interpreter function usually ends up very big
which causes problems with register allocation and other per function
optimizati
I reworked the musttail patchkit to make it work without optimization
and also give better error messages and fixed some bugs and increased
the test coverage.
The no optimization support is not perfect: it cannot handle returning
small structures which would need to be allocated to registers first
> On May 21, 2024, at 9:57 AM, Jeff Law wrote:
>
>
>
> On 5/21/24 12:05 AM, Richard Biener via Gcc wrote:
>> On Mon, May 20, 2024 at 4:45 PM Gerald Pfeifer wrote:
>>>
>>> On Wed, 5 Jul 2023, Joern Rennecke wrote:
I haven't worked with these targets in years and can't really do
se
On 5/21/24 12:05 AM, Richard Biener via Gcc wrote:
On Mon, May 20, 2024 at 4:45 PM Gerald Pfeifer wrote:
On Wed, 5 Jul 2023, Joern Rennecke wrote:
I haven't worked with these targets in years and can't really do
sensible maintenance or reviews of patches for them. I am currently
working on
> Since you matching @2 for the realpart rather than `(IFN_ADD_OVERFLOW
> @0 @1)` directly the :c is not needed and genmatch will just generate
> extra matching code that cannot be not get reached
Got it, thanks for explanation. I may need to check the generated matching code
for a better underst
> I can't see how this triggers on the IL above, the loop should have
> ignored both the return and the clobber and when recursing to
> the predecessor stop before the above check when runnig into the
> call?
Yes, I tracked that down later. The problem was that there
were multiple successors to th
Hi All,
The following patch has been bootstrapped and regtested with default
configuration
[--enable-checking=yes] and with --enable-checking=release on powerpc64le-linux.
This patch removes passing the -many assembler option for release builds. Now,
GCC no longer passes -many under any condit
On 20/05/2024 21:50, Ajit Agarwal wrote:
> Hello Alex/Richard:
>
> Move pair fusion pass from aarch64-ldp-fusion.cc to middle-end
> to support multiple targets.
>
> Common infrastructure of load store pair fusion is divided into
> target independent and target dependent code.
>
> Target independ
On Tue, May 21, 2024 at 11:01 AM Haochen Jiang wrote:
>
> Hi all,
>
> This is the v3 patch to fix PR115069. The new testcase has passed.
>
> Changes in v3:
> - Simplify the testcase.
>
> Changes in v2:
> - Add a testcase.
> - Change the comment for the early exit.
>
> Thx,
> Haochen
>
> Sinc
The gcc.dg/vect/slp-12a.c case is interesting as we currently split
the 8 store group into lanes 0-5 which we SLP with an unroll factor
of two (on x86-64 with SSE) and the remaining two lanes are using
interleaving vectorization with a final unroll factor of four. Thus
we're using hybrid SLP withi
The following avoids splitting store dataref groups during SLP
discovery but instead forces (eventually single-lane) consecutive
lane SLP discovery for all lanes of the group, creating VEC_PERM
SLP nodes merging them so the store will always cover the whole group.
With this for example
int x[1024
SLP permute nodes can end up without a SLP_REPRESENTATIVE now,
the following avoids touching it in this case in vect_schedule_slp_node.
* tree-vect-slp.cc (vect_schedule_slp_node): Avoid looking
at SLP_REPRESENTATIVE for VEC_PERM nodes.
---
gcc/tree-vect-slp.cc | 28 ++
The following plugs one hole where we require a VEC_PERM node
representative unnecessarily. This is for vect_check_store_rhs
which looks at the RHS and checks whether a constant can be
native encoded. The fix is to guard that with vect_constant_def
additionally and making vect_is_simple_use forgi
Andrew Pinski 于2024年5月21日周二 20:23写道：
>
> On Tue, May 21, 2024 at 5:12 AM YunQiang Su wrote:
> >
> > If `find_a_program` cannot find `as/ld` and we are a cross toolchain,
> > the final fallback is `as/ld` of system. In fact, we can have a try
> > with -as/ld before fallback to native as/ld.
> >
>
On Tue, May 21, 2024 at 5:28 AM Li, Pan2 wrote:
>
> Thanks Andrew for comments.
>
>
>
> > I think you need to make sure type and @0's type matches.
>
>
>
> Oh, yes, we need that, will update in v2.
>
>
>
> > Also I don't think you need :c here since you don't match @0 nor @1 more
> > than once.
>
On 21/05/2024 16:02, Ajit Agarwal wrote:
> Hello Alex:
>
> On 21/05/24 1:16 am, Alex Coplan wrote:
> > On 20/05/2024 18:44, Alex Coplan wrote:
> >> Hi Ajit,
> >>
> >> On 20/05/2024 21:50, Ajit Agarwal wrote:
> >>> Hello Alex/Richard:
> >>>
> >>> Move pair fusion pass from aarch64-ldp-fusion.cc to
Thanks Andrew for comments.
> I think you need to make sure type and @0's type matches.
Oh, yes, we need that, will update in v2.
> Also I don't think you need :c here since you don't match @0 nor @1 more than
> once.
You mean the :c from (IFN_ADD_OVERFLOW:c@2 @0 @1)), right?
My initial idea i
On Tue, May 21, 2024 at 5:12 AM YunQiang Su wrote:
>
> If `find_a_program` cannot find `as/ld` and we are a cross toolchain,
> the final fallback is `as/ld` of system. In fact, we can have a try
> with -as/ld before fallback to native as/ld.
>
> This patch is derivatived from Debian's patch:
>
For enum and integer we allow aliasing by specifically returning
via a langhook the aliasing set of the underlying type.
But this is not sufficient for derived types, i.e. pointers to
enums and pointers to compatible integers also need to have the
same aliasing set.
We also allow forward declara
If `find_a_program` cannot find `as/ld` and we are a cross toolchain,
the final fallback is `as/ld` of system. In fact, we can have a try
with -as/ld before fallback to native as/ld.
This patch is derivatived from Debian's patch:
gcc-search-prefixed-as-ld.diff
gcc
* gcc.cc(execute): Lo
On Tue, May 21, 2024, 3:55 AM wrote:
> From: Pan Li
>
> This patch would like to support the __builtin_add_overflow branch form for
> unsigned SAT_ADD. For example as below:
>
> uint64_t
> sat_add (uint64_t x, uint64_t y)
> {
> uint64_t ret;
> return __builtin_add_overflow (x, y, &ret) ? -1
gcc.dg/pr115066.c currently FAILs on Solaris/SPARC with the native as:
FAIL: gcc.dg/pr115066.c scan-assembler .bytet0xbt# Define macro strx
Instead of the expected
.byte 0xb ! Define macro strx
the assembler output contains
.byte 0x1 ! Define macro
Appa
Gentle ping!
Kind regards,
Torbjörn
On 2024-05-14 13:01, Torbjorn SVENSSON wrote:
Hi,
I'm not sure if the previous "ok" from Richard on the v1 is enough for
this or if there needs another approval.
Adding extra maintainers since Richard Earnshaw appears to be busy the
past weeks.
Kind re
From: Pan Li
This patch would like to support the __builtin_add_overflow branch form for
unsigned SAT_ADD. For example as below:
uint64_t
sat_add (uint64_t x, uint64_t y)
{
uint64_t ret;
return __builtin_add_overflow (x, y, &ret) ? -1 : ret;
}
Different to the branchless version, we lever
From: Pan Li
After we support __builtin_add_overflow branch form unsigned SAT_ADD
from the middle end. Add more tests case to cover the functionarlities.
The below test suites are passed.
* The rv64gcv fully regression test.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/sat_arith.h: Ad
> Thanks, looks good to me! You still need approval from a maintainer..
Thanks Tamar, let's wait for a while, 😊!
Pan
-Original Message-
From: Tamar Christina
Sent: Tuesday, May 21, 2024 11:19 AM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; rich
Hello Alex:
On 21/05/24 1:16 am, Alex Coplan wrote:
> On 20/05/2024 18:44, Alex Coplan wrote:
>> Hi Ajit,
>>
>> On 20/05/2024 21:50, Ajit Agarwal wrote:
>>> Hello Alex/Richard:
>>>
>>> Move pair fusion pass from aarch64-ldp-fusion.cc to middle-end
>>> to support multiple targets.
>>>
>>> Common in
The following fixes the omission of const-pool included in NONLOCAL.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/115137
* tree-ssa-structalias.cc (pt_solution_includes_const_pool): NONLOCAL
also includes constant pool entries.
On Tue, May 21, 2024 at 11:03 AM Richard Sandiford
wrote:
>
> While reviewing Andrew's fix for PR114843, it seemed like it would
> be convenient to have a HARD_REG_SET of EH_RETURN_DATA_REGNOs.
> This patch adds one and uses it to simplify a couple of use sites.
>
> Tested on aarch64-linux-gnu & x
Recent changes made to the runtime library broke again its build on Solaris
because it uses Solaris threads instead of POSIX threads on this platform.
Tested by Rainer, applied on the mainline.
2024-05-21 Eric Botcazou
PR ada/115168
* libgnarl/s-taprop__solaris.adb (Initiali
While reviewing Andrew's fix for PR114843, it seemed like it would
be convenient to have a HARD_REG_SET of EH_RETURN_DATA_REGNOs.
This patch adds one and uses it to simplify a couple of use sites.
Tested on aarch64-linux-gnu & x86_64-linux-gnu. OK to install?
Richard
gcc/
* hard-reg-se
Hi all,
This is the v3 patch to fix PR115069. The new testcase has passed.
Changes in v3:
- Simplify the testcase.
Changes in v2:
- Add a testcase.
- Change the comment for the early exit.
Thx,
Haochen
Since vpermq is really slow, we should avoid using it for permutation
when vpmovwb is
The following fixes a bug in vop-live get_live_in which was using
NULL to indicate the first processed edge but at the same time
using it for the case the live-in virtual operand cannot be computed.
The following fixes this, avoiding sinking a load to a place where
we'd have to insert virtual PHIs
> > diff --git a/gcc/testsuite/gcc.target/i386/pr115069.c
> b/gcc/testsuite/gcc.target/i386/pr115069.c
> > new file mode 100644
> > index 000..c4b48b602ef
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/i386/pr115069.c
> > @@ -0,0 +1,78 @@
> > +/* { dg-do compile } */
> > +/* { dg-opti
On Mon, May 20, 2024 at 6:53 AM Andi Kleen wrote:
>
> On Tue, May 14, 2024 at 04:15:08PM +0200, Richard Biener wrote:
> > On Sun, May 5, 2024 at 8:16 PM Andi Kleen wrote:
> > >
> > > - Give error messages for all causes of non sibling call generation
> > > - Don't override choices of other non si
Hi Bernhard,
rep.dot@gmail.com wrote:
library such as @url{http://opencoarrays.org} needs to be linked.
Maybe use https?
Works, but as the certificate is not valid, it requires to ignore the
errors in a browser, which is a worse user experience.
The error is, e.g.,
"curl: (60) SSL cer
On Tue, May 21, 2024 at 09:36:05AM +0200, Tobias Burnus wrote:
> Jakub Jelinek wrote:
> > On Mon, May 20, 2024 at 08:31:02AM +0200, Tobias Burnus wrote:
> > > Hmm, there were now two daily bumps: [...] I really wonder why.
> > Because I've done it by hand.
>
> Okay, that explains it.
>
> I still
From: Eric Botcazou
This changes the test to use the Is_Base_Type predicate and also removes the
superfluous call to Base_Type before First_Subtype. No functional changes.
gcc/ada/
* gcc-interface/decl.cc (gnat_to_gnu_entity): Use the Is_Base_Type
predicate and remove superfluo
From: Eric Botcazou
This fixes a long-standing (implicit) violation of the strict aliasing rules
that occurs when the result of a call to an instance of Unchecked_Conversion
is directly passed as an actual parameter in a call to a subprogram and the
passing mechanism is by reference. In this cas
From: Ronan Desplanques
The way if expressions were translated led the gimplifying phase
to attempt to create a temporary of a variable-sized type in some
cases. This patch fixes this by adding an address indirection layer
in those cases.
gcc/ada/
* gcc-interface/utils2.cc (build_cond_e
From: Eric Botcazou
They are implemented by the nonbinary_modular_operation routine, which is
complex and, in particular, creates signed types and types with a partial
precision each time a subtraction or a multiplication resp. is generated.
Both are unnecessary and a simple approach even generat
1 - 100 of 130 matches
Mail list logo
