On November 17, 2021 8:46:54 AM GMT+01:00, apinski--- via Gcc-patches
wrote:
>From: Andrew Pinski
>
>The problem is r12-5300-gf98f373dd822b35c allows phiopt to recognize more
>basic blocks
>but missed one location where phiopt could move an assignment from the middle
>block
>to the non-middle
From: Andrew Pinski
The problem is r12-5300-gf98f373dd822b35c allows phiopt to recognize more basic
blocks
but missed one location where phiopt could move an assignment from the middle
block
to the non-middle one. This patch fixes that.
OK? Bootstrapped and tested on x86_64-linux-gnu with no
On Thu, Nov 11, 2021 at 12:25 PM Kewen Lin wrote:
>
> This patch is to fix some non-robust split conditions in some
> define_insn_and_splits, to make each of them applied on top of
> the corresponding condition for define_insn part, otherwise the
> splitting could perform unexpectedly.
>
>
From: Andrew Pinski
The Linux kernel started to fail compile when the jump threader was improved
(r12-2591-g2e96b5f14e4025691). This failure was due to the IPA splitting code
decided now to split off the basic block which contained two functions,
one of those functions included the error
On 11/8/21 11:40, Matthias Kretz wrote:
On Tuesday, 17 August 2021 20:31:54 CET Jason Merrill wrote:
2. Given a DECL_TI_ARGS tree, can I query whether an argument was deduced
or explicitly specified? I'm asking because I still consider diagnostics
of function templates unfortunate. `template
Hi Eric,
on 2021/11/17 上午12:57, Eric Botcazou wrote:
>> gcc/ChangeLog:
>>
>> * config/visium/visium.md (*add3_insn, *addsi3_insn, *addi3_insn,
>> *sub3_insn, *subsi3_insn, *subdi3_insn, *neg2_insn,
>> *negdi2_insn, *and3_insn, *ior3_insn, *xor3_insn,
>> *one_cmpl2_insn,
r12-5102-gfb161782545224f5 improves integer bit test on
__atomic_fetch_[or|and]_* returns only for nop_convert, .i.e.
transfrom
mask_5 = 1 << bit_4(D);
mask.0_1 = (unsigned int) mask_5;
_2 = __atomic_fetch_or_4 (a_7(D), mask.0_1, 0);
t1_9 = (int) _2;
t2_10 = mask_5 & t1_9;
to
On Linux/x86_64,
6dc90c4dbb6f9589dea9c670c3468496bb207de5 is the first bad commit
commit 6dc90c4dbb6f9589dea9c670c3468496bb207de5
Author: Jan Hubicka
Date: Tue Nov 16 23:01:28 2021 +0100
Use modref summaries for byte-wise dead store elimination.
caused
FAIL:
On Tue, Nov 16, 2021 at 09:28:21PM -0500, David Malcolm wrote:
> On Tue, 2021-11-16 at 19:37 -0500, Marek Polacek wrote:
> > Sorry for a dumb question, but is this what you have in mind?
> >
> > /* LRE
> > PDF */
> > /* FSI
> > PDI */
> > and check that we warn for these?
>
> I mean
On Tue, 2021-11-16 at 19:37 -0500, Marek Polacek wrote:
> On Tue, Nov 16, 2021 at 06:00:58PM -0500, David Malcolm wrote:
> > > On Mon, Nov 15, 2021 at 06:15:40PM -0500, David Malcolm wrote:
> > > > > On Mon, Nov 08, 2021 at 04:33:43PM -0500, Marek Polacek wrote:
> > > > > > Ping, can we conclude
— Jojo
在 2021年11月16日 +0800 PM8:12，Richard Biener ，写道：
> On Tue, Nov 16, 2021 at 12:45 PM Jojo R via Gcc-patches
> wrote:
> >
> > Skip renaming if instruction is noop move, and it will
> > been removed for performance.
>
> Is there any (target specific) testcase you can add? Such commits are
>
This patch fixes -Wanalyzer-write-to-const so that it will complain
about attempts to write to functions, to labels.
It also "teaches" the analyzer about strchr, in that strchr can either
return a pointer into the input area (and thus -Wanalyzer-write-to-const
can now complain about writes into a
Successfully regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r12-5329-ga80d4e098b10d5cd161f55e4fce64a6be9683ed3.
gcc/testsuite/ChangeLog:
PR analyzer/102779
* gcc.dg/analyzer/capacity-1.c: Add dg-require-effective-target
alloca. Use __builtin_alloca rather than
Bill,
Sorry, I mixed up the patches. There is one vec_reve patch which hasn't
gotten approval for a long time. I will re-send it. Thanks a lot.
On 16/11/2021 下午 9:10, Bill Schmidt wrote:
> Hi Hao Chen,
>
> I don't understand. This patch was already approved and you committed it.
> :-) I
> On Nov 16, 2021, at 4:19 PM, Marek Polacek via Gcc-patches
> wrote:
>
> On Tue, Nov 16, 2021 at 01:09:15PM -0800, Mike Stump via Gcc-patches wrote:
>> On Nov 15, 2021, at 5:48 PM, Marek Polacek via Gcc-patches
>> wrote:
>>>
>>> Nitpicking time. It's spelled "ones' complement" rather
On 11/16/21 1:23 PM, Jason Merrill wrote:
On 10/23/21 19:06, Martin Sebor wrote:
On 10/4/21 3:37 PM, Jason Merrill wrote:
On 10/4/21 14:42, Martin Sebor wrote:
While resolving the recent -Waddress enhancement request (PR
PR102103) I came across a 2007 problem report about GCC 4 having
stopped
Hi,
This patch fixes a bug that caused some optimizations to be dropped with
-fdump-ipa-inline.
gcc/ChangeLog:
2021-11-17 Jan Hubicka
PR ipa/103246
* ipa-modref.c (ipa_merge_modref_summary_after_inlining): Fix clearing
of to_info_lto
diff --git a/gcc/ipa-modref.c
On Tue, Nov 16, 2021 at 06:00:58PM -0500, David Malcolm wrote:
> > On Mon, Nov 15, 2021 at 06:15:40PM -0500, David Malcolm wrote:
> > > > On Mon, Nov 08, 2021 at 04:33:43PM -0500, Marek Polacek wrote:
> > > > > Ping, can we conclude on the name? IMHO, -Wbidirectional is just
> > > > > fine,
> >
-Warray-parameter and -Wvla-parameter assume that array bounds
in function parameters are either constant integers or variable,
but not something in between like a cast of a constant that's
not recognized as an INTEGER_CST until we strip the cast from
it. This leads to an ICE as the the internal
> Nitpicking time. It's spelled "ones' complement" rather than "one's
> complement". I didn't go into config/.
>
> Ok for trunk?
>
> gcc/ChangeLog:
>
> * doc/implement-c.texi: Fix spelling.
> * doc/md.texi: Likewise.
> * expmed.c (emit_store_flag_int): Likewise.
> *
> On Mon, Nov 15, 2021 at 06:15:40PM -0500, David Malcolm wrote:
> > > On Mon, Nov 08, 2021 at 04:33:43PM -0500, Marek Polacek wrote:
> > > > Ping, can we conclude on the name? IMHO, -Wbidirectional is just fine,
> > > > but changing the name is a trivial operation.
> > >
> > > Here's a patch
Hi GCC community,
This patch will add the missed pattern described in bug 102232 [1] to the
match.pd.
Tree-optimization/96779: Adding new optimization to match.pd:
* match.pd (-x == x) -> (x == 0): New optimization.
* gcc.dg/tree-ssa/pr96779.c: testcase for this
Tested powerpc64le-linux, pushed to trunk.
Some tests fail when run with -D_GLIBCXX_USE_CXX11_ABI or -stdgnu++20.
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h (operator<=>): Use constexpr
unconditionally.
*
On Tue, Nov 16, 2021 at 01:09:15PM -0800, Mike Stump via Gcc-patches wrote:
> On Nov 15, 2021, at 5:48 PM, Marek Polacek via Gcc-patches
> wrote:
> >
> > Nitpicking time. It's spelled "ones' complement" rather than "one's
> > complement". I didn't go into config/.
> >
> > Ok for trunk?
>
>
On Nov 15, 2021, at 5:48 PM, Marek Polacek via Gcc-patches
wrote:
>
> Nitpicking time. It's spelled "ones' complement" rather than "one's
> complement". I didn't go into config/.
>
> Ok for trunk?
So, is it two's complement or twos' complement then? Seems like it should be
the same, but
On Tuesday, 16 November 2021 21:49:31 CET Jason Merrill wrote:
> On 11/16/21 15:42, Matthias Kretz wrote:
> > On Tuesday, 16 November 2021 21:25:33 CET Jason Merrill wrote:
> >> On 11/8/21 15:00, Matthias Kretz wrote:
> >>> I forgot to mention why I tagged it [RFC]: I needed one more bit of
> >>>
On 11/16/21 15:42, Matthias Kretz wrote:
On Tuesday, 16 November 2021 21:25:33 CET Jason Merrill wrote:
On 11/8/21 15:00, Matthias Kretz wrote:
I forgot to mention why I tagged it [RFC]: I needed one more bit of
information on the template args TREE_VEC to encode
EXPLICIT_TEMPLATE_ARGS_P. Its
On Tuesday, 16 November 2021 21:25:33 CET Jason Merrill wrote:
> On 11/8/21 15:00, Matthias Kretz wrote:
> > I forgot to mention why I tagged it [RFC]: I needed one more bit of
> > information on the template args TREE_VEC to encode
> > EXPLICIT_TEMPLATE_ARGS_P. Its TREE_CHAIN already points to an
Hi! I recently submitted [1] to make adjustments to test cases for the new
builtins
support, mostly due to error messages changing for consistency. Thanks for the
previous review. I've reviewed the reasons for the changes and removed
unrelated
changes as requested.
A couple of comments:
-
On 11/8/21 15:00, Matthias Kretz wrote:
I forgot to mention why I tagged it [RFC]: I needed one more bit of
information on the template args TREE_VEC to encode EXPLICIT_TEMPLATE_ARGS_P.
Its TREE_CHAIN already points to an integer constant denoting the number of
non-default arguments, so I
On 10/23/21 19:06, Martin Sebor wrote:
On 10/4/21 3:37 PM, Jason Merrill wrote:
On 10/4/21 14:42, Martin Sebor wrote:
While resolving the recent -Waddress enhancement request (PR
PR102103) I came across a 2007 problem report about GCC 4 having
stopped warning for using the address of inline
Committed to mainline as obvious after regtesting.
When issuing an error on an invalid range in a SELECT CASE statement
with a logical case expression, we need to be careful to use the
right locus information.
Thanks,
Harald
From 3b3c9932338650c9a402cf1bfbdf7dfc03e185e7 Mon Sep 17 00:00:00 2001
On Tue, 16 Nov 2021 15:55:55 +0100
Aldy Hernandez via Gcc-patches wrote:
> All sources before Knuth are clearly wrong. How could they not?
> Folks living in the pre-Knuth era lived without a deity.
>
> :-P
Not sure if this one's a compliment.
Speaking of which:
$ git grep -i "complim"
On 11/16/21 08:48, Uecker, Martin wrote:
Am Montag, den 08.11.2021, 19:13 +0100 schrieb Martin Uecker:
Am Montag, den 08.11.2021, 12:13 -0500 schrieb Jason Merrill:
On 11/7/21 01:40, Uecker, Martin wrote:
Am Mittwoch, den 03.11.2021, 10:18 -0400 schrieb Jason Merrill:
...
Thank you! I
On Mon, Nov 15, 2021 at 06:15:40PM -0500, David Malcolm wrote:
> > On Mon, Nov 08, 2021 at 04:33:43PM -0500, Marek Polacek wrote:
> > > Ping, can we conclude on the name? IMHO, -Wbidirectional is just fine,
> > > but changing the name is a trivial operation.
> >
> > Here's a patch with a
Darwin x86_64 and aarch64 platforms are PIC (shared) by default,
and user-space code must be built in this mode. The patch
ensures that this is set correctly and applies a default when
--enable-host-shared is not set.
tested on *-darwin*, x86_64,powerpc64le-linux-gnu,
pushed to master, thanks
On Linux/x86_64,
045206450386bcd774db3bde0c696828402361c6 is the first bad commit
commit 045206450386bcd774db3bde0c696828402361c6
Author: Richard Biener
Date: Fri Nov 12 10:21:22 2021 +0100
tree-optimization/102880 - improve CD-DCE
caused
FAIL: gcc.dg/tree-ssa/if-to-switch-3.c
On Linux/x86_64,
e69b7c5779863469479698f863ab25e0d9b4586e is the first bad commit
commit e69b7c5779863469479698f863ab25e0d9b4586e
Author: Jan Hubicka
Date: Tue Nov 16 09:15:39 2021 +0100
Fix uninitialized access in merge_call_side_effects
caused
FAIL: gcc.dg/tree-ssa/modref-dse-5.c
Hi! I previously posted [1] to correct some problems with the new builtins
support targeting 32-bit code gen. Based on the discussion, I've made some
adjustments and would like to submit this for consideration.
We eventually agreed that the strange behavior for -m32 -mpowerpc64 for certain
HTM
Add -mindirect-branch-cs-prefix to add CS prefix to call and jmp to thunk
via r8-r15 registers when converting indirect call and jump to increase
the instruction length to 6, allowing the non-thunk form to be inlined.
gcc/
PR target/102952
* config/i386/i386.c
Add -mharden-sls= to mitigate against straight line speculation (SLS)
for function return and indirect branch by adding an INT3 instruction
after function return and indirect branch.
gcc/
PR target/102952
* config/i386/i386-opts.h (harden_sls): New enum.
*
On 11/13/21 7:25 AM, Segher Boessenkool wrote:
> On Wed, Oct 27, 2021 at 08:37:57PM -0500, Peter Bergner wrote:
>> PR102976 shows a test case where we generate wrong code when building
>> a vector pair from 2 vector registers. The bug here is that with unlucky
>> register assignments, we can
Richard Biener via Gcc-patches writes:
> On Mon, Nov 15, 2021 at 3:00 PM Richard Sandiford
> wrote:
>>
>> Richard Biener via Gcc-patches writes:
>> > On Fri, Nov 12, 2021 at 7:05 PM Richard Sandiford via Gcc-patches
>> > wrote:
>> >>
>> >> This patch is a prerequisite for a later one. At the
On Tue, Nov 16, 2021 at 8:41 AM Rich Felker wrote:
>
> On Tue, Nov 16, 2021 at 03:40:00PM +0100, Dragan Mladjenovic wrote:
> > Hi,
> >
> > Looks fine to me. If possible, maybe it should even be back-ported
> > to stable branches.
The change cherry-picks fine onto 10.x and 11.x branches. Should I
Hi! During a previous patch review, Segher asked that I provide better
messages when builtins are unavailable because they require both a minimum
CPU and the enablement of VSX instructions. This patch does just that.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions.
Is this
Sorry, I forgot to CC maintainers on this one.
Thanks!
Bill
On 11/16/21 11:06 AM, Bill Schmidt wrote:
> Hi! While reviewing the recent 32-bit changes for the new builtin
> infrastructure,
> I realized that I needed another stanza to represent builtins requiring both
> -mcpu=power6 and
Hi! While reviewing the recent 32-bit changes for the new builtin
infrastructure,
I realized that I needed another stanza to represent builtins requiring both
-mcpu=power6 and -mpowerpc64. (There's only one of these, but nonetheless...)
So this patch adds that support in the same fashion as
On Tue, Nov 16, 2021 at 11:53:14AM -0500, Jason Merrill via Gcc-patches wrote:
> Patrick observed recently that an element of the vector cache could be
> arbitrarily large. Let's only cache relatively small vecs.
>
> This has no effect on compiling the libstdc++ stdc++.h, presumably because
>
> gcc/ChangeLog:
>
> * config/visium/visium.md (*add3_insn, *addsi3_insn, *addi3_insn,
> *sub3_insn, *subsi3_insn, *subdi3_insn, *neg2_insn,
> *negdi2_insn, *and3_insn, *ior3_insn, *xor3_insn,
> *one_cmpl2_insn, *ashl3_insn, *ashr3_insn,
> *lshr3_insn,
Oops, the subject line was not supposed to say 2/2 for this commit, and I
was not supposed to have Michael de Lang as the author ... I messed up my
git send-email and git cherry-pick commands!
Sorry Michael, I originally tried to use your tests from
https://github.com/Oipo/gcc/ but as noted in
Patrick observed recently that an element of the vector cache could be
arbitrarily large. Let's only cache relatively small vecs.
This has no effect on compiling the libstdc++ stdc++.h, presumably because
nothing in the library requires a vec that large. I figure that this makes it
more likely
The `configure` scripts generated with autoconf often tests compiler
features by setting output to `/dev/null`, which then sets the dump
folder as being /dev/* and the compilation halts with an error because
GCC cannot create files in /dev/. This is a problem when configure is
testing for compiler
From: Michael de Lang
Tested x86_64-linux, committed to trunk.
This is only supported for the cxx11 ABI, not for COW strings.
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h (basic_string, operator""s): Add
constexpr for C++20.
Tested x86_64-linux, committed to trunk.
These swap overloads are non-standard, but are needed to make swap work
for vector::reference rvalues. They don't need to be called
explicitly, only via ADL, so hide them from normal lookup. This is what
I've proposed as the resolution to LWG 3638.
On 11/15/21 3:05 PM, Martin Sebor wrote:
The deeply nested PHI handling in get_range_strlen_dynamic makes
the code bigger and harder to follow than it would be if done in
its own function. The attached patch does that.
In addition, the get_range_strlen family of functions use a bitmap
to avoid
On Tue, Nov 16, 2021 at 03:40:00PM +0100, Dragan Mladjenovic wrote:
> Hi,
>
> Looks fine to me. If possible, maybe it should even be back-ported
> to stable branches.
>
> Not sure if MIPS assembly sources (if any) in musl would need
> explicit ..note.GNU-stack
>
> to complement this?
What are
Richard Biener via Gcc-patches writes:
> On Wed, Nov 10, 2021 at 1:48 PM Richard Sandiford via Gcc-patches
> wrote:
>>
>> This patch extends the reduction code to handle calls. So far
>> it's a structural change only; a later patch adds support for
>> specific function reductions.
>>
>> Most of
Am Di., 16. Nov. 2021 um 16:31 Uhr schrieb Patrick Palka via Libstdc++
:
>
[..]
> -- >8 --
>
> Subject: [PATCH 1/5] libstdc++: Import the fast_float library
>
[..]
> +## Reference
> +
> +- Daniel Lemire, [Number Parsing at a Gigabyte per
> Second](https://arxiv.org/abs/2101.11408), Software:
Richard Biener writes:
> On Wed, Nov 10, 2021 at 1:46 PM Richard Sandiford via Gcc-patches
> wrote:
>>
>> code_helper and gimple_match_op seem like generally useful ways
>> of summing up a gimple_assign or gimple_call (or gimple_cond).
>> This patch adds a gimple_extract_op function that can be
Hi All,
This updates the signbit-2 test to check for
the scalar optimization if the target does not
support vectorization.
Regtested on aarch64-none-linux-gnu,
x86_64-pc-linux-gnu and no regressions.
Committed under the gcc obvious rule.
Thanks,
Tamar
gcc/testsuite/ChangeLog:
*
Hi All,
When the rshrn commit was reverted I missed this testcase.
This now updates it.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Committed under the obvious rule.
Thanks,
Tamar
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/shrn-combine-10.c: Use shrn.
---
Hi All,
convert_mult_to_fma assumes that all gimple_assigns have a LHS set. This
assumption is however not true when an IFN is kept around just for the
side-effects. In those situations you have just the IFN and lhs will be null.
Since there's no LHS, there also can't be any ADD and such it
On Tue, 16 Nov 2021, Florian Weimer wrote:
> * Patrick Palka via Libstdc:
>
> > This copies the fast_float library[1] into the compiled-in library
> > sources. We're going to use this library in our floating-point
> > std::from_chars implementation for faster and more portable parsing of
> >
This was leading to an assertion failure ICE on a switch stmt when using
-fstrict-enums, due to erroneously reusing a range involving one enum
with a range involving a different enum.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as
On 11/4/21 16:32, Jakub Jelinek wrote:
On Thu, Nov 04, 2021 at 11:52:34AM -0400, Jason Merrill via Gcc-patches wrote:
It's been inconvenient that pretty-printing of PTRMEM_CST didn't display
what member the constant refers to.
Adding that is complicated by the absence of a langhook for
On Tue, Nov 16, 2021 at 3:40 PM Koning, Paul wrote:
>
>
>
> > On Nov 16, 2021, at 2:03 AM, Aldy Hernandez via Gcc-patches
> > wrote:
> >
> > On Tue, Nov 16, 2021, 03:20 Marek Polacek via Gcc-patches <
> > gcc-patches@gcc.gnu.org> wrote:
> >
> >> On Tue, Nov 16, 2021 at 02:01:47AM +, Koning,
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 analysis (as I hinted you possibly can use gimple_uid to mark
the stmts that simplify, IIRC
> On Nov 16, 2021, at 2:03 AM, Aldy Hernandez via Gcc-patches
> wrote:
>
> On Tue, Nov 16, 2021, 03:20 Marek Polacek via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
>
>> On Tue, Nov 16, 2021 at 02:01:47AM +, Koning, Paul via Gcc-patches
>> wrote:
>>>
>>>
On Nov 15, 2021, at
Hi,
Looks fine to me. If possible, maybe it should even be back-ported to
stable branches.
Not sure if MIPS assembly sources (if any) in musl would need explicit
.note.GNU-stack
to complement this?
Best regards,
Dragan
On 16-Nov-21 06:13, Ilya Lipnitskiy wrote:
musl only uses
Tested x86_64-linux, pushed to trunk.
I fixed some undefined behaviour in string tests in r238609, but I only
fixed the narrow char versions. This applies the same fixes to the
wchar_t ones. These problems were found when testing a patch to make
std::basic_string usable in constexpr.
Tested x86_64-linux, pushed to trunk.
libstdc++-v3/ChangeLog:
* testsuite/21_strings/basic_string/allocator/71964.cc: Fix
typo.
* testsuite/23_containers/set/allocator/71964.cc: Likewise.
---
.../testsuite/21_strings/basic_string/allocator/71964.cc| 2 +-
On 11/11/21 08:15, Richard Biener wrote:
If you look at simplify_using_entry_checks then this is really really simple,
so I'd try to abstract this, recording sth like a unswitch_predicate where
we store the condition we unswitch on plus maybe cache the constant
range of a VAR cmp CST variable
Am Montag, den 08.11.2021, 19:13 +0100 schrieb Martin Uecker:
> Am Montag, den 08.11.2021, 12:13 -0500 schrieb Jason Merrill:
> > On 11/7/21 01:40, Uecker, Martin wrote:
> > > Am Mittwoch, den 03.11.2021, 10:18 -0400 schrieb Jason Merrill:
>
> ...
>
> > > Thank you! I made these changes and ran
Hi Hao Chen,
I don't understand. This patch was already approved and you committed it. :-)
I know
because I needed to make corresponding adjustments to the new builtins code.
Thanks,
Bill
On 11/15/21 8:16 PM, HAO CHEN GUI wrote:
> Hi,
>
> The patch optimizes the code generation for
Hi Jakub,
On 2021/6/24 9:15 PM, Jakub Jelinek wrote:
On Fri, Jun 18, 2021 at 10:25:16PM +0800, Chung-Lin Tang wrote:
Note, you'll need to rebase your patch, it clashes with
r12-1768-g7619d33471c10fe3d149dcbb701d99ed3dd23528.
Sorry for that. And sorry for patch review delay.
---
On 03/11/2021 13:28, Florian Weimer via Gcc-patches wrote:
> This function is similar to __gnu_Unwind_Find_exidx as used on arm.
> It can be used to speed up the libgcc unwinder.
Besides the terse patch description, the design seems ok to accomplish the
lock-free read and update. There are
On Tue, 16 Nov 2021, Jan Hubicka wrote:
> >
> > Not sure, tree-ssa-dse.c doesn't seem to handle MEM_REF with offset?
> >
> > VN has adjust_offsets_for_equal_base_address for this purpose. I
> > agree that some common functionality like
> >
> > bool
> > get_relative_extent_of (const ao_ref
On Mon, Nov 15, 2021 at 2:04 PM Roger Sayle wrote:
>
>
> This patch tidies up the code that GCC generates for simple loops,
> by selecting/generating a simpler loop bound expression in ivopts.
> The original motivation came from looking at the following loop (from
> gcc.target/i386/pr90178.c)
>
>
>
> Not sure, tree-ssa-dse.c doesn't seem to handle MEM_REF with offset?
>
> VN has adjust_offsets_for_equal_base_address for this purpose. I
> agree that some common functionality like
>
> bool
> get_relative_extent_of (const ao_ref *base, const ao_ref *ref,
>
Hi There,
I think for AArch32 mapping it back to armv8-a sounds sufficient. Unless we
have string or math routines in newlib that make use of any ACLE guards that
are beyond armv8-a …
Ramana
From: Richard Earnshaw
Date: Tuesday, 16 November 2021 at 11:48
To: Christophe Lyon , Przemyslaw
On Fri, Nov 12, 2021 at 7:06 PM Richard Sandiford via Gcc-patches
wrote:
>
> This patch extends the previous SLP gather load support so
> that it can handle masked loads too.
>
> Regstrapped on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
OK.
Thanks,
Richard.
> Richard
>
>
> gcc/
>
On Tue, Nov 16, 2021 at 12:45 PM Jojo R via Gcc-patches
wrote:
>
> Skip renaming if instruction is noop move, and it will
> been removed for performance.
Is there any (target specific) testcase you can add? Such commits are
problematic
when later bisected to since the intent isn't clear.
>
On Fri, 12 Nov 2021, Andre Simoes Dias Vieira wrote:
>
> On 12/11/2021 10:56, Richard Biener wrote:
> > On Thu, 11 Nov 2021, Andre Vieira (lists) wrote:
> >
> >> Hi,
> >>
> >> This patch introduces two IFN's FTRUNC32 and FTRUNC64, the corresponding
> >> optabs and mappings. It also creates a
On Mon, 15 Nov 2021, Jan Hubicka wrote:
> Hi,
> this patch extends tree-ssa-dse to use modref kill summary to clear
> live_bytes. This makes it possible to remove calls that are killed
> in parts.
>
> I noticed that DSE duplicates the logic of tree-ssa-alias that is
> mathing bases of memory
This fixes the previous adjustment to operation_could_trap_helper_p
where I failed to realize that RDIV_EXPR is also used for
fixed-point types. It also fixes that handling by properly
checking for a fixed_zerop divisor.
Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
Thanks,
Richard.
Hi,
This patch is needed for AMD GCN offloading when we use the assembler
from LLVM 13+.
The GCN runtime (libgomp+ROCm) requires that the location of all
variables in the offloaded variables table are discoverable at runtime
(using the "hsa_executable_symbol_get_info" API), and this only
You can't make an omelette without breaking eggs, as they say. New
architectures need new assemblers.
However, I wonder if there's anything in v9-a that significantly affects
the quality of the base multilib code needed for building the libraries.
It might be that we can deal with v9-a by
Skip renaming if instruction is noop move, and it will
been removed for performance.
gcc/
* regrename.c (find_rename_reg): Return satisfied regno
if instruction is noop move.
---
gcc/regrename.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/regrename.c
On Tue, 16 Nov 2021 at 09:46, Florian Weimer via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> * Jonathan Wakely:
>
> > On Tue, 16 Nov 2021 at 08:01, Florian Weimer wrote:
> >>
> >> * Patrick Palka via Libstdc:
> >>
> >> > This copies the fast_float library[1] into the compiled-in library
> >> >
Hi,
I was in your website, and I got to know that you are one of the Point Of sales
(POS) company. We can help you in providing customers/users and competitors'
business contacts across USA and worldwide which includes entire business
details that you would require.
Technology Product we
The (u)maddsihi4 patterns are using the ARC's VMAC2H(U)
instruction with null destination, however, VMAC2H(U) doesn't
rewrite the accumulator. This patch solves the destination issue
of VMAC2H by replacing it with DMACH(U) instruction.
gcc/
* config/arc/arc.md (maddhisi4): Use a single
The PR shows a missed control-dependent DCE caused by CFG cleanup
merging a forwarder resulting in a partially degenerate PHI node.
With control-dependent DCE we need to mark control dependences
of incoming edges into PHIs as necessary but that is unnecessarily
conservative for the case when two
Updated patch 2 with explanation included in commit message and changes
requested.
Bootstrapped and regression tested on aarch64
> -Original Message-
> From: Joel Hutton
> Sent: 12 November 2021 11:42
> To: Richard Biener
> Cc: gcc-patches@gcc.gnu.org; Richard Sandiford
>
> Subject:
On Mon, Nov 15, 2021 at 1:09 AM apinski--- via Gcc-patches
wrote:
>
> From: Andrew Pinski
>
> For this PR, we have:
> if (d_5 < 0)
> goto ; [INV]
> else
> goto ; [INV]
>
>:
> v_7 = c_4 | -128;
>
>:
> # v_1 = PHI
>
> Which PHI-OPT will try to simplify
> "(d_5 < 0) ? (c_4
Hi all,
This patch moves the implementation of MVE ACLE types from
arm_mve_types.h to inside GCC via a new pragma, which replaces the prior
type definitions. This allows for the types to be used internally for
intrinsic function definitions.
Bootstrapped and regression tested on
Hi all,
This patch moves the arm_simd_type and arm_type_qualifiers enums, and
arm_simd_info struct from arm-builtins.c into arm-builtins.h header.
This is a first step towards internalising the type definitions for MVE
predicate, vector, and tuple types. By moving arm_simd_types into a
header,
Hi all,
This patch series implements the arm MVE ACLE types currently found
under config/arm/arm_mve_types.h internally via a new pragma. Exposing
the MVE ACLE types internally allows for an MVE intrinsics
implementation similar to the current SVE implementation.
Any prefix of the patch series
On Sat, Nov 13, 2021 at 9:14 PM apinski--- via Gcc-patches
wrote:
>
> From: Andrew Pinski
>
> This folds Fold ((type)(a<0)) << SIGNBITOFA into ((type)a) & signbit inside
> match.pd.
> This was already handled in fold-cost by:
> /* A < 0 ? : 0 is simply (A & ). */
> I have not removed as we
Philipp Tomsich writes:
> This adds support and a basic turning model for the Ampere Computing
> "Ampere-1" CPU.
>
> The Ampere-1 implements the ARMv8.6 architecture in A64 mode and is
> modelled as a 4-wide issue (as with all modern micro-architectures,
> the chosen issue rate is a compromise
Update assembly output test pattern. Take into consideration also for
which platform we do execute the test (baremetal or linux).
gcc/testsuite/ChangeLog:
* gcc.target/arc/add_n-combine.c: Update test patterns.
* gcc.target/arc/builtin_eh.c: Update test for linux platforms.
1 - 100 of 122 matches
Mail list logo
