On Tue, 11 Sep 2018, Qing Zhao wrote:
> no immediate use case for -finline-visibility=extern right now. But I guess
> that GCC developers might use this option to control inlining scope for
> debugging or development purpose in the future.
In that case I'd recommend to simplify the patch by implem
On Tue, Sep 11, 2018 at 10:20:26PM -0400, Julian Brown wrote:
> 2018-09-09 Cesar Philippidis
> Julian Brown
>
> PR middle-end/86336
>
> gcc/cp/
> * semantics.c (finish_omp_clauses): Treat C++ references the same in
> OpenACC as OpenMP.
>
>
Hi!
The following testcase is miscompiled, because it optimizes
(x & -128) ? -128 : 0 to (x & -128) when it shouldn't. The problem is if
the type of the COND_EXPR has smaller precision than the BIT_AND_EXPR in the
test, we verify that integer_pow2p (arg1), which is true in this case (-128
in sign
On Wed, 12 Sep 2018, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled, because it optimizes
> (x & -128) ? -128 : 0 to (x & -128) when it shouldn't. The problem is if
> the type of the COND_EXPR has smaller precision than the BIT_AND_EXPR in the
> test, we verify that integer
On 11/09/18 23:45, Jeff Law wrote:
Does this need a corresponding change to the RTL front-end so that it
can read the new form?
There's an RTL front-end? When did that happen... clearly I've not been
paying attention.
If it's expected that dumps can be fed back in unmodified then yes, it
ne
On Tue, Sep 11, 2018 at 04:06:40PM +0200, Andreas Krebbel wrote:
> > It is a fix, but not optimal.
> > We have essentially:
> > MEM[(int *)p_28] = 0;
> > MEM[(char *)p_28 + 3B] = 1;
> > MEM[(char *)p_28 + 1B] = 2;
> > MEM[(char *)p_28 + 2B] = MEM[(char *)p_28 + 6B];
> > It is us
On Wed, 12 Sep 2018, Jakub Jelinek wrote:
> On Tue, Sep 11, 2018 at 04:06:40PM +0200, Andreas Krebbel wrote:
> > > It is a fix, but not optimal.
> > > We have essentially:
> > > MEM[(int *)p_28] = 0;
> > > MEM[(char *)p_28 + 3B] = 1;
> > > MEM[(char *)p_28 + 1B] = 2;
> > > MEM[
On Wed, Sep 12, 2018 at 11:04:52AM +0200, Richard Biener wrote:
> OK. We need to fix the bug on the branch, so either we go with this
> variant or the other (which was pessimizing some cases?)
Yeah. Andreas' patch is simpler and for that reason might be better to
backport, on the other side try
On 9/11/18 5:08 PM, Alexander Monakov wrote:
> On Tue, 11 Sep 2018, Martin Liška wrote:
>> I've discussed the topic with Alexander on the Cauldron and we hoped
>> that the issue with unique __gcov_root can be handled with DECL_COMMON in
>> each DSO.
>> Apparently this approach does not work as all
On 9/6/18 12:24 PM, Gerald Pfeifer wrote:
Hi Nathan,
On Wed, 5 Sep 2018, Nathan Sidwell wrote:
this documents the fix for pr87137. Discovered as a GCC-8 regression,
turned out to be an ABI bug. Decided to fix the entire bug in one go.
Are these changes.html changes ok?
thanks for doing this!
PING^1
On 8/29/18 10:27 AM, Martin Liška wrote:
> Hi.
>
> That's just simple patch that wraps an option name
> in an error message into apostrophes.
>
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> Ready to be installed?
> Martin
>
> gcc/cp/ChangeLog:
>
> 201
On 9/2/18 10:26 AM, Gerald Pfeifer wrote:
Jason and Nathan,
while I completed one C+ non-bug entry with the patch below, I am
not sure the items as such is really still relevant?
In fact, if you could have a look at https://gcc.gnu.org/bugs/#nonbugs_cxx
and advise which entries perhaps should b
On 9/12/18 6:17 AM, Martin Liška wrote:
PING^1
gcc/cp/ChangeLog:
2018-08-28 Martin Liska
* constexpr.c (cxx_eval_call_expression): Add quotes
to -fconstexpr-depth=.
ok, thanks
--
Nathan Sidwell
On Wed, 12 Sep 2018, Jakub Jelinek wrote:
> On Wed, Sep 12, 2018 at 11:04:52AM +0200, Richard Biener wrote:
> > OK. We need to fix the bug on the branch, so either we go with this
> > variant or the other (which was pessimizing some cases?)
>
> Yeah. Andreas' patch is simpler and for that reas
On 11/09/18 23:42, Jeff Law wrote:
This feels like you're papering over a problem in regrename and/or the
GCN port.. regrename should be checking the predicate and constraints
when it makes changes. And I think that you're still allowed to refer
to a fixed register in alternatives.
I think yo
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2018-09-12 Richard Biener
PR tree-optimization/87266
* tree-ssa-sccvn.c (do_rpo_vn): Always iterate to not yet
visited blocks.
* gcc.dg/torture/pr87266-1.c: New testcase.
* gcc.dg
Hi.
The patch improves locations of the warning in following way:
sample.c: In function ‘main’:
sample.c:16:1: error: source locations for function ‘main’ have changed, the
profile data may be out of date [-Werror=coverage-mismatch]
16 | }
| ^
sample.c:16:1: error: source locations for functi
Hi.
This is follow-up of:
https://gcc.gnu.org/ml/gcc/2018-08/msg00162.html
I'm suggesting to introduce using colors in order to indicate hotness
of lines. Legend is printed at the very beginning of the output file.
Example: https://pasteboard.co/HDxK4Nm.png
Patch survives gcov.exp test-suite. Wi
Hi.
This is follow-up of:
https://gcc.gnu.org/ml/gcc/2018-08/msg7.html
I've chosen to implement that with new DECL_CXX_LAMBDA_FUNCTION that
uses an empty bit in tree_function_decl.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Ready for trunk?
gcc/ChangeLog:
2
Hi.
Honza asked me to do the follow-up. It moves definition of alignments
related to a CPU into *_cost scructures. Advantage of it is that there's
no redundant definition for CPUs that have equal cost.
I verified that it produces same output for all valid -march options:
gcc --help=common -Q -O2
Hi all,
This PR is an SSA validation error where the definition ends up not dominating
a use.
This appeared after my recip_sqrt optimisation. Though the optimisation doesn't
get triggered
as there is no sqrt involved it prevents execute_cse_reciprocals_1 from running
as it's currently
an eithe
On Wed, 5 Sep 2018, Jakub Jelinek wrote:
> On Wed, Sep 05, 2018 at 02:42:36PM +0200, Richard Biener wrote:
> > IIRC you said we're already doing x % power-of-two == 0 optimized but the
> > new
> > code isn't in that place?
>
> For unsigned %, there is no need for anything special, we just
> expa
On 11/09/18 17:53, James Greenhalgh wrote:
On Mon, Aug 06, 2018 at 11:14:17AM -0500, Vlad Lazar wrote:
Hi,
The patch adds support for the TARGET_COMPUTE_FRAME_LAYOUT hook on AArch64
and removes unneeded frame layout recalculation.
The removed aarch64_layout_frame calls are unnecessary because
Hi!
Sorry this is all taking so long.
On Mon, Aug 20, 2018 at 04:44:30PM -0500, Will Schmidt wrote:
> 2018-08-20 Will Schmidt
>
> * config/rs6000/rs6000.c (rs6000_gimple_fold_builtin): Add support for
> early gimple folding of vec_splat().
"early" should indent together wit
On 05/09/18 15:22, Joseph Myers wrote:
In cases like this with alternative diagnostic messages using ?:, you need
to mark up each message with G_() so they both get extracted for
translation by exgettext.
[...]
This concatenation with a macro won't work with exgettext extracting
messages for
On 9/12/18 8:23 AM, Segher Boessenkool wrote:
> Hi!
>
> Sorry this is all taking so long.
>
> On Mon, Aug 20, 2018 at 04:44:30PM -0500, Will Schmidt wrote:
>> 2018-08-20 Will Schmidt
>>
>> * config/rs6000/rs6000.c (rs6000_gimple_fold_builtin): Add support for
>>early gimple fol
On Wed, Sep 12, 2018 at 08:07:41AM -0500, Vlad Lazar wrote:
> On 11/09/18 17:53, James Greenhalgh wrote:
> > On Mon, Aug 06, 2018 at 11:14:17AM -0500, Vlad Lazar wrote:
> >> Hi,
> >>
> >> The patch adds support for the TARGET_COMPUTE_FRAME_LAYOUT hook on AArch64
> >> and removes unneeded frame layo
On 05/09/18 19:11, Janne Blomqvist wrote:
Ok, thanks.
Committed, thanks.
Apologies again for missing the Fortran list.
Andrew
On 05/09/18 19:09, Janne Blomqvist wrote:
Ok, thanks.
Committed, thanks.
Andrew
The following fixes PR87280 (and PR87169 in a different way).
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2018-09-12 Richard Biener
PR tree-optimization/87280
* tree-ssa-sccvn.c (process_bb): Handle the case of executable
edge but unreacha
> On Sep 12, 2018, at 2:46 AM, Alexander Monakov wrote:
>
> On Tue, 11 Sep 2018, Qing Zhao wrote:
>> no immediate use case for -finline-visibility=extern right now. But I guess
>> that GCC developers might use this option to control inlining scope for
>> debugging or development purpose in the
On Mon, 10 Sep 2018, Jan Hubicka wrote:
> Hi,
> TYPE_VALUES are currently only used to output warnings on ODR mismatched
> enums.
> I think those warnings are useful and thus we want to stream them to WPA, but
> there is no need to stream them further to ltrans units.
>
> Bootstrapped/regtested
On Wed, 12 Sep 2018, Qing Zhao wrote:
>
> > On Sep 12, 2018, at 2:46 AM, Alexander Monakov wrote:
> >
> > On Tue, 11 Sep 2018, Qing Zhao wrote:
> >> no immediate use case for -finline-visibility=extern right now. But I guess
> >> that GCC developers might use this option to control inlining sco
In r263225 (d2e378182a12d68fe5caeffae681252662a2fe7b), I fixed
condition_variable::wait_for to use std::chrono::steady_clock for the wait.
Unfortunately, I failed to spot that the same fix is required for the
wait_for variant that takes a predicate too.
Reported-by: Tom Wood
---
libstdc++-v3/inc
On Tue, Sep 11, 2018 at 4:36 PM Andrew Stubbs wrote:
>
> On 05/09/18 13:43, Richard Biener wrote:
> > No. You might want to look into the x86 backend if there's maybe more
> > tweaks
> > needed when using non-vector mask modes.
>
> I tracked it down to the vector alignment configuration.
>
> App
On Wed, Sep 12, 2018 at 12:56 AM Jeff Law wrote:
>
> On 9/5/18 5:48 AM, a...@codesourcery.com wrote:
> >
> > The HSA GPU drivers can't cope with binaries that have the same symbol
> > defined
> > multiple times, even though the names are not exported. This happens
> > whenever
> > there are fil
On Wed, Sep 12, 2018 at 11:27 AM Martin Liška wrote:
>
> On 9/11/18 5:08 PM, Alexander Monakov wrote:
> > On Tue, 11 Sep 2018, Martin Liška wrote:
> >> I've discussed the topic with Alexander on the Cauldron and we hoped
> >> that the issue with unique __gcov_root can be handled with DECL_COMMON i
On Wed, Sep 12, 2018 at 2:56 PM Kyrill Tkachov
wrote:
>
> Hi all,
>
> This PR is an SSA validation error where the definition ends up not
> dominating a use.
> This appeared after my recip_sqrt optimisation. Though the optimisation
> doesn't get triggered
> as there is no sqrt involved it preven
On Wed, 12 Sep 2018, Martin Liška wrote:
> I see, I'm attaching patch that does that. I can confirm your test-case works
> fine w/o -Wl,--dynamic-list-data.
>
> I'm wondering if it will work as well with dlopen/dlsym machinery? Or now
> the linker flag will be needed?
No, for this issue dlopen do
On 9/12/18 8:42 AM, Richard Biener wrote:
> On Wed, Sep 12, 2018 at 12:56 AM Jeff Law wrote:
>>
>> On 9/5/18 5:48 AM, a...@codesourcery.com wrote:
>>>
>>> The HSA GPU drivers can't cope with binaries that have the same symbol
>>> defined
>>> multiple times, even though the names are not exported.
Hello!
This pattern is not needed because all x87 float_extend RTXes
degenerate to a plain
move (or a no-op move).
2018-09-11 Uros Bizjak
* config/i386/i386.md (sqrt_extendxf3_i387): Remove.
(sqrt2): Extend operand 1 to XFmode and generate sqrtxf3 insn.
Patch was bootstrapped and reg
On Wed, Sep 12, 2018 at 5:02 PM Alexander Monakov wrote:
>
> On Wed, 12 Sep 2018, Martin Liška wrote:
> > I see, I'm attaching patch that does that. I can confirm your test-case
> > works
> > fine w/o -Wl,--dynamic-list-data.
> >
> > I'm wondering if it will work as well with dlopen/dlsym machine
On 9/12/18 2:46 AM, Andrew Stubbs wrote:
> On 11/09/18 23:45, Jeff Law wrote:
>> Does this need a corresponding change to the RTL front-end so that it
>> can read the new form?
>
> There's an RTL front-end? When did that happen... clearly I've not been
> paying attention.
Within the last couple ye
On Wed, Sep 12, 2018 at 5:07 PM Jeff Law wrote:
>
> On 9/12/18 8:42 AM, Richard Biener wrote:
> > On Wed, Sep 12, 2018 at 12:56 AM Jeff Law wrote:
> >>
> >> On 9/5/18 5:48 AM, a...@codesourcery.com wrote:
> >>>
> >>> The HSA GPU drivers can't cope with binaries that have the same symbol
> >>> de
On 9/11/18 9:12 AM, Qing Zhao wrote:
> Hi,
>
> This is a simple patch to add a new first-class option
>
> -finline-visibility={all|extern|static}
>
> to finer control inlining based on function’s visibility.
>
> '-finline-visibility=[all|extern|static]'
> By default, GCC inlines functio
On 09/05/2018 04:48 AM, a...@codesourcery.com wrote:
> @@ -1198,6 +1198,10 @@ see the files COPYING3 and COPYING.RUNTIME
> respectively. If not, see
> #define NO_FUNCTION_CSE false
> #endif
>
> +#ifndef SPECIAL_REGNO_P
> +#define SPECIAL_REGNO_P(REGNO) false
> +#endif
> +
> #ifndef HARD_REGN
On Wed, 12 Sep 2018, Andrew Stubbs wrote:
> > I'd expect this to fail on non-Unix configurations that don't have -ldl,
> > and thus to need appropriate conditionals / configure tests to avoid that
> > build failure.
>
> The attached diff from the previous patch should address these issues, I hope
PING: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01818.html
There have been follow up comments in this thread suggesting
alternate designs for the nonstr attribute but (AFAICT) no
objections to the bug fix. I don't expect to have the time
to redesign and reimplement the attribute for GCC 9 in
On Wed, 12 Sep 2018, Richard Biener wrote:
> With LTO "static" is too blurry - would -finline-only-hidden be OK
> with you?
This doesn't sound right - in non-pic, everything is hidden, effectively.
And the intended use is with Linux kernel, which does not use -fpic.
I agree with LTO this option m
> On Sep 12, 2018, at 9:33 AM, Richard Biener wrote:
>
> On Wed, 12 Sep 2018, Qing Zhao wrote:
>
>>
>>> On Sep 12, 2018, at 2:46 AM, Alexander Monakov wrote:
>>>
>>> On Tue, 11 Sep 2018, Qing Zhao wrote:
no immediate use case for -finline-visibility=extern right now. But I guess
t
On 12/09/18 16:31, Richard Henderson wrote:
How is this different from HARD_REGNO_RENAME_OK via the TO argument?
Seems like the hook you're looking for already exists...
I don't know how we got here (I didn't do the original work), but the
SPECIAL_REGNO_P was indeed used in HARD_REGNO_RENAME_O
> On Sep 12, 2018, at 10:22 AM, Jeff Law wrote:
>
> On 9/11/18 9:12 AM, Qing Zhao wrote:
>> Hi,
>>
>> This is a simple patch to add a new first-class option
>>
>> -finline-visibility={all|extern|static}
>>
>> to finer control inlining based on function’s visibility.
>>
>> '-finline-visib
On Wed, Aug 22, 2018 at 01:19:44PM +, Segher Boessenkool wrote:
> When combine splits a resulting parallel into its two SETs, it has to
> place one at i2, and the other stays at i3. This does not work if the
> destination of the SET that will be placed at i2 is modified between
> i2 and i3. T
On 12/09/18 15:51, Richard Biener wrote:
On Wed, Sep 12, 2018 at 2:56 PM Kyrill Tkachov
wrote:
Hi all,
This PR is an SSA validation error where the definition ends up not dominating
a use.
This appeared after my recip_sqrt optimisation. Though the optimisation doesn't
get triggered
as there
On 12/09/18 16:16, Richard Biener wrote:
I think the symptom GCN sees needs to be better understood - like wheter
it is generally OK to mangle things arbitrarily.
The name mangling is a horrible workaround for a bug in the HSA runtime
code (which we do not own, cannot fix, and would want to su
On 12/09/18 16:32, Joseph Myers wrote:
+ case "$host" in
+ x86_64*-*-linux-gnu )
+ if test "$ac_res" != no; then
+ extra_programs="${extra_programs} gcn-run\$(exeext)"
+ fi
ac_res is a generic autoconf variable used by a lot of tests
On Wed, 12 Sep 2018, Andrew Stubbs wrote:
> > What if the host is x86_64 with the x32 ABI? If the requirement is for
> > various types to be the same between the host and GCN, I'd expect that x32
> > ABI on the host means it is unsuitable for using gcn-run. Or are the
> > requirements for compat
Aldy Hernandez writes:
> diff --git a/gcc/wide-int-range.h b/gcc/wide-int-range.h
> index 589fdea4df6..e9ee418e5b2 100644
> --- a/gcc/wide-int-range.h
> +++ b/gcc/wide-int-range.h
> @@ -131,7 +131,7 @@ extern bool wide_int_range_div (wide_int &wmin, wide_int
> &wmax,
> /* Return TRUE if shifting
Tamar Christina writes:
> Hi Richard,
>
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Tuesday, September 11, 2018 15:49
>> To: Tamar Christina
>> Cc: Jeff Law ; gcc-patches@gcc.gnu.org; nd
>> ; James Greenhalgh ;
>> Richard Earnshaw ; Marcus Shawcroft
>>
>> Subject: Re: [PAT
On Wed, 12 Sep 2018 17:31:58 +0100
Andrew Stubbs wrote:
> On 12/09/18 16:16, Richard Biener wrote:
> > I think the symptom GCN sees needs to be better understood - like
> > wheter it is generally OK to mangle things arbitrarily.
>
> The name mangling is a horrible workaround for a bug in the H
On 09/12/2018 12:57 PM, Richard Sandiford wrote:
Aldy Hernandez writes:
diff --git a/gcc/wide-int-range.h b/gcc/wide-int-range.h
index 589fdea4df6..e9ee418e5b2 100644
--- a/gcc/wide-int-range.h
+++ b/gcc/wide-int-range.h
@@ -131,7 +131,7 @@ extern bool wide_int_range_div (wide_int &wmin, wid
On 08/31/2018 04:07 AM, Richard Biener wrote:
On Thu, Aug 30, 2018 at 7:39 PM Martin Sebor wrote:
On 08/30/2018 11:22 AM, Richard Biener wrote:
On August 30, 2018 6:54:21 PM GMT+02:00, Martin Sebor wrote:
On 08/30/2018 02:35 AM, Richard Biener wrote:
On Thu, Aug 30, 2018 at 2:12 AM Martin
On Fri, Aug 24, 2018 at 10:44:22AM +, Segher Boessenkool wrote:
> There currently is nothing that prevents replacing the TOC_REGISTER in
> a TOCREL unspec with something else, like a pseudo, or a memory ref.
> This of course does not work. Fix that.
I backported this to 7 and 8 now.
Segher
On Wed, Sep 12, 2018 at 03:02:41PM +0200, Richard Biener wrote:
> So I guess your patch is OK (with the small followup you posted).
Thanks, here is what I've committed after another bootstrap/regtest:
2018-09-12 Jakub Jelinek
PR middle-end/82853
* expr.h (maybe_optimize_mod_cm
Hi!
While working on the next PR, I've noticed we only fold this on generic, not
gimple.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2018-09-12 Jakub Jelinek
PR tree-optimization/87287
* fold-const.c (fold_binary_loc) : Move signed modul
Hello!
Although reg-stack.c is mostly an x86 affair, attached patch decouples
it from x86 a bit. The patch changes the default mode of pop and swap
insns to the reg_raw_mode of FIRST_STACK_REG (= XFmode on x86). Also,
the patch explicitly constructs swap insn, without calling x86
specific named in
Hi!
This patch optimizes signed x % C1 == C2 expansion if it is beneficial.
x % C1 == 0 should be handled unconditionally in match.pd (previous patch),
this only handles the cases where C1 is positive power of two and abs (C2)
is smaller than it and non-zero.
Bootstrapped/regtested on x86_64-linu
On Mon, Sep 03, 2018 at 02:14:55PM +, Joseph Myers wrote:
> On Sat, 1 Sep 2018, Jakub Jelinek wrote:
>
> > Couldn't we do something smarter than this?
> > Noticed while debugging why our bisect seed machine spends over 2 minutes in
> > sed when handling config.status, and the reason apparently
When producing error and warning messages, libgfortran writes a
message by using many system calls. By using vectored writes (the
POSIX writev function) when available and feasible to use without
major surgery, we reduce the chance that output gets intermingled with
other output to stderr.
In pra
On Wed, Sep 05, 2018 at 12:12:39AM +0200, Gerald Pfeifer wrote:
> On Fri, 24 Aug 2018, Richard Biener wrote:
> > Comments are still welcome - I've re-bootstrapped and tested the series
> > on x86_64-unknown-linux-gnu for all languages and will talk about
> > this work@the Cauldron in more detail.
>
On Wed, 12 Sep 2018, Jakub Jelinek wrote:
> Would the following minimal patch be acceptable, which just doesn't append
> the " : (reconfigured) " + arguments if the configure arguments already end
> with exactly that?
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, plus tested with
> .
On Wed, Sep 12, 2018 at 6:25 AM, Nathan Sidwell wrote:
> On 9/2/18 10:26 AM, Gerald Pfeifer wrote:
>>
>> Jason and Nathan,
>>
>> while I completed one C+ non-bug entry with the patch below, I am
>> not sure the items as such is really still relevant?
>>
>> In fact, if you could have a look at http
On 2018-09-05 11:38, Olivier Hainque wrote:
> Hi Rasmus,
>
> I think we should either do a fixinclude that would "work" for
> C and ASM (like #include vxCpu for ASM, vxTypesOld otherwise), or
> simply remove this hack (just using the fixinclude parlance here).
>
> My inclination would be for the
This patch to the Go frontend omits a couple of write barriers.
We omit a write barrier for
s = s[0:]
for a slice s. In this case the pointer is not changing and no write
barrier is required.
We omit a write barrier for
s = append(s, v)
in the case where len(s) < cap(s) (and similarly wh
On Mon, Sep 10, 2018 at 04:40:58PM +0100, Jason Merrill wrote:
On Mon, Sep 10, 2018 at 3:42 PM, John Darrington
wrote:
> On Mon, Sep 10, 2018 at 03:36:26PM +0100, Jason Merrill wrote:
> On Mon, Aug 27, 2018 at 8:20 PM, John Darrington
> wrote:
> >
All changes limited to hashtable_c++0x.cc file.
_Prime_rehash_policy::_M_next_bkt now really does what its comment was
declaring that is to say:
// Return a prime no smaller than n.
_Prime_rehash_policy::_M_need_rehash rehash only when _M_next_size is
exceeded, not only when it is reach.
On 9/12/18 12:31 PM, Jakub Jelinek wrote:
> Hi!
>
> While working on the next PR, I've noticed we only fold this on generic, not
> gimple.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?
>
> 2018-09-12 Jakub Jelinek
>
> PR tree-optimization/8728
On 9/12/18 12:34 PM, Uros Bizjak wrote:
> Hello!
>
> Although reg-stack.c is mostly an x86 affair, attached patch decouples
> it from x86 a bit. The patch changes the default mode of pop and swap
> insns to the reg_raw_mode of FIRST_STACK_REG (= XFmode on x86). Also,
> the patch explicitly constru
78 matches
Mail list logo