On 1/18/21 10:54 PM, Ilya Leoshkevich wrote:
...
> +static rtx_insn *
> +s390_md_asm_adjust (vec &outputs, vec &inputs,
> + vec &input_modes,
> + vec &constraints, vec & /*clobbers*/,
> + HARD_REG_SET & /*clobbered_regs*/)
> +{
> + if (!TARGET_VXE)
Hi：
As desribed in PR, also remove the relevant and useless expanders
and builtins, the user can
directly use == and >, without calling the builtin function.
Bootstrapped and regtested on x86_64-linux-gnu{-m32,}.
gcc/ChangeLog:
PR target/98833
* config/i386/i386-builtin.def (B
Sorry, I forgot to remove the line '*explicit_version_p = true;' in my
previous patch.
This is an updated patch.
Thanks!
---
gcc/ChangeLog:
* common/config/riscv/riscv-common.c
(riscv_subset_list::parsing_subset_version):
Fix -march option parsing when `p` extension exists.
gcc
Hi,
On 2021/1/27 03:00, David Edelsohn wrote:
> On Tue, Jan 26, 2021 at 2:46 AM Xionghu Luo wrote:
>>
>> From: "luo...@cn.ibm.com"
>>
>> UNSPEC_SI_FROM_SF is not supported when TARGET_DIRECT_MOVE_64BIT
>> is false for -m32, don't generate VIEW_CONVERT_EXPR(ARRAY_REF) for
>> variable vector inser
Hi Marcus:
Let you know reviewing this patch is on my TODO list, and I definitely
want this included in GCC 11, but I am working on other urgent work
this week, so I might not be able to give any review comment or
testing at this moment.
Thanks for your awesome work for big-endian support!
On Tu
I posted this patch on January 14th, 2021:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563498.html
| Date: Thu, 14 Jan 2021 12:09:36 -0500
| Subject: [PATCH] PowerPC: Add float128/Decimal conversions.
| Message-ID: <20210114170936.ga3...@ibm-toto.the-meissners.org>
You had a question a
Ping https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563496.html
| Date: Thu, 14 Jan 2021 11:59:19 -0500
| Subject: [PATCH] PowerPC: Map IEEE 128-bit long double built-ins.
| Message-ID: <20210114165919.ga1...@ibm-toto.the-meissners.org>
As I've said in the past, this is the most important
Running git gcc-verify on this version, I get
ERR: cannot find a ChangeLog location in message
I had to fix the indentation of the ChangeLog entries to make it work.
Probably best to include them in the attachment, e.g. by attaching the
result of git format-patch. It looks like you copied the
In this testcase, we refer to the a parameter through a reference in its own
member, which we asserted couldn't happen by marking the parameter as
'restrict'. This assumption could also be broken if the address escapes
from the constructor.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/C
On Tue, 26 Jan 2021, Martin Jambor wrote:
> I have discussed this with Pekka and we concluded that deprecating the
> HSAIL/BRIG front-end is the right thing to do. Therefore, I'd like to
> propose the following patch to the documentation repo. Is it OK?
> + The front-end for compiling BRIG form
On Fri, 2020-12-18 at 18:03 -0500, Lewis Hyatt wrote:
> Hello-
>
> The attached patch addresses PR93067:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93067#c0
>
> This is similar to the patch I posted last year on the PR, with some
tweaks
> to make it a little simpler. Recapping some of the com
On Tue, 26 Jan 2021, Richard Biener wrote:
> If it is an initializer from constants we gimplify to a series of
> assigns it might be still useful. OTOH, I'm not sure whether
> a const auto is really readonly in C or if it is safe to assume
> the stack part is writable and thus casting away the co
On 1/25/21 10:23 AM, Segher Boessenkool wrote:
Hi!
On Thu, Jan 21, 2021 at 05:49:14PM -0600, will schmidt wrote:
Noted as part of the work-in-progress builtins rewrite, the
__builtin_dfp_dtstsfi_*_{dd,td} builtins are redundant, and are thusly
being marked as deprecated. They will be remove
Since ld may depend on libctf (if present), and libctf may be relinked
by the installation process, libctf must be installed before ld is,
or the relink may fail if it calls on symbols or symbol versions that do
not exist in any libctf already present on the system. (If none is
present, the copy i
On 26 Jan 2021, Andreas Schwab outgrape:
> On Jan 26 2021, Nick Alcock via Gcc-patches wrote:
>
>> diff --git a/Makefile.in b/Makefile.in
>> index 03785200dc7..d8a94c4173d 100644
>> --- a/Makefile.in
>> +++ b/Makefile.in
>> @@ -565,7 +565,7 @@ STAGEprofile_TFLAGS = $(STAGE2_TFLAGS)
>> STAGEtrain_
On Jan 26 2021, Nick Alcock via Gcc-patches wrote:
> diff --git a/Makefile.in b/Makefile.in
> index 03785200dc7..d8a94c4173d 100644
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -565,7 +565,7 @@ STAGEprofile_TFLAGS = $(STAGE2_TFLAGS)
> STAGEtrain_CFLAGS = $(filter-out -fchecking=1,$(STAGE3_CFLAGS)
In the discussion of PR98463, Jakub pointed out that in C++17 and up,
cxx_fold_indirect_ref_1 could use the field we build for an empty base. I
tried implementing that, but it broke one of the tuple tests, so I did some
more digging.
To start with, I generalized the PR98463 patch to handle the ca
On 25 Jan 2021, Nathan Sidwell said:
> I think you're right about checking though, not
I'll look at it once I've dealt with this unfortunate "installing
binutils leaves the system linker broken" disaster I've caused. :)
--
NULL && (void)
Since ld may depend on libctf (if present), and libctf may be relinked
by the installation process, libctf must be installed before ld is,
or the relink may fail if it calls on symbols or symbol versions that do
not exist in any libctf already present on the system. (If none is
present, the copy i
On Tue, Jan 26, 2021 at 2:46 AM Xionghu Luo wrote:
>
> From: "luo...@cn.ibm.com"
>
> UNSPEC_SI_FROM_SF is not supported when TARGET_DIRECT_MOVE_64BIT
> is false for -m32, don't generate VIEW_CONVERT_EXPR(ARRAY_REF) for
> variable vector insert. Remove rs6000_expand_vector_set_var helper
> functi
Hi,
On Wed, Jan 06 2021, Gerald Pfeifer wrote:
> On Mon, 4 Jan 2021, Martin Jambor wrote:
>> Given that nobody bothered to update the FE to HSAIL 1.2 (which is 2.5
>> years old) and it is unlikely to have many users, maybe it is time to
>> deprecate the FE in GCC 11 (I guess it is not a promise to
On Tue, Jan 26, 2021 at 1:11 PM will schmidt wrote:
>
> On Tue, 2021-01-26 at 01:46 -0600, Xionghu Luo via Gcc-patches wrote:
> > From: "luo...@cn.ibm.com"
> >
> > (rs6000_expand_vector_set_var): Delete.
>
> The diff conflates the deleted function with the changes to an existing
> function,
On Tue, 2021-01-26 at 01:46 -0600, Xionghu Luo via Gcc-patches wrote:
> From: "luo...@cn.ibm.com"
>
> UNSPEC_SI_FROM_SF is not supported when TARGET_DIRECT_MOVE_64BIT
> is false for -m32, don't generate VIEW_CONVERT_EXPR(ARRAY_REF) for
> variable vector insert. Remove rs6000_expand_vector_set_va
This is the profiled bootstrap failure for s390x/Linux on the mainline, which
has been introduced by the modref pass but actually exposing an existing issue
in the maybe_pad_type function that is visible only on s390x. Marius did all
the heavy lifting and posted a fairly extensive investigation
Neon vector comparisons have a dedicated version when comparing with
constant zero: it means its cost is free.
Adjust the cost in arm_rtx_costs_internal accordingly, for Neon only,
since MVE does not support this.
2021-01-26 Christophe Lyon
gcc/
PR target/98730
* config/arm/arm.c (arm_rtx_cos
On Tue, Jan 26, 2021 at 06:29:47PM +0100, Jakub Jelinek wrote:
> On Sat, Jan 23, 2021 at 03:10:10PM -0600, Segher Boessenkool wrote:
> > > The reason I chose the "no-strict-aliasing" attribute (and already
> > > committed based on Richi's ack) was consistency with the i386
> > > testcase. I can ch
Hi!
On Tue, Jan 26, 2021 at 11:47:53AM +0100, Richard Biener wrote:
> Anyway, I think the GIMPLE -> RTL transition currently is a too
> big step
Much agreed. I also think that the expand pass itself needs a lot of
work to bring it into this century: it does much too much work, in a
circuitous wa
On Tue, Jan 26, 2021 at 04:53:25PM +0800, Kewen.Lin wrote:
> on 2021/1/26 上午4:37, Segher Boessenkool wrote:
> > On Mon, Jan 25, 2021 at 05:59:23PM +, Richard Sandiford wrote:
> >> Richard Biener writes:
> >>> On Fri, 22 Jan 2021, Segher Boessenkool wrote:
> But what could have been done d
Ping.
On 11/13/20 4:04 PM, Pat Haugen via Gcc-patches wrote:
> Add Power10 scheduling description.
>
> This patch adds the Power10 scheduling description. Since power10.md was
> pretty much a complete rewrite (existing version of power10.md is mostly just
> a copy of power9.md), I diffed power1
On Sat, Jan 23, 2021 at 03:10:10PM -0600, Segher Boessenkool wrote:
> > The reason I chose the "no-strict-aliasing" attribute (and already
> > committed based on Richi's ack) was consistency with the i386
> > testcase. I can change both.
>
> Yes please. Thanks!
So like this?
Tested on x86_64-li
Ping.
On 12/10/20 3:32 PM, Pat Haugen via Gcc-patches wrote:
> Update prefixed attribute for Power10.
>
>
> This patch was broken out from my larger patch to update various attributes
> for
> Power10, in order to make the review process hopefully easier. This patch only
> updates the prefix att
Ping
On 12/8/20 3:46 PM, Pat Haugen via Gcc-patches wrote:
> Update size attribute for Power10.
>
>
> This patch was broken out from my larger patch to update various attributes
> for
> Power10, in order to make the review process hopefully easier. This patch only
> updates the size attribute f
Hi!
My recent dwarf2asm.c patch broke powerpc*-*-* bootstrap, while most target
define POINTER_SIZE to (cond ? cst1 : cst2) or constant, rs6000 defines
it to a variable, and the arbitrarily chosen type of that variable determines
whether we get warnings on comparison of that against signed or unsi
On Mon, 11 Jan 2021, Jeff Law wrote:
> I think most are posting the stdout from the check run. So we don't
> generally get all the pass/xfail messages, but we do get fail/xpass
> messages. They don't need to be triaged or anything.
I now have the results, though I had to trim them by hand fro
Hi,
Can we backport PR94230 patch (add a new diagnostic
flag -flarge-source-files) to GCC 10 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94230
PR94230 backport will benefit people moving from
GCC 9 to GCC 10 who face issue while working with
large header/source files.
See example issue on Lina
Hi all,
This patch adds the arm and aarch64 sections changes.html for GCC 11.
There's more than that that went into the release, but this can serve as a
starting point for filling the sections in.
Pushing to the repo.
Thanks,
Kyrill
wwwdocs-arm.patch
Description: wwwdocs-arm.patch
Jakub Jelinek via Gcc-patches writes:
> Hi!
>
> The testcase in the patch doesn't assemble, because the instruction requires
> that the penultimate operand (lsb) range is [0, 32] (or [0, 64]) and the last
> operand's range is [1, 32 - lsb] (or [1, 64 - lsb]).
> The INTVAL (shft_amnt) < GET_MODE_BI
On Tue, 26 Jan 2021, Richard Sandiford wrote:
> Richard Biener writes:
> > This fixes VECTOR_CST element access with POLY_INT elements and
> > allows to produce dump files of the PR98726 testcase without
> > ICEing.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
>
> Thanks for
This fixes:
gcc a.c -fsanitize=leak
/usr/bin/ld:
/home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../lib64/liblsan.so:
undefined reference to `__lsan::GetThreadRangesLocked(unsigned long long,
unsigned long*, unsigned long*, unsigned long*, unsigned long*, unsigned long*,
un
Richard Biener writes:
> This fixes VECTOR_CST element access with POLY_INT elements and
> allows to produce dump files of the PR98726 testcase without
> ICEing.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
Thanks for doing this. I could have sworn I'd written almost
exactly the
This fixes VECTOR_CST element access with POLY_INT elements and
allows to produce dump files of the PR98726 testcase without
ICEing.
Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
Thanks,
Richard.
2021-01-26 Richard Biener
PR middle-end/98726
* tree.h (vector_cst_in
This avoids dumping them as <<< ??? >>>.
Will commit as obvoious.
2021-01-26 Richard Biener
* gimple-pretty-print.c (dump_binary_rhs): Handle
VEC_WIDEN_{PLUS,MINUS}_{LO,HI}_EXPR.
---
gcc/gimple-pretty-print.c | 4
1 file changed, 4 insertions(+)
diff --git a/gcc/gimple-
On 1/25/21 3:55 PM, Jan Hubicka wrote:
I've just installed the patch.
About the negative total value. Something similar can handle it:
diff --git a/libgcc/libgcov.h b/libgcc/libgcov.h
index df08e882dd7..ddc688509bd 100644
--- a/libgcc/libgcov.h
+++ b/libgcc/libgcov.h
@@ -443,7 +443,13 @@ gcov_to
Hi,
As subject, this patch rewrites integer mla_n Neon intrinsics to use RTL
builtins rather than inline assembly code, allowing for better scheduling
and optimization.
Regression tested and bootstrapped on aarch64-none-linux-gnu - no
issues.
Ok for master?
Thanks,
Jonathan
---
gcc/ChangeLo
Now backported to devel/omp/gcc-10.
On 26/01/2021 10:29, Andrew Stubbs wrote:
This patch fixes and AMD GCN bug in which attempting to use DFmode
vector reductions would cause an ICE.
There's no reason not to allow the reductions, so we simply enable them
thusly.
Andrew
On Tue, 26 Jan 2021, Jakub Jelinek wrote:
> On Tue, Jan 26, 2021 at 12:25:16PM +0100, Richard Biener wrote:
> > On Tue, 26 Jan 2021, Jakub Jelinek wrote:
> >
> > > On Tue, Jan 26, 2021 at 12:16:14PM +0100, Richard Biener wrote:
> > > > > + /* Unless this is called during FE folding. */
> >
On Tue, Jan 26, 2021 at 12:25:16PM +0100, Richard Biener wrote:
> On Tue, 26 Jan 2021, Jakub Jelinek wrote:
>
> > On Tue, Jan 26, 2021 at 12:16:14PM +0100, Richard Biener wrote:
> > > > + /* Unless this is called during FE folding. */
> > > > + if (cfun
> > > > + && (cfun->curr_
On Tue, 26 Jan 2021, Jakub Jelinek wrote:
> On Tue, Jan 26, 2021 at 12:16:14PM +0100, Richard Biener wrote:
> > > + /* Unless this is called during FE folding. */
> > > + if (cfun
> > > + && (cfun->curr_properties & (PROP_trees | PROP_rtl)) == 0
> >
> > don't you want && (cfun->curr_
On Tue, Jan 26, 2021 at 12:16:14PM +0100, Richard Biener wrote:
> > + /* Unless this is called during FE folding. */
> > + if (cfun
> > + && (cfun->curr_properties & (PROP_trees | PROP_rtl)) == 0
>
> don't you want && (cfun->curr_properties & PROP_trees) != 0?
No, PROP_trees is mis
On Tue, 26 Jan 2021, Jakub Jelinek wrote:
> On Tue, Jan 26, 2021 at 11:37:42AM +0100, Jan Hubicka wrote:
> > I think it would make more sense.
> > We could also simply clean it up next stage1.
>
> I'll rebootstrap/retest the following version then (adding PROP_rtl
> just in case it would be calle
On Tue, 26 Jan 2021, Kewen.Lin wrote:
> Hi Segher/Richard B./Richard S.,
>
> Many thanks for your all helps and comments on this!
>
> on 2021/1/25 下午3:56, Richard Biener wrote:
> > On Fri, 22 Jan 2021, Segher Boessenkool wrote:
> >
> >> On Fri, Jan 22, 2021 at 02:47:06PM +0100, Richard Biener w
On Mon, 25 Jan 2021, Richard Sandiford wrote:
> Richard Biener writes:
> > On Fri, 22 Jan 2021, Segher Boessenkool wrote:
> >
> >> On Fri, Jan 22, 2021 at 02:47:06PM +0100, Richard Biener wrote:
> >> > On Thu, 21 Jan 2021, Segher Boessenkool wrote:
> >> > > What is holding up this patch still? K
On Tue, Jan 26, 2021 at 11:37:42AM +0100, Jan Hubicka wrote:
> I think it would make more sense.
> We could also simply clean it up next stage1.
I'll rebootstrap/retest the following version then (adding PROP_rtl
just in case it would be called during expand or later).
2021-01-26 Jakub Jelinek
> On Tue, Jan 26, 2021 at 10:55:35AM +0100, Jan Hubicka wrote:
> > > On Tue, Jan 26, 2021 at 10:03:16AM +0100, Richard Biener wrote:
> > > > > In 4.8 and earlier we used to fold the following to 0 during GENERIC
> > > > > folding,
> > > > > but we don't do that anymore because ctor_for_folding etc
This patch fixes and AMD GCN bug in which attempting to use DFmode
vector reductions would cause an ICE.
There's no reason not to allow the reductions, so we simply enable them
thusly.
Andrew
amdgcn: Allow V64DFmode min/max reductions
I don't know why these were disabled. There're no direct
On Tue, Jan 26, 2021 at 10:52 AM Alexandre Oliva wrote:
>
> On Jan 22, 2021, Richard Biener via Gcc-patches
> wrote:
>
> > Yeah, I guess such addresses could be decl_address_invariant_p by changing
> > the
>
> > || DECL_CONTEXT (op) == current_function_decl
> > || decl_functi
On Tue, 26 Jan 2021, Jakub Jelinek wrote:
> On Tue, Jan 26, 2021 at 10:55:35AM +0100, Jan Hubicka wrote:
> > > On Tue, Jan 26, 2021 at 10:03:16AM +0100, Richard Biener wrote:
> > > > > In 4.8 and earlier we used to fold the following to 0 during GENERIC
> > > > > folding,
> > > > > but we don't d
On Tue, Jan 26, 2021 at 10:55:35AM +0100, Jan Hubicka wrote:
> > On Tue, Jan 26, 2021 at 10:03:16AM +0100, Richard Biener wrote:
> > > > In 4.8 and earlier we used to fold the following to 0 during GENERIC
> > > > folding,
> > > > but we don't do that anymore because ctor_for_folding etc. has been
> On Tue, Jan 26, 2021 at 10:03:16AM +0100, Richard Biener wrote:
> > > In 4.8 and earlier we used to fold the following to 0 during GENERIC
> > > folding,
> > > but we don't do that anymore because ctor_for_folding etc. has been
> > > turned into a
> > > GIMPLE centric API, but as the testcase s
On Jan 22, 2021, Richard Biener via Gcc-patches wrote:
> Yeah, I guess such addresses could be decl_address_invariant_p by changing
> the
> || DECL_CONTEXT (op) == current_function_decl
> || decl_function_context (op) == current_function_decl)
> to sth like
>|| auto
On Tue, 26 Jan 2021, Jakub Jelinek wrote:
> On Tue, Jan 26, 2021 at 10:03:16AM +0100, Richard Biener wrote:
> > > In 4.8 and earlier we used to fold the following to 0 during GENERIC
> > > folding,
> > > but we don't do that anymore because ctor_for_folding etc. has been
> > > turned into a
> >
On Tue, Jan 26, 2021 at 10:03:16AM +0100, Richard Biener wrote:
> > In 4.8 and earlier we used to fold the following to 0 during GENERIC
> > folding,
> > but we don't do that anymore because ctor_for_folding etc. has been turned
> > into a
> > GIMPLE centric API, but as the testcase shows, it is
On Tue, 26 Jan 2021, Jakub Jelinek wrote:
> Hi!
>
> In 4.8 and earlier we used to fold the following to 0 during GENERIC folding,
> but we don't do that anymore because ctor_for_folding etc. has been turned
> into a
> GIMPLE centric API, but as the testcase shows, it is invoked even during
> GEN
Hi,
This patch merges the D front-end implementation with upstream dmd
609c3ce2d, and the Phobos standard library with upstream 3dd5df686.
D front-end changes:
- Contracts for pre- and postconditions are now implicitly "this"
const, so that state can no longer be altered in these functions.
Hi!
In 4.8 and earlier we used to fold the following to 0 during GENERIC folding,
but we don't do that anymore because ctor_for_folding etc. has been turned into
a
GIMPLE centric API, but as the testcase shows, it is invoked even during
GENERIC folding and there the automatic vars still should ha
on 2021/1/26 上午4:37, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Jan 25, 2021 at 05:59:23PM +, Richard Sandiford wrote:
>> Richard Biener writes:
>>> On Fri, 22 Jan 2021, Segher Boessenkool wrote:
But what could have been done differently that would have helped? Of
course Ke Wen co
on 2021/1/26 上午1:59, Richard Sandiford via Gcc-patches wrote:
> Richard Biener writes:
>> On Fri, 22 Jan 2021, Segher Boessenkool wrote:
>>
>>> On Fri, Jan 22, 2021 at 02:47:06PM +0100, Richard Biener wrote:
On Thu, 21 Jan 2021, Segher Boessenkool wrote:
> What is holding up this patch st
Hi!
On Mon, Jan 25, 2021 at 01:18:05PM +0100, Richard Biener wrote:
> This simplifies vector_element_bits further, avoiding any mode
> dependence and instead relying on boolean vector construction
> to populate element precision accordingly.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu
Hi Segher/Richard B./Richard S.,
Many thanks for your all helps and comments on this!
on 2021/1/25 下午3:56, Richard Biener wrote:
> On Fri, 22 Jan 2021, Segher Boessenkool wrote:
>
>> On Fri, Jan 22, 2021 at 02:47:06PM +0100, Richard Biener wrote:
>>> On Thu, 21 Jan 2021, Segher Boessenkool wrote
69 matches
Mail list logo
