On 4/23/21 1:37 PM, Martin Liška wrote:
On 4/23/21 12:59 PM, Richard Biener wrote:
True, the question is on how much detail we have to pay attention to.
Agree with that.
For us of course the build-id solution works fine. And hopefully the
days of PCH are counted...
Yes.
I have a tentativ
On Mon, May 10, 2021 at 4:12 PM H.J. Lu wrote:
>
> On Mon, May 10, 2021 at 6:59 AM Richard Biener
> wrote:
> >
> > On Mon, May 10, 2021 at 3:29 PM H.J. Lu wrote:
> > >
> > > On Mon, May 10, 2021 at 2:39 AM Richard Sandiford
> > > wrote:
> > > >
> > > > Richard Biener via Gcc-patches writes:
>
On Tue, 11 May 2021 at 01:43, Jeff Law wrote:
>
> On 5/10/2021 3:45 PM, abebeos via Gcc-patches wrote:
> >
> > I've described this in my message here:
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569913.html
> >
> > The summary is possibly
> > * I identified via necessary week-long
On Tue, 11 May 2021 at 01:35, Ian Lance Taylor wrote:
> On Mon, May 10, 2021 at 2:45 PM abebeos
> wrote:
> >
> > The bounty was filed/advertised by the gcc project, so the gcc project
> should have intervened immediately at the point where an anonymous coward
> rigged the voting process (aborted
On 5/10/2021 3:45 PM, abebeos via Gcc-patches wrote:
I've described this in my message here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569913.html
The summary is possibly
* I identified via necessary week-long work a (shelved) patch as valid for
(re)use.
* The gcc project(members) s
On Mon, May 10, 2021 at 2:45 PM abebeos wrote:
>
> The bounty was filed/advertised by the gcc project, so the gcc project should
> have intervened immediately at the point where an anonymous coward rigged the
> voting process (aborted the vote before end of the voting period).
>
> The fact that
On Tue, Apr 20, 2021 at 03:00:42PM +, Segher Boessenkool wrote:
> There are various non-IBM CPUs with isel as well, so it is easiest if we
> just don't consider that flag here (it is not needed).
>
> 2021-04-20 Segher Boessenkool
>
> PR target/100108
> * config/rs6000/rs6000.c
On Mon, 10 May 2021 at 23:32, Ian Lance Taylor wrote:
> On Mon, May 10, 2021, 9:52 AM abebeos
> wrote:
>
>> Again, just heavily fascinating to see how you ignore the overall essence
>> of this, which is of course directly related to gcc.
>>
>> (bountysource is just a secondary disaster, it all s
(unable to comment to this without loosing my temper. So... no comment)
On Mon, 10 May 2021 at 05:49, Ian Lance Taylor wrote:
> On Sun, May 9, 2021 at 8:33 AM abebeos
> wrote:
> >
> > To me this sounds quite like an "disorganized mess, where bullies,
> abusers and even IT-fascists can thrive".
Hi!
On Fri, May 07, 2021 at 12:19:52PM +0930, Alan Modra wrote:
> PowerPC64 ELFv2 dual entry point functions have a couple of problems
> with -fpatchable-function-entry. One is that the nops added after the
> global entry land in the global entry code which is constrained to be
> a power of two n
Hi!
On Sat, May 08, 2021 at 04:19:34PM +0800, Kewen.Lin wrote:
> This patch is to move rs6000_vect_nonmem (target cost_data
> related information) into target cost_data struct.
> * config/rs6000/rs6000.c (rs6000_vect_nonmem): Renamed to
> vect_nonmem and moved into...
> (struct
On Mon, May 10, 2021, 9:52 AM abebeos
wrote:
> Again, just heavily fascinating to see how you ignore the overall essence
> of this, which is of course directly related to gcc.
>
> (bountysource is just a secondary disaster, it all starts here, at gcc.
>
What do you think that the GCC project has
We have a comment saying to replace the simple binary_semaphore type
with std::binary_semaphore, which has been done. However, that isn't
defined on all targets. So keep the simple one here that just implements
the parts of the API needed by , and remove the comment
suggesting it should be replaced
This has been tentatively approved by LWG. The deleter from a unique_ptr
can be moved into the shared_ptr (at least, since LWG 2802). This uses
std::forward<_Del>(__r.get_deleter()) not std::move(__r.get_deleter())
because we don't want to convert the deleter to an rvalue when _Del is
an lvalue ref
Hi!
On Sat, May 08, 2021 at 04:12:18PM +0800, Kewen.Lin wrote:
> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -5234,6 +5234,8 @@ typedef struct _rs6000_cost_data
>/* For each vectorized loop, this var holds TRUE iff a non-memory vector
> instruction is needed
> The following patch fixes that, ready for master?
Sure, thanks!
--
Eric Botcazou
On 5/10/21 5:59 PM, Eric Botcazou wrote:
Do you know Eric where version.o needs to be added to be included in the
problematic command line?
You can presumably remove it from GNATLINK_OBJS & GNATMAKE_OBJS. And it needs
to be added to GNAT1_C_OBJS instead of GNAT_ADA_OBJS in Make-lang.in.
Tha
Hi,
On Mon, May 10 2021, Richard Biener wrote:
> I've tried to have a look at this patch but it does a lot of IPA specific
> refactoring(?), so the actual DCE bits are hard to find. Is it possible
> to split the patch up or is it too entangled?
>
Yes:
I was asked by Richi to split my fix for PR
Hi,
On Mon, May 10 2021, Richard Biener wrote:
> I've tried to have a look at this patch but it does a lot of IPA specific
> refactoring(?), so the actual DCE bits are hard to find. Is it possible
> to split the patch up or is it too entangled?
>
Yes:
I was asked by Richi to split my fix for PR
On Mon, May 10 2021, Richard Biener wrote:
> On Tue, Apr 27, 2021 at 5:26 PM Martin Jambor wrote:
>>
>> Hi,
>>
>> Whereas the previous patch fixed issues with code left behind after
>> IPA-SRA removed a parameter but only reset all affected debug bind
>> statements, this one updates them with expr
On Mon, May 10, 2021 at 04:11:39PM +0200, Marcel Vollweiler wrote:
> @@ -15660,37 +15665,54 @@ c_parser_omp_clause_map (c_parser *parser, tree
> list)
>if (!parens.require_open (parser))
> return list;
>
> - if (c_parser_next_token_is (parser, CPP_NAME))
> + int always = 0;
> + int c
On 03/05/21 09:43 -0700, Thomas Rodgers wrote:
From: Thomas Rodgers
This should also be backported to gcc-11
The additional _M_laundered data member changes the object layout.
That isn't safe for the branch. Would it be possible to smuggle that
flag in the least significant bit of the _M_addr
> -Original Message-
> From: Richard Sandiford
> Sent: Monday, May 10, 2021 5:31 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; Kyrylo Tkachov
> Subject: Re: [PATCH]AArch64: Have -mcpu=native and -march=native enable
> extensions
Tamar Christina writes:
> diff --git a/gcc/config/aarch64/aarch64-simd.md
> b/gcc/config/aarch64/aarch64-simd.md
> index
> 4edee99051c4e2112b546becca47da32aae21df2..c9fb8e702732dd311fb10de17126432e2a63a32b
> 100644
> --- a/gcc/config/aarch64/aarch64-simd.md
> +++ b/gcc/config/aarch64/aarch64-si
On Mon, 10 May 2021 at 18:32, Richard Earnshaw
wrote:
>
>
>
> On 22/04/2021 08:01, Christophe Lyon via Gcc-patches wrote:
> > arm.h has had this error message since 1997, and was never updated to
> > take softfp into account. Anyway, it seems it was useful long ago, but
> > it is no longer needed
On 22/04/2021 08:01, Christophe Lyon via Gcc-patches wrote:
arm.h has had this error message since 1997, and was never updated to
take softfp into account. Anyway, it seems it was useful long ago, but
it is no longer needed since option parsing has been improved:
-mfloat-abi is handled via arm
Tamar Christina writes:
> Hi All,
>
> Currently when using -mcpu=native or -march=native on a CPU that is unknown to
> the compiler the compiler currently just used -march=armv8-a and enables none
> of the extensions.
>
> To make this a bit more useful this patch changes it to still use
> -march=
"H.J. Lu" writes:
> On Mon, May 10, 2021 at 6:59 AM Richard Biener
> wrote:
>>
>> On Mon, May 10, 2021 at 3:29 PM H.J. Lu wrote:
>> >
>> > On Mon, May 10, 2021 at 2:39 AM Richard Sandiford
>> > wrote:
>> > >
>> > > Richard Biener via Gcc-patches writes:
>> > > > On Fri, Apr 30, 2021 at 8:30 PM
> Hi,
>
> the node and edge summaries defined in ipa-prop.h are probably the
> oldest in GCC and so it happened that they are the only ones using
> macros to look them up and create them. With Honza and Martin we
> agreed it is ugly and the macros should be removed and the ipa-prop
> summaries sh
Hi,
the node and edge summaries defined in ipa-prop.h are probably the
oldest in GCC and so it happened that they are the only ones using
macros to look them up and create them. With Honza and Martin we
agreed it is ugly and the macros should be removed and the ipa-prop
summaries should be access
> Do you know Eric where version.o needs to be added to be included in the
> problematic command line?
You can presumably remove it from GNATLINK_OBJS & GNATMAKE_OBJS. And it needs
to be added to GNAT1_C_OBJS instead of GNAT_ADA_OBJS in Make-lang.in.
--
Eric Botcazou
On 10/05/21 16:29 +0100, Jonathan Wakely wrote:
GCC defaults to -std=gnu++17 now anyway, and using it explicitly in the
dg-options directive prevents running these tests with different modes
such as -std=c++17 or -std=gnu++20.
Tested powerpc64le-linux. Committed to trunk.
With the patch attach
GCC defaults to -std=gnu++17 now anyway, and using it explicitly in the
dg-options directive prevents running these tests with different modes
such as -std=c++17 or -std=gnu++20.
Tested powerpc64le-linux. Committed to trunk.
commit 0498d2d09a2364aae1e6b5e085c8ebb8fc517684
Author: Jonathan Wakely
GCC defaults to -std=gnu++17 now anyway, and using it explicitly in the
dg-options directive prevents running these tests with different modes
such as -std=c++17 or -std=gnu++20.
Tested powerpc64le-linux. Committed to trunk.
commit d7b2d92747f8d236050af3ec5741786f0f878716
Author: Jonathan Wakel
GCC defaults to -std=gnu++17 now anyway, and using it explicitly in the
dg-options directive prevents running these tests with different modes
such as -std=c++17 or -std=gnu++20.
Tested powerpc64le-linux. Committed to trunk.
GCC defaults to -std=gnu++17 now anyway, and using it explicitly in the
dg-options directive prevents running these tests with different modes
such as -std=c++17 or -std=gnu++20.
Tested powerpc64le-linux. Committed to trunk.
commit 8087e70267ce6fa0787152963339ba987e7b514d
Author: Jonathan Wakely
GCC defaults to -std=gnu++17 now anyway, and using it explicitly in the
dg-options directive prevents running these tests with different modes
such as -std=c++17 or -std=gnu++20.
Tested powerpc64le-linux. Committed to trunk.
commit 7a4e52e44a8c9e6c59060adc691de5144d3c6940
Author: Jonathan Wakely
GCC defaults to -std=gnu++17 now anyway, and using it explicitly in the
dg-options directive prevents running these tests with different modes
such as -std=c++17 or -std=gnu++20.
Tested powerpc64le-linux. Committed to trunk.
commit 9cd88c022fcad783997cd4111b2e6c3700c4b15b
Author: Jonathan Wakel
GCC defaults to -std=gnu++17 now anyway, and using it explicitly in the
dg-options directive prevents running these tests with different modes
such as -std=c++17 or -std=gnu++20.
Tested powerpc64le-linux. Committed to trunk.
commit 8240175b87e331c87993876e782971eda46f9a6e
Author: Jonathan Wakely
GCC defaults to -std=gnu++17 now anyway, and using it explicitly in the
dg-options directive prevents running these tests with different modes
such as -std=c++17 or -std=gnu++20.
Tested powerpc64le-linux. Committed to trunk.
commit aa60ff1c8879f67557efc188b1d18d008458c76a
Author: Jonathan Wakel
GCC defaults to -std=gnu++17 now anyway, and using it explicitly in the
dg-options directive prevents running these tests with different modes
such as -std=c++17 or -std=gnu++20.
Tested powerpc64le-linux. Committed to trunk.
commit 646e6c652448bfd8fca535d91f588b4606295a72
Author: Jonathan Wakely
libstdc++-v3/ChangeLog:
* testsuite/20_util/scoped_allocator/69293_neg.cc: Add dg-error
for additional errors in C++20.
*
testsuite/20_util/specialized_algorithms/memory_management_tools/destroy_neg.cc:
Likewise.
* testsuite/20_util/uses_allocator/69293_neg
> Do you know Eric where version.o needs to be added to be included in the
> problematic command line?
Presumably to the beginning of TOOLS_LIBS in ada/gcc-interface/Makefile.in:
TOOLS_LIBS = ../version.o ../link.o ../targext.o ../../ggc-none.o \
--
Eric Botcazou
> I have a slightly different issue, last week it was still okay,
> but now I get (using gcc-4.8 as bootstrap compiler):
>
> gcc -std=gnu99 -c -g -gnatpg -gnatwns -gnata -W -Wall -nostdinc -I- -I.
> -Iada/generated -Iada -Iada/gcc-interface -I../../gcc-trunk/gcc/ada
> -I../../gcc-trunk/gcc/ada/gc
Wilco Dijkstra writes:
> Hi Richard,
>
>> Normally we should only put two instructions in the same define_insn
>> if there's a specific ABI or architectural reason for not separating
>> them. Doing it purely for optimisation reasons is going against the
>> general direction of travel. So I think
On 5/9/21 10:33 PM, Patrick Palka wrote:
This unconditionally enables the maybe_save_operator_binding mechanism
for all function templates, so that when resolving a dependent operator
expression from a function template we ignore later-declared
namespace-scope bindings that weren't visible at tem
For some reason middle-end does not enforce operand
predicates for vcond patterns.
2021-05-10 Uroš Bizjak
gcc/
* config/i386/i386-expand.c (ix86_expand_sse_movcc)
: Force op_true to register.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Pushed to master.
Uros.
dif
A simple, self-explaining patch to avoid a wrong warning.
Regtested on x86_64-pc-linux-gnu.
OK for mainline? Affected branches?
Thanks,
Harald
PR fortran/98411 - Pointless warning for static variables
Variables with explicit SAVE attribute cannot end up on the stack.
There is no point in che
On Mon, May 10, 2021 at 08:53:31AM -0500, Peter Bergner wrote:
> On 5/10/21 7:52 AM, Pat Haugen wrote:
> > On 5/7/21 6:00 PM, Segher Boessenkool wrote:
> >> So what is this replaced with? Was it an "xxlmr" and it is just
> >> unnecessary now?
> >
> > Different RA choice made the reg copy unnecess
On 06/05/2021 01:14, Prathamesh Kulkarni via Gcc-patches wrote:
Hi,
The attached patch replaces __builtin_neon_vtst* (a, b) with (a & b) != 0.
Bootstrapped and tested on arm-linux-gnueabihf and cross-tested on arm*-*-*.
OK to commit ?
Thanks,
Prathamesh
You're missing the ChangeLog details
On 05/05/2021 13:39, Srinath Parvathaneni via Gcc-patches wrote:
Hi Richard,
-Original Message-
From: Richard Earnshaw
Sent: 05 May 2021 11:15
To: Srinath Parvathaneni ; gcc-
patc...@gcc.gnu.org
Cc: Richard Earnshaw
Subject: Re: [GCC][PATCH] arm: Remove duplicate definitions from
a
On Mon, May 10, 2021 at 6:59 AM Richard Biener
wrote:
>
> On Mon, May 10, 2021 at 3:29 PM H.J. Lu wrote:
> >
> > On Mon, May 10, 2021 at 2:39 AM Richard Sandiford
> > wrote:
> > >
> > > Richard Biener via Gcc-patches writes:
> > > > On Fri, Apr 30, 2021 at 8:30 PM Richard Sandiford via Gcc-patc
Hi,
This patch adds handling for the map-type-modifier 'close' in the map
clause that was introduced with OpenMP 5.0: "The close map-type-modifier
is a hint to the runtime to allocate memory close to the target device."
In OpenMP 5.0 'close' can be used beside/together with 'always' in a
list of
"Kewen.Lin via Gcc-patches" writes:
> on 2021/5/7 下午5:43, Richard Biener wrote:
>> On Fri, May 7, 2021 at 5:30 AM Kewen.Lin via Gcc-patches
>> wrote:
>>>
>>> Hi,
>>>
>>> When I was investigating density_test heuristics, I noticed that
>>> the current rs6000_density_test could be used for single s
Hi Richard,
> Normally we should only put two instructions in the same define_insn
> if there's a specific ABI or architectural reason for not separating
> them. Doing it purely for optimisation reasons is going against the
> general direction of travel. So I think the first question is: why
> d
When PCH are enabled this test file includes and so the
using-directive brings std::any into the global scope. It isn't
currently a problem, because the -std option in the dg-options means
that PCH is not used. If that option is removed, the test fails with PCH
and passes without.
This just renam
On Mon, May 10, 2021 at 3:29 PM H.J. Lu wrote:
>
> On Mon, May 10, 2021 at 2:39 AM Richard Sandiford
> wrote:
> >
> > Richard Biener via Gcc-patches writes:
> > > On Fri, Apr 30, 2021 at 8:30 PM Richard Sandiford via Gcc-patches
> > > wrote:
> > >>
> > >> "H.J. Lu via Gcc-patches" writes:
> >
On Sat, May 8, 2021 at 10:05 AM Kewen.Lin wrote:
>
> Hi Richi,
>
> Thanks for the comments!
>
> on 2021/5/7 下午5:43, Richard Biener wrote:
> > On Fri, May 7, 2021 at 5:30 AM Kewen.Lin via Gcc-patches
> > wrote:
> >>
> >> Hi,
> >>
> >> When I was investigating density_test heuristics, I noticed tha
On 5/10/21 7:52 AM, Pat Haugen wrote:
> On 5/7/21 6:00 PM, Segher Boessenkool wrote:
>> So what is this replaced with? Was it an "xxlmr" and it is just
>> unnecessary now?
>
> Different RA choice made the reg copy unnecessary.
>
> < xxspltib 0,8
> < xxlor 32,0,0
> ---
>> xxspltib 32
Again, just heavily fascinating to see how you ignore the overall essence
of this, which is of course directly related to gcc.
(bountysource is just a secondary disaster, it all starts here, at gcc.
On Mon, 10 May 2021 at 12:19, Jakub Jelinek wrote:
> On Sun, May 09, 2021 at 07:48:50PM -0700,
It is just fascinating to see how you don't realize that this affects
mainly gcc.
On Mon, 10 May 2021 at 01:42, Eric Botcazou
wrote:
> > It is a gcc issue, see the very first link you've quoted (
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729).
>
> IIUC you're complaining about the bount
On Mon, May 10, 2021 at 2:39 AM Richard Sandiford
wrote:
>
> Richard Biener via Gcc-patches writes:
> > On Fri, Apr 30, 2021 at 8:30 PM Richard Sandiford via Gcc-patches
> > wrote:
> >>
> >> "H.J. Lu via Gcc-patches" writes:
> >> > On Fri, Apr 30, 2021 at 5:49 AM H.J. Lu wrote:
> >> >>
> >> >>
On Mon, 10 May 2021, Tamar Christina wrote:
>
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Monday, May 10, 2021 12:40 PM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd
> > Subject: RE: [PATCH 1/4]middle-end Vect: Add support for dot-product
> > where the si
On Tue, Apr 27, 2021 at 5:26 PM Martin Jambor wrote:
>
> Hi,
>
> Whereas the previous patch fixed issues with code left behind after
> IPA-SRA removed a parameter but only reset all affected debug bind
> statements, this one updates them with expressions which can allow the
> debugger to print the
On Tue, Apr 27, 2021 at 5:25 PM Martin Jambor wrote:
>
> Hi,
>
> PR 93385 reveals that if the user explicitely disables DCE, IPA-SRA
> can leave behind statements which are useless because their results
> are eventually not used but can have problematic side effects,
> especially since their input
On Thu, May 6, 2021 at 2:31 AM Indu Bhagat via Gcc-patches
wrote:
>
> To support multiple debug formats, we need to move away from explicit
> enumeration of each individual combination of debug formats.
debug_set_names with its static buffer seems unused? You wire quite some
APIs with gcc_assert
> -Original Message-
> From: Richard Biener
> Sent: Monday, May 10, 2021 12:40 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: RE: [PATCH 1/4]middle-end Vect: Add support for dot-product
> where the sign for the multiplicant changes.
>
> On Fri, 7 May 2021, Tamar
On 5/7/21 6:00 PM, Segher Boessenkool wrote:
>> --- a/gcc/testsuite/gcc.target/powerpc/vec-rlmi-rlnm.c
>> +++ b/gcc/testsuite/gcc.target/powerpc/vec-rlmi-rlnm.c
>> @@ -62,6 +62,6 @@ rlnm_test_2 (vector unsigned long long x, vector unsigned
>> long long y,
>> /* { dg-final { scan-assembler-times "
On Mon, 10 May 2021 at 13:50, Kyrylo Tkachov wrote:
>
>
>
> > -Original Message-
> > From: Gcc-patches On Behalf Of
> > Christophe Lyon via Gcc-patches
> > Sent: 30 April 2021 15:06
> > To: gcc-patches@gcc.gnu.org
> > Subject: [PATCH] testsuite/arm: Add mve-vmul-scalar-1.c test
> >
> > Su
Move the check for register targets (i.e. REG_P ()) into the function
get_sub_rtx () and change the restriction of REE to "only one child of
a PARALLEL expression is a SET register expression" (was "only one child of
a PARALLEL expression is a SET expression").
This allows to handle more PARALLEL
On Thu, May 6, 2021 at 5:29 AM Jim Wilson wrote:
>
> On Fri, Apr 30, 2021 at 4:10 PM Christoph Müllner via Gcc-patches
> wrote:
>>
>> On Sat, May 1, 2021 at 12:48 AM Jeff Law wrote:
>> > On 4/26/2021 5:38 AM, Christoph Muellner via Gcc-patches wrote:
>> > > [ree] PR rtl-optimization/100264: Han
Wilco Dijkstra via Gcc-patches writes:
> Improve GOT addressing by emitting the instructions as a pair. This reduces
> register pressure and improves code quality. With -fPIC codesize improves by
> 0.65% and SPECINT2017 improves by 0.25%.
>
> Passes bootstrap and regress. OK for commit?
Normally
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 30 April 2021 15:10
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 5/9] arm: MVE: Factorize vcmp_*f*
>
> Like in the previous, we factorize the vcmp_*f* patterns to make
> maintenance easie
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 30 April 2021 15:10
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 4/9] arm: MVE: Factorize all vcmp* integer patterns
>
> After removing the signed and unsigned suffixes in the previous
>
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 30 April 2021 15:10
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 3/9] arm: MVE: Remove _s and _u suffixes from vcmp*
> builtins.
>
> This patch brings more unification in the vector compa
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 30 April 2021 15:10
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 2/9] arm: MVE: Cleanup vcmpne/vcmpeq builtins
>
> After the previous patch, we no longer need to emit the unsigned
> varia
On Fri, May 7, 2021 at 6:29 AM Feng Xue OS wrote:
>
> >> gcc/
> >> PR tree-optimization/98598
> >> * Makefile.in (OBJS): Add tree-ssa-loop-mgo.o.
> >> * common.opt (-ftree-loop-mgo): New option.
> >
> > Just a quick comment - -ftree-loop-mgo is user-facing and it isn't real
Hello.
As Jakub correctly noticed, we can remove ChangeLog locations only based
on branch (master, a release branch). The patch removes 2 locations for the
current
master (or any further release) based on the current master.
gccadmin/hooks-bin/commit_checker needs to be updated correspond
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 30 April 2021 15:10
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 1/9] arm: MVE: Convert vcmp[eq|ne]* in arm_mve.h to use
> only 's' builtin version
>
> There is no need to have a signed a
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 30 April 2021 15:06
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH] testsuite/arm: Add mve-vmul-scalar-1.c test
>
> Support for vmul has been present for a while, but it was lacking a
> tes
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 30 April 2021 15:07
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH] testsuite/arm: Add mve-vsub-scalar-1.c test
>
> This patchs adds a test similar to mve-vsub_1.c, but operates on a
> scal
From: Christoph Höger
The awk script used a zero-based index which worked on surprisingly
many plattforms. According to the man page, however, the function
expects one-based indexing.
For reference see this bug in the go git repository:
https://github.com/golang/go/issues/45843
Signed-off-by:
Hi Eric,
I have a slightly different issue, last week it was still okay,
but now I get (using gcc-4.8 as bootstrap compiler):
gcc -std=gnu99 -c -g -gnatpg -gnatwns -gnata -W -Wall -nostdinc -I- -I.
-Iada/generated -Iada -Iada/gcc-interface -I../../gcc-trunk/gcc/ada
-I../../gcc-trunk/gcc/ada/gc
On Fri, 7 May 2021, Tamar Christina wrote:
> Hi Richi,
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Friday, May 7, 2021 12:46 PM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd
> > Subject: Re: [PATCH 1/4]middle-end Vect: Add support for dot-product
> > where
This makes sure to align data so targets without unaligned
accesses can vectorize it.
Tested on x86_64-unknown-linux-gnu and sparc-solaris by Rainer, pushed.
2021-05-10 Richard Biener
PR testsuite/100452
* g++.dg/vect/slp-pr99971.cc: Align data.
---
gcc/testsuite/g++.dg/vect/
Ping?
On Tue, 27 Apr 2021 at 13:32, Christophe Lyon
wrote:
>
> Vector right shifts by immediate use vshr, while right shifts by
> vectors instead use vneg and vshl.
>
> This patch adds the corresponding scan-assembler-times that were
> missing.
>
> 2021-04-22 Christophe Lyon
>
> gcc/te
Ping?
On Tue, 27 Apr 2021 at 13:32, Christophe Lyon
wrote:
>
> Use a template macro to factorize the existing test functions.
>
> This patch also adds a version to check subtraction with __fp16 type.
>
> 2021-04-26 Christophe Lyon
>
> gcc/testsuite/
> * gcc.target/arm/simd/mve-
Ping?
On Tue, 27 Apr 2021 at 13:32, Christophe Lyon
wrote:
>
> Support for vadd has been present for a while, but it was lacking a
> test.
>
> 2021-04-22 Christophe Lyon
>
> gcc/testsuite/
> * gcc.target/arm/simd/mve-vadd-1.c: New.
> ---
> gcc/testsuite/gcc.target/arm/simd/mve
Ping?
On Fri, 30 Apr 2021 at 16:06, Christophe Lyon
wrote:
>
> This patch adds a test for the scalar mode of vadd, precisely noting
> that we do not yet use the T2 variants of vadd, which take a scalar as
> final argument.
>
> 2021-04-22 Christophe Lyon
>
> gcc/testsuite/
> * g
Ping?
On Fri, 30 Apr 2021 at 16:06, Christophe Lyon
wrote:
>
> Support for vmul has been present for a while, but it was lacking a
> test for the scalar variant.
>
> This patch adds one, precisely noting that we do not yet use the T2
> variants of vmul, which take a scalar as final argument.
>
>
Ping?
On Fri, 30 Apr 2021 at 16:06, Christophe Lyon
wrote:
>
> This patchs adds a test similar to mve-vsub_1.c, but operates on a
> scalar as second argument. For the moment we do not select the T2 vsub
> variant operating on a scalar final argument, and we use vadd of the
> opposite.
>
> 2021-04
Ping for the series?
On Fri, 30 Apr 2021 at 16:09, Christophe Lyon
wrote:
>
> There is no need to have a signed and an unsigned version of these
> builtins. This is similar to what we do for Neon in arm_neon.h.
> This mechanical patch enables later cleanup patches.
>
> 2021-03-01 Christophe Lyon
On Mon, May 10, 2021 at 1:06 PM Martin Liška wrote:
>
> Pushed as obvious.
Of course reload.c is a particularly bad choice of file to check for ... ;)
Richard.
> Thanks,
> Martin
>
> contrib/ChangeLog:
>
> * gcc_update: Start using reload.c instead of version.c.
> ---
> contrib/gcc_up
When we distribute away a condition we rely on the ability to
change it to either 1 != 0 or 0 != 0 depending on the direction
of the exit branch in the respective loop. But when the loop
contains an irreducible sub-region then for the conditions inside
this this fails and can lead to infinite loop
On 5/7/21 12:39 PM, Tobias Burnus wrote:
Test for a copyed-but-not-fully-edited error.
OK?
Yes, please install it.
Thanks,
Martin
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heur
On 5/7/21 11:28 AM, Tobias Burnus wrote:
Hi all, hi Martin,
when running the scripts manually, I tend to get confused
which one is which. --help helps a bit :-)
Good idea.
I see some "Q000 Remove bad quotes" flake8 errors:
Please use rather multiline python string:
"""
first_line
second_lin
Hi,
This patch fixes a regression where the qualifier was ignored in an
alias definition if parentheses were not present.
Bootstrapped and regression tested on x86_64-linux-gnu, committed to
mainline and backported to releases/gcc-11.
Regards,
Iain.
---
gcc/d/ChangeLog:
* dmd/MERGE: Me
Hi,
This patch adjusts the visibility of std.process.searchPathFor so it can
be used from other modules in the phobos library. In particular, this
symbol is used by std.file.thisExePath on OpenBSD.
Bootstrapped and regression tested on x86_64-linux-gnu, committed to
mainline and backported to re
Pushed as obvious.
Thanks,
Martin
contrib/ChangeLog:
* gcc_update: Start using reload.c instead of version.c.
---
contrib/gcc_update | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/gcc_update b/contrib/gcc_update
index 45a27b76cc3..04dc4907fd9 100755
--- a/c
On Sun, 9 May 2021, Jason Merrill wrote:
> On 5/7/21 6:21 AM, Richard Biener wrote:
> > On Fri, May 7, 2021 at 12:17 PM Richard Biener wrote:
> >>
> >> canonicalize_constructor_val was setting TREE_ADDRESSABLE on bases
> >> of ADDR_EXPRs but that's futile when we're dealing with CTOR values
> >>
1 - 100 of 113 matches
Mail list logo
