Tamar Christina writes:
> Hi All,
>
> There's a slight mismatch between the vectorizer optabs and the intrinsics
> patterns for NEON. The vectorizer expects operands[3] and operands[0] to be
> the same but the aarch64 intrinsics expanders expect operands[0] and
> operands[1] to be the same.
>
> T
Tamar Christina writes:
> Hi All,
>
> The previous fix for this problem was wrong due to a subtle difference between
> where NEON expects the RMW values and where intrinsics expects them.
>
> The insn pattern is modeled after the intrinsics and so needs an expand for
> the vectorizer optab to swit
Jonathan Wright via Gcc-patches writes:
> Hi,
>
> A recent change "gcc: Add vec_select -> subreg RTL simplification"
> updated the expected test results for SVE extraction tests. The new
> result should only have been changed for little endian. This patch
> restores the old expected result for big
On Tue, 13 Jul 2021 at 20:09, Patrick Palka via Libstdc++
wrote:
>
> The primary template for _CachedPosition is a dummy implementation for
> non-forward ranges, the iterators for which generally can't be cached.
> Because this implementation doesn't actually cache anything, _M_has_value
> is defi
On 7/15/21 9:06 AM, Richard Biener wrote:
On Thu, Jul 15, 2021 at 1:06 PM Aldy Hernandez wrote:
Currently gimple_expr_type is ICEing because it calls gimple_call_return_type.
I still think gimple_call_return_type should return void_type_node
instead of ICEing, but this will also fix my proble
On Tue, 13 Jul 2021 at 19:05, Patrick Palka via Libstdc++
wrote:
>
> This gives the new split_view's sentinel type a defaulted default
> constructor, something which was overlooked in r12-1665. This patch
> also fixes a couple of other issues with the new split_view as reported
> in the PR.
>
> T
Sorry for the slow review.
Robin Dapp writes:
> When if-converting multiple SETs and we encounter a swap-style idiom
>
> if (a > b)
> {
> tmp = c; // [1]
> c = d;
> d = tmp;
> }
>
> ifcvt should not generate a conditional move for the instruction at
> [1].
>
> In ord
Robin Dapp writes:
> This lifts the restriction of not allowing constants for
> noce_convert_multiple. The code later checks if a valid sequence
> is produced anyway.
OK, thanks.
I was initially worried that this might trump later, more targetted
optimisations, but it looks like that's already
Robin Dapp writes:
> When noce_convert_multiple is called the original costs are not yet
> initialized. Therefore, up to now, costs were only ever unfairly
> compared against COSTS_N_INSNS (2). This would lead to
> default_noce_conversion_profitable_p () rejecting all but the most
> contrived of
General regs on 32bit targets do not support 128bit modes,
including TDmode.
gcc/
2021-07-15 Uroš Bizjak
PR target/101346
* config/i386/i386.h (VALID_SSE_REG_MODE): Add TDmode.
(VALID_INT_MODE_P): Add SDmode and DDmode.
Add TDmode for TARGET_64BIT.
(VALID_DFP_MODE_P): Remo
Robin Dapp writes:
> Currently we only ever call emit_conditional_move with the comparison
> (as well as its comparands) we got from the jump. Thus, backends are
> going to emit a CC comparison for every conditional move that is being
> generated instead of re-using the existing CC.
> This, combi
The combination of DR 2481 and DR 2126 should allow us to do
void f()
{
constexpr const int &r = 42;
static_assert(r == 42);
}
because [expr.const]/4.7 now says that "a temporary object of
non-volatile const-qualified literal type whose lifetime is extended to
that of a variable tha
On Thu, Jul 15, 2021 at 09:40:52AM +0800, Kewen.Lin wrote:
> on 2021/7/15 上午3:32, Segher Boessenkool wrote:
> > The normal rule is you cannot go over 80. It is perfectly fine to have
> > shorter lines, certainly if that is nice for some other reason, so
> > automatically (by some tool) changing th
Added compatible implementation of _mm_minpos_epu16 for powerpc.
Copied, improved, and fixed testcase from i386.
Tested on BE, LE (32 and 64bit).
Paul A. Clarke (2):
rs6000: Add support for _mm_minpos_epu16
- v3: Changes per Bill's review.
rs6000: Add test for _mm_minpos_epu16
- v3: Change
Add a naive implementation of the subject x86 intrinsic to
ease porting.
2021-07-15 Paul A. Clarke
gcc
* config/rs6000/smmintrin.h (_mm_minpos_epu16): New.
---
v3: Minor formatting changes per review from Bill.
v2: Minor formatting changes per review from Segher.
gcc/config/rs6000/sm
Copy the test for _mm_minpos_epu16 from
gcc/testsuite/gcc.target/i386/sse4_1-phminposuw.c, with
a few adjustments:
- Adjust the dejagnu directives for powerpc platform.
- Make the data not be monotonically increasing,
such that some of the returned values are not
always the first value (index
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as c031ea2782a1873eee5ba82fb114cd87ff831412.
gcc/analyzer/ChangeLog:
* svalue.h (is_a_helper ::test): Make
param and template param const.
(is_a_helper ::test): Likewise.
(is_a_helper ::t
Jonathan pointed me at this issue where
constexpr unsigned f() { constexpr int n = -1; return unsigned{n}; }
is accepted in system headers, despite the narrowing conversion from
a constant. I suspect that whereas narrowing warnings should be
disabled, ill-formed narrowing of constants should b
On Fri, Jul 16, 2021 at 1:30 AM H.J. Lu via Gcc-patches
wrote:
>
> In a single SET, all bits of the source YMM/ZMM register are zero when
>
> 1. The source is contant zero.
> 2. The source YMM/ZMM operand are defined from contant zero.
>
> and we don't set AVX_U128_DIRTY.
>
> gcc/
>
> PR t
On Thu, Jul 15, 2021 at 7:48 PM Richard Biener wrote:
>
> On Thu, 15 Jul 2021, Hongtao Liu wrote:
>
> > On Thu, Jul 15, 2021 at 6:45 PM Richard Biener via Gcc-patches
> > wrote:
> > >
> > > On Thu, Jul 15, 2021 at 12:30 PM Richard Biener wrote:
> > > >
> > > > The following extends the existing
On Thu, Jul 15, 2021 at 8:33 PM Richard Biener wrote:
>
> The following defaults --param vect-partial-vector-usage to zero
> for x86_64 matching existing behavior where support for this
> is not present.
>
> OK for trunk?
>
Ok.
> Thanks,
> Richard/
>
> 2021-07-15 Richard Biener
>
> * co
From: Andrew Pinski
Every base 10 digit will take use ~3.32 bits to represent. So for
a 64bit signed integer, it is 20 characters. The buffer was only
20 so it did not fit; add in the null character and "-O" part,
the buffer would be 3 bytes too small.
Instead of just increasing the size of the
On Thu, Jul 15, 2021 at 6:36 PM Hongtao Liu wrote:
>
> On Fri, Jul 16, 2021 at 1:30 AM H.J. Lu via Gcc-patches
> wrote:
> >
> > In a single SET, all bits of the source YMM/ZMM register are zero when
> >
> > 1. The source is contant zero.
> > 2. The source YMM/ZMM operand are defined from contant
On Thu, Jul 15, 2021 at 10:01:01AM +0200, Richard Biener wrote:
> On Thu, Jul 15, 2021 at 4:24 AM Trevor Saunders wrote:
> >
> > On Wed, Jul 14, 2021 at 01:27:54PM +0200, Richard Biener wrote:
> > > On Wed, Jul 14, 2021 at 10:20 AM Trevor Saunders
> > > wrote:
> > > >
> > > > prior to this commi
Hi Mr. Santana,
Some strange stuff happened with my previous comment. I've been struggling
with this lately, so this patch would be really useful.
Em qui., 15 de jul. de 2021 às 15:44, Abraão de Santana <
abraaocsant...@gmail.com> escreveu:
> Hey João , I think there's a problem with your email,
On Thu, Jul 15, 2021 at 9:40 AM Tamar Christina via Gcc-patches
wrote:
>
> Hi All,
>
> These testcases accidentally contain the wrong signs for the expected values
> for the scalar code. The vector code however is correct.
>
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
>
> Co
The last missing piece of the C++17 standard library is the hardware
intereference size constants. Much of the delay in implementing these has
been due to uncertainty about what the right values are, and even whether
there is a single constant value that is suitable; the destructive
interference s
Adding CCs that got lost in the initial mail.
On Thu, Jul 15, 2021 at 10:36 PM Jason Merrill wrote:
> The last missing piece of the C++17 standard library is the hardware
> intereference size constants. Much of the delay in implementing these has
> been due to uncertainty about what the right v
On Thu, Jul 15, 2021 at 10:41 PM Jason Merrill via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> Adding CCs that got lost in the initial mail.
>
> On Thu, Jul 15, 2021 at 10:36 PM Jason Merrill wrote:
>
> > The last missing piece of the C++17 standard library is the hardware
> > intereference s
When I was reading code in conjunction with fixing PR101317, I noticed
an unrelated bug in the implementation of CFI_allocate and
CFI_select_part: they were mis-handling the CFI_signed_char type as if
it were a Fortran character type for the purposes of deciding whether to
use the elem_len arg
2021-07-12 Ankur Saini
gcc/analyzer/ChangeLog:
* call-string.cc (call_string::element_t::operator==): New operator.
(call_String::element_t::operator!=): New operator.
(call_string::element_t::get_caller_function): New function.
(call_string::element_t::get_calle
on 2021/7/15 下午7:58, Richard Biener wrote:
> On Thu, Jul 15, 2021 at 10:41 AM Kewen.Lin wrote:
>>
>> on 2021/7/15 下午4:04, Kewen.Lin via Gcc-patches wrote:
>>> Hi Uros,
>>>
>>> on 2021/7/15 下午3:17, Uros Bizjak wrote:
On Thu, Jul 15, 2021 at 9:07 AM Kewen.Lin wrote:
>
> on 2021/7/14 下午
Ping again.
On Wed, 2021-06-23 at 11:11 +0800, Xi Ruoyao wrote:
> Commit message shamelessly copied from 1777beb6b129 by jakub:
>
> This function, because it is sometimes called even outside of function
> bodies, uses create_tmp_var_raw rather than create_tmp_var. But in
> order
> for that to wo
Ping again.
I heard that Matthew is too busy to deal with MIPS things from someone's
private mail. Hope someone else can review it.
On Mon, 2021-06-21 at 21:42 +0800, Xi Ruoyao wrote:
> Middle-end started to emit vec_cmp and vec_cmpu since GCC 11, causing
> ICE on MIPS with MSA enabled. Add the
On Fri, 16 Jul 2021, Hongtao Liu wrote:
> On Thu, Jul 15, 2021 at 7:48 PM Richard Biener wrote:
> >
> > On Thu, 15 Jul 2021, Hongtao Liu wrote:
> >
> > > On Thu, Jul 15, 2021 at 6:45 PM Richard Biener via Gcc-patches
> > > wrote:
> > > >
> > > > On Thu, Jul 15, 2021 at 12:30 PM Richard Biener
On Wednesday, 14 July 2021 14:42:01 CEST H.J. Lu wrote:
> On Wed, Jul 14, 2021 at 12:32 AM Matthias Kretz wrote:
> > OK?
> >
> > On Wednesday, 30 June 2021 10:59:28 CEST Matthias Kretz wrote:
> > > Library code, especially in headers, sometimes needs to know how the
> > > compiler interprets / op
101 - 136 of 136 matches
Mail list logo
