On January 5, 2018 10:13:34 PM GMT+01:00, Joseph Myers
wrote:
>The folding of comparisons against Inf (to constants or comparisons
>with the maximum finite value) has various cases where it introduces
>or loses "invalid" exceptions for comparisons with NaNs.
>
>Folding x > +Inf to 0 should not be
On January 5, 2018 11:55:11 PM GMT+01:00, David Malcolm
wrote:
>On Fri, 2018-01-05 at 10:36 +0100, Richard Biener wrote:
>> On Thu, Jan 4, 2018 at 10:52 PM, David Malcolm
>> wrote:
>> > PR lto/83121 reports an ICE deep inside the linemap code when -Wodr
>> > reports on a type mismatch.
>> >
>>
On January 5, 2018 10:55:00 PM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>The recently added testcase for PR83666 ICEs on powerpc*/sparc*
>and perhaps other targets, where get_inner_reference gives us
>VOIDmode for a 512-bit field and smallest_int_mode_for_size
>ICEs on it because there is no such i
On January 5, 2018 11:05:59 PM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>All the vec_duplicate_p uses in simplify-rtx.c assume that it returns
>vector
>element if it returns true, and while that is the case for CONST_VECTOR
>which can't contain anything but scalars, VEC_DUPLICATE is documented:
>"T
On January 5, 2018 11:10:26 PM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>As the testcase shows, the sel-sched.c framework can't deal with
>debugging
>insns without causing -fcompare-debug failures, and I presume also with
>debug markers, with which it causes even ICEs right now.
>
>The following pa
This libgo patch by James Clarke fixes GOARCH_CACHELINESIZE on ia64.
Bootstrapped on x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 256262)
+++ gcc/go/gofr
This patch to the GCC portion of the Go frontend corrects the type
used for long double builtin math functions with one argument. This
lets gccgo inline calls to sqrt, cos, etc., on 32-bit x86. The math
package in libgo uses this feature. Previously it was generating
function calls rather than u
On 05/01/18 18:02 +, Jonathan Wakely wrote:
On 05/01/18 10:37 +, Jonathan Wakely wrote:
On 04/01/18 21:02 -0500, Tim Song wrote:
What if the file to be removed is externally removed between the
symlink_status and the ::remove call? This is probably QoI because
filesystem race, but it se
On 01/05/2018 03:02 PM, Jakub Jelinek wrote:
Hi!
Apparently LLVM allows similar warning to -Wclass-memaccess (is it just
similar or same?; if the latter, perhaps we should use the same option for
that) to be disabled not just by casting the destination pointer to
e.g. (char *) or some other poin
On 01/04/2018 02:28 PM, Richard Sandiford wrote:
> LRA has code to try to prevent cycling, by avoiding reloads that
> look too similar to the instruction being reloaded. E.g. if we
> have a R<-C move for some constant C, reloading the source with
> another R<-C move is unlikely to be a good idea.
On Fri, 2018-01-05 at 10:36 +0100, Richard Biener wrote:
> On Thu, Jan 4, 2018 at 10:52 PM, David Malcolm
> wrote:
> > PR lto/83121 reports an ICE deep inside the linemap code when -Wodr
> > reports on a type mismatch.
> >
> > The root cause is that the warning can access the
> > DECL_SOURCE_LOCA
On 01/05/2018 05:50 PM, Jonathan Wakely wrote:
On 05/01/18 09:54 -0500, Ed Smith-Rowland wrote:
This looks good to me. The only nit is that you have to uglify the k
loop variable.
Right, it needs to be __k.
I'm also not sure we can put the copyright notice there, rather than
at the top of th
On Fri, 2018-01-05 at 15:29 -0500, Jason Merrill wrote:
> On 12/29/2017 12:06 PM, David Malcolm wrote:
> > One issue I ran into was that fold_for_warn doesn't eliminate
> > location wrappers when processing_template_decl, leading to
> > failures of the template-based cases in
> > g++.dg/warn/Wmemse
This is a fix for PR target/83335. We are asserting in
aarch64_print_address_internal because we have a non Pmode
address coming from an asm instruction. My fix is to
just allow this by checking this_is_asm_operands. This is
what it was doing before the assert was added that caused
the ICE.
Ve
Hi!
Jason's recent change removed a mark_rvalue_use call from constant_value_1,
which unfortunately regressed quite a few cases where
-Wunused-but-set-variable now has false positives.
The easiest fix seems to be just deal with the -Wunused-but-set-variable
issue at that point.
Bootstrapped/regt
Hi!
As the testcase shows, the sel-sched.c framework can't deal with debugging
insns without causing -fcompare-debug failures, and I presume also with
debug markers, with which it causes even ICEs right now.
The following patch just follows what we do for -fvar-tracking-assignments,
disable it by
Hi!
All the vec_duplicate_p uses in simplify-rtx.c assume that it returns vector
element if it returns true, and while that is the case for CONST_VECTOR
which can't contain anything but scalars, VEC_DUPLICATE is documented:
"This operation converts a scalar into a vector or a small vector into a
l
Hi!
Apparently LLVM allows similar warning to -Wclass-memaccess (is it just
similar or same?; if the latter, perhaps we should use the same option for
that) to be disabled not just by casting the destination pointer to
e.g. (char *) or some other pointer to non-class, but also to (void *),
which i
Hi!
The recently added testcase for PR83666 ICEs on powerpc*/sparc*
and perhaps other targets, where get_inner_reference gives us
VOIDmode for a 512-bit field and smallest_int_mode_for_size
ICEs on it because there is no such integer mode.
Fixed by giving up above MAX_BITSIZE_MODE_ANY_INT, that w
On 01/04/2018 11:59 PM, Sebastian Huber wrote:
> gcc/
> * config/nios2/nios2.h (nios2_section_threshold): Guard by not
> USED_FOR_TARGET.
So I'm not familiar with *why* the section bits need to be
conditionalized at all. But there's certainly evidence that this is the
way they're suppo
On 14/12/17 21:53 +, Jonathan Wakely wrote:
I failed to notice that the man page for sendfile(3) says it won't
copy more than 2GiB. This refactors the code to first try sendfile
(because it's fast if it works) and if that fails, or stops before the
end of the file, then use filebufs to copy w
On Fri, 5 Jan 2018, Michael Meissner wrote:
> On Fri, Jan 05, 2018 at 05:28:03PM +, Joseph Myers wrote:
> > On Thu, 4 Jan 2018, Michael Meissner wrote:
> >
> > > (CVT_FLOAT128_TO_IBM128): Use TFtype instead of __float128 to
> > > accomidate -mabi=ieeelongdouble multilibs.
> >
> > Why is
The folding of comparisons against Inf (to constants or comparisons
with the maximum finite value) has various cases where it introduces
or loses "invalid" exceptions for comparisons with NaNs.
Folding x > +Inf to 0 should not be about HONOR_SNANS - ordered
comparisons of both quiet and signaling
[ was: Re: [RFC] Add vec::ordered_remove_if ]
On 01/02/2018 03:08 PM, Richard Biener wrote:
On Fri, Dec 29, 2017 at 2:55 PM, Tom de Vries wrote:
[ was: Re: [libgomp, openacc, openmp, PR83046] Prune removed funcs from
offload table ]
On 12/28/2017 05:06 PM, Jakub Jelinek wrote:
On Thu, Dec 2
This fixes the code that verifies that none of the uninitialized paths
reaching a PHI are actually taken (uninit_uses_cannot_happen).
As discussed in the PR, this is done by fixing the predicate analysis in
tree-ssa-uninit.c so that the set of predicates reaching the use of a
PHI take into the
On 12/29/2017 12:06 PM, David Malcolm wrote:
One issue I ran into was that fold_for_warn doesn't eliminate
location wrappers when processing_template_decl, leading to
failures of the template-based cases in
g++.dg/warn/Wmemset-transposed-args-1.C.
This is due to the early bailout when processing
On 12/22/2017 02:10 PM, David Malcolm wrote:
You describe the types needing to match "closely enough" (as opposed
to *exactly*), and that may be the key here: what I didn't say in my
message above is that the decl is "const" whereas the value isn't.
Right, differences in top-level qualifiers do
On Fri, Jan 05, 2018 at 08:22:57PM +0100, Jakub Jelinek wrote:
> On Fri, Jan 05, 2018 at 02:07:51PM -0500, Michael Meissner wrote:
> > Yes, in C code _Float128 _Comples works. The trouble is compiling
> > libstdc++-v3. In C++, we don't have _Float128, and __float128 _Complex does
> > not work for
On Thu, Jan 04, 2018 at 06:05:55PM -0500, Michael Meissner wrote:
> This patch is the beginning step to switching the PowerPC long double support
> from IBM extended double to IEEE 128-bit floating point on PowerPC servers.
> It
> will be necessary to have this patch or a similar patch to allow t
Hi Jeff
On 05/01/18 18:44, Jeff Law wrote:
On 01/04/2018 08:35 AM, Sudakshina Das wrote:
Hi
The bug reported a particular test di-longlong64-sync-1.c failing when
run on arm-linux-gnueabi with options -mthumb -march=armv5t -O[g,1,2,3]
and -mthumb -march=armv6 -O[g,1,2,3].
According to what I
On Fri, Jan 05, 2018 at 02:07:51PM -0500, Michael Meissner wrote:
> Yes, in C code _Float128 _Comples works. The trouble is compiling
> libstdc++-v3. In C++, we don't have _Float128, and __float128 _Complex does
> not work for either x86 or PowerPC. So on PowerPC the code from bits/floatn.h
> is
On Fri, Jan 05, 2018 at 05:47:39PM +, Joseph Myers wrote:
> On Fri, 5 Jan 2018, Jakub Jelinek wrote:
>
> > On Thu, Jan 04, 2018 at 06:05:55PM -0500, Michael Meissner wrote:
> > > This patch is the beginning step to switching the PowerPC long double
> > > support
> > > from IBM extended double
On Fri, Jan 05, 2018 at 06:33:50PM +0100, Jakub Jelinek wrote:
> On Thu, Jan 04, 2018 at 06:05:55PM -0500, Michael Meissner wrote:
> > This patch is the beginning step to switching the PowerPC long double
> > support
> > from IBM extended double to IEEE 128-bit floating point on PowerPC servers.
On Fri, Jan 05, 2018 at 05:28:03PM +, Joseph Myers wrote:
> On Thu, 4 Jan 2018, Michael Meissner wrote:
>
> > (CVT_FLOAT128_TO_IBM128): Use TFtype instead of __float128 to
> > accomidate -mabi=ieeelongdouble multilibs.
>
> Why is that correct in the -mabi=ibmlongdouble case?
The Powe
On 01/04/2018 08:35 AM, Sudakshina Das wrote:
> Hi
>
> The bug reported a particular test di-longlong64-sync-1.c failing when
> run on arm-linux-gnueabi with options -mthumb -march=armv5t -O[g,1,2,3]
> and -mthumb -march=armv6 -O[g,1,2,3].
>
> According to what I could see, the crash was caused b
On 01/04/2018 08:53 AM, Jakub Jelinek wrote:
On Thu, Jan 04, 2018 at 08:50:30AM -0700, Martin Sebor wrote:
On 01/04/2018 01:30 AM, Jakub Jelinek wrote:
On Wed, Jan 03, 2018 at 05:00:41PM -0700, Martin Sebor wrote:
This is an example where having a solution for bug 78014 would
be helpful. I.e.
On 05/01/18 10:37 +, Jonathan Wakely wrote:
On 04/01/18 21:02 -0500, Tim Song wrote:
What if the file to be removed is externally removed between the
symlink_status and the ::remove call? This is probably QoI because
filesystem race, but it seems reasonable to double check errno if
::remove
On Fri, 5 Jan 2018, David Malcolm wrote:
> Ping:
> https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01494.html
OK.
--
Joseph S. Myers
jos...@codesourcery.com
On Fri, 5 Jan 2018, Jakub Jelinek wrote:
> On Thu, Jan 04, 2018 at 06:05:55PM -0500, Michael Meissner wrote:
> > This patch is the beginning step to switching the PowerPC long double
> > support
> > from IBM extended double to IEEE 128-bit floating point on PowerPC servers.
> > It
> > will be n
Ping:
https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01494.html
(FWIW, the only other patch still needing review in the kit is:
"[v2 of PATCH 03/14] C++: add location_t wrapper nodes during parsing
(minimal impl)"
https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01594.html )
On Fri, 2017-1
On Thu, Jan 04, 2018 at 06:05:55PM -0500, Michael Meissner wrote:
> This patch is the beginning step to switching the PowerPC long double support
> from IBM extended double to IEEE 128-bit floating point on PowerPC servers.
> It
> will be necessary to have this patch or a similar patch to allow t
On Thu, 4 Jan 2018, Michael Meissner wrote:
> (CVT_FLOAT128_TO_IBM128): Use TFtype instead of __float128 to
> accomidate -mabi=ieeelongdouble multilibs.
Why is that correct in the -mabi=ibmlongdouble case?
As I understand it, TFtype is always of mode TFmode (it would certainly be
co
On 01/04/2018 11:20 AM, Joseph Myers wrote:
> On Thu, 4 Jan 2018, Richard Earnshaw wrote:
>
>> 1 - generic modifications to GCC providing the builtin function for all
>> architectures and expanding to an implementation that gives the
>> logical behaviour of the builtin only. A warning is
On 01/04/2018 06:58 AM, Richard Earnshaw wrote:
>
> Recently, Google Project Zero disclosed several classes of attack
> against speculative execution. One of these, known as variant-1
> (CVE-2017-5753), allows explicit bounds checks to be bypassed under
> speculation, providing an arbitrary read g
On 01/05/2018 03:47 AM, Richard Biener wrote:
> On Fri, Jan 5, 2018 at 11:40 AM, Richard Earnshaw (lists)
> wrote:
>> On 05/01/18 09:44, Richard Biener wrote:
>>> On Thu, Jan 4, 2018 at 2:58 PM, Richard Earnshaw
>>> wrote:
Recently, Google Project Zero disclosed several classes of attac
On 05/01/18 09:54 -0500, Ed Smith-Rowland wrote:
On 01/04/2018 03:54 PM, Michele Pezzutti wrote:
On 01/04/2018 06:16 PM, Ed Smith-Rowland wrote:
On 01/03/2018 02:49 PM, Michele Pezzutti wrote:
Hi.
On 01/02/2018 05:43 PM, Michele Pezzutti wrote:
On 01/02/2018 02:28 AM, Ed Smith-Rowland wr
On 01/05/2018 04:57 AM, Richard Earnshaw (lists) wrote:
> On 05/01/18 11:35, Jakub Jelinek wrote:
>> On Fri, Jan 05, 2018 at 10:59:21AM +, Richard Earnshaw (lists) wrote:
But the condition could be just 'true' in the instruction encoding? That
is,
why do you do both the jump-ar
On 01/05/2018 03:40 AM, Richard Earnshaw (lists) wrote:
> On 05/01/18 09:44, Richard Biener wrote:
>> On Thu, Jan 4, 2018 at 2:58 PM, Richard Earnshaw
>> wrote:
>>>
>>> Recently, Google Project Zero disclosed several classes of attack
>>> against speculative execution. One of these, known as varia
On 01/05/2018 02:44 AM, Richard Biener wrote:
> On Thu, Jan 4, 2018 at 2:58 PM, Richard Earnshaw
> wrote:
>>
>> Recently, Google Project Zero disclosed several classes of attack
>> against speculative execution. One of these, known as variant-1
>> (CVE-2017-5753), allows explicit bounds checks to
On 01/05/2018 03:48 AM, Richard Earnshaw (lists) wrote:
> On 05/01/18 09:51, Richard Biener wrote:
>> On Thu, Jan 4, 2018 at 2:58 PM, Richard Earnshaw
>> wrote:
>>>
>>> This patch implements support for __builtin_load_no_speculate on
>>> AArch64. On this architecture we inhibit speclation by emit
On 01/05/2018 01:06 AM, Sebastian Huber wrote:
> On 04/01/18 18:37, Jeff Law wrote:
>> On 01/04/2018 01:51 AM, Sebastian Huber wrote:
>>> gcc/
>>> config.gcc (epiphany-*-elf*): Add (epiphany-*-rtems*)
>>> configuration.
>>> config/epiphany/rtems.h: New file.
>>>
>>> libgcc/
>>> conf
Hello Jakub!
On 28 Dec 11:07, Jakub Jelinek wrote:
> Hi!
>
> Martin reported sse-13.c ICEs without all the options it has in dg-options.
> The problem is that the GFNI builtins used incorrect ISA masks and the
> headers too. GFNI has one SSE encoded instruction (but that really needs
> SSE2 rathe
Hello Jakub!
On 28 Dec 10:10, Jakub Jelinek wrote:
> Hi!
>
> These insns don't really need AVX512BW in any way themselves, only their
> masked variants might need it for reloading of the mask register, but that
> should be covered in builtins.def, doesn't need duplication in sse.md.
> For non-mask
On 01/04/2018 03:54 PM, Michele Pezzutti wrote:
On 01/04/2018 06:16 PM, Ed Smith-Rowland wrote:
On 01/03/2018 02:49 PM, Michele Pezzutti wrote:
Hi.
On 01/02/2018 05:43 PM, Michele Pezzutti wrote:
On 01/02/2018 02:28 AM, Ed Smith-Rowland wrote:
I like the patch.
I have a similar one in t
Hi Oleg,
Thank you very much for those suggestions, they are definitely the better way
to go.
>From my point of view I would like drop both patches(RX and RL78) however I
>contacted the AP4 tool team to see if they agree with this change and are
>willing to update their tool.
If not I will foll
On Fri, 5 Jan 2018, Richard Earnshaw (lists) wrote:
> This is quite tricky. For ARM we have to have a speculated load.
Sorry, I don't follow. On ARM, it is surprising that CSEL-CSDB-LDR sequence
wouldn't work (applying CSEL to the address rather than loaded value), and
if it wouldn't, then ARM-sp
On Fri, 2018-01-05 at 12:12 +, Sebastian Perta wrote:
>
> > >
> > > Is this for some kind of legacy backwards compatibility of
> > > something?
> Sort of, this is required by the following tool
> https://www.renesas.com/en-eu/products/software-tools/tools/code-
> generator/ap4-application-le
Andrew Pinski wrote:
> Seems like you should do something similar to the integer madd/msub
> instructions too (aarch64_mla is already correct but aarch64_mla_elt
> needs this too).
Integer madd/msub may benefit too, however it wouldn't make a difference
for a 3-operand mla since the register allo
The shrinkwrap optimization added late in GCC 7 allows each callee-save to
be delayed and done only across blocks which need a particular callee-save.
Although this reduces unnecessary memory traffic on code paths that need
few callee-saves, it typically uses LDR/STR rather than LDP/STP. The
numbe
Hi,
Thank you for your comment.
>>Is this for some kind of legacy backwards compatibility of something?
Sort of, this is required by the following tool
https://www.renesas.com/en-eu/products/software-tools/tools/code-generator/ap4-application-leading-tool-applilet.html
There are not many plans to
Hi,
On Fri, 2018-01-05 at 11:03 +, Sebastian Perta wrote:
>
> Hello,
>
> The following patch adds a new pragma, "pragma address" for RX.
> The patch updates extend.texi and add a test case to the regression
> as well.
> For the test case I checked than test is getting picked up in gcc.log
>
On 05/01/18 11:35, Jakub Jelinek wrote:
> On Fri, Jan 05, 2018 at 10:59:21AM +, Richard Earnshaw (lists) wrote:
>>> But the condition could be just 'true' in the instruction encoding? That
>>> is,
>>> why do you do both the jump-around and the csel? Maybe I misunderstood
>>> the RTL you appe
On 05/01/18 11:37, Alexander Monakov wrote:
> I believe the proposed behavior of the new builtin is over-specialized.
> In principle the following snippet may be open to exploitation too:
>
> if (predicate)
> foo = arr[(secret >> untrusted) & 64];
>
> assuming the attacker has a means to ob
PING
On 15/12/17 11:57, Sudakshina Das wrote:
Hi
This patch fixes the inconsistent behavior observed at -O3 for the
unordered comparisons. According to the online docs
(https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gccint/Unary-and-Binary-Expressions.html),
all of the following should not raise a
Here's the patch updated to apply on top of the v8.4 and
__builtin_load_no_speculate support. It also handles the new
vec_perm_indices and CONST_VECTOR encoding and uses VNx... names
for the SVE modes.
Richard Sandiford writes:
> This patch adds support for ARM's Scalable Vector Extension.
> The
On Fri, Jan 5, 2018 at 12:02 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Mon, Nov 6, 2017 at 9:12 PM, Richard Sandiford
>> wrote:
>>> initialize_matrix_A requires the CHREC_RIGHT to be an INTEGER_CST:
>>>
>>> switch (TREE_CODE (chrec))
>>> {
>>> case POLYNOMIAL_CHREC:
>
I believe the proposed behavior of the new builtin is over-specialized.
In principle the following snippet may be open to exploitation too:
if (predicate)
foo = arr[(secret >> untrusted) & 64];
assuming the attacker has a means to observe which part of 'arr' is brought into
cache, but canno
On Fri, Jan 05, 2018 at 10:59:21AM +, Richard Earnshaw (lists) wrote:
> > But the condition could be just 'true' in the instruction encoding? That
> > is,
> > why do you do both the jump-around and the csel? Maybe I misunderstood
> > the RTL you appear to generate. I'd have expected an UNSP
Ping. Here's the patch updated to apply on top of the v8.4 and
__builtin_load_no_speculate support.
Richard Sandiford writes:
> This patch switches the AArch64 port to use 2 poly_int coefficients
> and updates code as necessary to keep it compiling.
>
> One potentially-significant change is to
>
Sorry the spaces got removed from previous email.
-Original Message-
From: Sebastian Perta
Sent: 05 January 2018 10:59
To: 'gcc-patches@gcc.gnu.org'
Subject: [PATCH] RX pragma address
Hello,
The following patch adds a new pragma, "pragma address" for RX.
The patch updates extend.texi
Hi Kyrill
On 04/01/18 16:36, Kyrill Tkachov wrote:
Hi Sudi,
On 04/01/18 15:35, Sudakshina Das wrote:
Hi
The bug reported a particular test di-longlong64-sync-1.c failing when
run on arm-linux-gnueabi with options -mthumb -march=armv5t -O[g,1,2,3]
and -mthumb -march=armv6 -O[g,1,2,3].
Accordi
Richard Biener writes:
> On Mon, Nov 6, 2017 at 9:12 PM, Richard Sandiford
> wrote:
>> initialize_matrix_A requires the CHREC_RIGHT to be an INTEGER_CST:
>>
>> switch (TREE_CODE (chrec))
>> {
>> case POLYNOMIAL_CHREC:
>> A[index][0] = mult * int_cst_value (CHREC_RIGHT (chrec));
>>
On 05/01/18 10:47, Richard Biener wrote:
> On Fri, Jan 5, 2018 at 11:40 AM, Richard Earnshaw (lists)
> wrote:
>> On 05/01/18 09:44, Richard Biener wrote:
>>> On Thu, Jan 4, 2018 at 2:58 PM, Richard Earnshaw
>>> wrote:
Recently, Google Project Zero disclosed several classes of attack
>>>
Hello,
The following patch adds a new pragma, "pragma address" for RX.
The patch updates extend.texi and add a test case to the regression as well.
For the test case I checked than test is getting picked up in gcc.log
unfortunately for the .texi part I don't know where to look/what to do to get
t
On 05/01/18 09:51, Richard Biener wrote:
> On Thu, Jan 4, 2018 at 2:58 PM, Richard Earnshaw
> wrote:
>>
>> This patch implements support for __builtin_load_no_speculate on
>> AArch64. On this architecture we inhibit speclation by emitting a
>> combination of CSEL and a hint instruction that ensur
Hi Jeff
On 04/01/18 18:30, Jeff Law wrote:
On 01/03/2018 06:57 AM, Sudakshina Das wrote:
Hi
This patch add support for the missing transformation of (x | y) == x ->
(y & ~x) == 0.
The transformation for (x & y) == x case already exists in
simplify-rtx.c since 2014 as of r218503 and this patch
On Fri, Jan 5, 2018 at 11:40 AM, Richard Earnshaw (lists)
wrote:
> On 05/01/18 09:44, Richard Biener wrote:
>> On Thu, Jan 4, 2018 at 2:58 PM, Richard Earnshaw
>> wrote:
>>>
>>> Recently, Google Project Zero disclosed several classes of attack
>>> against speculative execution. One of these, know
On 05/01/18 09:44, Richard Biener wrote:
> On Thu, Jan 4, 2018 at 2:58 PM, Richard Earnshaw
> wrote:
>>
>> Recently, Google Project Zero disclosed several classes of attack
>> against speculative execution. One of these, known as variant-1
>> (CVE-2017-5753), allows explicit bounds checks to be by
On 04/01/18 21:02 -0500, Tim Song wrote:
What if the file to be removed is externally removed between the
symlink_status and the ::remove call? This is probably QoI because
filesystem race, but it seems reasonable to double check errno if
::remove fails and not fail if the failure is due to the f
On Fri, Jan 05, 2018 at 10:25:35AM +, Richard Sandiford wrote:
> Jakub Jelinek writes:
> > On Fri, Jan 05, 2018 at 09:49:56AM +, Richard Sandiford wrote:
> >> Is the patch OK as a compromise for GCC 8? We don't speculatively
> >> increase the user alignment in increase_alignment, but do s
Jakub Jelinek writes:
> On Fri, Jan 05, 2018 at 09:49:56AM +, Richard Sandiford wrote:
>> Is the patch OK as a compromise for GCC 8? We don't speculatively
>> increase the user alignment in increase_alignment, but do still increase
>> it if it helps to vectorise a particular loop access?
>
>
On Fri, Jan 05, 2018 at 09:49:56AM +, Richard Sandiford wrote:
> Is the patch OK as a compromise for GCC 8? We don't speculatively
> increase the user alignment in increase_alignment, but do still increase
> it if it helps to vectorise a particular loop access?
I'd be a little bit worried abo
On Thu, Jan 4, 2018 at 2:58 PM, Richard Earnshaw
wrote:
>
> This patch implements support for __builtin_load_no_speculate on
> AArch64. On this architecture we inhibit speclation by emitting a
> combination of CSEL and a hint instruction that ensures the CSEL is
> full resolved when the operands
Richard Biener writes:
> On Fri, Jan 5, 2018 at 9:47 AM, Richard Biener
> wrote:
>> On Wed, Jan 3, 2018 at 4:06 PM, Richard Sandiford
>> wrote:
>>> r241959 included code to stop us increasing the alignment of a
>>> "user-aligned" variable. This wasn't the main purpose of the patch,
>>> and I th
On Thu, Jan 4, 2018 at 2:58 PM, Richard Earnshaw
wrote:
>
> Recently, Google Project Zero disclosed several classes of attack
> against speculative execution. One of these, known as variant-1
> (CVE-2017-5753), allows explicit bounds checks to be bypassed under
> speculation, providing an arbitrar
On Thu, Jan 4, 2018 at 10:52 PM, David Malcolm wrote:
> PR lto/83121 reports an ICE deep inside the linemap code when -Wodr
> reports on a type mismatch.
>
> The root cause is that the warning can access the DECL_SOURCE_LOCATION
> of a streamed-in decl before the lto_location_cache has been applie
On Thu, Jan 4, 2018 at 10:27 PM, Marc Glisse wrote:
> (just a log of my thoughts while reading the patch)
>
> On Thu, 4 Jan 2018, Wilco Dijkstra wrote:
>
>> Richard Biener wrote:
>>>
>>> On Tue, Oct 17, 2017 at 6:28 PM, Wilco Dijkstra
>>> wrote:
>>
>>
+(if (flag_unsafe_math_optimizations)
>>
On Tue, 28 Nov 2017, Richard Biener wrote:
>
> The following adds a new target hook, targetm.vectorize.split_reduction,
> which allows the target to specify a preferred mode to perform the
> final reducion on using either vector shifts or scalar extractions.
> Up to that mode the vector reduction
On Thu, Jan 4, 2018 at 11:06 AM, Richard Sandiford
wrote:
> The first BIT_FIELD_REF folding pattern assumed without checking that
> operands satisfy tree_fits_uhwi_p. The second pattern does check this:
>
> /* On constants we can use native encode/interpret to constant
> fold (near
On Thu, Jan 4, 2018 at 6:46 PM, Jeff Law wrote:
> On 01/04/2018 03:02 AM, Richard Sandiford wrote:
>> tree-ssa-forwprop.c was asserting that a VEC_PERM_EXPR fold on three
>> VECTOR_CSTs would always succeed, but it's possible for it to fail
>> with variable-length vectors.
>>
>> Tested on aarch64-
On Wed, Jan 3, 2018 at 5:31 PM, Marek Polacek wrote:
> Here we are crashing because cxx_fold_indirect_ref got a POINTER_PLUS_EXPR
> with offset > signed HOST_WIDE_INT and we tried to convert it to sHWI.
>
> The matching code in fold_indirect_ref_1 uses uHWIs so I've followed suit.
> But that code
On Fri, Jan 5, 2018 at 9:47 AM, Richard Biener
wrote:
> On Wed, Jan 3, 2018 at 4:06 PM, Richard Sandiford
> wrote:
>> r241959 included code to stop us increasing the alignment of a
>> "user-aligned" variable. This wasn't the main purpose of the patch,
>> and I think it was just there to make the
On Wed, Jan 3, 2018 at 4:06 PM, Richard Sandiford
wrote:
> r241959 included code to stop us increasing the alignment of a
> "user-aligned" variable. This wasn't the main purpose of the patch,
> and I think it was just there to make the testcase work.
>
> The documentation for the aligned attribut
On Thu, 4 Jan 2018, Jakub Jelinek wrote:
> Hi!
>
> While the testcase could be perhaps handled with some extra effort (the
> issue there is just CSE of an early possibly throwing trapping addition,
> so maybe_cleanup_or_replace_eh_stmt + gimple_purge_dead_eh_edges +
> TODO_cleanup_cfg might do th
On 04/01/18 18:37, Jeff Law wrote:
On 01/04/2018 01:51 AM, Sebastian Huber wrote:
gcc/
config.gcc (epiphany-*-elf*): Add (epiphany-*-rtems*)
configuration.
config/epiphany/rtems.h: New file.
libgcc/
config.host (epiphany-*-elf*): Add (epiphany-*-rtems*)
c
95 matches
Mail list logo
