, eliminate
iv_use with enumeral type iv_cand in case of -fstrict-enums.
gcc/testsuite
2020-03-02 Bin Cheng
PR tree-optimization/93674
* g++.dg/pr93674.C: New test.
pr93674-20200302.txt
Description: Binary data
On 21/02/2020 20:29, Patrick Palka wrote:
diff --git a/libstdc++-v3/include/bits/ranges_algo.h
b/libstdc++-v3/include/bits/ranges_algo.h
index 7de1072abf0..c36afc6e19b 100644
--- a/libstdc++-v3/include/bits/ranges_algo.h
+++ b/libstdc++-v3/include/bits/ranges_algo.h
@@ -3683,6 +3683,54 @@ namesp
On 2/28/20 12:34 AM, Gerald Pfeifer wrote:
Okay? Or does this qualify as obvious?
The patch seems to me obvious. Please install it.
Martin
On Sat, Feb 29, 2020 at 2:00 PM H.J. Lu wrote:
>
> On Fri, Feb 28, 2020 at 7:38 AM H.J. Lu wrote:
> >
> > On Fri, Feb 28, 2020 at 6:30 AM H.J. Lu wrote:
> > >
> > > When generating the separate file with LTO debug sections, we should
> > > also copy .note.gnu.property section.
> > >
> > > OK for
Hi.
There's one patch that was approved by Jakub before
another RC of GCC 8.4.0.
Martin
>From 5da6f38276fac87c89d86e0d447aefb7058d1880 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Fri, 28 Feb 2020 17:52:57 +0100
Subject: [PATCH] Backport 08bf7bde9f2987b1c623d272cc71fc14a1622442
gcc/Change
On Sat, Feb 29, 2020 at 8:35 PM Jeff Law wrote:
>
> On Sun, 2020-03-01 at 01:47 +0900, Oleg Endo wrote:
> > On Sat, 2020-02-29 at 09:38 -0700, Jeff Law wrote:
> > > It really would have just been a workaround for some of the R0 issues
> > > anyway.
> > > I think at its core R0 on the SH probably n
Hi,
this corrects a thinko that seemed initially to be a missed
optimisation, but turns out to lead to wrong code in some
cases.
tested on x86_64 darwin, linux and powerpc linux
OK for trunk?
thanks
Iain
In general, we need to manage the lifetime of compiler-
generated awaitable instances in the
On Mon, Mar 2, 2020 at 9:07 AM bin.cheng wrote:
>
> Hi,
> This is a simple fix for PR93674. It adds cand carefully for enumeral type
> iv_use in
> case of -fstrict-enums, it also avoids computing, replacing iv_use with the
> candidate
> so that no IV of enumeral type is introduced with -fstrict
Hi,
In the absence of specific comment on the handling of closures I'd
implemented something more than was intended (extending the lifetime
of lambda capture-by-copy vars to the duration of the coro).
After discussion at WG21 in February and by email, the correct handling
is to treat the closure
On 2/27/20 7:55 AM, Roman Zhuykov wrote:
Does anybody considered backporting this?
I'm for the backport (after 8.4.0 will be released).
I would like to get a permission from release managers about this patch?
Martin
"Kewen.Lin" writes:
> on 2020/1/20 下午9:14, Segher Boessenkool wrote:
>> Hi!
>>
>> On Mon, Jan 20, 2020 at 10:42:12AM +, Richard Sandiford wrote:
>>> "Kewen.Lin" writes:
gcc/ChangeLog
2020-01-16 Kewen Lin
* config/rs6000/rs6000.c (TARGET_STRIDE_DFORM_VALID_P): N
On Fri, 28 Feb 2020, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR and discussed on IRC, the following patch is the
> patch that fixes the originally reported issue.
> We have there because of the premature bitfield comparison -> BIT_FIELD_REF
> optimization:
> s$s4_19 = 0;
> s.s4 = s
On Mon, Jan 20, 2020 at 9:53 AM Ian Lance Taylor wrote:
>
> kamlesh kumar writes:
>
> > yes, current expected entry is wrong and
> > Nick's patch corrects that.
>
> Thanks. Nick, the patch is OK.
>
> Ian
> >> > libiberty/ChangeLog
> >> > 2020-01-20 Nick Clifton
> >> >
> >> > * testsuit
Hi.
One obvious patch where I remove a duplicate declaration.
Martin
libgcc/ChangeLog:
2020-03-02 Martin Liska
* libgcov-interface.c: Remove duplicate
declaration of __gcov_flush_mx.
---
libgcc/libgcov-interface.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libgcc/
Hi.
The patch is about wrong comment, we can optimize
the testcase.
Martin
gcc/testsuite/ChangeLog:
2020-03-02 Martin Liska
* gcc.dg/vect/bb-slp-19.c: The comment
does not align with fact that we started
to SLP the testcase.
---
gcc/testsuite/gcc.dg/vect/bb-slp-19.
On 02/03/20 10:03 +0100, Stephan Bergmann wrote:
On 21/02/2020 20:29, Patrick Palka wrote:
diff --git a/libstdc++-v3/include/bits/ranges_algo.h
b/libstdc++-v3/include/bits/ranges_algo.h
index 7de1072abf0..c36afc6e19b 100644
--- a/libstdc++-v3/include/bits/ranges_algo.h
+++ b/libstdc++-v3/includ
On Fri, 28 Feb 2020 at 22:53, Jonathan Wakely wrote:
>
> On 28/02/20 14:59 -0500, Patrick Palka wrote:
> >We were enabling the memcmp optimization in ranges::lexicographical_compare
> >for
> >signed integral types and for integral types larger than a byte. But memcmp
> >gives the wrong answer fo
Hi.
It's a documentation update for the new -fprofile-reproducible option.
Martin
---
htdocs/gcc-10/changes.html | 6 ++
1 file changed, 6 insertions(+)
diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 53d0ca08..6e08ba41 100644
--- a/htdocs/gcc-10/changes.html
+
On 27/02/2020 13:37, Nathan Sidwell wrote:
On 2/3/20 6:41 AM, Richard Earnshaw (lists) wrote:
On 22/01/2020 17:45, Richard Earnshaw (lists) wrote:
[updated based on v2 discussions]
This patch proposes some new (additional) rules for email subject lines
when contributing to GCC. The goal is t
On 02/03/20 13:22 +0100, Christophe Lyon wrote:
On Fri, 28 Feb 2020 at 22:53, Jonathan Wakely wrote:
On 28/02/20 14:59 -0500, Patrick Palka wrote:
>We were enabling the memcmp optimization in ranges::lexicographical_compare for
>signed integral types and for integral types larger than a byte.
Hi.
For situations like -Q --help=warning,c one can't see a warning
that is common. For that one needs to use -Q --help=warning,common.
My patch explains the behavior in documentation.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2020-03-02 Martin Liska
PR c/93886
P
On Mon, Mar 02, 2020 at 01:01:46PM +, Richard Earnshaw (lists) wrote:
> I'd like to. But have we reached consensus? Seems that every time I
> produce a revised version of the text we end up in another round of bike
> shedding. (Is that a word?)
It's called a "lap", but "criterium" would b
On 3/2/20 4:37 AM, Iain Sandoe wrote:
Hi,
this corrects a thinko that seemed initially to be a missed
optimisation, but turns out to lead to wrong code in some
cases.
tested on x86_64 darwin, linux and powerpc linux
OK for trunk?
thanks
Iain
In general, we need to manage the lifetime of compil
On 3/2/20 8:01 AM, Richard Earnshaw (lists) wrote:
On 27/02/2020 13:37, Nathan Sidwell wrote:
On 2/3/20 6:41 AM, Richard Earnshaw (lists) wrote:
On 22/01/2020 17:45, Richard Earnshaw (lists) wrote:
[updated based on v2 discussions]
This patch proposes some new (additional) rules for email su
On 3/2/20 4:43 AM, Iain Sandoe wrote:
Hi,
In the absence of specific comment on the handling of closures I'd
implemented something more than was intended (extending the lifetime
of lambda capture-by-copy vars to the duration of the coro).
After discussion at WG21 in February and by email, the c
On 2/10/20 3:33 AM, bin.cheng wrote:
Hi,
We found more ICEs because of unexpanded CO_AWAIT_EXPR, it turned out we
can fix these issues with more simplification in function co_await_expander.
Here
is the patch with a new test.
Bootstrap and test on x86_64. Is it OK?
Thanks,
bin
gcc/cp
2020-
On Fri, 28 Feb 2020 at 17:39, Vladimir Makarov wrote:
>
> The following patch is dealing with arm failures after submitting
> original patch for PR93564.
>
>Changing heuristics in the original patch resulted in different order
> of allocation and creating gaps in hard reg file which were not
On Mon, 2 Mar 2020 at 14:31, Nathan Sidwell wrote:
>
> On 3/2/20 8:01 AM, Richard Earnshaw (lists) wrote:
> > On 27/02/2020 13:37, Nathan Sidwell wrote:
> >> On 2/3/20 6:41 AM, Richard Earnshaw (lists) wrote:
> >>> On 22/01/2020 17:45, Richard Earnshaw (lists) wrote:
>
> [updated based o
On 2/5/20 4:17 AM, JunMa wrote:
在 2020/2/5 下午2:14, JunMa 写道:
Hi
This patch builds co_await/yield_expr with unknown_type when we can not
know the promise type in processing_template_decl phase. it avoid to
confuse compiler when handing type deduction and conversion.
Bootstrap and test on X86_64,
On 2/12/20 2:23 AM, JunMa wrote:
Hi
In captures_temporary, the current implementation fails to handle
component_ref. This causes ice with case co_await A while
operator co_await is defined in base class of A. Also it is necessary
to capture the object of base class as if it is temporary object.
On Mon, Mar 02, 2020 at 12:46:30PM +0100, Richard Biener wrote:
> > + void *r = data.push_partial_def (pd, 0, prec);
> > + if (r == (void *) -1)
> > + return NULL_TREE;
> > + gcc_assert (r == NULL_TREE);
> > + }
> > + pos += tz;
>
On Mon, 2020-03-02 at 15:37 +0100, Christophe Lyon wrote:
> On Fri, 28 Feb 2020 at 17:39, Vladimir Makarov wrote:
> > The following patch is dealing with arm failures after submitting
> > original patch for PR93564.
> >
> >Changing heuristics in the original patch resulted in different orde
On 02/03/2020 14:41, Jonathan Wakely wrote:
On Mon, 2 Mar 2020 at 14:31, Nathan Sidwell wrote:
On 3/2/20 8:01 AM, Richard Earnshaw (lists) wrote:
On 27/02/2020 13:37, Nathan Sidwell wrote:
On 2/3/20 6:41 AM, Richard Earnshaw (lists) wrote:
On 22/01/2020 17:45, Richard Earnshaw (lists) wrote
On Mon, 2020-03-02 at 08:17 -0700, Jeff Law wrote:
> On Mon, 2020-03-02 at 15:37 +0100, Christophe Lyon wrote:
> > On Fri, 28 Feb 2020 at 17:39, Vladimir Makarov wrote:
> > > The following patch is dealing with arm failures after submitting
> > > original patch for PR93564.
> > >
> > >Chang
Ping: Jeff, see the question below. Thanks.
On Mon, Feb 24, 2020 at 10:19:20AM -0500, Marek Polacek wrote:
> On Mon, Feb 24, 2020 at 09:59:51AM -0500, Jason Merrill wrote:
> > On 2/24/20 9:58 AM, Jason Merrill wrote:
> > > On 2/21/20 2:14 PM, Marek Polacek wrote:
> > > > This was approved in the
On 2020-03-02 10:17 a.m., Jeff Law wrote:
On Mon, 2020-03-02 at 15:37 +0100, Christophe Lyon wrote:
On Fri, 28 Feb 2020 at 17:39, Vladimir Makarov wrote:
The following patch is dealing with arm failures after submitting
original patch for PR93564.
Changing heuristics in the original
More minor fallout from Vlad's IRA changes.
Previously this test used r3 to hold a value across a call (it's an ipa-ra
test). After Vlad's changes we're using r1 instead.
This patch makes the obvious change to pattern we can for which should bring
the test back to a passing status.
There's a n
In 2/28/20 10:31 AM, Jakub Jelinek wrote:
On Fri, Feb 28, 2020 at 04:23:03PM +, GT wrote:
Do we want to change the name and title of the document since Segher doesn't
believe it
is an ABI. My initial suggestion: "POWER Architecture Specification of Scalar
Function
to Vector Function Mappin
On Mon, 2020-03-02 at 08:40 -0700, Jeff Law wrote:
> On Mon, 2020-03-02 at 08:17 -0700, Jeff Law wrote:
> > On Mon, 2020-03-02 at 15:37 +0100, Christophe Lyon wrote:
> > > On Fri, 28 Feb 2020 at 17:39, Vladimir Makarov
> > > wrote:
> > > > The following patch is dealing with arm failures after s
On 2020-02-29 10:47 a.m., Jeff Law wrote:
On Sun, 2020-03-01 at 00:43 +0900, Oleg Endo wrote:
This could well be a target issue. I haven't tried to debug it. If
it's a
target issue, I'm fully comfortable punting it to the SH folks for
resolving.
The R0_REGS spill failure is a general proble
On 2020-03-02 4:34 a.m., Richard Biener wrote:
One could also simply pessimize R0 for RA via either an existing mechanism
or a new target hook ...
Yes, it could be a good strategy. I'd recommend to try
HONOR_REG_ALLOC_ORDER first with/without LRA.
If it does not work I am ready to accept
On Mon, 2020-03-02 at 10:45 -0500, Marek Polacek wrote:
> Ping: Jeff, see the question below. Thanks.
Sorry, totally missed the question. I'm guessing you want me to run it through
the Fedora build tester?
jeff
>
On Mon, Mar 02, 2020 at 09:25:35AM -0700, Jeff Law wrote:
> On Mon, 2020-03-02 at 10:45 -0500, Marek Polacek wrote:
> > Ping: Jeff, see the question below. Thanks.
> Sorry, totally missed the question. I'm guessing you want me to run it
> through
> the Fedora build tester?
Yeah -- we want to al
On Mon, 2020-03-02 at 11:29 -0500, Marek Polacek wrote:
> On Mon, Mar 02, 2020 at 09:25:35AM -0700, Jeff Law wrote:
> > On Mon, 2020-03-02 at 10:45 -0500, Marek Polacek wrote:
> > > Ping: Jeff, see the question below. Thanks.
> > Sorry, totally missed the question. I'm guessing you want me to run
On 02/03/2020 15:46, Jeff Law wrote:
More minor fallout from Vlad's IRA changes.
Previously this test used r3 to hold a value across a call (it's an ipa-ra
test). After Vlad's changes we're using r1 instead.
This patch makes the obvious change to pattern we can for which should bring
the test
On Mon, 2020-03-02 at 16:40 +, Richard Earnshaw (lists) wrote:
> On 02/03/2020 15:46, Jeff Law wrote:
> > More minor fallout from Vlad's IRA changes.
> >
> > Previously this test used r3 to hold a value across a call (it's an ipa-ra
> > test). After Vlad's changes we're using r1 instead.
> >
This patch adds support for vector reductions in all remaining vector modes.
Previously, only those modes directly supported by hardware instructions
were available. This patch implements multi-instruction sequences for
all the others.
There are no visible test changes. Either the tests stil
On 2/29/20 3:05 PM, Marek Polacek wrote:
One missing bit from r10-6656. The docs and target-supports.exp
already handle -std=gnu++20.
OK.
2020-02-29 Marek Polacek
PR c++/93958 - add missing -std=gnu++20.
* c.opt: Add -std=gnu++20.
---
gcc/c-family/c.opt | 6 +-
1
On 3/2/20 11:38 AM, Jeff Law wrote:
On Mon, 2020-03-02 at 11:29 -0500, Marek Polacek wrote:
On Mon, Mar 02, 2020 at 09:25:35AM -0700, Jeff Law wrote:
On Mon, 2020-03-02 at 10:45 -0500, Marek Polacek wrote:
Ping: Jeff, see the question below. Thanks.
Sorry, totally missed the question. I'm g
On Mon, Mar 02, 2020 at 11:59:12AM -0500, Jason Merrill wrote:
> On 3/2/20 11:38 AM, Jeff Law wrote:
> > On Mon, 2020-03-02 at 11:29 -0500, Marek Polacek wrote:
> > > On Mon, Mar 02, 2020 at 09:25:35AM -0700, Jeff Law wrote:
> > > > On Mon, 2020-03-02 at 10:45 -0500, Marek Polacek wrote:
> > > > >
Bill Schmidt writes:
> One tiny nit on the document: For the "b" value, let's just say "VSX"
> rather than
> "VSX as defined in PowerISA v2.07)." We will plan to only change
> values in case
> a different vector length is defined in future.
That change would have more implications: all lib
On 02/03/20 13:12 +, Jonathan Wakely wrote:
On 02/03/20 13:22 +0100, Christophe Lyon wrote:
On Fri, 28 Feb 2020 at 22:53, Jonathan Wakely wrote:
On 28/02/20 14:59 -0500, Patrick Palka wrote:
We were enabling the memcmp optimization in ranges::lexicographical_compare for
signed integral t
On 3/2/20 11:10 AM, Tulio Magno Quites Machado Filho wrote:
Bill Schmidt writes:
One tiny nit on the document: For the "b" value, let's just say "VSX"
rather than
"VSX as defined in PowerISA v2.07)." We will plan to only change values
in case
a different vector length is defined in futur
On Mon, Mar 2, 2020 at 1:40 AM Richard Biener
wrote:
>
> On Mon, Mar 2, 2020 at 9:07 AM bin.cheng wrote:
> >
> > Hi,
> > This is a simple fix for PR93674. It adds cand carefully for enumeral type
> > iv_use in
> > case of -fstrict-enums, it also avoids computing, replacing iv_use with the
> >
Hi Paul,
Thanks for the review. This is now committed as:
r10-6976-gf3c276aec26d9e406cc4bbf0e18b1105df63f0ee
I'll keep this in mind for future patches - this one seemed simple enough that
I'd be confident to commit it without review after waiting for a few days. I'm
hoping to find time to fini
Hi all,
On 17/01/2020 16:46, Dennis Zhang wrote:
Hi all,
This patch is part of a series adding support for Armv8.6-A features.
It depends on Arm BFMode patch
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01448.html
This patch implements intrinsics to convert between bfloat16 and float32
for
On Mon, 24 Feb 2020, Patrick Palka wrote:
> On Mon, 24 Feb 2020, Patrick Palka wrote:
>
> > This implements signed and unsigned integer-class types, whose width is one
> > bit
> > larger than the widest native signed and unsigned integral type
> > respectively.
> > In our case this is either __
*movstrict_1 insn pattern allows only general registers,
so we have to reject modes not suitable for general regs in
corresponding movstrict expander.
2020-03-02 Uroš Bizjak
PR target/93997
* config/i386/i386.md (movstrict): Allow only
registers with VALID_INT_MODE_P modes.
testsu
On Mon, Mar 02, 2020 at 08:20:01PM +, GT wrote:
> Which raises the question: what use-case motivated allowing the compiler
> to auto-vectorize user defined functions? From having manually created vector
The feature made it into the OpenMP standard (already OpenMP 4.0) and so got
implemented as
‐‐‐ Original Message ‐‐‐
On Thursday, February 27, 2020 9:52 AM, Jakub Jelinek wrote:
> On Thu, Feb 27, 2020 at 08:47:19AM -0600, Bill Schmidt wrote:
>
> > But is this actually a good idea? It seems to me this will generate lousy
> > code in the absence of hardware support. Won't we be be
PR analyzer/93959 reported that g++.dg/analyzer/malloc.C was failing
with no output on Solaris.
The issue is that there has "using std::free;", converting
all the "free" calls to std::free, which fails the name-matching via
is_named_call_p.
This patch implements an is_std_named_call_p variant of
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as 6e078aec716aa8214c13d7d20292aa232b5b.
gcc/ChangeLog:
* doc/invoke.texi (Static Analyzer Options): Add
-Wanalyzer-stale-setjmp-buffer to the list of options enabled
by -fanalyzer.
---
gcc
The note about duplicates attached to analyzer diagnostics feels like an
implementation detail; it's likely just noise from the perspective of an
end-user.
This patch disables it by default, introducing a flag to re-enable it.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed
‐‐‐ Original Message ‐‐‐
On Monday, March 2, 2020 3:31 PM, Jakub Jelinek wrote:
> On Mon, Mar 02, 2020 at 08:20:01PM +, GT wrote:
>
> > Which raises the question: what use-case motivated allowing the compiler
> > to auto-vectorize user defined functions? From having manually created
On Mon, Mar 02, 2020 at 09:40:59PM +, GT wrote:
> Searching openmp.org located document "OpenMP API Examples". The relevant
> example
> for inbranch/notinbranch shows very simple functions (SIMD.6.c). GCC testsuite
> functions are similarly simple.
> Wouldn't the same effect be achieved by let
PR87560 reports an ICE when a test case is compiled with -mpower9-vector
and -mno-altivec. This patch terminates compilation with an error when
this combination (and other unreasonable ones) are requested.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions. Reported err
Ping: https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00883.html
On 2/21/20 9:49 AM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00883.html
On 2/14/20 3:41 PM, Martin Sebor wrote:
Because attribute weakref introduces a kind of a definition, it can
only be applied to d
On 2/29/20 2:32 PM, Marek Polacek wrote:
The point of this patch is to fix the recurring problem of trees
generated by convert_like while processing a template that break when
substituting. For instance, when convert_like creates a CALL_EXPR
while in a template, substituting such a call breaks i
On Mon, 2 Mar 2020, Martin Liška wrote:
> +version of GCC@. If an option is supported by all languages, one needs
> +to use @var{common} qualifier instead.
"common" is literal text, so it should be @samp{common} not @var{common},
and the existing documentation here describes it as a "class" wit
The wide_int APIs expect operands to have the same precision and
abort when they don't. This is especially insidious in code where
the operands normally do have the same precision but where mixed
precision arguments can come up as a result of unusual combinations
optimization options. That is al
On Fri, Feb 28, 2020 at 06:45:25AM -0600, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Feb 28, 2020 at 12:32:06AM -0500, Michael Meissner wrote:
> > As part of my work in adding support for -mcpu=future, I noticed an insn
> > that
> > would never match.
>
> > It will never match, because the zero
在 2020/3/2 下午5:43, Iain Sandoe 写道:
Hi,
In the absence of specific comment on the handling of closures I'd
implemented something more than was intended (extending the lifetime
of lambda capture-by-copy vars to the duration of the coro).
After discussion at WG21 in February and by email, the corr
在 2020/3/2 下午10:49, Nathan Sidwell 写道:
On 2/12/20 2:23 AM, JunMa wrote:
Hi
In captures_temporary, the current implementation fails to handle
component_ref. This causes ice with case co_await A while
operator co_await is defined in base class of A. Also it is necessary
to capture the object of ba
Hi
Isn't it something to fix before gcc 10 release ?
François
On 12/27/19 11:57 AM, François Dumont wrote:
Here is the patch to extend DR 526 to forward_list and list remove_if
and unique.
As the adopted pattern is simpler I also applied it to the remove
methods.
PR libstdc++/9162
On Wed, Feb 26, 2020 at 11:29:18AM +0100, Richard Biener wrote:
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
This got fixed with Martin's C FE change, so I've just committed
the testcases as obvious to trunk.
2020-03-03 Jakub Jelinek
PR tree-optimization/93
On Mon, Mar 02, 2020 at 03:54:36PM +0100, Jakub Jelinek wrote:
> So, like this if it passes bootstrap/regtest?
Bootstrapped/regtested successfully on x86_64-linux and i686-linux.
> 2020-03-02 Jakub Jelinek
>
> PR tree-optimization/93582
> * tree-ssa-sccvn.h (vn_reference_lookup):
After add --param max-inline-insns-size=1 all target will remove the
redundant store at dse1, except some targets like AArch64 and MIPS will
expand the struct initialization into loop due to CLEAR_RATIO.
Tested on cross compiler of riscv32, riscv64, x86, x86_64, mips, mips64,
aarch64, nds32 and ar
On 2/25/20 10:20 AM, Jakub Jelinek wrote:
> Hi!
>
> In Fedora we configure GCC with --with-arch=zEC12 --with-tune=z13 right now
> and furthermore redhat-rpm-config adds to rpm packages -march=zEC12 -mtune=z13
> options (among others). While looking at the git compilation, I've been
> surprised th
Hi!
The following testcase ICEs in cross to riscv64-linux. The problem is
that we have a DImode integral constant (that doesn't fit into SImode),
which is pushed into a constant pool and later access just the first half of
it using a MEM. When plus_constant is called on such a MEM, if the consta
79 matches
Mail list logo
