On 8/6/2021 2:59 PM, sunil.k.pandey via Gcc-patches wrote:
On Linux/x86_64,
f31da42e047e8018ca6ad9809273bc7efb6ffcaf is the first bad commit
commit f31da42e047e8018ca6ad9809273bc7efb6ffcaf
Author: Richard Biener
Date: Fri Aug 6 14:39:05 2021 +0200
tree-optimization/101801 - remove
Hi!
On Thu, Jul 29, 2021 at 08:30:50AM -0500, Bill Schmidt wrote:
> + const vsc __builtin_altivec_abss_v16qi (vsc);
> +ABSS_V16QI altivec_abss_v16qi {}
> +
> + const vsi __builtin_altivec_abss_v4si (vsi);
> +ABSS_V4SI altivec_abss_v4si {}
> +
> + const vss __builtin_altivec_abss_v8hi
On Fri, 6 Aug 2021, Victor Tong wrote:
Thanks for the feedback. Here's the updated pattern:
/* X - (X - Y) --> Y */
(simplify
(minus (convert1? @0) (convert2? (minus@2 (convert3? @@0) @1)))
(if (ANY_INTEGRAL_TYPE_P (type)
&& TYPE_OVERFLOW_UNDEFINED(type)
&&
On Fri, Aug 06, 2021 at 02:07:10PM -0500, Pat Haugen wrote:
> Add additional checks to verify destination[source] of a load[store]
> instruction is a register.
> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -18357,8 +18357,13 @@ is_load_insn1 (rtx pat, rtx *load_mem)
>
Thanks for the feedback. Here's the updated pattern:
/* X - (X - Y) --> Y */
(simplify
(minus (convert1? @0) (convert2? (minus@2 (convert3? @@0) @1)))
(if (ANY_INTEGRAL_TYPE_P (type)
&& TYPE_OVERFLOW_UNDEFINED(type)
&& !TYPE_OVERFLOW_SANITIZED(type)
&&
Dear Fortranners,
I intend to commit the following pretty obvious fix within the next
24 hours unless there are objections.
Regtested on x86_64-pc-linux-gnu.
Thanks,
Harald
Fortran: ICE with automatic character object, save, and various options
gcc/fortran/ChangeLog:
PR fortran/68568
On Linux/x86_64,
7b1de3eb9ed3f8dde54732d88520292c5ad1157d is the first bad commit
commit 7b1de3eb9ed3f8dde54732d88520292c5ad1157d
Author: Jonathan Wakely
Date: Thu Aug 5 13:34:00 2021 +0100
libstdc++: Move attributes that follow requires-clauses [PR101782]
caused
FAIL:
On Linux/x86_64,
f31da42e047e8018ca6ad9809273bc7efb6ffcaf is the first bad commit
commit f31da42e047e8018ca6ad9809273bc7efb6ffcaf
Author: Richard Biener
Date: Fri Aug 6 14:39:05 2021 +0200
tree-optimization/101801 - remove vect_worthwhile_without_simd_p
caused
FAIL:
On Linux/x86_64,
0d04fe49239d91787850036599164788f1c87785 is the first bad commit
commit 0d04fe49239d91787850036599164788f1c87785
Author: Jonathan Wakely
Date: Tue Aug 3 20:50:52 2021 +0100
libstdc++: Add [[nodiscard]] to sequence containers
caused
FAIL: g++.old-deja/g++.other/inline7.C
On Linux/x86_64,
31855ba6b16cd138d7484076a08cd40d609654b8 is the first bad commit
commit 31855ba6b16cd138d7484076a08cd40d609654b8
Author: Richard Biener
Date: Thu Jul 29 14:14:48 2021 +0200
Add emulated gather capability to the vectorizer
caused
FAIL: gcc.target/i386/vect-gather-1.c
On Linux/x86_64,
240b01b0215f9e46ecf04267c8a3faeb19d4fe3c is the first bad commit
commit 240b01b0215f9e46ecf04267c8a3faeb19d4fe3c
Author: Jonathan Wakely
Date: Tue Aug 3 18:06:27 2021 +0100
libstdc++: Add [[nodiscard]] to iterators and related utilities
caused
FAIL:
On Fri, 6 Aug 2021, Jakub Jelinek via Gcc-patches wrote:
> On Fri, Aug 06, 2021 at 11:53:56AM +0200, Jakub Jelinek via Gcc-patches wrote:
> > Actually, there is another change in P1949R7 that I haven't touched
> > in the patch and not sure what the implications are.
> >
> > To the
On Wed, Aug 4, 2021 at 9:24 PM Ian Lance Taylor wrote:
>
> This Go frontend patch by Cherry Mui makes the escape analysis pass
> stricter about builtin functions In the places where we handle
> builtin functions, list all supported ones, and fail if an unexpected
> one is seen. So if a new
Add additional checks to verify destination[source] of a load[store]
instruction is a register.
Modified code based on review comment to not change general logic of the flow.
Braces needed on inner if-else to prevent error during bootstrap for ambiguous
'else'.
Bootstrap/regtest on powerpc64le
On Fri, Aug 06, 2021 at 08:10:05AM -0500, Bill Schmidt wrote:
> On 8/4/21 9:06 PM, Kewen.Lin wrote:
> >- UNSPEC_VUPKHUB
> >- UNSPEC_VUPKHUH
> >- UNSPEC_VUPKLUB
> >- UNSPEC_VUPKLUH
> >+ UNSPEC_VUPKHUBHW
> >+ UNSPEC_VUPKLUBHW
>
> Up to you, but... maybe just UNSPEC_VUPKHU and
On 8/6/21 11:05 AM, Segher Boessenkool wrote:
> On Fri, Aug 06, 2021 at 10:29:40AM -0500, Pat Haugen wrote:
>> On 8/6/21 10:02 AM, Segher Boessenkool wrote:
- if (GET_CODE (pat) == SET)
+ if (GET_CODE (pat) == SET && REG_P (SET_DEST (pat)))
return find_mem_ref (SET_SRC (pat),
On Fri, Aug 06, 2021 at 10:29:40AM -0500, Pat Haugen wrote:
> On 8/6/21 10:02 AM, Segher Boessenkool wrote:
> >> - if (GET_CODE (pat) == SET)
> >> + if (GET_CODE (pat) == SET && REG_P (SET_DEST (pat)))
> >> return find_mem_ref (SET_SRC (pat), load_mem);
> >
> > So this now falls through if
On Thu, 29 Jul 2021 11:41:39 -0400
Jason Merrill wrote:
> On 7/22/21 7:15 PM, Sergei Trofimovich wrote:
> > From: Sergei Trofimovich
> >
> > r12-1804 ("cp: add support for per-location warning groups.") among other
> > things removed warning suppression from a few places including ptrmemfuncs.
On 8/6/21 10:02 AM, Segher Boessenkool wrote:
> On Fri, Aug 06, 2021 at 09:47:40AM -0500, Pat Haugen wrote:
>> Add additional checks to verify destination[source] of a load[store]
>> instruction is a register.
>
>> * config/rs6000/rs6000.c: (is_load_insn1): Verify destination is a
>>
On 8/6/21 4:50 AM, Tamar Christina wrote:
Hi All,
The build is broken since a3d3e8c362c2 since it's deleted the ability to pass
vec<> by value and now much be past by reference.
However some language hooks used by AArch64 were not updated and breaks the
build on AArch64. This patch updates
On August 6, 2021 4:09:37 PM GMT+02:00, Thomas Schwinge
wrote:
>Hi!
>
>I'm working on plugging a memory leak in an entirely different
>compartment of GCC, but also ran into this issue:
>
>On 2021-02-12T08:35:52+0100, Richard Biener via Gcc-patches
> wrote:
>> On Thu, Feb 11, 2021 at 7:35 PM
On Fri, Aug 06, 2021 at 09:47:40AM -0500, Pat Haugen wrote:
> Add additional checks to verify destination[source] of a load[store]
> instruction is a register.
> * config/rs6000/rs6000.c: (is_load_insn1): Verify destination is a
> register.
No colon before " (".
> ---
On 07/06/21 6:25 am, François Dumont wrote:
On 03/06/21 2:31 pm, Jonathan Wakely wrote:
+ }
+
/* Checks that [first, last) is a valid range, and then returns
* __first. This routine is useful when we can't use a separate
* assertion statement because, e.g., we are in a constructor.
On Fri, Aug 06, 2021 at 11:53:56AM +0200, Jakub Jelinek via Gcc-patches wrote:
> Actually, there is another change in P1949R7 that I haven't touched
> in the patch and not sure what the implications are.
>
> To the preprocessing-token non-terminal it adds
> each universal-character-name
Add additional checks to verify destination[source] of a load[store]
instruction is a register.
Bootstrap/regtest on powerpc64le with no new regressions. Ok for master?
-Pat
2021-08-06 Pat Haugen
gcc/ChangeLog:
* config/rs6000/rs6000.c: (is_load_insn1): Verify destination is a
On Fri, Aug 6, 2021 at 4:28 PM Richard Earnshaw <
richard.earns...@foss.arm.com> wrote:
>
>
> On 06/08/2021 15:21, Christophe Lyon via Gcc-patches wrote:
> > On Fri, Aug 6, 2021 at 4:08 PM Christophe Lyon <
> > christophe.lyon@gmail.com> wrote:
> >
> >>
> >>
> >> On Thu, Aug 5, 2021 at 1:58
On 06/08/2021 15:21, Christophe Lyon via Gcc-patches wrote:
On Fri, Aug 6, 2021 at 4:08 PM Christophe Lyon <
christophe.lyon@gmail.com> wrote:
On Thu, Aug 5, 2021 at 1:58 PM Richard Earnshaw wrote:
A change to the way gas interprets the .fpu directive in binutils-2.34
means that
On 06/08/2021 15:08, Christophe Lyon via Gcc-patches wrote:
On Thu, Aug 5, 2021 at 1:58 PM Richard Earnshaw wrote:
A change to the way gas interprets the .fpu directive in binutils-2.34
means that issuing .fpu will clear any features set by .arch_extension
that apply to the floating point
On August 6, 2021 3:47:44 PM GMT+02:00, Richard Sandiford
wrote:
>Richard Biener via Gcc-patches writes:
>> This removes the cost part of vect_worthwhile_without_simd_p, retaining
>> only the correctness bits. The reason is that the cost heuristic
>> do not properly account for SLP plus the
On Fri, Aug 6, 2021 at 4:08 PM Christophe Lyon <
christophe.lyon@gmail.com> wrote:
>
>
> On Thu, Aug 5, 2021 at 1:58 PM Richard Earnshaw wrote:
>
>>
>> A change to the way gas interprets the .fpu directive in binutils-2.34
>> means that issuing .fpu will clear any features set by
Hi!
I'm working on plugging a memory leak in an entirely different
compartment of GCC, but also ran into this issue:
On 2021-02-12T08:35:52+0100, Richard Biener via Gcc-patches
wrote:
> On Thu, Feb 11, 2021 at 7:35 PM Martin Sebor wrote:
>> On 2/11/21 12:59 AM, Richard Biener wrote:
>> > On
On Fri, Aug 06, 2021 at 11:55:52AM +0100, Richard Sandiford wrote:
> liuhongt via Gcc-patches writes:
> > Hi:
> > Bootstrapped and regtested on x86_64-linux-gnu{-m32,}
> > Ok for trunk?
>
> I think if anything the canonicalisation should be the other way:
> if the shift amount is an in-range
On Thu, Aug 5, 2021 at 1:58 PM Richard Earnshaw wrote:
>
> A change to the way gas interprets the .fpu directive in binutils-2.34
> means that issuing .fpu will clear any features set by .arch_extension
> that apply to the floating point or simd units. This unfortunately
> causes problems for
ping
On Fri, Jun 25, 2021 at 12:23:32PM +0200, Stefan Schulze Frielinghaus wrote:
> On Wed, Jun 16, 2021 at 04:22:35PM +0200, Richard Biener wrote:
> > On Mon, Jun 14, 2021 at 7:26 PM Stefan Schulze Frielinghaus
> > wrote:
> > >
> > > On Thu, May 20, 2021 at 08:37:24PM +0200, Stefan Schulze
Richard Biener via Gcc-patches writes:
> This removes the cost part of vect_worthwhile_without_simd_p, retaining
> only the correctness bits. The reason is that the cost heuristic
> do not properly account for SLP plus the check whether "without simd"
> applies misfires for AVX512 mask vectors
This removes the cost part of vect_worthwhile_without_simd_p, retaining
only the correctness bits. The reason is that the cost heuristic
do not properly account for SLP plus the check whether "without simd"
applies misfires for AVX512 mask vectors at the moment, leading to
missed vectorizations
On 05/08/21 19:02 +0100, Jonathan Wakely wrote:
On 05/08/21 15:40 +0100, Jonathan Wakely wrote:
On 05/08/21 15:19 +0100, Jonathan Wakely wrote:
On 04/08/21 12:55 +0100, Jonathan Wakely wrote:
This adds [[nodiscard]] throughout , as proposed by P2377R0
(with some minor corrections).
The
Hi Kewen,
On 8/4/21 9:06 PM, Kewen.Lin wrote:
Hi,
The existing vec_unpacku_{hi,lo} supports emulated unsigned
unpacking for short and char but misses the support for int.
This patch adds the support for vec_unpacku_{hi,lo}_v4si.
Meanwhile, the current implementation uses vector permutation
Tejas Belagod via Gcc-patches writes:
> Hi,
>
> Loops containing long long shifts fail to vectorize due to the vectorizer
> not being able to recognize long long right shifts. This is due to a bug
> in the iterator used for the vashr and vlshr patterns in aarch64-simd.md.
>
> Tested and
s available. */
> > > > + if (GET_MODE_INNER (mode) == DImode && !TARGET_64BIT
> > > > + && (!TARGET_AVX512F
> > > > + || (GET_MODE_SIZE (mode) < 64 && !TARGET_AVX512VL)))
> > > > return nullptr;
> > &g
Add missing operand predicate, otherwise any RTX will match.
2021-08-06 Uroš Bizjak
gcc/
PR target/101797
* config/i386/i386.md (cmove reg-to-reg move elimination peephole2s):
Add general_gr_operand predicate to operand 3.
gcc/testsuite/
PR target/101797
*
Jonathan Wright writes:
> diff --git a/gcc/testsuite/gcc.target/aarch64/vector_structure_intrinsics.c
> b/gcc/testsuite/gcc.target/aarch64/vector_structure_intrinsics.c
> index
> 60c53bc27f8378c78b119576ed19fde0e5743894..a8e31ab85d6fd2a045c8efaf2cbc42b5f40d2411
> 100644
> ---
On Fri, Aug 6, 2021 at 9:52 AM Christophe Lyon <
christophe.lyon@gmail.com> wrote:
>
>
> On Fri, Aug 6, 2021 at 4:07 AM Martin Sebor via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
>
>> On 7/30/21 9:06 AM, Jason Merrill wrote:
>> > On 7/27/21 2:56 PM, Martin Sebor wrote:
>> >> Ping:
On Mon, Aug 2, 2021 at 7:05 AM Xiong Hu Luo wrote:
>
> There was a patch trying to avoid move cold block out of loop:
>
> https://gcc.gnu.org/pipermail/gcc/2014-November/215551.html
>
> Richard suggested to "never hoist anything from a bb with lower execution
> frequency to a bb with higher one
Sorry for the slow reply.
Robin Dapp via Gcc-patches writes:
>> Hmm, OK. Doesn't expanding both versions up-front create the same kind of
>> problem that the patch is fixing, in that we expand (and therefore cost)
>> both the reversed and unreversed comparison? Also…
>>
> [..]
>>
>> …for
On Fri, Aug 6, 2021 at 11:51 AM Prathamesh Kulkarni <
prathamesh.kulka...@linaro.org> wrote:
> On Fri, 6 Aug 2021 at 14:49, Christophe Lyon
> wrote:
> >
> >
> >
> > On Fri, Aug 6, 2021 at 11:00 AM Prathamesh Kulkarni <
> prathamesh.kulka...@linaro.org> wrote:
> >>
> >> On Thu, 5 Aug 2021 at
On Tue, 3 Aug 2021, Xionghu Luo wrote:
> loop split condition is moved between loop1 and loop2, the split bb's
> count and probability should also be duplicated instead of (100% vs INV),
> secondly, the original loop1 and loop2 count need be propotional from the
> original loop.
>
> Regression
On Fri, Aug 6, 2021 at 11:05 AM Richard Sandiford
wrote:
>
> Richard Biener via Gcc-patches writes:
> > On Fri, Aug 6, 2021 at 5:32 AM liuhongt wrote:
> >>
> >> Hi:
> >> ---
> >> OK, I think sth is amiss here upthread. insv/extv do look like they
> >> are designed
> >> to work on integer modes
This patch replaces the use of BUILT_IN_CLRSB with CFN_BUILT_IN_CLRSB
in my recent patch to tree-ssa-phiopt.c. Both of these have identical
values, so there's no change in behavior, but consistent use of the same
enumeration avoids warnings when using clang (or static analysis tools).
This
On Fri, 6 Aug 2021, Tamar Christina wrote:
> Hi All,
>
> The build is broken since a3d3e8c362c2 since it's deleted the ability to pass
> vec<> by value and now much be past by reference.
>
> However some language hooks used by AArch64 were not updated and breaks the
> build on AArch64. This
liuhongt via Gcc-patches writes:
> Hi:
> Bootstrapped and regtested on x86_64-linux-gnu{-m32,}
> Ok for trunk?
I think if anything the canonicalisation should be the other way:
if the shift amount is an in-range constant, we know that it fits
within a vector element, and so the vector form
Hi All,
The build is broken since a3d3e8c362c2 since it's deleted the ability to pass
vec<> by value and now much be past by reference.
However some language hooks used by AArch64 were not updated and breaks the
build on AArch64. This patch updates these hooks.
However most of the changes are
On 06/08/2021 12:26, Martin Liška wrote:
On 8/6/21 10:05 AM, Sebastian Huber wrote:
What about the attached patch?
The patch is fine, please install it.
Thanks, I checked it in.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email:
On 8/6/21 10:05 AM, Sebastian Huber wrote:
What about the attached patch?
The patch is fine, please install it.
Martin
On Thu, 29 Jul 2021 09:49:05 +0200
Thomas Schwinge wrote:
> > namespace {
> >
> > +const pass_data pass_data_oacc_loop_designation =
> > +{
> > + GIMPLE_PASS, /* type */
> > + "oaccloops", /* name */
> > + OPTGROUP_OMP, /* optinfo_flags */
> > + TV_NONE, /* tv_id */
> > + PROP_cfg, /*
On Fri, 6 Aug 2021 at 14:49, Christophe Lyon
wrote:
>
>
>
> On Fri, Aug 6, 2021 at 11:00 AM Prathamesh Kulkarni
> wrote:
>>
>> On Thu, 5 Aug 2021 at 18:05, Christophe Lyon
>> wrote:
>> >
>> >
>> >
>> > On Thu, Aug 5, 2021 at 2:28 PM Prathamesh Kulkarni
>> > wrote:
>> >>
>> >> On Tue, 3 Aug
Jonathan Wright writes:
> Hi,
>
> As subject, this patch uses __builtin_memcpy to copy vector structures
> instead of using a union - or constructing a new opaque structure one
> vector at a time - in each of the vst[234][q] and vst1[q]_x[234] bfloat
> Neon intrinsics in arm_neon.h.
>
> It also
Jonathan Wright writes:
> Hi,
>
> As subject, this patch uses __builtin_memcpy to copy vector structures
> instead of using a union - or constructing a new opaque structure one
> vector at a time - in each of the vst2[q]_lane Neon intrinsics in
> arm_neon.h.
>
> It also adds new code generation
Jonathan Wright writes:
> Hi,
>
> As subject, this patch uses __builtin_memcpy to copy vector structures
> instead of using a union - or constructing a new opaque structure one
> vector at a time - in each of the vst3[q]_lane Neon intrinsics in
> arm_neon.h.
>
> It also adds new code generation
Jonathan Wright writes:
> Hi,
>
> As subject, this patch uses __builtin_memcpy to copy vector structures
> instead of using a union - or constructing a new opaque structure one
> vector at a time - in each of the vst4[q]_lane Neon intrinsics in
> arm_neon.h.
>
> It also adds new code generation
On Wed, 4 Aug 2021 15:56:49 +0200
Thomas Schwinge wrote:
> > This version of the patch [...]
> > avoids moving SESE-region finding code out
> > of the NVPTX backend
>
> So that's 'struct bb_sese' and following functions.
>
> > since that code isn't used by the middle-end worker
> >
On Fri, Aug 6, 2021 at 11:00 AM Prathamesh Kulkarni <
prathamesh.kulka...@linaro.org> wrote:
> On Thu, 5 Aug 2021 at 18:05, Christophe Lyon
> wrote:
> >
> >
> >
> > On Thu, Aug 5, 2021 at 2:28 PM Prathamesh Kulkarni <
> prathamesh.kulka...@linaro.org> wrote:
> >>
> >> On Tue, 3 Aug 2021 at
On Fri, Aug 6, 2021 at 10:05 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Hello Christophe,
>
> On 06/08/2021 09:50, Christophe Lyon wrote:
> > Looks like there's a problem with your patch:
> >
>
>
Richard Biener via Gcc-patches writes:
> On Fri, Aug 6, 2021 at 5:32 AM liuhongt wrote:
>>
>> Hi:
>> ---
>> OK, I think sth is amiss here upthread. insv/extv do look like they
>> are designed
>> to work on integer modes (but docs do not say anything about this here).
>> In fact the caller of
On Thu, 5 Aug 2021 at 18:05, Christophe Lyon
wrote:
>
>
>
> On Thu, Aug 5, 2021 at 2:28 PM Prathamesh Kulkarni
> wrote:
>>
>> On Tue, 3 Aug 2021 at 20:52, Christophe Lyon
>> wrote:
>> >
>> >
>> >
>> > On Tue, Aug 3, 2021 at 12:57 PM Prathamesh Kulkarni
>> > wrote:
>> >>
>> >> On Tue, 3 Aug
On Wed, 4 Aug 2021 15:13:30 +0200
Thomas Schwinge wrote:
> 'oacc_do_neutering' is the 'execute' function of the pass, so that
> means every time this executes, a fresh 'field_map' is set up, no
> state persists across runs (assuming I'm understanding that
> correctly). Why don't we simply use
Hi!
The paper that introduced constinit mentioned in rationale that constinit
can be used on externs as well and that it can be used to avoid the
thread_local initialization wrappers, because the standard requires that
if constinit is present on any declaration, it is also present on the
Hello Christophe,
On 06/08/2021 09:50, Christophe Lyon wrote:
Looks like there's a problem with your patch:
/tmp/1784442_7.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc1/./gcc/xgcc
-B/tmp/1784442_7.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc1/./gcc/
On Fri, Aug 6, 2021 at 4:07 AM Martin Sebor via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> On 7/30/21 9:06 AM, Jason Merrill wrote:
> > On 7/27/21 2:56 PM, Martin Sebor wrote:
> >> Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575690.html
> >>
> >> Are there any other suggestions
On Fri, Aug 6, 2021 at 7:31 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 05/08/2021 14:53, Martin Liška wrote:
> > On 7/23/21 11:39 AM, Sebastian Huber wrote:
> >> Add __gcov_info_to_gcda() to libgcov to get the gcda data for a gcda
> >> info in a
> >> freestanding
Hi:
Bootstrapped and regtested on x86_64-linux-gnu{-m32,}
Ok for trunk?
gcc/ChangeLog:
PR rtl-optimization/101796
* simplify-rtx.c
(simplify_context::simplify_binary_operation_1): Simplify
vector shift/rotate with const_vec_duplicate to vector
On Fri, Aug 6, 2021 at 6:54 AM Hongtao Liu via Gcc-patches
wrote:
>
> On Fri, Aug 6, 2021 at 11:44 AM Andrew Pinski via Gcc-patches
> wrote:
> >
> > On Thu, Aug 5, 2021 at 8:33 PM liuhongt via Gcc-patches
> > wrote:
> > >
> > > Hi:
> > > ---
> > > OK, I think sth is amiss here upthread.
On Fri, Aug 6, 2021 at 5:32 AM liuhongt wrote:
>
> Hi:
> ---
> OK, I think sth is amiss here upthread. insv/extv do look like they
> are designed
> to work on integer modes (but docs do not say anything about this here).
> In fact the caller of extract_bit_field_using_extv is named
>
On Fri, Aug 6, 2021 at 12:01 AM Martin Sebor via Gcc-patches
wrote:
>
> As I mentioned in the description of the access warning pass when
> I submitted it in July(*), I planned to change the -Wstringop-xxx
> code in the pass to run on the GIMPLE IL instead of on trees in
> builtins.c (and
On Thu, Aug 5, 2021 at 3:26 PM Christophe Lyon via Gcc-patches
wrote:
>
> On Thu, Aug 5, 2021 at 11:53 AM Richard Biener wrote:
>
> > On Thu, 5 Aug 2021, Christophe Lyon wrote:
> >
> > > On Wed, Aug 4, 2021 at 2:08 PM Richard Biener wrote:
> > >
> > > > On Wed, 4 Aug 2021, Richard Sandiford
e mode, rtx
> > > operands[])
> > >
> > >if (can_create_pseudo_p ()
> > >&& GET_MODE_SIZE (mode) >= 16
> > > - && GET_MODE_CLASS (mode) == MODE_VECTOR_INT
> > > + && VECTOR_MODE_P (mode)
> &
On Tue, Aug 3, 2021 at 10:44 AM Hongtao Liu wrote:
>
> On Tue, Aug 3, 2021 at 3:34 AM Joseph Myers wrote:
> >
> > On Mon, 2 Aug 2021, liuhongt via Gcc-patches wrote:
> >
> > > diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> > > index 7979e240426..dc673c89bc8 100644
> > > ---
77 matches
Mail list logo
