On Wed, 13 Oct 2021, Martin Jambor wrote:
> Hi,
>
> On Mon, Sep 27 2021, Richard Biener via Gcc-patches wrote:
> >
> [...]
> >
> > The following is what I have pushed after re-bootstrapping and testing
> > on x86_64-unknown-linux-gnu.
> >
> > Richard.
> >
> > From fc335f9fde40d7a20a1a6e38fd6f842e
On Thu, Oct 14, 2021 at 10:39 AM Hongyu Wang via Gcc-patches
wrote:
>
> Hi,
>
> This patch supports HFmode vector shuffle by creating HImode subreg when
> expanding permutation expr.
>
> Bootstrapped/regtested on x86_64-pc-linux-gnu{-m32,} and sde{-m32,}
> OK for master?
>
> gcc/ChangeLog:
>
>
Hi,
The patch optimizes the code generation for vec_xl_sext builtin. Now all the
sign extensions are done on VSX registers directly.
Bootstrapped and tested on powerpc64le-linux with no regressions. Is this
okay for trunk? Any recommendations? Thanks a lot.
I refined the patch according
Hi Harald,
another simple and obvious fix: we need to reorder the argument checks
to the SHAPE intrinsic so that invalid KIND arguments can be detected.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
As I consider this a safe fix, I'd like to backport to suitable branches.
Also OK for b
H Harald,
when simplifying RESHAPE we hit a gcc_assert for negative entries in the
SHAPE array. Obvious solution: replace gcc_assert by an error message.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
As this is a safe fix, I'd like to backport to suitable branches.
OK for both.
Thank
The condition of the 'if' encompassed that of the 'elsif', so the error
message wouldn't get a chance to be printed.
Regstrapped on x86_64-linux-gnu. I'm checking this in.
for gcc/ada/ChangeLog
* par-ch10.adb (P_Compilation_Unit): Reenable ada83 library
unit renaming test and
Hi,
This patch supports HFmode vector shuffle by creating HImode subreg when
expanding permutation expr.
Bootstrapped/regtested on x86_64-pc-linux-gnu{-m32,} and sde{-m32,}
OK for master?
gcc/ChangeLog:
* config/i386/i386-expand.c (ix86_expand_vec_perm): Convert
HFmode input ope
On Linux/x86_64,
97c320016642a40a347d558abc952cc487ad4ff6 is the first bad commit
commit 97c320016642a40a347d558abc952cc487ad4ff6
Author: Roger Sayle
Date: Wed Oct 13 19:49:47 2021 +0100
x86_64: Some SUBREG related optimization tweaks to i386 backend.
caused
FAIL: gcc.target/i386/avx-1.c
On Wed, Oct 13, 2021 at 5:07 PM Hongyu Wang via Gcc-patches
wrote:
>
> Hi,
>
> Current mask/mask3 implementation for complex fma contains
> duplicated parameter in macro, which may cause error at -O0.
> Refactor macro implementation to builtins to avoid potential
> error.
>
> For round intrinsic w
This change fixes building libgcc with -msoft-float. Getting soft float to
work in libgcc
is still a work in progress.
Tested on hppa-unkown-linux-gnu, hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11.
Committed to active branches.
Dave
---
Fix TARGET_SOFT_FLOAT patterns in pa.md
2021-10-13 Jo
On Wed, Sep 29, 2021 at 04:32:19PM +0800, HAO CHEN GUI wrote:
> The patch punishes reload of alternative pair of "d, Z" for
> movsi_internal1. The reload occurs if 'Z' doesn't match and generates an
> additional insn. So the memory reload should be punished.
As David says, why only for loads?
On Wed, Oct 13, 2021 at 12:04:39PM -0500, Paul A. Clarke wrote:
> On Mon, Oct 11, 2021 at 07:11:13PM -0500, Segher Boessenkool wrote:
> > > - _mm_mul_epu32: vec_mule(v4su) uses vmuleuw.
> >
> > Did this fail on p7? If not, add a test that *does*?
>
> Do you mean fail if not for "dg-require-effec
On Wed, Oct 13, 2021 at 2:08 AM Uros Bizjak via Gcc-patches
wrote:
>
> On Wed, Oct 13, 2021 at 10:23 AM Roger Sayle
> wrote:
> >
> >
> > Good catch. I agree with Hongtao that although my testing revealed
> > no problems with the previous version of this patch, it makes sense to
> > call gen_reg
On 13/10/21 21:19 +0100, Jonathan Wakely wrote:
On 13/10/21 20:41 +0100, Jonathan Wakely wrote:
Adjust the __detail::__effective_range overloads so they always return a
string or string view using std::char_traits, because we don't care
about the traits of an incoming string.
Use std::contiguou
libstdc++-v3/ChangeLog:
* testsuite/27_io/filesystem/path/construct/102592.C: Moved to...
* testsuite/27_io/filesystem/path/construct/102592.cc: ...here.
* testsuite/28_regex/match_results/102667.C: Moved to...
* testsuite/28_regex/match_results/102667.cc: ...here.
On Wed, 13 Oct 2021, HAO CHEN GUI via Gcc-patches wrote:
> As to IEEE behavior, do you mean "Minimum and maximum operations" defined in
> IEEE-754 2019? If so, I think VSX/altivec min/max instructions don't conform
> with it. It demands a quite NaN if either operand is a NaN while our
> instruc
I'd like to cancel the request to apply that patch.
At the time I had actually assumed that Clang was at fault, but your comment
made me pause. I'll submit a bug report as you suggest. We can reconsider the
patch in future once that bug is resolved.
From
As work has progressed, we're pretty close to being able to functionally
replace VRP with another EVRP pass. At least it seems close enough that
we should discuss if thats something we might want to consider for this
release. Replacing just one of the 2 VRP passes is another option.
First,
Hi Kito,
On 9/23/21 12:57 AM, Kito Cheng wrote:
Bit manipulation extension[1] is finishing the public review and waiting for
the rest of the ratification process, I believe that will become a ratified
extension soon, so I think it's time to submit to upstream for review now :)
As the title incl
On 13/10/21 20:41 +0100, Jonathan Wakely wrote:
Adjust the __detail::__effective_range overloads so they always return a
string or string view using std::char_traits, because we don't care
about the traits of an incoming string.
Use std::contiguous_iterator in the __effective_range(const Source&
Hi Tobias,
Am 13.10.21 um 18:01 schrieb Tobias Burnus:
Dear all,
a minor update [→ v3].
this has become an impressive work.
I searched for XFAIL in Sandra's c-interop/ and found
two remaining true** xfails, now fixed:
- gfortran.dg/c-interop/typecodes-scalar-basic.f90
The conversion of
Adjust the __detail::__effective_range overloads so they always return a
string or string view using std::char_traits, because we don't care
about the traits of an incoming string.
Use std::contiguous_iterator in the __effective_range(const Source&)
overload, to allow returning a basic_string_view
When creating a path from a pair of non-contiguous iterators we pass the
iterators to _S_convert(Iter, Iter). That function passes the iterators
to __string_from_range to get a contiguous sequence of characters, and
then calls _S_convert(const C*, const C*) to perform the encoding
conversions. If t
Dear Fortranners,
another simple and obvious fix: we need to reorder the argument checks
to the SHAPE intrinsic so that invalid KIND arguments can be detected.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
As I consider this a safe fix, I'd like to backport to suitable branches.
Thanks,
H
Dear Fortranners,
when simplifying RESHAPE we hit a gcc_assert for negative entries in the
SHAPE array. Obvious solution: replace gcc_assert by an error message.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
As this is a safe fix, I'd like to backport to suitable branches.
Thanks,
Harald
Simple mangled names (only with identifiers) are not being covered by coverage
tests.
Signed-off-by: Luís Ferreira
libiberty/ChangeLog:
* testsuite/d-demangle-expected: add test cases for simple special
mangles
---
libiberty/testsuite/d-demangle-expected | 8
1 file changed,
On Oct 12, 2021, Richard Biener wrote:
> Are there any issues with respect to debugging when using such
> asm()s?
Not in this case. When creating short-lived copies for immediate use,
like I do in the proposed patch, either the original value remains live
in its original location and we use an
Coverage tests doesn't include a case for function literals
Signed-off-by: Luís Ferreira
libiberty/ChangeLog:
* testsuite/d-demangle-expected: add test case for function literals
---
libiberty/testsuite/d-demangle-expected | 4
1 file changed, 4 insertions(+)
diff --git a/libiber
On Tue, Oct 12, 2021 at 04:57:43PM +0800, HAO CHEN GUI wrote:
> b/gcc/config/rs6000/rs6000-call.c
> index b4e13af4dc6..90527734ceb 100644
> --- a/gcc/config/rs6000/rs6000-call.c
> +++ b/gcc/config/rs6000/rs6000-call.c
> @@ -12159,6 +12159,11 @@ rs6000_gimple_fold_builtin (gimple_stmt_iterator
> *g
On Wed, Oct 13, 2021 at 10:29:26AM +0200, Richard Biener wrote:
> On Wed, Oct 13, 2021 at 9:43 AM HAO CHEN GUI wrote:
> >As to IEEE behavior, do you mean "Minimum and maximum operations"
> > defined in IEEE-754 2019? If so, I think VSX/altivec min/max instructions
> > don't conform with it.
On Linux/x86_64,
3c0194d7ff21d61c02f3c6b111c83ef24a69e1f0 is the first bad commit
commit 3c0194d7ff21d61c02f3c6b111c83ef24a69e1f0
Author: Richard Biener
Date: Mon Oct 11 12:27:10 2021 +0200
tree-optimization/102659 - avoid undefined overflow after if-conversion
caused
FAIL: gcc.dg/tortur
This also helps get rid of warning
ctfc.h:215:18: warning: comma at end of enumerator list [-Wpedantic]
CTF_DTU_D_SLICE,
gcc/ChangeLog:
* ctfc.h (enum ctf_dtu_d_union_enum): Remove redundant comma.
---
gcc/ctfc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc
Hi
libstdc++: [_GLIBCXX_DEBUG] Implement unordered container merge
The _GLIBCXX_DEBUG unordered containers need a dedicated merge
implementation
so that any existing iterator on the transfered nodes is properly
invalidated.
Add typedef/using declaration for everything used as
On Mon, Oct 11, 2021 at 07:11:13PM -0500, Segher Boessenkool wrote:
> On Mon, Aug 23, 2021 at 02:03:10PM -0500, Paul A. Clarke wrote:
> > Some compatibility implementations of x86 intrinsics include
> > Power intrinsics which require POWER8. Guard them.
>
> > emmintrin.h:
> > - _mm_cmpord_pd: Rem
On 10/13/21 2:25 AM, Richard Biener wrote:
On Wed, Oct 13, 2021 at 3:32 AM Martin Sebor via Gcc-patches
wrote:
On 10/11/21 6:26 PM, Joseph Myers wrote:
The testcase uses the __seg_fs address space, which is x86-specific, but
it isn't in an x86-specific directory or otherwise restricted to x86
Hi,
On Mon, Sep 27 2021, Richard Biener via Gcc-patches wrote:
>
[...]
>
> The following is what I have pushed after re-bootstrapping and testing
> on x86_64-unknown-linux-gnu.
>
> Richard.
>
> From fc335f9fde40d7a20a1a6e38fd6f842ed93a039e Mon Sep 17 00:00:00 2001
> From: Richard Biener
> Date: W
On Wed, 2021-10-13 at 16:42 +0100, Luís Ferreira wrote:
> On Wed, 2021-10-13 at 16:34 +0100, Luís Ferreira wrote:
> > Since Tuple!() is templated type from standard library, this can
> > make
> > two
> > demangled names undistinguishable.
> >
> > Signed-off-by: Luís Ferreira
> >
> > libiberty/Ch
Since Tuple!() is templated type from standard library, this can make two
demangled names undistinguishable.
Signed-off-by: Luís Ferreira
libiberty/ChangeLog:
* d-demangle.c (dlang_parse_tuple): use tuple() instead of Tuple!()
* testsuite/d-demangle-expected: rename the tests to
This patches patch allows inlining 64-bit hardware multiplication on 32-bit
hppa targets
instead of using __muldi3 from libgcc. This should improve performance at the
expense of
a slight increase in code size.
We need this because I am testing a change to build libgcc with software float
and
Dear all,
a minor update [→ v3].
I searched for XFAIL in Sandra's c-interop/ and found
two remaining true** xfails, now fixed:
- gfortran.dg/c-interop/typecodes-scalar-basic.f90
The conversion of scalars of type(c_ptr) was mishandled;
fixed now; the fix did run into issues converting a stri
Currently _D8demangle4testFYv and _D8demangle4testFXv report the same demangled
symbol and they are not the same. The official demangler reports
"demangle.test(, ...)", which is the distinguishable way to do it.
Signed-off-by: Luís Ferreira
libiberty/ChangeLog:
* d-demangle.c (dlang_fun
> -Original Message-
> From: Andre Vieira (lists)
> Sent: Wednesday, October 13, 2021 2:09 PM
> To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
> Cc: Christophe Lyon
> Subject: Re: [arm] Fix MVE addressing modes for VLDR[BHW] and
> VSTR[BHW]
>
>
> On 13/10/2021 13:37, Kyrylo Tkachov wrot
On Wed, 2021-10-13 at 16:34 +0100, Luís Ferreira wrote:
> Since Tuple!() is templated type from standard library, this can make
> two
> demangled names undistinguishable.
>
> Signed-off-by: Luís Ferreira
>
> libiberty/ChangeLog:
>
> * d-demangle.c (dlang_parse_tuple): use tuple() instea
Since Tuple!() is templated type from standard library, this can make two
demangled names undistinguishable.
Signed-off-by: Luís Ferreira
libiberty/ChangeLog:
* d-demangle.c (dlang_parse_tuple): use tuple() instead of Tuple!()
---
libiberty/d-demangle.c | 2 +-
1 file changed, 1 insert
>> gcc/
>> * config/rs6000/rs6000-call.c (altivec_expand_lxvr_builtin):
>> Modify the expansion for sign extension. All extentions are done
>> within VSX resgisters.
>
> Two typos here: extentions => extensions, resgisters => registers.
This is okay with Bill's comments ad
> The patch punishes reload of alternative pair of "d, Z" for
> movsi_internal1. The reload occurs if 'Z' doesn't match and generates an
> additional insn. So the memory reload should be punished.
>
> Bootstrapped and tested on powerpc64le-linux with no regressions. Is this
> okay for trunk?
2021-08-25 Haochen Gui
gcc/
* config/rs6000/rs6000-call.c (rs6000_gimple_fold_builtin):
Modify the VSX_BUILTIN_XVMINDP, ALTIVEC_BUILTIN_VMINFP,
VSX_BUILTIN_XVMAXDP, ALTIVEC_BUILTIN_VMAXFP expansions.
Please write something more than "modify". The ChangeLog should be
more like the
Hello,
[this is the fourth attempt to write a comment/review/opinion for this
ao_ref-in-tcc_reference, please accept some possible incoherence]
On Tue, 12 Oct 2021, Richard Biener via Gcc-patches wrote:
> This prototype hack introduces a new tcc_reference TREE_AOREFWRAP
> which we can use to wr
On 10/13/21 1:43 AM, Kewen.Lin wrote:
on 2021/10/13 下午2:29, Hongtao Liu via Gcc-patches wrote:
On Wed, Oct 13, 2021 at 11:34 AM Hongtao Liu wrote:
On Tue, Oct 12, 2021 at 11:49 PM Martin Sebor wrote:
On 10/11/21 8:31 PM, Hongtao Liu wrote:
On Tue, Oct 12, 2021 at 4:08 AM Martin Sebor via
Hi,
in spring I added code eliminating any statements using parameters
removed by IPA passes (to fix PR 93385). That patch fixed issues such
as divisions by zero that such code could perform but it only reset
all affected debug bind statements, this one updates them with
expressions which can all
On Wed, Oct 13, 2021 at 4:00 PM Iain Sandoe wrote:
>
> The code that checks to see if objects have LTO content via
> simple-object was not releasing resources, fixed thus.
>
> tested on x86_64, powerpc64le linux, powerpc-aix, i686,x86_64-darwin,
> OK for master and backports?
OK.
Richard.
> tha
The code that checks to see if objects have LTO content via
simple-object was not releasing resources, fixed thus.
tested on x86_64, powerpc64le linux, powerpc-aix, i686,x86_64-darwin,
OK for master and backports?
thanks
Iain
Signed-off-by: Iain Sandoe
gcc/ChangeLog:
* collect2.c (is_l
On Wed, Oct 13, 2021 at 6:03 AM Richard Biener
wrote:
>
> On Wed, Oct 13, 2021 at 2:56 PM H.J. Lu wrote:
> >
> > On Wed, Oct 13, 2021 at 5:45 AM Richard Biener
> > wrote:
> > >
> > > On Thu, Sep 2, 2021 at 5:50 PM H.J. Lu wrote:
> > > >
> > > > Change in the v2 patch:
> > > >
> > > > 1. Disable
On Wed, Oct 13, 2021 at 3:12 PM Martin Liška wrote:
>
> On 10/13/21 14:50, Richard Biener wrote:
> > It does, yes. But that's a ^ with flag_var_tracking_assignments_toggle;)
> >
> > It's also one of the more weird flags, so it could be applied after the
> > otherwise single set of flag_var_tracki
On 10/11/21 16:05, Martin Liška wrote:
May I install the patch now?
Pushed to master, I guess we can tweak documentation in the future
if needed.
Martin
On 10/13/21 14:50, Richard Biener wrote:
It does, yes. But that's a ^ with flag_var_tracking_assignments_toggle;)
It's also one of the more weird flags, so it could be applied after the
otherwise single set of flag_var_tracking_assignments ...
Well, it's far from being simple.
Can we please m
On 13/10/2021 13:37, Kyrylo Tkachov wrote:
Hi Andre,
@@ -24276,7 +24271,7 @@ arm_print_operand (FILE *stream, rtx x, int code)
else if (code == POST_MODIFY || code == PRE_MODIFY)
{
asm_fprintf (stream, "[%r", REGNO (XEXP (addr, 0)));
- postinc_reg = XEX
On Wed, Oct 13, 2021 at 2:56 PM H.J. Lu wrote:
>
> On Wed, Oct 13, 2021 at 5:45 AM Richard Biener
> wrote:
> >
> > On Thu, Sep 2, 2021 at 5:50 PM H.J. Lu wrote:
> > >
> > > Change in the v2 patch:
> > >
> > > 1. Disable static trampolines by default.
> > >
> > >
> > > GCC maintained a copy of li
On Wed, Oct 13, 2021 at 5:45 AM Richard Biener
wrote:
>
> On Thu, Sep 2, 2021 at 5:50 PM H.J. Lu wrote:
> >
> > Change in the v2 patch:
> >
> > 1. Disable static trampolines by default.
> >
> >
> > GCC maintained a copy of libffi snapshot from 2009 and cherry-picked fixes
> > from upstream over t
> -Original Message-
> From: Tamar Christina
> Sent: Wednesday, October 13, 2021 12:06 PM
> To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
> Cc: nd ; Richard Earnshaw ;
> Marcus Shawcroft ; Richard Sandiford
>
> Subject: RE: [PATCH 4/7]AArch64 Add pattern xtn+xtn2 to uzp2
>
> >
> > Hmmm
On Wed, Oct 13, 2021 at 1:59 PM Martin Liška wrote:
>
> On 10/13/21 10:47, Richard Biener wrote:
> > Let's split this;) The debug_inline_points part is OK.
>
> Fine.
>
> >
> > How can debug_variable_location_views be ever -1? But the
> > debug_variable_location_views part looks OK as well.
>
>
On Thu, Sep 2, 2021 at 5:50 PM H.J. Lu wrote:
>
> Change in the v2 patch:
>
> 1. Disable static trampolines by default.
>
>
> GCC maintained a copy of libffi snapshot from 2009 and cherry-picked fixes
> from upstream over the last 10+ years. In the meantime, libffi upstream
> has been changed sig
Hi Andre,
> -Original Message-
> From: Andre Vieira (lists)
> Sent: Tuesday, October 12, 2021 5:42 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Christophe Lyon
>
> Subject: [arm] Fix MVE addressing modes for VLDR[BHW] and VSTR[BHW]
>
> Hi,
>
> The way we were previously deal
On Sun, Oct 10, 2021 at 3:49 PM H.J. Lu wrote:
>
> Changes in v4:
>
> 1. Bypass redundant check when inputs have been transformed to the
> equivalent canonical form with valid bit operation.
>
> Changes in v3:
>
> 1. Check invalid bit operation.
>
> commit adedd5c173388ae505470df152b9cb3947339566
Currently when adding a sequence before there's no way to get the
iterator placed at the last added stmt which results in convoluted
code in the if-conversion usecase. The following adds
GSI_LAST_NEW_STMT and corrects one obvious mistake in
execute_update_addresses_taken as well as tries to avoid
On Tue, 5 Oct 2021, Tamar Christina wrote:
> Hi All,
>
> Here's a new version of the patch handling both scalar and vector modes
> and non-uniform constant vectors.
>
> Bootstrapped Regtested on aarch64-none-linux-gnu,
> x86_64-pc-linux-gnu and no regressions.
>
> In order to not break IVopts a
On Mon, 11 Oct 2021, Tamar Christina wrote:
> Hi all,
>
> Here's a new version of the patch.
>
> > >>> " If an exceptional condition occurs during the evaluation of an
> > >>> expression
> > >> (that is, if the result is not mathematically defined or not in the
> > >> range of representable valu
On 10/13/21 10:47, Richard Biener wrote:
Let's split this;) The debug_inline_points part is OK.
Fine.
How can debug_variable_location_views be ever -1? But the
debug_variable_location_views part looks OK as well.
It comes from here:
gvariable-location-views=incompat5
Common Driver Rejec
On Wed, Oct 13, 2021 at 12:02 PM Martin Liška wrote:
>
> On 10/13/21 10:39, Richard Biener wrote:
> > On Tue, Oct 12, 2021 at 5:11 PM Martin Liška wrote:
> >>
> >> On 10/12/21 15:37, Richard Biener wrote:
> >>> by adding EnabledBy(funroll-loops) to the respective options instead
> >>> (and funrol
Richard Biener writes:
> On Wed, 13 Oct 2021, Richard Sandiford wrote:
>
>> Richard Biener via Gcc-patches writes:
>> > The following makes sure to rewrite arithmetic with undefined behavior
>> > on overflow to a well-defined variant when moving them to be always
>> > executed as part of doing if
On Wed, 13 Oct 2021, Richard Sandiford wrote:
> Richard Biener via Gcc-patches writes:
> > The following makes sure to rewrite arithmetic with undefined behavior
> > on overflow to a well-defined variant when moving them to be always
> > executed as part of doing if-conversion for loop vectorizat
>
> Hmmm these patterns are identical in what they match they just have the
> effect of printing operands 1 and 2 in a different order.
> Perhaps it's more compact to change the output template into a
> BYTES_BIG_ENDIAN ?
> "uzp1\\t%0., %1., %2."" :
> uzp1\\t%0., %2., %1."
> and avoid having a sec
Richard Biener via Gcc-patches writes:
> The following makes sure to rewrite arithmetic with undefined behavior
> on overflow to a well-defined variant when moving them to be always
> executed as part of doing if-conversion for loop vectorization.
>
> Bootstrapped and tested on x86_64-unknown-linu
VPR_REG should be part of ALL_REGS, this patch fixes this omission.
2021-10-13 Christophe Lyon
gcc/
* config/arm/arm.h (REG_CLASS_CONTENTS): Add VPR_REG to ALL_REGS.
diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index eae1b1cd0fb..fab39d05916 100644
--- a/gcc/config
This patch covers a few non-load/store builtins where we do not use
the iterator and thus we cannot use .
We need to update the expected code in cde-mve-full-assembly.c because
we now use mve_movv16qi instead of movhi to generate the vmsr
instruction.
2021-10-13 Christophe Lyon
gcc/
This patch covers a few builtins where we do not use the
iterator and thus we cannot use .
For v2di instructions, we use the V8BI mode for predicates.
2021-10-13 Christophe Lyon
gcc/
PR target/100757
PR target/101325
* config/arm/arm-builtins.c (STRSBS_P_QUALI
This is mostly a mechanical change, only tested by the intrinsics
expansion tests.
2021-10-13 Christophe Lyon
gcc/
PR target/100757
PR target/101325
* config/arm/arm-builtins.c (BINOP_UNONE_NONE_NONE_QUALIFIERS):
Delete.
(TERNOP_UNONE_NONE_NONE_U
The problem in this PR is that we call VPSEL with a mask of vector
type instead of HImode. This happens because operand 3 in vcond_mask
is the pre-computed vector comparison and has vector type.
This patch fixes it by implementing TARGET_VECTORIZE_GET_MASK_MODE,
returning the appropriate VxBI mode
On Mon, Oct 11, 2021 at 4:10 PM Richard Sandiford via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> Christophe Lyon via Gcc-patches writes:
> > The vmvnq_n* intrinsics and have [u]int[16|32]_t arguments, so use
> > iterator instead of HI in mve_vmvnq_n_.
> >
> > 2021-09-03 Christophe Lyon
>
We make use of qualifier_predicate to describe MVE builtins
prototypes, restricting to auto-vectorizable vcmp* and vpsel builtins,
as they are exercised by the tests added earlier in the series.
Special handling is needed for mve_vpselq because it has a v2di
variant, which has no natural VPR.P0 re
This patch implements support for vectors of booleans to support MVE
predicates, instead of HImode. Since the ABI mandates pred16_t (aka
uint16_t) to represent predicates in intrinsics prototypes, we
introduce a new "predicate" type qualifier so that we can map relevant
builtins HImode arguments a
The vmvnq_n* intrinsics and have [u]int[16|32]_t arguments, so use
iterator instead of HI in mve_vmvnq_n_.
2021-10-13 Christophe Lyon
gcc/
* config/arm/mve.md (mve_vmvnq_n_): Use V_elem mode
for operand 1.
diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md
ind
VPR_REG is the only register in its class, so it should be handled by
TARGET_CLASS_LIKELY_SPILLED_P, which is achieved by calling
default_class_likely_spilled_p. No test fails without this patch, but
it seems it should be implemented.
2021-10-13 Christophe Lyon
gcc/
* config/a
At some point during the development of this patch series, it appeared
that in some cases the register allocator wants “VPR or general”
rather than “VPR or general or FP” (which is the same thing as
ALL_REGS). The series does not seem to require this anymore, but it
seems to be a good thing to do
These tests are derived from the one provided in the PR: there is a
compile-only test because I did not have access to anything that could
execute MVE code until recently.
I have been able to add an executable test since QEMU supports MVE.
Instead of adding arm_v8_1m_mve_hw, I update arm_mve_hw so
These tests currently trigger an ICE which is fixed later in the patch
series.
The pr100757*.c testcases are derived from
gcc.c-torture/compile/20160205-1.c, forcing the use of MVE, and using
various types and return values different from 0 and 1 to avoid
commonalization with boolean masks. In ad
This patch mainly adds Neon tests similar to existing MVE ones,
to make sure we do not break Neon when fixing MVE.
mve-vcmp-f32-2.c is similar to mve-vcmp-f32.c but uses a conditional
with 2.0f and 3.0f constants to help scan-assembler-times.
2021-10-13 Christophe Lyon
gcc/testsuite/
This is v2 of this patch series, addressing the comments I received.
The changes v1 -> v2 are:
- Patch 3: added an executable test, and updated
check_effective_target_arm_mve_hw
- Patch 4: split into patch 4 and patch 14 (to keep numbering the same
for the other patches)
- Patch 5: updated arm
On 10/13/21 10:39, Richard Biener wrote:
On Tue, Oct 12, 2021 at 5:11 PM Martin Liška wrote:
On 10/12/21 15:37, Richard Biener wrote:
by adding EnabledBy(funroll-loops) to the respective options instead
(and funroll-loops EnabledBy(funroll-all-loops))
All right, so the suggested approach wo
On 11/10/21 20:38 +0100, Jonathan Wakely wrote:
On 08/10/21 12:23 +0100, Jonathan Wakely wrote:
This adds an inline wrapper for std::terminate that doesn't add the
declaration of std::terminate to namespace std. This allows the
library to terminate without including all of .
libstdc++-v3/Change
The following fixes the volatileness check of IPA SRA which was
looking at the innermost reference when checking TREE_THIS_VOLATILE
but the reference to check is the outermost one.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-10-13 Richard Biener
PR ipa/102714
On 13/10/2021 下午 4:29, Richard Biener wrote:
On Wed, Oct 13, 2021 at 9:43 AM HAO CHEN GUI wrote:
Richard,
Thanks so much for your comments.
As far as I know, VSX/altivec min/max instructions don't conform with
C-Sytle Min/Max Macro. The fold converts it to MIN/MAX_EXPR then it has
On Wed, Oct 13, 2021 at 10:23 AM Roger Sayle wrote:
>
>
> Good catch. I agree with Hongtao that although my testing revealed
> no problems with the previous version of this patch, it makes sense to
> call gen_reg_rtx to generate an pseudo intermediate instead of attempting
> to reuse the existing
Hi,
Current mask/mask3 implementation for complex fma contains
duplicated parameter in macro, which may cause error at -O0.
Refactor macro implementation to builtins to avoid potential
error.
For round intrinsic with NO_ROUND as input, ix86_erase_embedded_rounding
erases embedded_rounding upspec
On Tue, Oct 12, 2021 at 5:21 PM Martin Liška wrote:
>
> On 10/11/21 15:45, Richard Biener wrote:
> > Btw, I'd be more comfortable when the move of the code would be
> > independent of the adjustment to not rely on AUTODETECT_VALUE.
> > Can we do the latter change first (IIRC the former one failed
I recently saw that 'ancestor:' wasn't handled in -fdump-parse-tree.
I also did run once into an ICE for the swap flag in atomics when
dumping. – This fixes the two.
Additionally, I changed 'ancestor' to a bit field.
Comments? If not, I will commit it later today.
Tobias
-
Sieme
On Tue, Oct 12, 2021 at 5:11 PM Martin Liška wrote:
>
> On 10/12/21 15:37, Richard Biener wrote:
> > by adding EnabledBy(funroll-loops) to the respective options instead
> > (and funroll-loops EnabledBy(funroll-all-loops))
>
> All right, so the suggested approach works correctly.
>
> Patch can boo
On Wed, Oct 13, 2021 at 9:43 AM HAO CHEN GUI wrote:
>
> Richard,
>
>Thanks so much for your comments.
>
>As far as I know, VSX/altivec min/max instructions don't conform with
> C-Sytle Min/Max Macro. The fold converts it to MIN/MAX_EXPR then it has a
> chance to be implemented by scalar
On 10/13/21 13:50, Richard Biener wrote:
On Tue, Oct 12, 2021 at 8:34 PM Siddhesh Poyarekar wrote:
The warning is falsely triggered for THREAD_SELF in glibc when
accessing TCB through the segment register.
I think this is a more generic bug - the warning is also bogus if the
general address
On Wed, Oct 13, 2021 at 3:32 AM Martin Sebor via Gcc-patches
wrote:
>
> On 10/11/21 6:26 PM, Joseph Myers wrote:
> > The testcase uses the __seg_fs address space, which is x86-specific, but
> > it isn't in an x86-specific directory or otherwise restricted to x86
> > targets; thus, I'd expect it to
1 - 100 of 107 matches
Mail list logo
