On Wednesday, 10/17/2018 22:26:58 EEST Richard Sandiford wrote:
> > +; Note: "JUMP_INSNs and CALL_INSNs are not allowed to have any output
> > +; reloads;". Hence this insn must be prepared for a counter that is
> > +; not a register.
> > +(define_insn "doloop_end_internal"
> > + [(set (pc)
> >
On 10/18/2018 03:12 PM, David Malcolm wrote:
Here's an updated version of the patch, addressing your above comments,
and those from Martin and Richard (I hope).
Thanks, this one looks more readable. Some more specific comments
included inline below.
I have a couple of texinfo questions:
On 10/18/18 2:06 PM, Stafford Horne wrote:
> On Thu, Oct 18, 2018 at 03:22:56PM +0200, Sebastian Huber wrote:
>> Hello,
>>
>> is there a chance to get the or1k support integrated before the GCC 9 stage
>> 3?
>
> Hello,
>
> I would definitly like that and that is my goal. It seems the limiting
This patch to the Go frontend adds a COMPARE_ALIASES flag for type
compare and hash functions. Normally aliases compare as identical to
the underlying type. The new COMPARE_ALIASES flag lets them compare
(and hash) differently. This will be used by later work.
Bootstrapped and ran Go testsuite
The "persistent" and "noinit" data attributes for MSP430 assign the variable
they are applied to to the .persistent and .noinit sections, respectively.
The following patch extends the handler for these attributes to check for
misuse.
The testsuite updates add tests for these attributes, and
Previously when the Go frontend generated export data that referred to
a type that was not defined in a directly imported package, it would
write the package name as additional information in the type's export
data. That approach required all type information to be read in
order. This patch
Well,,that's unfortunate. Please forgive the alternative patch submission.
https://github.com/asutton/gcc/blob/master/concepts.patch
> Attached is a rework of the Concepts TS implementation to match the
> Working Draft. It's a big patch -- I'd loved to make it smaller, but
> it didn't work out
On Sat, Sep 22, 2018 at 12:08 PM, marxin wrote:
>
> gcc/go/ChangeLog:
>
> 2018-09-24 Martin Liska
>
> * gofrontend/escape.cc (Gogo::analyze_escape): Remove
> usage of a parameter.
> (Gogo::assign_connectivity): Likewise.
> (class Escape_analysis_tag): Likewise.
This patch to the Go frontend changes the Type::are_identical function
to use a single flags parameter instead of the Cmp_tags and
errors_are_identical bool parameters. The existing behavior is
unchanged. This is a simplification step for future work that will
add a new flag. Bootstrapped and
> I've added the missing ChangeLog entry as r265272 (using yesterday's
> date, since that's when I committed the change).
Thanks!
--
Eric Botcazou
Hi,
> Well, I compared the results before and after the simplifications with a
> 512-bit
> precise mpfr value. Unfortunately, I found that sometimes the error is very
> noticeable :-( .
Did you enable FMA? I'd expect 1 - x*x to be accurate with FMA, so the relative
error
should be much better.
On Tue, 16 Oct 2018 at 19:01, Richard Sandiford
wrote:
>
> Iain Buclaw writes:
> > diff --git a/libphobos/d_rules.am b/libphobos/d_rules.am
> > new file mode 100644
> > index 000..b16cf5052d2
> > --- /dev/null
> > +++ b/libphobos/d_rules.am
> > @@ -0,0 +1,60 @@
> > +# This file contains
Many AVX512 vector operations can broadcast from a scalar memory source.
This patch enables memory broadcast for FP add operations.
gcc/
PR target/72782
* config/i386/sse.md
(*3_bcst_1): New.
(*add3_bcst_2): Likewise.
gcc/testsuite/
PR target/72782
On 18/10/18 22:39 +0200, François Dumont wrote:
As reported in another mail a symbol is missing.
This patch update test framework so that the problem is obvious and fix it.
* testsuite/util/testsuite_containers.h
(forward_members_unordered<>::forward_members_unordered
(const
On 10/18, Jeff Law wrote:
> On 10/17/18 4:21 PM, Giuliano Augusto Faulin Belinassi wrote:
> > Oh, please note that the error that I'm talking about is the
> > comparison with the result obtained before and after the
> > simplification. It is possible that the result obtained after the
> >
On 10/18/18, Richard Sandiford wrote:
> "H.J. Lu" writes:
>> On 10/18/18, Richard Sandiford wrote:
>>> "H.J. Lu" writes:
On 10/18/18, Richard Sandiford wrote:
> "H.J. Lu" writes:
>> On 10/18/18, Richard Sandiford wrote:
>>> "H.J. Lu" writes:
On 10/17/18, Marc
Richard Biener writes:
> On Thu, 18 Oct 2018, Richard Sandiford wrote:
>
>> Richard Biener writes:
>> > PR63155 made me pick up this old work from Steven, it turns our
>> > linked-list implementation to a two-mode one with one being a
>> > splay tree featuring O(log N) complexity for
As reported in another mail a symbol is missing.
This patch update test framework so that the problem is obvious and fix it.
* testsuite/util/testsuite_containers.h
(forward_members_unordered<>::forward_members_unordered
(const value_type&)): Add local_iterator pre and post
On 18/10/18 22:12 +0200, François Dumont wrote:
Current build of libstdc++ with
--enable-symvers=gnu-versioned-namespace fails (at least under Linux)
because of:
In file included from
/home/fdt/dev/gcc/build_versioned_ns/x86_64-pc-linux-gnu/libstdc++-v3/include/memory_resource:39,
Am Donnerstag, den 18.10.2018, 20:53 +0100 schrieb Richard Sandiford:
> "Uecker, Martin" writes:
> > Hi Richard,
> >
> > responding here to a couple of points.
> >
> > For bignums and for a type-descibing type 'type'
> > there were proposals (including from me) to implement
> > these as
On Tue, 2018-10-16 at 21:39 -0600, Sandra Loosemore wrote:
> On 10/12/2018 09:43 AM, David Malcolm wrote:
> > Here's a proposed "User Experience Guidelines" section for our
> > internals manual
> >
> > It's a mixture of proposed policy, together with notes on how to
> > implement the
On Thu, 18 Oct 2018, Uecker, Martin wrote:
> Most of the restrictions for these types would be the same
> as proposed for your sizeless types.
>
> Because all these types fall into the same overall class
> of types which do not have a size known at compile
> time, I would suggest to add this
Current build of libstdc++ with --enable-symvers=gnu-versioned-namespace
fails (at least under Linux) because of:
In file included from
/home/fdt/dev/gcc/build_versioned_ns/x86_64-pc-linux-gnu/libstdc++-v3/include/memory_resource:39,
from
On Thu, 18 Oct 2018, Richard Sandiford wrote:
> - Type introspection for things like parsing format strings
>
> It sounded like the type descriptors would be fixed-sized types,
> a bit like a C version of std::type_info.
It wasn't clear if people might also want to e.g. extract a list of
On Thu, Oct 18, 2018 at 03:22:56PM +0200, Sebastian Huber wrote:
> Hello,
>
> is there a chance to get the or1k support integrated before the GCC 9 stage
> 3?
Hello,
I would definitly like that and that is my goal. It seems the limiting factor
is getting technical review and signoff on this
* testsuite/20_util/duration/cons/2.cc: Add -ffloat-store to fix
failure when compiled without optimisation.
* testsuite/ext/profile/mutex_extensions_neg.cc: Prune additional
errors caused by C++17 std::pmr alias templates.
Tested x86_64-linux, committed to trunk.
If a locale's THOUSANDS_SEP or MON_THOUSANDS_SEP string is not a
single character we either need to narrow it to a single char or
ignore it (and therefore disable digit grouping for that facet).
PR libstdc++/87642
* config/locale/gnu/monetary_members.cc
"Uecker, Martin" writes:
> Hi Richard,
>
> responding here to a couple of points.
>
> For bignums and for a type-descibing type 'type'
> there were proposals (including from me) to implement
> these as variable-sized types which have some restrictions,
> i.e. they cannot be stored in a
This is the first in a series of patches to start changing gccgo's
export data to support type indexing and, eventually cross-package
inlining of simple functions. (This is an inlining approach different
than LTO that relies on recording the function body in the export
data). This patch doesn't
Hi Richard,
responding here to a couple of points.
For bignums and for a type-descibing type 'type'
there were proposals (including from me) to implement
these as variable-sized types which have some restrictions,
i.e. they cannot be stored in a struct/union.
Most of the restrictions for these
"H.J. Lu" writes:
> On 10/18/18, Richard Sandiford wrote:
>> "H.J. Lu" writes:
>>> On 10/18/18, Richard Sandiford wrote:
"H.J. Lu" writes:
> On 10/18/18, Richard Sandiford wrote:
>> "H.J. Lu" writes:
>>> On 10/17/18, Marc Glisse wrote:
On Wed, 17 Oct 2018, H.J. Lu
Hi!
I've realized there is UB in this testcase, because taskloop simd
non-collapsed iterator is linear on simd, which implies lastprivate on
taskloop, but with nogroup the last iteration's value might be stored
when bar is out of scope already.
Fixed by declaring it in the construct, then
> On Oct 18, 2018, at 1:18 PM, Jeff Law wrote:
>
> On 10/17/18 5:48 PM, Paul Koning wrote:
>> This is a revision of a patch I proposed a while back, to add udivhi3 and
>> umodhi3 functions to libgcc since some platforms (like pdp11) need it. The
>> code is adopted from that of udivsi3.
>>
On 10/15/18 8:31 AM, Richard Sandiford wrote:
> Some tests for COMPLETE_TYPE_P are just protecting against a null
> TYPE_SIZE or TYPE_SIZE_UNIT. Rather than replace them with a new
> macro, it seemed clearer to write out the underlying test.
>
> 2018-10-15 Richard Sandiford
>
> gcc/
>
On 10/17/18 5:48 PM, Paul Koning wrote:
> This is a revision of a patch I proposed a while back, to add udivhi3 and
> umodhi3 functions to libgcc since some platforms (like pdp11) need it. The
> code is adopted from that of udivsi3.
>
> In earlier discussion it was pointed out that internal
On 10/18/18 9:43 AM, Jonathan Wakely wrote:
> * doc/invoke.texi (-dumpversion): Improve grammar.
> (-dumpfullversion): Make more consistent with -dumpversion.
>
> OK for trunk?
>
>
>
> patch.txt
>
> commit 67e1782be13b180e537fcf56aa041cd199b38ae9
> Author: Jonathan Wakely
> Date:
On 10/18/18 7:09 AM, Richard Biener wrote:
>
> PR63155 made me pick up this old work from Steven, it turns our
> linked-list implementation to a two-mode one with one being a
> splay tree featuring O(log N) complexity for find/remove.
>
> Over Stevens original patch I added a bitmap_tree_to_vec
Hi Olivier,
> STATIC_CHAIN_REGNUM still needs to be adjusted directly I think.
>
> I wondered if we could set it to R11 unconditionally and picked
> the way ensuring no change for !vxworks ports, especially since I
> don't have means to test more than what I described above.
Yes it should always
On 10/17/18 12:14 PM, Ilya Leoshkevich wrote:
> Boostrapped and regtested on x86_64-redhat-linux.
>
> Changes since v1:
>
> * Added the missing INSN_P () check.
> * Rewrote the commit message.
>
> FROM..TO range might contain NOTE_INSN_DELETED insns, for which the
> corresponding entries in
On 10/18/18 2:10 AM, Robin Dapp wrote:
> Hi,
>
> I added a check before calling priority in restore_pattern. In the last
> version, not checking that would lead to assertion failure in priority
> since the insn might already have been scheduled.
>
> Bootstrapped and regtested on x86_64 and
On 10/17/18 4:21 PM, Giuliano Augusto Faulin Belinassi wrote:
> Oh, please note that the error that I'm talking about is the
> comparison with the result obtained before and after the
> simplification. It is possible that the result obtained after the
> simplification be more precise when compared
2018-10-18 Uros Bizjak
* config/i386/i386.c (ix86_emit_fp_unordered_jump):
Set JUMP_LABEL to the jump insn.
(ix86_emit_i387_log1p): Use ix86_expand_branch to expand branch.
Predict emitted jump and add label to jump insn.
Bootstrapped and regression tested on x86_64-linux-gnu
Your patch at: https://gcc.gnu.org/ml/fortran/2018-10/msg00079.html is
OK for trunk.
Thanks
Paul
It turned out that this patch did not quite complete the job (Thanks
Walt): The ICE has gone but reallocation on assignment is not
occurring because the correct string length for the rhs expression was
not being picked up. The fix for this took rather more detective work
than I anticipated but
Hi!
OpenMP 5.0 adds a couple of new combined constructs, mainly to save typing
when using tasking.
In particular
#pragma omp parallel master
#pragma omp master taskloop
#pragma omp master taskloop simd
#pragma omp parallel master taskloop
#pragma omp parallel master taskloop simd
Tested on
On Thu, 2018-10-18 at 07:59 +0200, Eric Botcazou wrote:
> > Thanks; I've committed this to trunk as r265240.
>
> You modified gcc-interface/Make-lang.in without ChangeLog entry.
Oops. I've double-checked my ChangeLog-writing script [1], and it did
generate an entry for ada, but I believe I
On October 18, 2018 5:42:56 PM GMT+02:00, Aldy Hernandez
wrote:
>
>
>On 10/18/18 8:11 AM, Richard Biener wrote:
>> On Thu, 18 Oct 2018, Richard Biener wrote:
>>
>>>
>>> At some point we decided to not simply intersect all ranges we get
>>> via register_edge_assert_for. Instead we simply
In r264887 I broke the build of 502.gcc_r due to an ICE.
The ICE occurs when generating a location for an sprintf warning within
a string literal, where the sprintf call is in a macro.
The root cause is a bug in the original commit of substring locations
(r239175). get_substring_ranges_for_loc
On 10/18/18 8:11 AM, Richard Biener wrote:
On Thu, 18 Oct 2018, Richard Biener wrote:
At some point we decided to not simply intersect all ranges we get
via register_edge_assert_for. Instead we simply register them
in-order. That causes things like replacing [64, +INF] with ~[0, 0].
The
* doc/invoke.texi (-dumpversion): Improve grammar.
(-dumpfullversion): Make more consistent with -dumpversion.
OK for trunk?
commit 67e1782be13b180e537fcf56aa041cd199b38ae9
Author: Jonathan Wakely
Date: Thu Oct 18 16:40:00 2018 +0100
Improve -dumpversion and
Use the value of the first element as the initial value of the
__valarray_sum accumulator. Value-initialization might not create the
additive identity for the value type.
Make a similar change to __valarray_product even though it's only ever
used internally with a value_type of size_t.
On Thu, 2018-10-18 at 15:09 +0200, Richard Biener wrote:
> PR63155 made me pick up this old work from Steven, it turns our
> linked-list implementation to a two-mode one with one being a
> splay tree featuring O(log N) complexity for find/remove.
>
> Over Stevens original patch I added a
On Thu, 18 Oct 2018, Richard Sandiford wrote:
> Richard Biener writes:
> > PR63155 made me pick up this old work from Steven, it turns our
> > linked-list implementation to a two-mode one with one being a
> > splay tree featuring O(log N) complexity for find/remove.
> >
> > Over Stevens original
Richard Biener writes:
> PR63155 made me pick up this old work from Steven, it turns our
> linked-list implementation to a two-mode one with one being a
> splay tree featuring O(log N) complexity for find/remove.
>
> Over Stevens original patch I added a bitmap_tree_to_vec helper
> that I use
Hi Kyrill,
> On 16 Oct 2018, at 18:33, Kyrill Tkachov wrote:
>
>> I'm happy to move that part to aarch64_conditional_register_usage
>> if that's considered more canonical of course.
>
> I don't think it's more canonical, and it is a run-time thing, whereas your
> patch changes things
> at
> On 18 Oct 2018, at 15:10, Olivier Hainque wrote:
>
> The only difference there would be wrt to this part
> is the use of the macro within called_used_regs[] as well,
> part of what we discussed with Kyrill.
Ah, no, call_used[r18] is 1 currently.
Will give this some thought ...
Hello,
is there a chance to get the or1k support integrated before the GCC 9
stage 3?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP :
> On 18 Oct 2018, at 14:14, Sam Tebbs wrote:
>
>
>
> On 10/12/2018 07:43 PM, Olivier Hainque wrote:
>>> On 12 Oct 2018, at 05:50, Kyrill Tkachov
>>> wrote:
>>>
>>> CC'ing the aarch64 maintainers as they'll have to approve it.
>>> I'm guessing you've tested this in the usual way (bootstrap
PR63155 made me pick up this old work from Steven, it turns our
linked-list implementation to a two-mode one with one being a
splay tree featuring O(log N) complexity for find/remove.
Over Stevens original patch I added a bitmap_tree_to_vec helper
that I use from the debug/print methods to avoid
Joseph Myers writes:
> On Wed, 17 Oct 2018, Richard Sandiford wrote:
>> Yeah, can't deny that if you look at it as a general-purpose extension.
>> But that's not really what this is supposed to be. It's fairly special
>> purpose: there has to be some underlying variable-length/sizeless
>>
On Thu, 18 Oct 2018, Jan Hubicka wrote:
> >
> > So like the following which removes the use of ix86_vec_cost
> > for SSE loads and stores since we have per-mode costs already.
> > I've applied the relevant factor to the individual cost tables
> > (noting that for X86_TUNE_SSE_SPLIT_REGS we only
On 10/12/2018 07:43 PM, Olivier Hainque wrote:
On 12 Oct 2018, at 05:50, Kyrill Tkachov wrote:
CC'ing the aarch64 maintainers as they'll have to approve it.
I'm guessing you've tested this in the usual way (bootstrap and test)?
Sorry, I failed to mention the testing indeed. We don't
have a
On 10/18/18, Richard Sandiford wrote:
> "H.J. Lu" writes:
>> On 10/18/18, Richard Sandiford wrote:
>>> "H.J. Lu" writes:
On 10/18/18, Richard Sandiford wrote:
> "H.J. Lu" writes:
>> On 10/17/18, Marc Glisse wrote:
>>> On Wed, 17 Oct 2018, H.J. Lu wrote:
>>>
We
On Thu, 18 Oct 2018, Richard Biener wrote:
>
> At some point we decided to not simply intersect all ranges we get
> via register_edge_assert_for. Instead we simply register them
> in-order. That causes things like replacing [64, +INF] with ~[0, 0].
>
> The following patch avoids replacing a
> we need to generate
>
> vxorp[ds] %xmmN, %xmmN, %xmmN
> ...
> vcvtss2sd f(%rip), %xmmN, %xmmX
> ...
> vcvtsi2ss i(%rip), %xmmN, %xmmY
>
> to avoid partial XMM register stall. This patch adds a pass to generate
> a single
>
> vxorps
On Thu, Oct 18, 2018 at 1:54 PM H.J. Lu wrote:
>
> On 10/18/18, Uros Bizjak wrote:
> > On Thu, Oct 18, 2018 at 1:19 PM H.J. Lu wrote:
> >
> >> >> +(define_insn
> >> >> "*fma_fmadd__bcst_1"
> >> >> + [(set (match_operand:VF_AVX512 0 "register_operand" "=v,v")
> >> >> + (fma:VF_AVX512
> >>
On 10/18/18, Uros Bizjak wrote:
> On Thu, Oct 18, 2018 at 1:19 PM H.J. Lu wrote:
>
>> >> +(define_insn
>> >> "*fma_fmadd__bcst_1"
>> >> + [(set (match_operand:VF_AVX512 0 "register_operand" "=v,v")
>> >> + (fma:VF_AVX512
>> >> + (match_operand:VF_AVX512 1 "nonimmediate_operand"
>
> So like the following which removes the use of ix86_vec_cost
> for SSE loads and stores since we have per-mode costs already.
> I've applied the relevant factor to the individual cost tables
> (noting that for X86_TUNE_SSE_SPLIT_REGS we only apply the
> multiplication for size == 128, not
"H.J. Lu" writes:
> On 10/18/18, Richard Sandiford wrote:
>> "H.J. Lu" writes:
>>> On 10/18/18, Richard Sandiford wrote:
"H.J. Lu" writes:
> On 10/17/18, Marc Glisse wrote:
>> On Wed, 17 Oct 2018, H.J. Lu wrote:
>>
>>> We may simplify
>>>
>>> (subreg (vec_merge
Joseph Myers writes:
> On Wed, 17 Oct 2018, Richard Sandiford wrote:
>
>> > But as shown in the related discussions, there are other possible features
>> > that might also involve non-VLA types whose size is not a compile-time
>> > constant. And so it's necessary to work with the people
On Thu, Oct 18, 2018 at 1:19 PM H.J. Lu wrote:
> >> +(define_insn "*fma_fmadd__bcst_1"
> >> + [(set (match_operand:VF_AVX512 0 "register_operand" "=v,v")
> >> + (fma:VF_AVX512
> >> + (match_operand:VF_AVX512 1 "nonimmediate_operand" "0,v")
> >> + (match_operand:VF_AVX512 2
>
> The following fixes vec_construct cost calculation to properly consider
> that the inserts will happen to SSE regs thus forgo the multiplication
> done in ix86_vec_cost which is passed the wrong mode. This gets rid of
> the only call passing false to ix86_vec_cost (so consider the patch
>
On 10/18/18, Uros Bizjak wrote:
> On Thu, Oct 18, 2018 at 11:11 AM H.J. Lu wrote:
>>
>> Many AVX512 vector operations can broadcast from a scalar memory source.
>> This patch enables memory broadcast for FMA operations.
>>
>> gcc/
>>
>> PR target/72782
>> * config/i386/sse.md
On 18/10/18 12:06 +0100, Renlin Li wrote:
Hi Jonathan,
I saw those tests failed to compile on baremetal targets with the following
error:
```
libstdc++-v3/include/experimental/io_context:45: fatal error: poll.h: No such
file or directory
```
That error should be fixed at r265203 but the
Hi Jonathan,
I saw those tests failed to compile on baremetal targets with the following
error:
```
libstdc++-v3/include/experimental/io_context:45: fatal error: poll.h: No such
file or directory
```
Should we add a check to prevent it from running on unsupported platforms?
Thanks!
Renlin
At some point we decided to not simply intersect all ranges we get
via register_edge_assert_for. Instead we simply register them
in-order. That causes things like replacing [64, +INF] with ~[0, 0].
The following patch avoids replacing a range with a larger one
as obvious improvement.
Patch for the PR70149 regression committed as revision 265263.
Likewise the patch for PR58618 has been committed as revision 265264.
Cheers
Paul
On Wed, 17 Oct 2018 at 22:17, Tobias Burnus wrote:
>
> Hi Paul,
>
> Paul Richard Thomas wrote:
> > This problem concerned associate targets being
On 10/18/18, Richard Sandiford wrote:
> "H.J. Lu" writes:
>> On 10/18/18, Richard Sandiford wrote:
>>> "H.J. Lu" writes:
On 10/17/18, Marc Glisse wrote:
> On Wed, 17 Oct 2018, H.J. Lu wrote:
>
>> We may simplify
>>
>> (subreg (vec_merge (vec_duplicate X) (vector)
I do not think that there will be a PR for the ICE. This is a
regression introduced by my patch for PR70149 (September 30th). A
patch is attached. I will commit it as 'obvious' as soon as it has
finished regtesting. I will also commit the patch for PR58618 shortly
afterwards. Thanks for the
"H.J. Lu" writes:
> On 10/18/18, Richard Sandiford wrote:
>> "H.J. Lu" writes:
>>> On 10/17/18, Marc Glisse wrote:
On Wed, 17 Oct 2018, H.J. Lu wrote:
> We may simplify
>
> (subreg (vec_merge (vec_duplicate X) (vector) (const_int 1)) 0)
>
> to X when mode of X is
On Thu, Oct 18, 2018 at 11:11 AM H.J. Lu wrote:
>
> Many AVX512 vector operations can broadcast from a scalar memory source.
> This patch enables memory broadcast for FMA operations.
>
> gcc/
>
> PR target/72782
> * config/i386/sse.md (VF_AVX512): New.
> (avx512bcst):
Many AVX512 vector operations can broadcast from a scalar memory source.
This patch enables memory broadcast for FMA operations.
gcc/
PR target/72782
* config/i386/sse.md (VF_AVX512): New.
(avx512bcst): Likewise.
(*fma_fmadd__bcst_1):
Likewise.
On 10/18/18, Richard Sandiford wrote:
> "H.J. Lu" writes:
>> On 10/17/18, Marc Glisse wrote:
>>> On Wed, 17 Oct 2018, H.J. Lu wrote:
>>>
We may simplify
(subreg (vec_merge (vec_duplicate X) (vector) (const_int 1)) 0)
to X when mode of X is the same as of mode of
Hi,
this enables QImode and HImode for load on condition. For SPEC2006 this
reduces code size overall, performance impact is negligible.
Regtested on s390x.
Regards
Robin
--
gcc/ChangeLog:
2018-10-18 Robin Dapp
* config/s390/s390.md: Add movcc for QImode and HImode.
diff --git
I have tested the following patch to revert the fix for PR84204.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk
and branch.
Richard.
2018-10-18 Richard Biener
PR middle-end/87087
Revert
2018-02-07 Richard Biener
PR
"H.J. Lu" writes:
> On 10/17/18, Marc Glisse wrote:
>> On Wed, 17 Oct 2018, H.J. Lu wrote:
>>
>>> We may simplify
>>>
>>> (subreg (vec_merge (vec_duplicate X) (vector) (const_int 1)) 0)
>>>
>>> to X when mode of X is the same as of mode of subreg.
>>
>> Hello,
>>
>> we already have code to
"H.J. Lu" writes:
> We can simplify
>
> (subreg (vec_merge (vec_duplicate X)
>(vector)
>(const_int ((1 << N) | M)))
> (N * sizeof (X)))
>
> to X when mode of X is the same as of mode of subreg.
>
> gcc/
>
> PR target/87537
> *
Hi,
I added a check before calling priority in restore_pattern. In the last
version, not checking that would lead to assertion failure in priority
since the insn might already have been scheduled.
Bootstrapped and regtested on x86_64 and ppc8, regtested on s390x.
Regards
Robin
--
On Thu, Oct 18, 2018 at 12:45:00AM +0200, Jakub Jelinek wrote:
> Is a partial backport (just add
> attr_id = canonicalize_attr_name (attr_id);
> in the else if (attr_ns) case plus the non-__gnu__ lines from the testcase)
> ok for 7/8 release branches where it ICEs?
Small clarification, only
On 10/17/18, Marc Glisse wrote:
> On Wed, 17 Oct 2018, H.J. Lu wrote:
>
>> We may simplify
>>
>> (subreg (vec_merge (vec_duplicate X) (vector) (const_int 1)) 0)
>>
>> to X when mode of X is the same as of mode of subreg.
>
> Hello,
>
> we already have code to simplify vec_select(vec_merge):
>
>
On Wed, 17 Oct 2018, H.J. Lu wrote:
We may simplify
(subreg (vec_merge (vec_duplicate X) (vector) (const_int 1)) 0)
to X when mode of X is the same as of mode of subreg.
Hello,
we already have code to simplify vec_select(vec_merge):
/* If we select elements in a vec_merge that all
> Thanks; I've committed this to trunk as r265240.
You modified gcc-interface/Make-lang.in without ChangeLog entry.
--
Eric Botcazou
92 matches
Mail list logo
