On 08/01/2018 12:55 AM, Bernd Edlinger wrote:
Certainly not every "strlen" has these semantics. For example,
this open-coded one doesn't:
int len = 0;
for (int i = 0; s.a[i]; ++i)
++len;
It computes 2 (with no warning for the out-of-bounds access).
yes, which is questionable as
On 08/01/2018 02:40 AM, Jakub Jelinek wrote:
On Wed, Aug 01, 2018 at 09:19:43AM +0200, Richard Biener wrote:
And if so, what makes it well defined?
The fact that strlen takes a char * argument and thus inline-expansion
of a trivial implementation like
int len = 0;
for (; *p; ++p)
++len;
On 08/02/2018 12:20 PM, Jakub Jelinek wrote:
On Thu, Aug 02, 2018 at 11:00:32AM -0600, Martin Sebor wrote:
As an alternate approach I have been thinking about, if
there is a strong feeling that allowing strlen to iterate
past the subobject boundary is necessary (I don't believe
it is.)
Rather
On 08/02/2018 12:15 PM, Bernd Edlinger wrote:
On 08/02/18 19:00, Martin Sebor wrote:
As an alternate approach I have been thinking about, if
there is a strong feeling that allowing strlen to iterate
past the subobject boundary is necessary (I don't believe
it is.)
Rather than indiscriminately
On 08/03/2018 12:02 AM, James Greenhalgh wrote:
On Thu, Aug 02, 2018 at 11:58:37AM -0500, Siddhesh Poyarekar wrote:
There was a typo in the pipeline description where DUP was assigned to
the vector pipes for quad mode ops when it really only uses the VTOG
pipes. Fixing this does not show any
"make selftest-valgrind" shows:
187 bytes in 1 blocks are definitely lost in loss record 567 of 669
at 0x4A081D4: calloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x1F08260: xcalloc (xmalloc.c:162)
by 0xB24F32: init_emit() (emit-rtl.c:5843)
by 0xC10080:
We should always set cfun->machine->max_used_stack_alignment if the
maximum stack slot alignment may be greater than 64 bits.
Tested on i686 and x86-64. OK for master and backport for GCC 8?
Thanks.
H.J.
gcc/
PR target/86386
* config/i386/i386.c
On 07/27/2018 09:36 AM, Vladimir Makarov wrote:
> On 07/23/2018 05:14 AM, Ilya Leoshkevich wrote:
>> FIRST_PSEUDO_REGISTER is not a hard regno, so comparisons should use
>> "<" instead of "<=", and ">=" instread of ">".
>>
> Thank you for finding these typos. LRA parts of the patch are ok for me.
On 07/26/2018 08:43 AM, Martin Liška wrote:
> Hi.
>
> It's just a cosmetics change where I want to print 2 digits of fraction
> part of heuristics probabilities. It helps to distinguish 100% from
> PROB_VERY_LIKELY (99.96%).
>
> Patch can bootstrap on ppc64le-redhat-linux and survives regression
On 07/27/2018 07:49 PM, Sandra Loosemore wrote:
> On 07/26/2018 12:06 AM, 瞿仙淼 wrote:
>>
>> I wrote a case to reproduce this problem on C-SKY. C code is as follows:
>> ---
>> int e1, e2;
>>
>> void func (int a, int b, int c, int d,
On 07/26/2018 12:06 AM, 瞿仙淼 wrote:
>
>> 在 2018年7月25日，上午5:24，Jeff Law 写道：
>>
>> On 07/24/2018 12:18 PM, Sandra Loosemore wrote:
>>> On 07/24/2018 09:45 AM, Jeff Law wrote:
On 07/23/2018 10:21 PM, Sandra Loosemore wrote:
I'm not a big fan of more awk code, but I'm not going to object to
On Donnerstag, 2. August 2018 23:15:28 CEST Marc Glisse wrote:
> On Thu, 2 Aug 2018, Allan Sandfeld Jensen wrote:
> > I forgot. One of the things that makes using __builtin_shuffle ugly is
> > that
> > __v4si as the suffle argument needs to be in _mm_move_ss, is declared
> > in emmintrin.h, but
On Donnerstag, 2. August 2018 23:46:37 CEST Jakub Jelinek wrote:
> On Thu, Aug 02, 2018 at 10:50:58PM +0200, Allan Sandfeld Jensen wrote:
> > Here is the version with __builtin_shuffle. It might be more expectable
> > -O0, but it is also uglier.
>
> I don't find anything ugly on it, except the
On Thu, Aug 02, 2018 at 10:50:58PM +0200, Allan Sandfeld Jensen wrote:
> Here is the version with __builtin_shuffle. It might be more expectable -O0,
> but it is also uglier.
I don't find anything ugly on it, except the formatting glitches (missing
space before (, overlong line, and useless
On Thu, 2 Aug 2018, Allan Sandfeld Jensen wrote:
I forgot. One of the things that makes using __builtin_shuffle ugly is that
__v4si as the suffle argument needs to be in _mm_move_ss, is declared
in emmintrin.h, but _mm_move_ss is in xmmintrin.h.
__v4si is some internal detail, I don't see
On Donnerstag, 2. August 2018 11:18:41 CEST Richard Biener wrote:
> On Thu, Aug 2, 2018 at 11:12 AM Allan Sandfeld Jensen
>
> wrote:
> > On Mittwoch, 1. August 2018 18:51:41 CEST Marc Glisse wrote:
> > > On Wed, 1 Aug 2018, Allan Sandfeld Jensen wrote:
> > > > extern __inline __m128d
On Mittwoch, 1. August 2018 18:51:41 CEST Marc Glisse wrote:
> On Wed, 1 Aug 2018, Allan Sandfeld Jensen wrote:
> > extern __inline __m128d __attribute__((__gnu_inline__, __always_inline__,
> >
> > __artificial__))
> >
> > _mm_move_sd (__m128d __A, __m128d __B)
> > {
> >
> > - return
On 08/02/2018 12:56 PM, Bernd Edlinger wrote:
On 08/02/18 15:26, Bernd Edlinger wrote:
/* If the length can be computed at compile-time, return it. */
- len = c_strlen (src, 0);
+ tree array;
+ tree len = c_strlen (src, 0, );
You know the c_strlen tries to compute wide character
On 2018-08-02 2:40 PM, Jeff Law wrote:
It's been eons. I think there's enough building blocks on the PA to
mount a spectre v1 attack. They've got branch prediction with varying
degress of speculative execution, caches and user accessable cycle timers.
Yes.
There's varying degrees of out of
Hi
Here is a patch to avoid definition of invalid operators on the
Debug mode safe iterator type depending on its category.
Even if it is limited to the Debug mode code I would like to have a
feedback before committing. Especially on the following points:
- _Safe_tagged_iterator:
We were rather sloppy about handling the ownership of prefixes for
pretty_printer, and this lead to a memory leak for any time a
diagnostic_show_locus call emits multiple line spans.
This showed up in "make selftest-valgrind" as:
3,976 bytes in 28 blocks are definitely lost in loss record 632 of
The recently added test gcc.dg/torture/builtin-sprintf.c
to verify that the sprintf result computed by GCC matches
libc's for Infinity and NaN has been failing on AIX which
formats NaN as either QNaN or SNaN, contrary to C/POSIX
requirements. The attached tweak adjusts the result
computed by GCC
On Tue, Jul 31, 2018 at 04:53:19AM -0500, Matthew Malcomson wrote:
> Fixing the ilp32 issue that Christophe found.
>
> The existing testcase uses `long` to represent a 64 bit integer.
> This breaks when compiled using the `-mabi=ilp32` flag.
> We switch the use of int/long for int32_t/int64_t to
On 2018-08-01 06:37 AM, Richard Biener wrote:
> On Tue, Jul 31, 2018 at 7:40 PM Michael Ploujnikov
> wrote:
>>
>> On 2018-07-26 01:27 PM, Michael Ploujnikov wrote:
>>> On 2018-07-24 09:57 AM, Michael Ploujnikov wrote:
On 2018-07-20 06:05 AM, Richard Biener wrote:
>> /* Return a new
On 08/02/2018 02:50 PM, Jeff Law wrote:
On 08/02/2018 12:23 PM, Aldy Hernandez wrote:
On 08/02/2018 02:07 PM, Jeff Law wrote:
On 08/01/2018 03:19 PM, David Malcolm wrote:
On Wed, 2018-08-01 at 15:39 -0400, Aldy Hernandez wrote:
This is actually an obvious patch, but I'm not committing
On 2018-08-02 13:44, Tom Tromey wrote:
"Simon" == Simon Marchi writes:
Simon> intl/ChangeLog:
Simon> * libgnuintl.h (_INTL_MAY_RETURN_STRING_ARG, gettext, dgettext,
Simon> dcgettext, ngettext, dngettext, dcngettext): Backport changes
Simon> from upstream gettext.
Thanks, I
On 08/02/18 15:26, Bernd Edlinger wrote:
>>
>> /* If the length can be computed at compile-time, return it. */
>> - len = c_strlen (src, 0);
>> + tree array;
>> + tree len = c_strlen (src, 0, );
>
> You know the c_strlen tries to compute wide character sizes,
> but strlen does not do that,
On 08/02/2018 02:23 PM, Aldy Hernandez wrote:
On 08/02/2018 02:07 PM, Jeff Law wrote:
On 08/01/2018 03:19 PM, David Malcolm wrote:
On Wed, 2018-08-01 at 15:39 -0400, Aldy Hernandez wrote:
This is actually an obvious patch, but I'm not committing it just in
case you'd prefer another name
On 08/02/2018 12:23 PM, Aldy Hernandez wrote:
>
>
> On 08/02/2018 02:07 PM, Jeff Law wrote:
>> On 08/01/2018 03:19 PM, David Malcolm wrote:
>>> On Wed, 2018-08-01 at 15:39 -0400, Aldy Hernandez wrote:
This is actually an obvious patch, but I'm not committing it just in
case you'd
On 07/27/2018 01:48 PM, John David Anglin wrote:
> On 2018-07-27 5:37 AM, Richard Earnshaw wrote:
>> Port Maintainers: You need to decide what action is required for your
>> port to handle speculative execution, even if that action is to use
>> the trivial no-speculation on this architecture. You
On Thu, Aug 02, 2018 at 08:28:22PM +0200, Jakub Jelinek wrote:
> --- gcc/c/c-typeck.c.jj 2018-08-01 17:00:46.329549760 +0200
> +++ gcc/c/c-typeck.c 2018-08-02 18:57:31.969477582 +0200
> @@ -13112,6 +13112,7 @@ c_omp_finish_iterators (tree iter)
>tree begin = TREE_VEC_ELT (it, 1);
>
On Thu, Aug 02, 2018 at 11:58:37AM -0500, Siddhesh Poyarekar wrote:
> There was a typo in the pipeline description where DUP was assigned to
> the vector pipes for quad mode ops when it really only uses the VTOG
> pipes. Fixing this does not show any noticeable difference in
> performance
Hi!
Another thing being voted into OpenMP 5.0 these days are clarifications for
iterators - step must be integral, and whether it is > 0 determines if it
iterates up or down, so one can use downward iterators even with unsigned
iterator type, either just use signed negative step constant, or some
On 08/02/2018 02:07 PM, Jeff Law wrote:
On 08/01/2018 03:19 PM, David Malcolm wrote:
On Wed, 2018-08-01 at 15:39 -0400, Aldy Hernandez wrote:
This is actually an obvious patch, but I'm not committing it just in
case you'd prefer another name for the files.
BTW, is it our policy that new
On Thu, Aug 02, 2018 at 11:00:32AM -0600, Martin Sebor wrote:
> As an alternate approach I have been thinking about, if
> there is a strong feeling that allowing strlen to iterate
> past the subobject boundary is necessary (I don't believe
> it is.)
>
> Rather than indiscriminately expanding the
On 08/02/18 19:00, Martin Sebor wrote:
> As an alternate approach I have been thinking about, if
> there is a strong feeling that allowing strlen to iterate
> past the subobject boundary is necessary (I don't believe
> it is.)
>
> Rather than indiscriminately expanding the provenance of
> the
On 08/01/2018 03:19 PM, David Malcolm wrote:
> On Wed, 2018-08-01 at 15:39 -0400, Aldy Hernandez wrote:
>> This is actually an obvious patch, but I'm not committing it just in
>> case you'd prefer another name for the files.
>
> BTW, is it our policy that new gcc C++ source files should have a
While m68k does have branch prediction, it's a dead architecture, does
not have out of order properties and AFAIK doesn't have a suitably
accurate timer. Thus, it doesn't seem worth trying to do any spectre v1
mitigations.
Committed to the trunk.
Jeff
commit
Use the STLUR instruction introduced in Armv8.4-a.
This insruction has the store-release semantic like STLR but can take a
9-bit unscaled signed immediate offset.
Example test case:
```
void
foo ()
{
int32_t *atomic_vals = calloc (4, sizeof (int32_t));
atomic_store_explicit (atomic_vals +
> "Simon" == Simon Marchi writes:
Simon> intl/ChangeLog:
Simon> * libgnuintl.h (_INTL_MAY_RETURN_STRING_ARG, gettext, dgettext,
Simon> dcgettext, ngettext, dngettext, dcngettext): Backport changes
Simon> from upstream gettext.
Thanks, I think you should check this in.
Tom
Hi Matthew
On 01/08/18 10:25, matthew.malcom...@arm.com wrote:
My first patch included an incorrect ChangeLog entry -- the filename was
misspelt. This corrects it.
I think this counts as an obvious change. I have committed this on your
behalf.
Thanks
Sudi
Ping!
Siddhesh
On 07/24/2018 12:37 PM, Siddhesh Poyarekar wrote:
Hi,
This is a rewrite of the tag collision avoidance patch that Kugan had
written as a machine reorg pass back in February.
The falkor hardware prefetching system uses a combination of the
source, destination and offset to
Fixing the ilp32 issue that Christophe found.
The existing testcase uses `long` to represent a 64 bit integer.
This breaks when compiled using the `-mabi=ilp32` flag.
We switch the use of int/long for int32_t/int64_t to avoid this problem
and show the requirement of a widening operation more
My first patch included an incorrect ChangeLog entry -- the filename was
misspelt. This corrects it.diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index
76f935a48adbcbab2ec765372f48a4599ad85966..6e56ba2d2f081b5e755b2ff834c7878a1268a3ba
100644
--- a/gcc/testsuite/ChangeLog
+++
I'm not aware of any H8 part that does speculation that would cause
problems here.
Committed to the trunk.
Jeff
commit a56e14aaf64f3726a3e2114dc76db74925a4b078
Author: law
Date: Thu Aug 2 17:24:59 2018 +
PR target/86784
* config/h8300/h8300.c
On Jul 17 2018, Andreas Schwab wrote:
> The mulu.l insn sets the CC according to the 64-bit result, but we are
> only using the high part, so the Z flag cannot be used. The other flags
> would still be valid, but we have no cc_status flag for that case.
>
> * config/m68k/m68k.md
On Thu, Aug 02, 2018 at 05:42:46PM +0200, Christophe Lyon wrote:
> On Thu, 2 Aug 2018 at 13:35, Nicolas Koenig wrote:
> >
> >
> > Hello everyone,
> >
> > Here is an updated version of the patch that hopefully fixes the compilation
> > problems by disabling async I/O if conditions are not
On Tue, 2018-07-31 at 19:56 +, Joseph Myers wrote:
> On Tue, 31 Jul 2018, David Malcolm wrote:
>
> > I didn't exhaustively check every callsite to the changed calls;
> > I'm
> > assuming that -Wformat during bootstrap has effectively checked
> > that
> > for me. Though now I think about it,
On Thu, Aug 2, 2018 at 12:12 PM Jonathan Wakely wrote:
>
> On 02/08/18 11:32 -0400, David Edelsohn wrote:
> >Jonathan
> >
> >This patch broke AIX bootstrap.
> >
> >/nasfarm/edelsohn/src/src/libstdc++-v3/src/c++11/system_error.cc: In
> >member function 'virtual std::error_condition
>
As an alternate approach I have been thinking about, if
there is a strong feeling that allowing strlen to iterate
past the subobject boundary is necessary (I don't believe
it is.)
Rather than indiscriminately expanding the provenance of
the subobject regardless of what members follow it in
the
There was a typo in the pipeline description where DUP was assigned to
the vector pipes for quad mode ops when it really only uses the VTOG
pipes. Fixing this does not show any noticeable difference in
performance (there's a very small bump of 1.7% in x264 but that's
about it) in my tests but is
On Tue, Jul 31, 2018 at 10:33:59AM -0500, Aaron Sawdey wrote:
> Just teasing things apart a bit more in this function so I can add
> vec/vsx code generation without making it enormous and
> incomprehensible.
>
> Bootstrap/regtest passes on powerpc64le, ok for trunk?
Yes please. Thanks!
Segher
On 27/07/18 17:45, Nicolas Pitre wrote:
> On Fri, 27 Jul 2018, Wilco Dijkstra wrote:
>
>> Nicolas Pitre wrote:
>>
However if r4 is non-zero, the carry will be set, and the tsths will be
executed. This
clears the carry and sets the Z flag based on bit 20.
>>>
>>> No, not at all.
On 07/25/2018 01:08 AM, Richard Biener wrote:
>>
>> So ISTM that you really need a stronger justification using the
>> standards compliance and/or real world code that is made less safe by
>> keeping string lengths as accurate as possible.
>
> Note you cannot solely look at what the C standard
On 08/02/2018 04:19 PM, Kyrill Tkachov wrote:
Hi Siddhesh,
On 02/08/18 11:23, Siddhesh Poyarekar wrote:
There was a typo in the pipeline description where DUP was assigned to
the vector pipes for quad mode ops when it really only uses the VTOG
pipes. Fixing this does not show any noticeable
Hi Kelvin,
On Wed, Aug 01, 2018 at 02:55:22PM -0500, Kelvin Nilsen wrote:
> Several errors were discovered in the descriptions of the __builtin_bcdadd,
> __builtin_bcdadd_lt, __builtin_bcdadd_eq, __builtin_bcdadd_gt,
> __builtin_bcdadd_ov, __builtin_bcdsub, __builtin_bcdsub_lt,
>
On Wed, 1 Aug 2018, Martin Sebor wrote:
> Richard, do you have any further comments or suggestions or is
> the patch acceptable?
>
> I realize it's not ideal but I don't see how to achieve the ideal
> (understanding PTRDIFF_MAX) without deferring the processing of
> these options until the back
On 02/08/18 11:32 -0400, David Edelsohn wrote:
Jonathan
This patch broke AIX bootstrap.
/nasfarm/edelsohn/src/src/libstdc++-v3/src/c++11/system_error.cc: In
member function 'virtual std::error_condition
{anonymous}::system_error_category::default_error_condition(int)
const':
On 08/02/2018 05:39 PM, Jakub Jelinek wrote:
> On Thu, Aug 02, 2018 at 05:30:53PM +0200, Tom de Vries wrote:
>> The nvptx port can't support exceptions using sjlj, because ptx does not
>> support sjlj. However, default_except_unwind_info still returns UI_SJLJ,
>> even
>> even if we configure
On 07/26/2018 05:18 AM, Richard Biener wrote:
> On Thu, Jul 26, 2018 at 12:29 PM Alexander Monakov wrote:
>>
>> Hi,
>>
>> when using explicit register variables ('register int foo asm("%ebp");'),
>> using const/volatile type qualifiers on the declaration does not result in
>> the logically
On 08/01/2018 08:33 AM, Richard Biener wrote:
>
> Repeating the boiler-plate from 0/4 here again, in case you didn't read
> it. This is the main patch (and thus big). It scraps all of the
> SCCVN engine replacing it with RPO stuff but the stmt-based workers mostly
> stay the same.
>
>
> This
On Thu, 2 Aug 2018 at 13:35, Nicolas Koenig wrote:
>
>
> Hello everyone,
>
> Here is an updated version of the patch that hopefully fixes the compilation
> problems by disabling async I/O if conditions are not supported by the target.
>
> I would appreciate if people could test it on systems on
On 08/02/2018 04:22 AM, Bernd Edlinger wrote:
Hi,
this is an update of the patch to prevent unsafe optimizations due to strlen
range assuming
always zero-terminated char arrays.
Since the previous version I do no longer try to locate the outermost char
array,
but just bail out if there is a
On Thu, Aug 02, 2018 at 05:30:53PM +0200, Tom de Vries wrote:
> The nvptx port can't support exceptions using sjlj, because ptx does not
> support sjlj. However, default_except_unwind_info still returns UI_SJLJ, even
> even if we configure with --disable-sjlj-exceptions, because UI_SJLJ is the
>
Jonathan
This patch broke AIX bootstrap.
/nasfarm/edelsohn/src/src/libstdc++-v3/src/c++11/system_error.cc: In
member function 'virtual std::error_condition
{anonymous}::system_error_category::default_error_condition(int)
const':
Hi,
The nvptx port can't support exceptions using sjlj, because ptx does not
support sjlj. However, default_except_unwind_info still returns UI_SJLJ, even
even if we configure with --disable-sjlj-exceptions, because UI_SJLJ is the
fallback option.
The reason default_except_unwind_info doesn't
This patch just resyncs the branch version of the "@" pattern support
to match the current trunk version. It now supports "@" patterns
with code iterators and avoids trailing and double underscores
when removing "<...>" from the name.
Tested on aarch64-linux-gnu and applied to
On Thu, Aug 2, 2018 at 1:44 AM, Pierre-Marie de Rodat
wrote:
> On 07/06/2018 01:45 AM, Jim Wilson wrote:
>>
>> These are some patches I needed to complete my cross build of a native
>> riscv linux Ada compiler. Some paths were different on the build machine
>> and host machine. I needed to pass
Noticed by Tamar (thanks).
Tested on aarch64-linux-gnu and committed as obvious.
Richard
2018-08-02 Richard Sandiford
gcc/
* genemit.c (print_overload_test): Fix typo.
Index: gcc/genemit.c
===
--- gcc/genemit.c
I am testing the following to fix another __builtin_va_arg_pack_len ()
inlining issue.
Bootstrap & regtest running on x86_64-unknown-linux-gnu.
2018-08-02 Richard Biener
PR middle-end/86505
* tree-inline.c (copy_bb): When inlining __builtin_va_arg_pack_len ()
across
On 08/02/2018 01:30 AM, Richard Biener wrote:
This fixes the PR by making sure CLASSTYPE_AS_BASE types inherit
TYPE_TYPELESS_STORAGE from the main type so that types that inherit
a type with TYPE_TYPELESS_STORAGE also get TYPE_TYPELESS_STORAGE
propagated.
Bootstrap & regtest running on
On 08/02/18 04:44, Martin Sebor wrote:
> Since the foundation of the patch is detecting and avoiding
> the overly aggressive folding of unterminated char arrays,
> besides issuing a warning for such arguments to strlen,
> the patch also fixes pr86711 - wrong folding of memchr, and
> pr86714 -
> On 26 Jul 2018, at 10:13, Alan Hayward wrote:
>
> This is rebasing of the patch posted in November.
> It's aim is to support aarch64 SVE register preservation around TLS calls
> by adding a CLOBBER_HIGH expression.
>
> Across a TLS call, Aarch64 SVE does not explicitly preserve the
> SVE
On Tue, Jul 31, 2018 at 6:36 AM, Kyrill Tkachov
wrote:
> Hi Thomas,
>
>
> On 25/07/18 14:28, Thomas Preudhomme wrote:
>>
>> Hi Kyrill,
>>
>> Using memory_operand worked, the issues I encountered when using it in
>> earlier versions of the patch must have been due to the missing test
>> on
Hello everyone,
Here is an updated version of the patch that hopefully fixes the compilation
problems by disabling async I/O if conditions are not supported by the target.
I would appreciate if people could test it on systems on which it failed
before. As for the array_constructor_8.f90
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Committed to trunk as r263244, under the "obvious" rule.
gcc/ChangeLog:
* dumpfile.c (dump_user_location_t::dump_user_location_t): Add
"const" to the "gimple *" and "rtx_insn *" parameters.
* dumpfile.h
Convert the specified duration to the target clock's duration type before
adding it to the current time. This avoids the situation described in PR
libstdc++/68519 when the specified duration type lacks sufficient
precision.
---
libstdc++-v3/include/bits/atomic_futex.h | 6 +-
On Wednesday 01 August 2018 at 20:38:33 +0100, Jonathan Wakely wrote:
> On 01/08/18 14:19 +0100, Mike Crowe wrote:
> > I believe that I've added this functionality in a way that it doesn't break
> > ABI compatibility, but that has made it more verbose and less type safe. I
> > believe that it
The following fixes PR86816 - CFG cleanup can introduce new SSA names
which we may not query the VN lattice with.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2018-08-02 Richard Biener
PR tree-optimization/86816
* tree-ssa-tail-merge.c
"Richard Earnshaw (lists)" writes:
> On 13/07/18 10:15, Richard Sandiford wrote:
>> Given a pattern like:
>>
>> (define_insn "aarch64_frecpe" ...)
>>
>> the SVE ACLE implementation wants to generate the pattern for a
>> particular (non-constant) mode. This patch automatically generates
>>
On 08/01/2018 05:04 PM, Marc Glisse wrote:
> On Wed, 1 Aug 2018, Martin Liška wrote:
>
>> On 08/01/2018 02:25 PM, Marc Glisse wrote:
>>> On Wed, 1 Aug 2018, Martin Liška wrote:
>>>
On 07/27/2018 02:38 PM, Marc Glisse wrote:
> On Fri, 27 Jul 2018, Martin Liška wrote:
>
>> So
Hi Siddhesh,
On 02/08/18 11:23, Siddhesh Poyarekar wrote:
There was a typo in the pipeline description where DUP was assigned to
the vector pipes for quad mode ops when it really only uses the VTOG
pipes. Fixing this does not show any noticeable difference in
performance (there's a very small
There was a typo in the pipeline description where DUP was assigned to
the vector pipes for quad mode ops when it really only uses the VTOG
pipes. Fixing this does not show any noticeable difference in
performance (there's a very small bump of 1.7% in x264 but that's
about it) in my tests but is
Hi,
this is an update of the patch to prevent unsafe optimizations due to strlen
range assuming
always zero-terminated char arrays.
Since the previous version I do no longer try to locate the outermost char
array,
but just bail out if there is a typecast, that means, supposed we have a
On 13/07/18 10:15, Richard Sandiford wrote:
> Given a pattern like:
>
> (define_insn "aarch64_frecpe" ...)
>
> the SVE ACLE implementation wants to generate the pattern for a
> particular (non-constant) mode. This patch automatically generates
> helpers to do that, specifically:
>
> //
"H.J. Lu" writes:
> On Tue, Jul 24, 2018 at 2:58 AM, Richard Sandiford
> wrote:
>> This patch changes STMT_VINFO_VEC_STMT from a gimple stmt to a
>> stmt_vec_info and makes the vectorizable_* routines pass back
>> a stmt_vec_info to vect_transform_stmt.
>>
>>
>> 2018-07-24 Richard Sandiford
On 08/02/2018 11:39 AM, Richard Earnshaw (lists) wrote:
> On 18/07/18 16:48, Martin Liška wrote:
>> Hi.
>>
>> This is aarch64 fix for PR83193. It's about setting of default options
>> so that --help=target -Q prints proper numbers:
>>
>> Now this is seen on my cross-compiler:
>>
>> ---
On 18/07/18 16:48, Martin Liška wrote:
> Hi.
>
> This is aarch64 fix for PR83193. It's about setting of default options
> so that --help=target -Q prints proper numbers:
>
> Now this is seen on my cross-compiler:
>
> --- /home/marxin/Downloads/options-2-before.txt 2018-07-18
>
Hi.
As seen in the PR, we must first read all functions into global array functions
and then processing of these can happen. Currently we process functions
multiple times.
I'm planning to install that after it survives regression tests.
Martin
gcc/ChangeLog:
2018-08-02 Martin Liska
Hi.
I'm sending following cherry pick that I'm going to install. And I'll backport
that
then.
Martin
Fix sizeof(struct pthread) in glibc 2.14.
libsanitizer/ChangeLog:
2018-08-02 Martin Liska
PR sanitizer/86022
* sanitizer_common/sanitizer_linux_libcdep.cc
On Thu, Aug 2, 2018 at 11:12 AM Allan Sandfeld Jensen
wrote:
>
> On Mittwoch, 1. August 2018 18:51:41 CEST Marc Glisse wrote:
> > On Wed, 1 Aug 2018, Allan Sandfeld Jensen wrote:
> > > extern __inline __m128d __attribute__((__gnu_inline__, __always_inline__,
> > >
> > > __artificial__))
> > >
>
Hi, during testing of the new in-review C-SKY port, we discovered some FAILs
due to
the default va_args gimplifying (targhooks.c:std_gimplify_va_arg_expr) not
properly
having the logic to handle the TARGET_SPLIT_COMPLEX_ARG hook.
It appears that all other targets that happen to use
On Mittwoch, 1. August 2018 18:51:41 CEST Marc Glisse wrote:
> On Wed, 1 Aug 2018, Allan Sandfeld Jensen wrote:
> > extern __inline __m128d __attribute__((__gnu_inline__, __always_inline__,
> >
> > __artificial__))
> >
> > _mm_move_sd (__m128d __A, __m128d __B)
> > {
> >
> > - return
The ordering is fixed by the ordering of types in the CFI part of the
standard. Intrinsic types, then derived types and finally all the
others.
For the time being I will interchange character and derived types in
the conversion functions.
Cheers
Paul
On Tue, 31 Jul 2018 at 18:10, Janus Weil
Hello Jim,
On 07/06/2018 01:45 AM, Jim Wilson wrote:
These are some patches I needed to complete my cross build of a native
riscv linux Ada compiler. Some paths were different on the build machine
and host machine. I needed to pass options into gnatmake to work around this,
and that required
This fixes the PR by making sure CLASSTYPE_AS_BASE types inherit
TYPE_TYPELESS_STORAGE from the main type so that types that inherit
a type with TYPE_TYPELESS_STORAGE also get TYPE_TYPELESS_STORAGE
propagated.
Bootstrap & regtest running on x86_64-unknown-linux-gnu, OK?
Thanks,
Richard.
96 matches
Mail list logo
