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
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
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
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
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 下午
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
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
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
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
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
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
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 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
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
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 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
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 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
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
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
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
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
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
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
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
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
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:
> 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
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
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
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
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 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
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
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
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
The initial gcc 10 era commit of the analyzer (in
757bf1dff5e8cee34c0a75d06140ca972bfecfa7) had an implementation of
-Wanalyzer-use-of-uninitialized-value, but was sufficiently buggy
that I removed it in 78b9783774bfd3540f38f5b1e3c7fc9f719653d7 before
the release of gcc 10.1
This patch reintroduce
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as 98cd4d123aa14598b1f0d54c22663c8200a96d9c.
gcc/analyzer/ChangeLog:
* analyzer.opt (fdump-analyzer-exploded-paths): New.
* diagnostic-manager.cc
(diagnostic_manager::emit_saved_diagnostic): Impl
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as e9711fe482b4abef0e7572809d3593631991276e.
gcc/analyzer/ChangeLog:
* analyzer.cc (fixup_tree_for_diagnostic_1): Use DECL_DEBUG_EXPR
if it's available.
* engine.cc (readability): Likewise.
Sign
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as a9241df96e1950c630550ada9371c0b4a03496cf.
gcc/analyzer/ChangeLog:
* state-purge.cc (self_referential_phi_p): New.
(state_purge_per_ssa_name::process_point): Don't purge an SSA name
at its def-
This is to make development version string more readable, and
to simplify navigation through gcc-testresults.
Currently gcc_update uses git log --pretty=tformat:%p:%t:%H to
generate version string, which is somewhat excessive since conversion
to git because commit hashes are now stable.
Even bett
On Thu, 15 Jul 2021, 18:21 François Dumont via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> On 15/07/21 5:26 pm, Jonathan Wakely via Libstdc++ wrote:
> > This results in slightly smaller code when assertions are enabled when
> > either using Clang (because it adds code to call std::terminate when
Hey João , I think there's a problem with your email, it's empty!
--
*Abraão C. de Santana*
--
João Gabriel Jardim
--
João Gabriel Jardim
Hi!
The following patch implements C++20 # __VA_OPT__ (...) support.
Testcases cover what I came up with myself and what LLVM has for #__VA_OPT__
in its testsuite and the string literals are identical between the two
compilers on the va-opt-5.c testcase.
Haven't looked at the non-#__VA_OPT__ diff
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 target/101456
* config/i386/i386.c (ix86_avx_u128_mode_needed): Don't set
On 15/07/21 5:26 pm, Jonathan Wakely via Libstdc++ wrote:
This results in slightly smaller code when assertions are enabled when
either using Clang (because it adds code to call std::terminate when
potentially-throwing functions are called in a noexcept function) or a
freestanding or non-verbose
On Sat, May 8, 2021 at 8:42 AM Jason Merrill wrote:
>
> On 5/7/21 12:33 PM, Patrick Palka wrote:
> > This PR is about CTAD but the underlying problems are more general;
> > CTAD is a good trigger for them because of the necessary substitution
> > into constraints that deduction guide generation en
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 switch the RTL.
However operand[3] is no
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 switch the RTL.
However operand[3] is no
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.
This means we need different patterns he
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.
Committed as a trivial fix.
Thanks,
Tamar
gcc/testsuite/ChangeLog:
PR middle-e
This implements the wording changes of DR 960 which clarifies that two
reference types are covariant only if they're both lvalue references
or both rvalue references.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
DR 960
PR c++/99664
gcc/cp/Change
This is the alias CTAD version of the CTAD bug PR93248, and the fix is
the same: clear cp_unevaluated_operand so that the entire chain of
DECL_ARGUMENTS gets substituted.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/11?
PR c++/101233
gcc/cp/ChangeLog:
On 7/8/21 5:36 PM, Jeff Law wrote:
On 7/1/2021 7:02 PM, Martin Sebor via Gcc-patches wrote:
-Wvla-parameter relies on operand_equal_p() with OEP_LEXICOGRAPHIC
set to compare VLA bounds for equality. But operand_equal_p()
doesn't consider decl names, and so nontrivial expressions that
refer to
Christophe Lyon via Gcc-patches writes:
> This patch removes this recently-introduced effective-target, as it
> looks like a typo and duplicate for arm_v8_2a_i8mm_ok (imm8 vs i8mm),
> and it is not used.
>
> 2021-07-15 Christophe Lyon
>
> gcc/testsuite/
> * lib/target-supports.exp (
Christophe Lyon via Gcc-patches writes:
> This test fails when forcing an -mcpu option incompatible with
> -march=armv8.2-a+i8mm.
>
> This patch adds the missing arm_v8_2a_i8mm_ok effective-target, as
> well as the associated dg-add-options arm_v8_2a_i8mm.
>
> 2021-07-15 Christophe Lyon
>
>
> Hi,
>
> gcc/ChangeLog:
>
> 2021-06-29 Martin Jambor
>
> * cgraph.h (ipa_replace_map): New field force_load_ref.
> * ipa-prop.h (ipa_param_descriptor): Reduce precision of move_cost,
> aded new flag load_dereferenced, adjusted comments.
> (ipa_get_param_dereferenced):
On Thu, Jul 15, 2021 at 09:15:55AM -0500, Peter Bergner wrote:
> On 7/14/21 4:12 PM, Peter Bergner wrote:
> > I'll make the change above and rebuild just to be safe and then commit.
>
> Regtesting was clean as expected, so I pushed the commit to trunk. Thanks.
> Is this ok for backporting to GCC
This patch removes this recently-introduced effective-target, as it
looks like a typo and duplicate for arm_v8_2a_i8mm_ok (imm8 vs i8mm),
and it is not used.
2021-07-15 Christophe Lyon
gcc/testsuite/
* lib/target-supports.exp (arm_v8_2a_imm8_neon_ok_nocache):
Delete.
--
This test fails when forcing an -mcpu option incompatible with
-march=armv8.2-a+i8mm.
This patch adds the missing arm_v8_2a_i8mm_ok effective-target, as
well as the associated dg-add-options arm_v8_2a_i8mm.
2021-07-15 Christophe Lyon
gcc/testsuite/
* gcc.target/arm/simd/vusdot
On Thu, 15 Jul 2021, Richard Biener wrote:
> On Thu, 15 Jul 2021, Richard Sandiford wrote:
>
> > Richard Biener writes:
> > > 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
On Thu, Jul 15, 2021 at 11:25 AM Bill Schmidt wrote:
>
> Hi,
>
> Segher preapproved this patch in https://gcc.gnu.org/PR101129. It differs
> slightly from what was posted there, needing an additional test to ensure the
> insn is a SET. The patch also includes the test case provided by the OP.
On 15/07/21 16:26 +0100, Jonathan Wakely wrote:
The std::get functions relied on deduction failing if more than one
base class existed for the type T. However the implementation of Core
DR 2303 (in r11-4693) made deduction succeed (and select the
more-derived base class).
This rewrites the impl
The std::get functions relied on deduction failing if more than one
base class existed for the type T. However the implementation of Core
DR 2303 (in r11-4693) made deduction succeed (and select the
more-derived base class).
This rewrites the implementation of std::get to explicitly check for
mor
This results in slightly smaller code when assertions are enabled when
either using Clang (because it adds code to call std::terminate when
potentially-throwing functions are called in a noexcept function) or a
freestanding or non-verbose build (because it doesn't use printf).
Signed-off-by: Jonat
On Sun, 11 Jul 2021 21:29:13 PDT (-0700), kito.ch...@sifive.com wrote:
It was undocument before, but it might used in linux kernel for resolve
code model issue, so LLVM community suggest we should document that,
so that make it become supported/documented/non-internal machine constraints.
gcc/Ch
Hi,
Segher preapproved this patch in https://gcc.gnu.org/PR101129. It
differs slightly from what was posted there, needing an additional test
to ensure the insn is a SET. The patch also includes the test case
provided by the OP. Bootstrap and regtest succeeded on P9 little-endian.
This bug
On Thu, Jul 15, 2021 at 2:34 PM Richard Biener wrote:
> On Thu, 15 Jul 2021, Christophe Lyon wrote:
>
> > Hi,
> >
> >
> >
> > On Tue, Jul 13, 2021 at 2:09 PM Richard Biener
> wrote:
> >
> > > The following adds support for re-using the vector reduction def
> > > from the main loop in vectorized
Hi,
The field in which profile_count holds the count has 61 bits but the
getter method only returns it as a 32 bit number. The getter is (and
should be) only used for dumping but even dumps are better when they do
not lie.
The patch has passed bootstrap and testing on x86_64-linux and Honza has
On Thu, 15 Jul 2021, Richard Sandiford wrote:
> Richard Biener writes:
> > 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:
> >> > >
> >> > > T
Hi Guys,
Attached is a proposed patch to fix PR 99935 and 100968, both
of which are stack exhaustion problems in libiberty's Rust
demangler. The patch adds a recursion limit along the lines
of the one already in place for the C++ demangler.
OK to apply ?
Cheers
Nick
diff --git a/li
As mentioned in my previous email, these are some minor changes to the
previous revision. All I'm changing here is the call into the solver
to use range_of_expr and range_of_stmt. Everything else remains the
same.
Tested on x86-64 Linux.
On Mon, Jul 5, 2021 at 5:39 PM Aldy Hernandez wrote:
>
>
Richard Biener writes:
> 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 loop masking support using
>> > > SVE W
Jeff has mentioned that it'll take a while longer to review the
threader rewrite, so I've decided to make some minor cleanups while he
gets to it.
There are few minor changes here:
1. I've renamed the solver to gimple-range-path.* which expresses
better that it's part of the ranger tools. The pre
> On Jul 15, 2021, at 9:16 AM, Qing Zhao via Gcc-patches
> wrote:
>
>>
Note that I think .DEFERRED_INIT can be elided for variables that do
not have their address
taken - otherwise we'll also have to worry about aggregate copy
initialization and SRA
decomposing
Hi, Richard,
> On Jul 15, 2021, at 2:56 AM, Richard Biener
> wrote:
>
>>> On Wed, Jul 14, 2021 at 1:17 AM Qing Zhao wrote:
Hi, Kees,
I took a look at the kernel testing case you attached in the previous
email, and found the testing failed with the following case:
>>
On 7/14/21 4:12 PM, Peter Bergner wrote:
> I'll make the change above and rebuild just to be safe and then commit.
Regtesting was clean as expected, so I pushed the commit to trunk. Thanks.
Is this ok for backporting to GCC 11 after a day or two on trunk?
Given GCC 10 doesn't have the opaque mod
On Thu, 15 Jul 2021, Richard Sandiford wrote:
> Richard Biener writes:
> > The following extends the existing loop masking support using
> > SVE WHILE_ULT to x86 by proving an alternate way to produce the
> > mask using VEC_COND_EXPRs. So with --param vect-partial-vector-usage
> > you can now en
Richard Biener writes:
> The following extends the existing loop masking support using
> SVE WHILE_ULT to x86 by proving an alternate way to produce the
> mask using VEC_COND_EXPRs. So with --param vect-partial-vector-usage
> you can now enable masked vectorized epilogues (=1) or fully
> masked v
On 7/15/21 3:53 AM, Jakub Jelinek wrote:
Hi!
Comparisons of NULLPTR_TYPE operands cause all kinds of problems in the
middle-end and in fold-const.c, various optimizations assume that if they
see e.g. a non-equality comparison with one of the operands being
INTEGER_CST and it is not INTEGRAL_TYPE
Add --enable-first-stage-cross configure option
Build static-only, C-only compiler that is sufficient to cross compile
glibc. This option disables various runtime libraries that require
libc to compile, turns on --with-newlib, --without-headers,
--disable-decimal-float, --disable-shared, --disabl
On Thu, Jul 15, 2021 at 3:23 PM Richard Biener
wrote:
>
> On Thu, Jul 15, 2021 at 3:21 PM Richard Biener
> wrote:
> >
> > On Thu, Jul 15, 2021 at 3:16 PM Aldy Hernandez wrote:
> > >
> > >
> > >
> > > On 7/15/21 3:06 PM, Richard Biener wrote:
> > > > On Thu, Jul 15, 2021 at 1:06 PM Aldy Hernandez
On Thu, Jul 15, 2021 at 3:21 PM Richard Biener
wrote:
>
> On Thu, Jul 15, 2021 at 3:16 PM Aldy Hernandez wrote:
> >
> >
> >
> > On 7/15/21 3:06 PM, Richard Biener wrote:
> > > On Thu, Jul 15, 2021 at 1:06 PM Aldy Hernandez wrote:
> > >>
> > >> Well, if we don't adjust gimple_call_return_type() t
On Thu, Jul 15, 2021 at 3:16 PM Aldy Hernandez wrote:
>
>
>
> On 7/15/21 3:06 PM, Richard Biener wrote:
> > On Thu, Jul 15, 2021 at 1:06 PM Aldy Hernandez wrote:
> >>
> >> Well, if we don't adjust gimple_call_return_type() to handle built-ins
> >> with no LHS, then we must adjust the callers.
> >
On 7/15/21 3:06 PM, Richard Biener wrote:
On Thu, Jul 15, 2021 at 1:06 PM Aldy Hernandez wrote:
Well, if we don't adjust gimple_call_return_type() to handle built-ins
with no LHS, then we must adjust the callers.
The attached patch fixes gimple_expr_type() per it's documentation:
/* Retur
Ah, yes - those test results should have only been changed for little endian.
I've submitted a patch to the list restoring the original expected results for
big
endian.
Thanks,
Jonathan
From: Christophe Lyon
Sent: 15 July 2021 10:09
To: Richard Sandiford ; Jonat
On Thu, Jul 15, 2021 at 1:06 PM Aldy Hernandez wrote:
>
> Well, if we don't adjust gimple_call_return_type() to handle built-ins
> with no LHS, then we must adjust the callers.
>
> The attached patch fixes gimple_expr_type() per it's documentation:
>
> /* Return the type of the main expression com
Hi Christophe,
Sorry about that, the ICEs should be fixed now and the execution tests are
being fixed now.
They were being hidden by a model bug which kept saying everything passed even
when failed ☹
Regards,
Tamar
From: Christophe Lyon
Sent: Thursday, July 15, 2021 9:39 AM
To: Tamar Christi
This is a followup to Srinath's recent patch: the newly added test is
failing e.g. on arm-linux-gnueabihf without R/M profile multilibs.
It is also failing on arm-eabi with R/M profile multilibs if the
execution engine does not support v8.1-M instructions.
The patch avoids this by adding check_e
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 endian.
Ok for master?
Thanks,
Jonathan
---
gcc
Richard Biener writes:
> This adjusts the vect_gen_while API to match that of
> vect_gen_while_not allowing further patches to generate more
> than one stmt for the while case.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, tested a
> toy example on SVE that it still produces the same co
On Thu, 15 Jul 2021, H.J. Lu wrote:
> On Tue, Jul 6, 2021 at 12:00 AM Richard Biener wrote:
> >
> >
> > Status
> > ==
> >
> > The GCC 11 branch is open for regression and documentation fixes.
> > It's time for a GCC 11.2 release and we are aiming for a release
> > candidate in about two weeks
On Tue, Jul 6, 2021 at 12:00 AM Richard Biener wrote:
>
>
> Status
> ==
>
> The GCC 11 branch is open for regression and documentation fixes.
> It's time for a GCC 11.2 release and we are aiming for a release
> candidate in about two weeks which would result in the GCC 11.2
> release about thr
On Thu, 15 Jul 2021, Christophe Lyon wrote:
> Hi,
>
>
>
> On Tue, Jul 13, 2021 at 2:09 PM Richard Biener wrote:
>
> > The following adds support for re-using the vector reduction def
> > from the main loop in vectorized epilogue loops on architectures
> > which use different vector sizes for
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?
Thanks,
Richard/
2021-07-15 Richard Biener
* config/i386/i386-options.c (ix86_option_override_internal): Set
param_vect_
Hi,
On Tue, Jul 13, 2021 at 2:09 PM Richard Biener wrote:
> The following adds support for re-using the vector reduction def
> from the main loop in vectorized epilogue loops on architectures
> which use different vector sizes for the epilogue. That's only
> x86 as far as I am aware.
>
> vect
Hi Jason,
A new revision of the patch is attached. I think I implemented all your
suggestions.
Please comment on cp/decl2.c (is_alias_template_p). I find it surprising that
I had to write this function. Maybe I missed something? In any case,
DECL_ALIAS_TEMPLATE_P requires a template_decl and t
There are 4 exact copies of the non-null range adjusting code in the
ranger. This patch abstracts the functionality into a separate method.
As a follow-up I would like to remove the varying_p check, since I have
seen incoming ranges such as [0, 0xffef] which are not varying, but
are not-null.
1 - 100 of 136 matches
Mail list logo
