Hi All,
Here is another of Steve Kargl's patches.
Before the patch is applied, the following code is generated:
atmp.0.span = 4;
atmp.0.data = 0B;
atmp.0.offset = 0;
(*(integer(kind=4)[0] * restrict) atmp.0.data)[0] = 1;
(*(integer(kind=4)[0] * restrict) atmp.0.data)[1] = 2;
Hi Richard
I found that some instructions are using '#' before immediate value，
and others are not. For example
(define_insn "insv_imm"
[(set (zero_extract:GPI (match_operand:GPI 0 "register_operand" "+r")
(const_int 16)
(match_operand:GPI 1 "c
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Wednesday, August 26, 2020 6:14 PM
> To: xiezhiheng
> Cc: Richard Biener ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR94442] [AArch64] Redundant ldp/stp instructions
> emitted at -O3
>
Cut...
PowerPC: Add power10 xscmp{eq,gt,ge}qp support.
This patch adds the conditional move support. In adding the conditional move
support, the optimizers will be able to convert things like:
a = (b > c) ? b : c;
into the instructions. This patch merges together the scalar SF/DF conditional
PowerPC: Add power10 xsmaxcqp/xsmincqp support.
This patch adds support for the ISA 3.1 (power10) IEEE 128-bit "C" minimum and
maximum functions. Because of the NaN differences, the built-in functions will
only generate these instructions if -ffast-math is used until the conditional
move support
PowerPC: Rename functions for min, max, cmove.
This patch renames the functions that generate the ISA 3.0 C minimum, C
maximum, and conditional move instructions to use a better name than just using
a _p9 suffix. Because the functions can fail, the names use "maybe_emit"
instead of "generate_" in
PowerPC: Change cmove function return to bool.
In doing the other work for adding ISA 3.1 128-bit minimum, maximum, and
conditional move support, I noticed the two functions that process conditional
moves return 'int' instead of 'bool'. This patch changes these functions to
return 'bool'.
I have
The following patches are a rewrite of the previous set of patches to add
support for the power10 IEEE 128-bit C minimum, C maximum, and compare/set mask
instructions that are similar to the instructions added in power9.
There are 4 patches in this series.
The first patch is a cosmetic patch. In
On 2020-08-26 11:15 a.m., Alex Coplan wrote:
Thanks for the review, both.
Please find a reworked version of the patch attached incorporating
Richard's feedback.
Testing:
* Bootstrap and regtest on aarch64-none-linux-gnu,
arm-none-linux-gnueabihf, and x86_64-pc-linux-gnu: no regressions.
This patch add -fno-tree-fre to dg-options in gcc.dg/guality/sra-1.c,
to make the following testcases passed.
FAIL: gcc.dg/guality/sra-1.c -Og -DPREVENT_OPTIMIZATION line 43 a.i == 4
FAIL: gcc.dg/guality/sra-1.c -Og -DPREVENT_OPTIMIZATION line 43 a.j == 14
FAIL: gcc.dg/guality/s
On 2020-08-26 5:23 p.m., Roger Sayle wrote:
> These more accurate target rtx_costs are used by the
> gimple-ssa-strength-reduction.c
> (via a call to mult_by_coeff_cost) to decide whether applying strength
> reduction would
> be profitable. This test case, slsr-13.c, assumes that two multiplicat
On Wed, Aug 26, 2020 at 2:38 PM Mark Wielaard wrote:
>
> Hi gcc hackers, binutils hackers,
>
> Nick, Jakub and I were discussing the gcc patch below and all the ways
> it is wrong. Most things can be fixed in the spec. Like only passing
> -gdwarf if we are generating DWARF and passing the right DW
This libgo patch by Clément Chigot adds -maix32 when running GCC on
32-bit AIX. As gcc might now be compiled in 64bit, -maix32 must
always be added to ensure that created objects will be 32bit.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
0c223b02b6e4dfbde
This libgo patch by Clément Chigot adds FAT library support for static
libraries on AIX. Like shared libraries, AIX static libraries must
also have both 32 and 64 bit objects. Bootstrapped and ran Go
testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
a66f773796a78d61891f5e78d275aeb462
On Tue, 2020-08-18 at 18:18 -0400, Pat Bernardi wrote:
> A number of i386 math optimisation tests are looking assembly instructions
> that are only emitted when the compiler knows the target has a C99 libm
> available. Since targets like *-elf may not have such a libm, a C99 runtime
> requirement i
On Fri, 2020-07-24 at 15:42 +0200, Martin Liška wrote:
> On 7/24/20 1:02 PM, Göran Uddeborg wrote:
> > The wording of the description of -fprofile-exclude-files is easy to
> > misunderstand. One can be led to believe a file is excluded only if
> > it matches all of the patterns, not just one. Thi
Hi gcc hackers, binutils hackers,
Nick, Jakub and I were discussing the gcc patch below and all the ways
it is wrong. Most things can be fixed in the spec. Like only passing
-gdwarf if we are generating DWARF and passing the right DWARF version
as -gdwarf-N for the version that gcc itself creates.
On Wed, 2020-08-26 at 22:23 +0100, Roger Sayle wrote:
> The failure of slsr-13.c is not caused by the patchh3.txt, but the previous
> patchh2.txt
> that's now on mainline and the gcc-10 branch. That change provided more
> accurate
> rtx_costs for hppa, and solved the performance problems with sy
On Tue, 2020-08-04 at 14:05 +0800, Hongtao Liu via Gcc-patches wrote:
> Update patch.
>
> There are a lot of avx512 define_insns which lack corresponding memory
> broadcast version, i only add *avx512f_mul3_bcst and
> *avx512dq_mul3_bcst in this patch.
>
> On Fri, Jul 24, 2020 at 10:37 AM Hongtao
The failure of slsr-13.c is not caused by the patchh3.txt, but the previous
patchh2.txt
that's now on mainline and the gcc-10 branch. That change provided more
accurate
rtx_costs for hppa, and solved the performance problems with synth_mult.
These more accurate target rtx_costs are used by th
On Wed, 2020-08-26 at 15:58 -0500, Segher Boessenkool wrote:
> On Tue, Aug 25, 2020 at 02:35:51PM -0600, Jeff Law wrote:
> > I've gone back and forth on pre allocation splitting as well as
> > post-allocating
> > splitting and re-allocation. I could argue either side of that discussion
> > --
>
On Tue, 2020-08-11 at 13:37 +0200, Martin Liška wrote:
> From cc1d41a469d76f2f8e4f44bed788ace77a1c6d62 Mon Sep 17 00:00:00 2001
> From: Martin Liska
> Date: Mon, 10 Aug 2020 12:09:19 +0200
> Subject: [PATCH 3/3] vec: use inexact growth where possible.
>
> gcc/ChangeLog:
>
> * cfgrtl.c (rtl
On Tue, 2020-08-11 at 13:37 +0200, Martin Liška wrote:
> From 292532ea9e3d42ca164b9951674c1eccc86a1f11 Mon Sep 17 00:00:00 2001
> From: Martin Liska
> Date: Mon, 10 Aug 2020 12:01:59 +0200
> Subject: [PATCH 2/3] vec: default exect = false in grow functions.
>
> gcc/ChangeLog:
>
> * vec.h (
On Tue, 2020-08-11 at 13:36 +0200, Martin Liška wrote:
> Hello.
>
> All right, I did it in 3 steps:
> 1) - new exact argument is added (no default value) - I tested the on
> x86_64-linux-gnu
> and I build all cross targets.
> 2) set default value of exact = false
> 3) change places which calculat
On Tue, Aug 25, 2020 at 02:35:51PM -0600, Jeff Law wrote:
> I've gone back and forth on pre allocation splitting as well as
> post-allocating
> splitting and re-allocation. I could argue either side of that discussion --
If you end up wanting something split it is best to do it early. But if
y
On 26/08/20 16:44 -0400, Patrick Palka via Libstdc++ wrote:
Almost all of the proposed resolution for LWG 3448 is already
implemented; the only part left is to adjust the return type of
transform_view::sentinel::operator-.
libstdc++-v3/ChangeLog:
LWG 3448
PR libstdc++/95322
On 26/08/20 16:44 -0400, Patrick Palka via Libstdc++ wrote:
This implements the proposed resolution for LWG 3406 and adds a testcase
for the example from P1994R1.
libstdc++-v3/ChangeLog:
LWG 3406
* include/std/ranges (elements_view::begin): Adjust constraints.
(elements_
On 26/08/20 16:44 -0400, Patrick Palka via Libstdc++ wrote:
The example from the paper doesn't compile without the proposed
resolution for LWG 3406, so we'll add a testcase for this once the
proposed resolution is in.
libstdc++-v3/ChangeLog:
P1994R1: elements_view needs its own sentinel
Hi!
(All that Will says included by reference ;-) )
On Mon, Aug 24, 2020 at 02:39:41PM -0700, Carl Love wrote:
> I attempted to do the backport however the patch doesn't even come
> close to applying. The names XVCVBF16SPN and XVCVSPBF16 are the only
> two builtin names that exist in GCC 10. Th
Almost all of the proposed resolution for LWG 3448 is already
implemented; the only part left is to adjust the return type of
transform_view::sentinel::operator-.
libstdc++-v3/ChangeLog:
LWG 3448
PR libstdc++/95322
* include/std/ranges (transform_view::__distance_from): Gi
This implements the proposed resolution for LWG 3406 and adds a testcase
for the example from P1994R1.
libstdc++-v3/ChangeLog:
LWG 3406
* include/std/ranges (elements_view::begin): Adjust constraints.
(elements_view::end): Likewise.
(elements_view::_Sentinel::opera
The example from the paper doesn't compile without the proposed
resolution for LWG 3406, so we'll add a testcase for this once the
proposed resolution is in.
libstdc++-v3/ChangeLog:
P1994R1: elements_view needs its own sentinel.
* include/std/ranges (elements_view::end): Replace t
Deeply sorry, I indeed didn't sent the patch I wanted to commit. It was
in 3 commits on my side and it looks like I had miss the last one
regarding the changes for _ExtractKey.
But moreover I had change the ebo helper index wrongly, I missed the abi
change here, thanks for fixing it.
On 26/
On Tue, 2020-06-23 at 20:05 -0600, Martin Sebor wrote:
> -Wstringop-overflow is issued for both writing and reading past
> the end, even though the latter problem is often viewed as being
> lower severity than the former, or at least sufficiently different
> to triage separately. In CWE, for examp
On 2020-08-26 4:08 p.m., Jeff Law wrote:
> It 3-stages, but trips:
> Tests that now fail, but worked before (5 tests):
>
> gcc.dg/tree-ssa/slsr-13.c scan-tree-dump-times optimized " \\* 4" 2
> gcc.dg/tree-ssa/slsr-13.c scan-tree-dump-times optimized " \\* 4" 2
> gcc.dg/tree-ssa/slsr-13.c scan-tree-
Segher:
On Thu, 2020-08-20 at 16:50 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Aug 11, 2020 at 12:23:05PM -0700, Carl Love wrote:
> > +;; 128-bit int modes
> > +(define_mode_iterator VEC_I128 [V1TI TI])
>
> We already have VSX_TI for this (in vsx.md). Rename that to
> something
> withou
On Sun, 2020-08-23 at 00:24 +0100, Roger Sayle wrote:
> Hi Dave,
> I actually think using plus_xor_ior operator is useful. It means that if
> combine,
> inlining or some other RTL simplification generates these variants, these
> forms
> will still be recognized by the backend. It's more typing,
> Reject target("no-general-regs-only") pragma and attribute.
>
> gcc/
>
> PR target/96802
> * config/i386/i386-options.c (ix86_valid_target_attribute_inner_p):
> Reject target("no-general-regs-only").
>
> gcc/testsuite/
>
> PR target/96802
> * gcc.target/i386/pr96802-1.c: New test.
> * gcc.target/
Reject target("no-general-regs-only") pragma and attribute.
gcc/
PR target/96802
* config/i386/i386-options.c (ix86_valid_target_attribute_inner_p):
Reject target("no-general-regs-only").
gcc/testsuite/
PR target/96802
* gcc.target/i386/pr96802-1.c: New t
On Wed, 2020-08-26 at 09:02 -0300, Alexandre Oliva wrote:
> On Aug 25, 2020, Jeff Law wrote:
>
> > On Tue, 2020-08-25 at 02:16 -0300, Alexandre Oliva wrote:
> > > On Aug 24, 2020, Richard Biener wrote:
> > >
> > > > since the option is quite elaborate on what (sub-)set of regs is
> > > > suppos
The _Tuple_impl constructor for allocator-extended construction from a
different tuple type uses the _Tuple_impl's own _Head type in the
__use_alloc test. That is incorrect, because the argument tuple could
have a different type. Using the wrong type might select the
leading-allocator convention wh
libstdc++-v3/ChangeLog:
* include/std/tuple (_Tuple_impl): Whitespaces changes for
consistent indentation. Also use __enable_if_t alias template.
Tested powerpc64le-linux. Committed to trunk.
commit af06acfc8de1ddcfd02a4de1200735b5479f086f
Author: Jonathan Wakely
Date: Wed Aug
Segher:
On Wed, 2020-08-19 at 20:29 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Aug 11, 2020 at 12:22:59PM -0700, Carl Love wrote:
> > +(define_insn "floattitd2"
> > + [(set (match_operand:TD 0 "gpc_reg_operand" "=d")
> > + (float:TD (match_operand:TI 1 "gpc_reg_operand" "v")))]
> > +
> On Aug 26, 2020, at 7:02 AM, Alexandre Oliva wrote:
>
> On Aug 25, 2020, Jeff Law mailto:l...@redhat.com>> wrote:
>
>> On Tue, 2020-08-25 at 02:16 -0300, Alexandre Oliva wrote:
>>> On Aug 24, 2020, Richard Biener wrote:
>>>
since the option is quite elaborate on what (sub-)set of reg
On 8/26/20 1:07 PM, Jason Merrill wrote:
On 8/26/20 12:56 PM, Nathan Sidwell wrote:
On 8/26/20 12:06 PM, Jason Merrill wrote:
On 8/26/20 8:30 AM, Nathan Sidwell wrote:
This still retains only recording on lambdas. As the comment says, we
could enable for all templates.
If we're going to
On 8/26/20 12:56 PM, Nathan Sidwell wrote:
On 8/26/20 12:06 PM, Jason Merrill wrote:
On 8/26/20 8:30 AM, Nathan Sidwell wrote:
Jason's fix to retain operator lookups inside dependent lambda
functions turns out to be needed on the modules branch for all
template functions. Because the context
On 8/26/20 12:06 PM, Jason Merrill wrote:
On 8/26/20 8:30 AM, Nathan Sidwell wrote:
Jason's fix to retain operator lookups inside dependent lambda
functions turns out to be needed on the modules branch for all
template functions. Because the context for that lookup no longer
exists in imports.
This change evaluates __glibcxx_assert checks unconditionally when a
function is being constant evaluated (when std::is_constant_evaluated()
is true). If the check fails, compilation will fail with an error.
If the function isn't being constant evaluated, the normal runtime check
will be done if e
On 26/08/20 16:58 +0100, Jonathan Wakely wrote:
On 26/08/20 16:55 +0100, Jonathan Wakely wrote:
On 26/08/20 16:30 +0100, Jonathan Wakely wrote:
I'm seeing new FAILures with this:
FAIL: 20_util/function_objects/searchers.cc (test for excess errors)
UNRESOLVED: 20_util/function_objects/searchers
On 26/08/20 12:35 -0400, Patrick Palka via Libstdc++ wrote:
Tested on x86_64-pc-linux-gnu, does this look OK to commit?
OK, thanks.
libstdc++-v3/ChangeLog:
* include/std/chrono (year_month_weekday::operator==): Compare
weekday_indexed instead of weekday.
* testsuite/
Tested on x86_64-pc-linux-gnu, does this look OK to commit?
libstdc++-v3/ChangeLog:
* include/std/chrono (year_month_weekday::operator==): Compare
weekday_indexed instead of weekday.
* testsuite/std/time/year_month_weekday/1.cc: Augment testcase.
---
libstdc++-v3/include/
This fixes an issue caused by the patch for PR 94672, which
affects both GCC 10 and GCC 11.
Only 'sVal' of 'subroutine foo' was affected, the rest is
only a crosscheck that it worked for those code paths.
(I did check against the dump – which looks fine. I could
add dump tests as well. The 'foo'
On Wed, 2020-08-26 at 12:19 +0100, Roger Sayle wrote:
> Hi Dave,
>
> > This change is also fine.
> >
> > The gcc.target/hppa/shadd-2.c test now fails because there are two
> additional sh1add instructions.
> > However, the total number of instructions is the same as before.
>
> Just to be on the
On 8/26/20 8:30 AM, Nathan Sidwell wrote:
Jason's fix to retain operator lookups inside dependent lambda
functions turns out to be needed on the modules branch for all
template functions. Because the context for that lookup no longer
exists in imports. There were also a couple of shortcomings,
On 26/08/20 16:55 +0100, Jonathan Wakely wrote:
On 26/08/20 16:30 +0100, Jonathan Wakely wrote:
I'm seeing new FAILures with this:
FAIL: 20_util/function_objects/searchers.cc (test for excess errors)
UNRESOLVED: 20_util/function_objects/searchers.cc compilation failed to produce
executable
FAI
On 26/08/20 16:30 +0100, Jonathan Wakely wrote:
On 25/08/20 15:30 +0100, Jonathan Wakely wrote:
On 17/08/20 19:13 +0200, François Dumont via Libstdc++ wrote:
Hi
   Here is the new proposal.
   As we can't remove template parameters I simply restore those
that I tried to pass differe
On 25/08/20 15:30 +0100, Jonathan Wakely wrote:
On 17/08/20 19:13 +0200, François Dumont via Libstdc++ wrote:
Hi
   Here is the new proposal.
   As we can't remove template parameters I simply restore those
that I tried to pass differently _H2 and _ExtractKey, so eventually
I only r
Thanks for the review, both.
On 26/08/2020 09:19, Vladimir Makarov wrote:
>
> On 2020-08-26 5:06 a.m., Richard Sandiford wrote:
> > Alex Coplan writes:
> >
> > Minor nit, should be formatted as:
> >
> > static rtx
> > canonicalize_reload_addr (rtx addr)
> Sorry for missing this. Alex, it shou
This improves DSEs stmt walking by not considering a DEF without
uses for further processing (and thus giving up when there's two
paths to follow).
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2020-08-26 Richard Biener
PR tree-optimization/96565
* t
On 8/26/20 7:37 AM, Nathan Sidwell wrote:
Hi,
I had a need to add a new type of informative message on the modules
branch, with an option to enable it. The message is not a warning or an
error, but just 'hey, you asked if X happens. It happens just here'.
This is emitted as a note. I chose
PING * 2
On 8/11/20 1:55 PM, Aldy Hernandez wrote:
-- Forwarded message -
From: *Aldy Hernandez* mailto:al...@redhat.com>>
Date: Tue, Aug 4, 2020, 13:34
Subject: [PATCH] Adjust tree-ssa-strlen.c for irange API.
To: mailto:gcc-patches@gcc.gnu.org>>
Cc: mailto:l...@redhat.com>>, <
PING * 2
On 8/11/20 1:56 PM, Aldy Hernandez wrote:
-- Forwarded message -
From: *Aldy Hernandez* mailto:al...@redhat.com>>
Date: Thu, Aug 6, 2020, 16:54
Subject: [PATCH] Rewrite get_size_range for irange API.
To: mailto:gcc-patches@gcc.gnu.org>>
Cc: mailto:mse...@redhat.com>>, A
On 8/26/20 9:40 AM, Richard Biener wrote:
On Wed, Aug 26, 2020 at 3:37 PM Nathan Sidwell wrote:
Hi,
I had a need to add a new type of informative message on the modules
branch, with an option to enable it. The message is not a warning or an
error, but just 'hey, you asked if X happens. It ha
This fixes vectorized PHI latch edge updating and delay it until
all of the loop is code generated to deal with the case that the
latch def is a PHI in the same block.
Boostrapped and tested on x86_64-unknown-linux-gnu, pushed.
2020-08-26 Richard Biener
PR tree-optimization/96698
On 8/26/20 9:50 AM, Rainer Orth wrote:
Hi Nathan,
Hi,
I had a need to add a new type of informative message on the modules
branch, with an option to enable it. The message is not a warning or an
error, but just 'hey, you asked if X happens. It happens just here'. This
is emitted as a note. I
On 8/12/20 2:28 PM, Martin Liška wrote:
I guess Richi can defend his strategy for this
Richi?
Martin
Hi Nathan,
> Hi,
> I had a need to add a new type of informative message on the modules
> branch, with an option to enable it. The message is not a warning or an
> error, but just 'hey, you asked if X happens. It happens just here'. This
> is emitted as a note. I chose -fnote-$NAME for the opti
On Wed, 2020-08-26 at 09:37 -0400, Nathan Sidwell wrote:
> Hi,
> I had a need to add a new type of informative message on the modules
> branch, with an option to enable it. The message is not a warning or
> an
> error, but just 'hey, you asked if X happens. It happens just
> here'.
> This is e
Hi.
There's one obvious fix that I've just noticed.
I'm going to install it.
Martin
>From a5d075d595d35cd5d6607bbd9c8b2eb7707ca920 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Wed, 26 Aug 2020 13:18:14 +0200
Subject: [PATCH] symver: fix attribute matching.
gcc/ChangeLog:
* cgraphunit.c
On Wed, Aug 26, 2020 at 3:37 PM Nathan Sidwell wrote:
>
> Hi,
> I had a need to add a new type of informative message on the modules
> branch, with an option to enable it. The message is not a warning or an
> error, but just 'hey, you asked if X happens. It happens just here'.
> This is emitted
Hi,
I had a need to add a new type of informative message on the modules
branch, with an option to enable it. The message is not a warning or an
error, but just 'hey, you asked if X happens. It happens just here'.
This is emitted as a note. I chose -fnote-$NAME for the option, but
that wasn
Hi Mark,
OK to commit and backport?
OK. Thanks for the patch!
Best regards
Thomas
Hi Mark,
Please find attach a fix for PR95398. The original patch was by Steve
Kargl.
OK to commit?
OK. Thanks for taking this on!
Regards
Thomas
On 2020-08-26 5:06 a.m., Richard Sandiford wrote:
Alex Coplan writes:
Minor nit, should be formatted as:
static rtx
canonicalize_reload_addr (rtx addr)
Sorry for missing this. Alex, it should be fixed anyway.
I don't think we should we restrict this to (plus (mult X Y) Z),
since addresse
This appropriately uses VMAT_ELEMENTWISE when the vectors cannot be
filled from a single SLP group until we get more explicit support
for negative stride SLP.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
Richard.
2020-08-26 Richard Biener
PR tree-optimization/96783
On Wed, Aug 26, 2020 at 5:24 AM Martin Liška wrote:
>
> On 8/26/20 2:22 PM, H.J. Lu wrote:
> > What is the question?
>
> What are the scenarios where the new syntax:
>
>.symver foo, foo@VERS_1, local# Change foo to a local symbol.
foo is local to the file. Use it there is no global refer
On Thu, 6 Aug 2020, Richard Biener wrote:
> On Thu, 6 Aug 2020, Richard Biener wrote:
>
> > This adds a move CTOR to auto_vec and makes use of a
> > auto_vec return value for get_loop_exit_edges denoting
> > that lifetime management of the vector is handed to the caller.
> >
> > The move CTOR pr
Jason's fix to retain operator lookups inside dependent lambda
functions turns out to be needed on the modules branch for all
template functions. Because the context for that lookup no longer
exists in imports. There were also a couple of shortcomings, which
this patch fixes.
(a) we conflate '
On 8/26/20 2:22 PM, H.J. Lu wrote:
What is the question?
What are the scenarios where the new syntax:
.symver foo, foo@VERS_1, local# Change foo to a local symbol.
.symver foo, foo@VERS_2, hidden # Change foo to a hidden symbol.
is useful?
Thanks,
Martin
Hello, Mark,
On Aug 25, 2020, Mark Wielaard wrote:
> On Tue, 2020-08-25 at 01:05 -0300, Alexandre Oliva wrote:
>> it would seem to
>> make more sense to adopt and promote the proposed extension,
>> implemented in =incompat5 in GCC, but it would need some
>> implementation work in consumers to at
On Wed, Aug 26, 2020 at 4:34 AM Martin Liška wrote:
>
> On 8/26/20 1:27 PM, Jan Hubicka wrote:
> >> On 8/26/20 11:22 AM, Jan Hubicka wrote:
> On 8/25/20 8:46 PM, Jan Hubicka wrote:
> > What will happen here with protected visibility?
>
> I forgot about it. Should it be mapped al
On Aug 25, 2020, Jeff Law wrote:
> On Tue, 2020-08-25 at 02:16 -0300, Alexandre Oliva wrote:
>> On Aug 24, 2020, Richard Biener wrote:
>>
>> > since the option is quite elaborate on what (sub-)set of regs is
>> > supposed to be cleared I'm not sure an implementation not involving
>> > any targe
On 8/26/20 1:27 PM, Jan Hubicka wrote:
On 8/26/20 11:22 AM, Jan Hubicka wrote:
On 8/25/20 8:46 PM, Jan Hubicka wrote:
What will happen here with protected visibility?
I forgot about it. Should it be mapped also to "local"?
+ const char *visibility = NULL;
+ if (!TREE_PUBLIC (origin_decl))
On Wed, Aug 26, 2020 at 01:08:00PM +0200, Richard Biener via Gcc-patches wrote:
> You only need -fexceptions for that, then you can throw; from a signal handler
> for example. If you want to be able to catch the exception somewhere up
> the call chain all intermediate code needs to be compiled so
> On 8/26/20 11:22 AM, Jan Hubicka wrote:
> > > On 8/25/20 8:46 PM, Jan Hubicka wrote:
> > > > What will happen here with protected visibility?
> > >
> > > I forgot about it. Should it be mapped also to "local"?
> > >
> > > + const char *visibility = NULL;
> > > + if (!TREE_PUBLIC (origin_decl)
Hi Dave,
> This change is also fine.
>
> The gcc.target/hppa/shadd-2.c test now fails because there are two
additional sh1add instructions.
> However, the total number of instructions is the same as before.
Just to be on the safe side, I took a deeper look into this.
We're now generating a sli
On 8/26/20 11:22 AM, Jan Hubicka wrote:
On 8/25/20 8:46 PM, Jan Hubicka wrote:
What will happen here with protected visibility?
I forgot about it. Should it be mapped also to "local"?
+ const char *visibility = NULL;
+ if (!TREE_PUBLIC (origin_decl))
+visibility = "remove";
+ else if (
On Wed, Aug 26, 2020 at 10:13 AM Martin Liška wrote:
>
> Hey.
>
> We should document how we currently merge pie and pie options
> as we fixed PR80838.
>
> Ready for master?
OK.
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> * doc/invoke.texi: Document how are pie and pic options merged.
> ---
On Tue, Aug 25, 2020 at 6:32 PM Maciej W. Rozycki wrote:
>
> Hi Kito,
>
> > I just found the mail thread about div mod with -fnon-call-exceptions,
> > I think keeping the default LIB2_DIVMOD_EXCEPTION_FLAGS unchanged
> > should be the best way to go.
> >
> > Non-call exceptions and libcalls
> > ht
Hello,
Thank you for adjusting the patch.
I don't have commit privileges, so if you could please commit it, that would be
great.
Best regards,
Darius Galis
On 25-Aug-20 10:48 PM, Jeff Law wrote:
On Tue, 2020-08-18 at 16:05 +0300, Darius Galis wrote:
Hello,
The following patch is adding the
xiezhiheng writes:
>> -Original Message-
>> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
>> Sent: Tuesday, August 25, 2020 7:08 PM
>> To: xiezhiheng
>> Cc: Richard Biener ; gcc-patches@gcc.gnu.org
>> Subject: Re: [PATCH PR94442] [AArch64] Redundant ldp/stp instructions
>> em
Qian Jianhua writes:
> There are three failures in gcc.target/aarch64/insv_1.c.
> FAIL: gcc.target/aarch64/insv_1.c scan-assembler bfi\tx[0-9]+, x[0-9]+, 0, 8
> FAIL: gcc.target/aarch64/insv_1.c scan-assembler bfi\tx[0-9]+, x[0-9]+, 16, 5
> FAIL: gcc.target/aarch64/insv_1.c scan-assembler movk\
Hi,
This is a fix for PR96757.
Before vect pass, the main statements of the test case will be optimized like：
_1 = d_10(D) > 3;
_2 = a_11(D) > m_12(D);
_18 = _1 > _2 ? _26 : 0;
At the beginning of vectorization analysis, function
vect_recog_mask_conversion_pattern
proce
> On 8/25/20 8:46 PM, Jan Hubicka wrote:
> > What will happen here with protected visibility?
>
> I forgot about it. Should it be mapped also to "local"?
>
> + const char *visibility = NULL;
> + if (!TREE_PUBLIC (origin_decl))
> +visibility = "remove";
> + else if (DECL_VISIBILITY (origin_
On 8/25/20 4:46 PM, Nick Desaulniers wrote:
This would solve a common pattern in the kernel where folks are using
`extern inline` with `gnu_inline` semantics or worse (empty `asm("");`
statements) in certain places where it would be much more preferable
to have this attribute. Thank you very muc
Alex Coplan writes:
> Hello,
>
> Inside a (mem) RTX, it is canonical to write multiplications by powers
> of two using a (mult) [0]. For example, given the following C function:
>
> long f(long *p, long x)
> {
> return p[x];
> }
>
> AArch64 GCC generates the following RTL insn (in final):
>
>
On Wed, 26 Aug 2020, Jakub Jelinek wrote:
> Hi!
>
> The addition of NOTE_INSN_BEGIN_STMT and NOTE_INSN_INLINE_ENTRY notes
> reintroduced quadratic behavior into dwarf2out_var_location.
> This function needs to know the next real instruction to which the var
> location note applies, but the way fi
Hi!
The addition of NOTE_INSN_BEGIN_STMT and NOTE_INSN_INLINE_ENTRY notes
reintroduced quadratic behavior into dwarf2out_var_location.
This function needs to know the next real instruction to which the var
location note applies, but the way final_scan_insn is called outside of
final.c main loop do
Hi,
This patch backports a change from upstream dmd that moves front-end
NRVO checking from ReturnStatement semantic to the end of
FuncDeclaration semantic.
In the codegen, retStyle has been partially implemented so that only
structs and static arrays return RETstack. This isn't accurate, but
do
Hi,
This patch merges the D front-end implementation with upstream dmd
cb4a96fae. Fixes both a bug where compilation would hang, and an issue
where recursive template limits are hit too early.
Regstrapped on x86_64-linux-gnu/-m32/-mx32, committed to mainline, and
cherry-picked to the releases/gc
1 - 100 of 113 matches
Mail list logo
