Pushed to master.
Martin
contrib/ChangeLog:
* check-params-in-docs.py: Support @itemx in param documentation
and support multi-line documentation for parameters.
---
contrib/check-params-in-docs.py | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
Hi,
testcase modref-dse-4.c and modref-dse-5.c fails on some targets because they
depend on store merging. What really happens is that without store merging
we produce for kill_me combined write that is ao_ref with offset=0, size=32
and max_size=96. We have size != max_size becaue we do ont
On 2021/11/23 13:51, Xionghu Luo wrote:
> r12-4526 cancelled jump thread path rotates loop. It exposes a issue in
> profile-estimate when predict_extra_loop_exits, outer loop's exit edge
> is marked as inner loop's extra loop exit and set with incorrect
> prediction, then a hot inner loop will
r12-4526 cancelled jump thread path rotates loop. It exposes a issue in
profile-estimate when predict_extra_loop_exits, outer loop's exit edge
is marked as inner loop's extra loop exit and set with incorrect
prediction, then a hot inner loop will become cold loop finally through
optimizations,
From: Andrew Pinski
This is a new version of the patch to fix PR 102216.
Instead of doing the canonicalization inside forwprop, Richi
mentioned we should do it inside fold_stmt_1 and that is what
this patch does.
PR tree-optimization/102216
gcc/ChangeLog:
* gimple-fold.c
Bill and David,
Currently, the absolute jump table is not by default enabled. It can be
enabled by undocumented option "-mno-relative-jumptables". If the target
supports named sections (have_named_sections), the feature can be enabled. We
plan to enable the future by default in GCC12 and
Thanks Jeff for this too.
Best wishes,
Navid.
From: Jeff Law
Sent: Monday, November 22, 2021 19:09
To: Richard Biener; Navid Rahimi
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [EXTERNAL] Re: [PATCH] PR tree-optimization/102232 Adding a
missing pattern to
Thanks Jeff.
Best wishes,
Navid.
From: Jeff Law
Sent: Monday, November 22, 2021 16:48
To: Richard Biener; Navid Rahimi
Cc: Navid Rahimi via Gcc-patches
Subject: Re: [EXTERNAL] Re: [PATCH] PR tree-optimization/96779 Adding a missing
pattern to match.pd
On 11/10/2021 1:35 AM, Richard Biener via Gcc-patches wrote:
On Tue, Nov 9, 2021 at 5:25 PM Navid Rahimi wrote:
Hi Richard,
Thank you so much for your detailed feedback. I am attaching another version of
the patch which does include all the changes you mentioned.
Bellow you can see my
On Mon, Nov 22, 2021 at 4:29 PM Jeff Law wrote:
>
>
>
> On 11/13/2021 9:33 AM, H.J. Lu via Gcc-patches wrote:
> > Sync with binutils for building binutils with LTO:
> >
> > From 50ad1254d5030d0804cbf89c758359ae202e8d55 Mon Sep 17 00:00:00 2001
> > From: "H.J. Lu"
> > Date: Sat, 9 Jan 2021
Hi David!
I updated the patch to allow initializing global variables with values
of type array or struct.
I also fixed the bug I was talking in my previous message by using the
following workaround: I create a new memento for the action of setting
the global variable initial value and as such,
On 11/1/2021 4:17 PM, Martin Sebor via Gcc-patches wrote:
Patch 1 in the series detects a small subset of uses of pointers
made indeterminate by calls to deallocation functions like free
or C++ operator delete. To control the conditions the warnings
are issued under the new -Wuse-after-free=
On Mon, Nov 22, 2021 at 3:40 AM Richard Biener
wrote:
>
> On Mon, Nov 22, 2021 at 9:40 AM Andrew Pinski wrote:
> >
> > On Wed, Oct 27, 2021 at 3:42 AM Richard Biener via Gcc-patches
> > wrote:
> > >
> > > On Wed, Oct 27, 2021 at 12:00 PM apinski--- via Gcc-patches
> > > wrote:
> > > >
> > > >
On 11/22/2021 1:45 AM, Richard Biener via Gcc-patches wrote:
On Fri, Nov 19, 2021 at 11:33 PM Navid Rahimi wrote:
Hi Richard,
Thanks for the detailed comment. I am attaching a newer version of the patch
which does have required fixes included. Bellow you can see my response to your
On 11/18/2021 4:01 AM, Xi Ruoyao via Gcc-patches wrote:
Some distro may ship dangling symlinks in include directories, triggers
the access failure. Skip it and continue to next header instead of
being to panic.
Restore to old behavior before r12-5234 but without resurrecting the
problematic
On 11/15/2021 10:10 PM, Ilya Lipnitskiy wrote:
On Mon, Nov 15, 2021 at 2:50 PM Jeff Law wrote:
On 11/15/2021 1:25 AM, Ilya Lipnitskiy via Gcc-patches wrote:
musl only uses PT_GNU_STACK to set default thread stack size and has no
executable stack support[0], so there is no reason not to
On 11/13/2021 9:33 AM, H.J. Lu via Gcc-patches wrote:
Sync with binutils for building binutils with LTO:
From 50ad1254d5030d0804cbf89c758359ae202e8d55 Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Sat, 9 Jan 2021 06:43:11 -0800
Subject: [PATCH] GCC: Pass --plugin to AR and RANLIB
Detect
On 11/22/2021 10:22 AM, Marek Polacek via Gcc-patches wrote:
Let's hide [[likely]] behind a macro, to suppress warnings if the
compiler doesn't support it.
Co-authored-by: Jonathan Wakely
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
PR preprocessor/103355
In an effort to avoid false positives while still detecting
certain out-of-bounds accesses the warning code that handles
PHI nodes chooses the operand with the most space remaining
as the one representative of the PHI. That's not right when
the offsets into the operands are unequal, because it
On Mon, Nov 22, 2021 at 04:00:56PM -0700, Martin Sebor via Gcc-patches wrote:
> While going through old -Waddress bug reports to close after
> the recent improvements to the warning I came across PR 96507
> that points out that member references aren't handled. Since
> testing the address of a
While going through old -Waddress bug reports to close after
the recent improvements to the warning I came across PR 96507
that points out that member references aren't handled. Since
testing the address of a reference for equality to null is
in general diagnosed, this seems like an oversight
Jakub recently mentioned that a PTRMEM_CST has no location; let's give it a
location wrapper.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* typeck.c (build_x_unary_op): Set address location.
(convert_member_func_to_ptr): Handle location wrapper.
*
Stripping the location wrapper from retval meant we didn't have the
necessary location information for any conversion diagnostics. We only need
the stripping for the named return value optimization, let's use the
unstripped expression for everything else.
Tested x86_64-pc-linux-gnu, applying to
Here the problem is that we aren't detecting a NSDMI in C++98:
struct A {
void *x = NULL;
};
because maybe_warn_cpp0x uses input_location and that happens to point
to NULL which comes from a system header. Jakub suggested changing the
location to the '=', thereby avoiding the system header
Hi!
On Tue, Nov 16, 2021 at 11:06:55AM -0600, Bill Schmidt via Gcc-patches wrote:
> gcc/
> * config/rs6000/rs6000-builtin-new.def: Add power6-64 stanza.
> Move CMPB to power6-64 stanza.
Don't break lines early please.
> * config/rs6000/rs6000-call.c
On Mon, Nov 22, 2021 at 3:42 PM Joseph Myers wrote:
>
> On Sun, 21 Nov 2021, Will Wray via Gcc-patches wrote:
>
> > gcc/c/ChangeLog:
> >
> > * c-decl.c (grokdeclarator): Don't complain of array returns.
>
> A C front-end change like this doesn't belong in a C++ patch
Of course, thanks.
On Mon, Nov 22, 2021 at 11:09:22AM -0500, David Edelsohn wrote:
> On Mon, Nov 22, 2021 at 10:58 AM Bill Schmidt wrote:
> And do the absolute addressing for switch tables changes work on AIX?
> I thought that Hao Chen only had done the work for PPC64 Linux ELF
> syntax with promises of future
On Mon, Nov 22, 2021 at 10:06:17AM -0600, Bill Schmidt wrote:
> Hi Mike,
>
> On 11/19/21 8:55 AM, Michael Meissner wrote:
> > Set power10 fusion if -mtune=power10.
> >
> > In doing the patch for zero cycle moves for switch statements and indirect
> > jumps, I noticed the fusion support is only
On Mon, Nov 22, 2021 at 10:36:13AM -0600, Bill Schmidt wrote:
> Hi Mike,
>
> Thanks for this patch!
> > --- a/gcc/config/rs6000/rs6000.md
> > +++ b/gcc/config/rs6000/rs6000.md
> > @@ -12988,15 +12988,34 @@ (define_expand "indirect_jump"
> > emit_jump_insn (gen_indirect_jump_nospec (Pmode,
On Mon, 22 Nov 2021, Jakub Jelinek via Gcc-patches wrote:
> On Thu, Nov 18, 2021 at 09:55:52PM +, Joseph Myers wrote:
> > On Thu, 18 Nov 2021, Jakub Jelinek via Gcc-patches wrote:
> >
> > > Are we handling the pragma at a wrong phase of preprocessing?
> >
> > I think that converting it to a
On Sun, 21 Nov 2021, Will Wray via Gcc-patches wrote:
> gcc/c/ChangeLog:
>
> * c-decl.c (grokdeclarator): Don't complain of array returns.
A C front-end change like this doesn't belong in a C++ patch (I don't see
any reason why this C++ patch would need such a C front-end change, it's
On Sun, 21 Nov 2021, Daniil Stas via Gcc-patches wrote:
> This option is enabled by default when -Wformat option is enabled. A
> user can specify -Wno-format-int-precision to disable emitting
> warnings when passing an argument of an incompatible integer type to
> a 'd', 'i', 'o', 'u', 'x', or
On Mon, 22 Nov 2021 19:17:51 +0100
Harald Anlauf via Gcc-patches wrote:
> Am 21.11.21 um 12:46 schrieb Mikael Morin:
> > Le 19/11/2021 à 20:47, Harald Anlauf via Fortran a écrit :
> >> Dear Fortranners,
> >>
> >> scalariziation of the elemental intrinsic LEN_TRIM was ICEing
> >> when the
Am 21.11.21 um 12:46 schrieb Mikael Morin:
Le 19/11/2021 à 20:47, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
scalariziation of the elemental intrinsic LEN_TRIM was ICEing
when the optional KIND argument was present.
The cleanest solution is to use the infrastructure added by
Let's hide [[likely]] behind a macro, to suppress warnings if the
compiler doesn't support it.
Co-authored-by: Jonathan Wakely
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
PR preprocessor/103355
libcpp/ChangeLog:
* lex.c: Use ATTR_LIKELY instead of [[likely]].
Hi Mike,
Thanks for this patch!
On 11/19/21 8:53 AM, Michael Meissner wrote:
> Add power10 zero cycle moves for switches.
>
> Power10 will fuse adjacenet 'mtctr' and 'bctr' instructions to form zero
> cycle moves. This code exploits this fusion opportunity.
>
> I have built bootstrapped
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583735.html
On 11/15/21 9:49 AM, Martin Sebor wrote:
Ping for the following cleanup patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583735.html
On 11/8/21 7:34 PM, Martin Sebor wrote:
The pointer-query code that
Pinging the two patches below:
-Wuse-after-free:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583044.html
and -Wdangling-pointer:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583045.html
On 11/15/21 9:47 AM, Martin Sebor wrote:
Pinging the two patches below:
The params are documented twice.
Pushed as obvious.
Martin
gcc/ChangeLog:
* doc/invoke.texi: Remove duplicate documentation for 3 params.
---
gcc/doc/invoke.texi | 12
1 file changed, 12 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index
When using recent libstc++ trunk with Clang in C++20 mode,
std::u16string literals as in
#include
int main() {
using namespace std::literals;
u""s;
}
started to cause linker failures due to undefined
On Mon, Nov 22, 2021 at 10:58 AM Bill Schmidt wrote:
>
> Hi!
>
> On 11/19/21 8:49 AM, Michael Meissner wrote:
> > The next set of 3 patches add zero cycle move support to the Power10. Zero
> > cycle moves are where the move to LR/CTR/TAR register that is adjacent to
> > the
> > jump to
Hi Mike,
On 11/19/21 8:55 AM, Michael Meissner wrote:
> Set power10 fusion if -mtune=power10.
>
> In doing the patch for zero cycle moves for switch statements and indirect
> jumps, I noticed the fusion support is only done if -mcpu=power10. This
> option
> enables power10 fusion if we use
Hi!
On 11/19/21 8:49 AM, Michael Meissner wrote:
> The next set of 3 patches add zero cycle move support to the Power10. Zero
> cycle moves are where the move to LR/CTR/TAR register that is adjacent to the
> jump to LR/CTR/TAR register can be fused together.
>
> At the moment, these set of three
On Mon, Nov 22, 2021 at 3:40 PM Maxim Blinov wrote:
>
> Hi Richard,
>
> The purpose of this patch is to give more of the target code access to
> the cumulative_args_t structure in order to enable certain (otherwise
> currently impossible) stack layout constraints, specifically for
> parameters
On 11/19/21 11:00, Richard Biener wrote:
On Tue, Nov 16, 2021 at 3:40 PM Martin Liška wrote:
On 11/11/21 08:15, Richard Biener wrote:
So I'd try to do no functional change first, improving the costing and
setting up the transform to simply pick up the stmts to "fold" as discovered
during
On Mon, Nov 22, 2021 at 03:49:42PM +0100, Thomas Schwinge wrote:
> Then, regarding the user-visible behavior:
>
> > +#pragma acc routine /* { dg-error "not immediately followed by a single
> > function declaration or definition" "" { target c++ } } */
> > +int foo (int bar ());
>
> So in C++
Tested x86_64-linux, pushed to trunk.
The check for C++14 was using the wrong date.
libstdc++-v3/ChangeLog:
* include/bits/c++config (_GLIBCXX14_DEPRECATED): Fix condition
checking for C++14.
---
libstdc++-v3/include/bits/c++config | 4 ++--
1 file changed, 2 insertions(+), 2
Hi Jakub!
On 2021-11-20T09:39:53+0100, Jakub Jelinek via Gcc-patches
wrote:
> The following testcase ICEs because two function declarations are nested in
> each other and the acc routine handling code isn't prepared to put the
> pragma on both.
Ha. Many things covered in
Hi all, apologies for forgetting to add the cover letter.
The motivation of this work is to provide (limited) support for GCC
nested function trampolines on targets that do not have an executable
stack. This code has been (roughly) tested by creating several
thousand nested functions (i.e. enough
Hi Richard,
The purpose of this patch is to give more of the target code access to
the cumulative_args_t structure in order to enable certain (otherwise
currently impossible) stack layout constraints, specifically for
parameters that are passed over the stack. For example, there are some
targets
On Mon, Nov 22, 2021 at 02:10:08PM +0100, Martin Liška wrote:
> On 11/22/21 14:05, Jakub Jelinek wrote:
> > On Mon, Nov 22, 2021 at 02:03:19PM +0100, Martin Liška wrote:
> > > I see only one patch attached, Jakub. Can you please send also the second
> > > one?
> >
> > The first one has been
Ping.
Another use case; casting arrays of char to arrays of unsigned char
(useful in some crypto APIs).
On Mon, Nov 15, 2021 at 6:32 PM will wray wrote:
>
> Yes - direct use of any builtin is not to be encouraged, in user code.
>
> This __builtin_bit_cast patch is intended to encourage
On 11/22/21 14:05, Jakub Jelinek wrote:
On Mon, Nov 22, 2021 at 02:03:19PM +0100, Martin Liška wrote:
I see only one patch attached, Jakub. Can you please send also the second one?
The first one has been inlined in the mail body (the one with attribs.[ch]
changes), the second one has been
On Mon, Nov 22, 2021 at 02:03:19PM +0100, Martin Liška wrote:
> I see only one patch attached, Jakub. Can you please send also the second one?
The first one has been inlined in the mail body (the one with attribs.[ch]
changes), the second one has been attached (the one without that).
On 11/22/21 10:36, Jakub Jelinek via Gcc-patches wrote:
Hi!
The target attribute handling is very expensive and for the common case
from x86intrin.h where many functions get implicitly the same target
attribute, we can speed up compilation a lot by caching it.
The following patches both create
On Mon, 22 Nov 2021, Andre Vieira (lists) wrote:
>
> On 12/11/2021 13:12, Richard Biener wrote:
> > On Thu, 11 Nov 2021, Andre Vieira (lists) wrote:
> >
> >> Hi,
> >>
> >> This is the rebased and reworked version of the unroll patch. I wasn't
> >> entirely sure whether I should compare the
On Sun, 2021-11-21 at 00:47 -0300, Alexandre Oliva wrote:
> Hello, Giuliano, thanks for turning my suggestion into a patch!
>
> On Nov 19, 2021, Richard Biener wrote:
>
> > > +/* { dg-options "-fdump-ipa-clones -o /dev/null" } */
>
> May I suggest actually checking that the ipa-clones dump
On Mon, Nov 22, 2021 at 06:01:08PM +0530, Siddhesh Poyarekar wrote:
> On 11/22/21 17:30, Siddhesh Poyarekar wrote:
> > So I've got patch 10/10, which handles dynamic (and consequently
> > negative) offsets. It basically computes a "whole size", which then
> > gives the extent to which a negative
On 11/22/21 17:30, Siddhesh Poyarekar wrote:
So I've got patch 10/10, which handles dynamic (and consequently
negative) offsets. It basically computes a "whole size", which then
gives the extent to which a negative offset is valid, making the
estimates a bit more precise. I didn't do it for
On Mon, Nov 22, 2021 at 9:40 AM Roger Sayle wrote:
>
>
> This patch implements PR tree-optimization/103345 to merge adjacent
> loads when combined with addition or bitwise xor. The current code
> in gimple-ssa-store-merging.c's find_bswap_or_nop alreay handles ior,
> so that all that's required
On 11/22/21 16:01, Jakub Jelinek wrote:
On Mon, Nov 22, 2021 at 03:41:57PM +0530, Siddhesh Poyarekar wrote:
So I played around a bit with this. Basically:
char buf[8];
__SIZE_TYPE__ test (void)
{
char *p = [0x9004];
return __builtin_object_size (p + 2, 0);
}
when built with -m32
On 12/11/2021 13:12, Richard Biener wrote:
On Thu, 11 Nov 2021, Andre Vieira (lists) wrote:
Hi,
This is the rebased and reworked version of the unroll patch. I wasn't
entirely sure whether I should compare the costs of the unrolled loop_vinfo
with the original loop_vinfo it was unrolled of.
On Mon, 22 Nov 2021, Andre Vieira (lists) wrote:
>
> On 18/11/2021 11:05, Richard Biener wrote:
> >
> > @@ -3713,12 +3713,21 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> > trapping behaviour, so require !flag_trapping_math. */
> > #if GIMPLE
> > (simplify
> > - (float (fix_trunc @0))
> >
On Mon, Nov 22, 2021 at 9:40 AM Andrew Pinski wrote:
>
> On Wed, Oct 27, 2021 at 3:42 AM Richard Biener via Gcc-patches
> wrote:
> >
> > On Wed, Oct 27, 2021 at 12:00 PM apinski--- via Gcc-patches
> > wrote:
> > >
> > > From: Andrew Pinski
> > >
> > > The problem here is tree-ssa-forwprop.c
On 18/11/2021 11:05, Richard Biener wrote:
@@ -3713,12 +3713,21 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
trapping behaviour, so require !flag_trapping_math. */
#if GIMPLE
(simplify
- (float (fix_trunc @0))
- (if (!flag_trapping_math
- && types_match (type, TREE_TYPE (@0))
-
On Mon, Nov 22, 2021 at 7:26 AM apinski--- via Gcc-patches
wrote:
>
> From: Andrew Pinski
>
> Combine disabled this optimization in r10-254-gddbb5da5199fb42 but it makes
> sense to do this on the gimple level and then let expand decide which way is
> better. So this adds the transformation on
On Mon, Nov 22, 2021 at 7:25 AM apinski--- via Gcc-patches
wrote:
>
> From: Andrew Pinski
>
> The pattern here was not catching all comparisons and the multiply
> was not commutative when it should have been. This patches fixes
> that by using tcc_comparison and adding :c to the multiply.
>
>
On Sun, Nov 21, 2021 at 3:19 PM apinski--- via Gcc-patches
wrote:
>
> From: Andrew Pinski
>
> This PR was orignally for the missed optimization of a few isnegative which
> had been solved a long time ago (sometime before 4.4.0). I noticed there was
> one missed optimization on the gimple level.
This avoids differences in the split edge of a cluster due to different
order of same key PHI args when sorting by sorting after the edge
destination index as second key.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-11-22 Richard Biener
PR
On Mon, Nov 22, 2021 at 03:41:57PM +0530, Siddhesh Poyarekar wrote:
> So I played around a bit with this. Basically:
>
> char buf[8];
>
> __SIZE_TYPE__ test (void)
> {
> char *p = [0x9004];
> return __builtin_object_size (p + 2, 0);
> }
>
> when built with -m32 returns 0x7002 but
Hi!
Ping.
Grüße
Thomas
On 2021-11-15T15:50:58+0100, I wrote:
> Hi!
>
> ..., and here is another ping.
>
>
> Grüße
> Thomas
>
>
> On 2021-11-08T11:45:12+0100, I wrote:
>> Hi!
>>
>> Ping, once more.
>>
>>
>> Grüße
>> Thomas
>>
>>
>> On 2021-10-14T12:12:41+0200, I wrote:
>>> Hi!
>>>
>>> Ping,
On 11/20/21 00:31, Siddhesh Poyarekar wrote:
This doesn't match what the code did and I'm surprised if it works at
all.
TREE_OPERAND (pt_var, 1), while it is an INTEGER_CST or POLY_INT_CST,
has in its type encoded the type for aliasing, so the type is some
pointer
type. Performing size_binop
Hi!
The target attribute handling is very expensive and for the common case
from x86intrin.h where many functions get implicitly the same target
attribute, we can speed up compilation a lot by caching it.
The following patches both create a single entry cache, where they cache
for a particular
Hi,
on exchange2 benchamrk we miss some useful propagation because modref gives
up very early on analyzing accesses through pointers. For example in
int test (int *a)
{
int i;
for (i=0; a[i];i++);
return i+a[i];
}
We are not able to determine that a[i] accesses are relative to a.
This is
On Thu, Nov 18, 2021 at 09:55:52PM +, Joseph Myers wrote:
> On Thu, 18 Nov 2021, Jakub Jelinek via Gcc-patches wrote:
>
> > Are we handling the pragma at a wrong phase of preprocessing?
>
> I think that converting it to a single preprocessing token (rather than
> four separate preprocessing
Hi!
When adding OMP_MASKED, I apparently forgot to handle it in
potential_constant_expression_1, which means we can ICE on it.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk.
2021-11-22 Jakub Jelinek
PR c++/103349
* constexpr.c
On Sat, Nov 20, 2021 at 9:43 AM Jacob Kroon via Gcc-patches
wrote:
>
> On 11/20/21 09:32, Jakub Jelinek wrote:
> > On Sat, Nov 20, 2021 at 12:24:21AM -0800, Andrew Pinski via Gcc-patches
> > wrote:
> >> On Sat, Nov 20, 2021 at 12:18 AM Jacob Kroon via Gcc-patches
> >> wrote:
> >>>
> >>>
On Fri, Nov 19, 2021 at 11:33 PM Navid Rahimi wrote:
>
> Hi Richard,
>
> Thanks for the detailed comment. I am attaching a newer version of the patch
> which does have required fixes included. Bellow you can see my response to
> your feedbacks:
>
> > you need to check TYPE_OVERFLOW_WRAPS on
On Fri, Nov 19, 2021 at 8:17 PM Jakub Jelinek via Gcc-patches
wrote:
>
> On Sat, Nov 20, 2021 at 12:31:19AM +0530, Siddhesh Poyarekar wrote:
> > > Neither of these are equivalent to what it used to do before.
> > > If some target has e.g. pointers wider than size_t, then previously we
> > >
On Wed, Oct 27, 2021 at 3:42 AM Richard Biener via Gcc-patches
wrote:
>
> On Wed, Oct 27, 2021 at 12:00 PM apinski--- via Gcc-patches
> wrote:
> >
> > From: Andrew Pinski
> >
> > The problem here is tree-ssa-forwprop.c likes to produce
> > [(void *)_4 + 152B] which is the same as
> > _4 p+
This patch implements PR tree-optimization/103345 to merge adjacent
loads when combined with addition or bitwise xor. The current code
in gimple-ssa-store-merging.c's find_bswap_or_nop alreay handles ior,
so that all that's required is to treat PLUS_EXPR and BIT_XOR_EXPR in
the same way at
From: SiYu Wu
This patch add gcc backend support for RISC-V Scalar Cryptography
Extension (k-ext), including machine description, builtins defines and
testcases for each k-ext's subset.
A note about Zbkx: The Zbkx should be implemented in bitmanip's Zbp, but
since zbp is not included in the
From: SiYu Wu
gcc/ChangeLog:
2021-11-21 SiYu Wu
* common/config/riscv/riscv-common.c (riscv_ext_version_table):
Add zbk* and zk*.
* config/riscv/riscv-opts.h (MASK_ZBKB): New.
(MASK_ZBKC): Ditto.
(MASK_ZBKX): Ditto.
(MASK_ZKNE): Ditto.
From: SiYu Wu
gcc/ChangeLog:
2021-11-22 SiYu Wu
* common/config/riscv/riscv-common.c (riscv_implied_info):
Add K-ext related entry.
(riscv_supported_std_ext): Add 'k'.
* config/riscv/arch-canonicalize (CANONICAL_ORDER): Add 'k'.
(IMPLIED_EXT): Add
84 matches
Mail list logo
