Jeff Law writes:
> On 01/09/2018 11:39 AM, Richard Sandiford wrote:
>> This patch generalises various places that used hwi tree accessors
>> so that they can handle poly_ints instead. Earlier patches did
>> this while updating interfaces; this patch just mops up some
>> left-over pieces that were
This is my current multilib version support for migrating PowerPC servers from
using IBM extended double as the long double type to IEEE 128-bit floating
point.
I have built both little endian and big endian PowerPC toolchains without the
options, and it works with no regressions. I have also bui
On 12 January 2018 at 06:15, Martin Sebor wrote:
> On 01/11/2018 02:48 PM, Rainer Orth wrote:
>>
>> Hi Martin,
>>
I am not sure why constant string is not emitted for arm-linux-gnueabihf
?
As far as this issue is concerned, should I simply XFAIL it on arm for
now ?
>>>
>>>
>>>
On 12 January 2018 at 05:02, Jeff Law wrote:
> On 01/10/2018 10:04 PM, Prathamesh Kulkarni wrote:
>> On 11 January 2018 at 04:50, Jeff Law wrote:
>>> On 01/09/2018 05:57 AM, Prathamesh Kulkarni wrote:
As Jakub pointed out for the case:
void *f()
{
return __builtin_mallo
On 01/11/2018 02:48 PM, Rainer Orth wrote:
Hi Martin,
I am not sure why constant string is not emitted for arm-linux-gnueabihf ?
As far as this issue is concerned, should I simply XFAIL it on arm for now ?
This is not unique to the arm back end but affects other targets
as well, including pow
On 01/11/2018 04:40 PM, Joseph Myers wrote:
> On Thu, 11 Jan 2018, Jeff Law wrote:
>
>>> Well, given retpolines are largely kernel relevant right now we don't
>>> need to care here.
>> That's still TBD as far as I can tell. I certainly hope we don't have
>> to go retpolines in user space, at leas
On 01/11/2018 04:24 PM, Jeff Law wrote:
On 01/10/2018 01:26 PM, Martin Sebor wrote:
To avoid issuing duplicate warnings for the same function call
in the source code the -Wrestrict warning code makes sure
the no-warning bit is propagated between trees and GIMPLE and
tested before issuing a warni
This is a patch for PR target/79924, which says the error messages
called from aarch64_err_no_fpadvsimd cannot be translated due to
how they are constructed. To make them translatable and not change
the actual messages would have required creating 16 individual messages
which seemed a bit excessiv
On Thu, 11 Jan 2018, Jeff Law wrote:
> > Well, given retpolines are largely kernel relevant right now we don't
> > need to care here.
> That's still TBD as far as I can tell. I certainly hope we don't have
> to go retpolines in user space, at least not in the general case. I'm
> holding out hope
On 01/11/2018 01:27 AM, Richard Biener wrote:
> On Thu, 11 Jan 2018, Marc Glisse wrote:
>
>> On Tue, 9 Jan 2018, Prathamesh Kulkarni wrote:
>>
>>> As Jakub pointed out for the case:
>>> void *f()
>>> {
>>> return __builtin_malloc (0);
>>> }
>>>
>>> The malloc propagation would set f() to malloc.
On 01/10/2018 10:04 PM, Prathamesh Kulkarni wrote:
> On 11 January 2018 at 04:50, Jeff Law wrote:
>> On 01/09/2018 05:57 AM, Prathamesh Kulkarni wrote:
>>>
>>> As Jakub pointed out for the case:
>>> void *f()
>>> {
>>> return __builtin_malloc (0);
>>> }
>>>
>>> The malloc propagation would set f
On 01/09/2018 11:39 AM, Richard Sandiford wrote:
> This patch generalises various places that used hwi tree accessors
> so that they can handle poly_ints instead. Earlier patches did
> this while updating interfaces; this patch just mops up some
> left-over pieces that weren't necessary to make th
On 01/10/2018 01:26 PM, Martin Sebor wrote:
> To avoid issuing duplicate warnings for the same function call
> in the source code the -Wrestrict warning code makes sure
> the no-warning bit is propagated between trees and GIMPLE and
> tested before issuing a warning. But the warning also detects
>
PR c++/83799 reports a failure building LLVM due to a bogus
"no matching function for call to" error at a callsite like this:
TLI->getTypeLegalizationCost(DL);
where "DL" is from:
using TargetTransformInfoImplBase::DL;
The root cause is that type_dependent_expression_p on a USING_DECL
should r
On 01/07/2018 03:59 PM, H.J. Lu wrote:
> Add 'V', a special modifier which prints the name of the full integer
> register without '%'. For
>
> extern void (*func_p) (void);
>
> void
> foo (void)
> {
> asm ("call __x86_indirect_thunk_%V0" : : "a" (func_p));
> }
>
> it generates:
>
> foo:
>
On 01/07/2018 03:59 PM, H.J. Lu wrote:
> Add -mindirect-branch-register to force indirect branch via register.
> This is implemented by disabling patterns of indirect branch via memory,
> similar to TARGET_X32.
>
> -mindirect-branch= and -mfunction-return= tests are updated with
> -mno-indirect-br
On Thu, Jan 11, 2018 at 03:46:51PM -0700, Jeff Law wrote:
> Note I'm expecting Uros to chime in. So please do not consider this
> ack'd until you hear from Uros.
>
> At a high level is there really that much value in having thunks in the
> object file? Why not put the full set of thunks into lib
On Thu, Jan 11, 2018 at 2:54 PM, Jeff Law wrote:
> On 01/07/2018 03:59 PM, H.J. Lu wrote:
>> Add -mfunction-return= option to convert function return to call and
>> return thunks. The default is 'keep', which keeps function return
>> unmodified. 'thunk' converts function return to call and retur
On Thu, Jan 11, 2018 at 2:46 PM, Jeff Law wrote:
> On 01/07/2018 03:59 PM, H.J. Lu wrote:
>> Add -mindirect-branch= option to convert indirect call and jump to call
>> and return thunks. The default is 'keep', which keeps indirect call and
>> jump unmodified. 'thunk' converts indirect call and j
On 01/07/2018 03:59 PM, H.J. Lu wrote:
> Add -mfunction-return= option to convert function return to call and
> return thunks. The default is 'keep', which keeps function return
> unmodified. 'thunk' converts function return to call and return thunk.
> 'thunk-inline' converts function return to i
On 01/07/2018 03:59 PM, H.J. Lu wrote:
> Add -mindirect-branch= option to convert indirect call and jump to call
> and return thunks. The default is 'keep', which keeps indirect call and
> jump unmodified. 'thunk' converts indirect call and jump to call and
> return thunk. 'thunk-inline' convert
On Wed, Jan 10, 2018 at 11:48:30PM +, Joseph Myers wrote:
> On Wed, 10 Jan 2018, Michael Meissner wrote:
>
> > This patch is next in my series of patches to enable us to configure the
> > long
> > double type on PowerPC systems. This patch is only about the configuration
> > option. A futur
Hi Jonathan,
Thanks for looking into this! It’s unfortunate that we can't know if the
pointer in the iterator is legal to dereference. Nevertheless, inspecting
smart pointers is a far more common use case, it's good that it has finally
been sorted out.
Thanks, Juraj
On Tue, 9 Jan 2018 at 23:10,
On 01/11/2018 01:32 PM, Jan Hubicka wrote:
As long as the marked definition still satisfies the assumptions
GCC makes about the function it won't be harmful. I don't know
all the nuances of pointer aliasing in GCC that might rely on it
but assuming they faithfully reflect the standard requireme
Hi,
On 11/01/2018 21:33, Jason Merrill wrote:
On 01/10/2018 06:50 PM, Paolo Carlini wrote:
thus the below is a rather "dull" solution at the level of
cplus_decl_attributes itself: cp_check_const_attributes is tweaked to
check for error_mark_node at each outer iteration
This shouldn't be nece
Uros Bizjak writes:
> Hello!
>
> Current gcc fails bootstrap on alpha-linux-gnu with:
>
> /space/homedirs/uros/gcc-svn/trunk/gcc/hsa-dump.c: In function ‘void
> dump_hsa_symbol(FILE*, hsa_symbol*)’:
> /space/homedirs/uros/gcc-svn/trunk/gcc/hsa-dump.c:784:21: error: ‘%s’
> directive writing up to 7
Hi Martin,
>> I am not sure why constant string is not emitted for arm-linux-gnueabihf ?
>> As far as this issue is concerned, should I simply XFAIL it on arm for now ?
>
> This is not unique to the arm back end but affects other targets
> as well, including powerpc64. There's a bug open (PR 8346
On Thu, Jan 11, 2018 at 1:42 PM, Jeff Law wrote:
> On 01/07/2018 03:59 PM, H.J. Lu wrote:
>> Add -mindirect-branch-loop= option to control loop filler in call and
>> return thunks generated by -mindirect-branch=. 'lfence' uses "lfence"
>> as loop filler. 'pause' uses "pause" as loop filler. 'no
On 01/07/2018 03:59 PM, H.J. Lu wrote:
> Add -mindirect-branch-loop= option to control loop filler in call and
> return thunks generated by -mindirect-branch=. 'lfence' uses "lfence"
> as loop filler. 'pause' uses "pause" as loop filler. 'nop' uses "nop"
> as loop filler. The default is 'lfence
On Thu, 2018-01-11 at 22:17 +0100, Florian Weimer wrote:
> * David Woodhouse:
>
> >
> > On Sun, 2018-01-07 at 16:36 -0700, Jeff Law wrote:
> > >
> > >
> > > My fundamental problem with this patchkit is that it is 100% x86/x86_64
> > > specific.
> > >
> > > ISTM we want a target independent mec
On Thu, Jan 11, 2018 at 03:35:37PM +, Wilco Dijkstra wrote:
> Segher Boessenkool wrote:
>
> > Of course I see that ldp is useful. I don't think that this particular
> > way of forcing more pairs is a good idea. Needs testing / benchmarking /
> > instrumentation, and we haven't seen any of
On Thu, Jan 11, 2018 at 11:07 AM, Uros Bizjak wrote:
> On Wed, Jan 10, 2018 at 9:40 PM, H.J. Lu wrote:
>> When a function call is removed, it may become a leaf function. But if
>> argument may be passed on stack, we need to align the stack frame when
>> there is no tail call.
>>
>> Tested on Lin
* David Woodhouse:
> On Sun, 2018-01-07 at 16:36 -0700, Jeff Law wrote:
>>
>> My fundamental problem with this patchkit is that it is 100% x86/x86_64
>> specific.
>>
>> ISTM we want a target independent mechanism (ie, new standard patterns,
>> options, etc) then an x86/x86_64 implementation usin
On 01/11/2018 02:20 PM, Joseph Myers wrote:
On Thu, 11 Jan 2018, Bill Seurer wrote:
PR sanitizer/65479
Wrong bug number.
+/* { dg-skip-if "remove this when pr58684 is fixed" { powerpc64*-*-* } } */
As previously noted, testing powerpc64 like that in tests is always wrong
(because
On 01/09/2018 11:28 AM, Richard Biener wrote:
Note that the vectorizer gives up on loops with gathers with no target
support for
gathers. It could simply open-code the gather though (and properly cost that
open-coded variant), that's probably the way to go here.
Man, I wish I had made this co
On 01/11/2018 01:17 PM, Joseph Myers wrote:
Code intended to work as both C and C++ may well use () for no arguments.
Maybe what's enabled by -Wextra should be a subset of the warning that
allows function definitions with ()? Especially since if C does remove
unprototyped functions at some point
On 01/10/2018 06:50 PM, Paolo Carlini wrote:
thus the below is a rather "dull" solution at the level of
cplus_decl_attributes itself: cp_check_const_attributes is tweaked to
check for error_mark_node at each outer iteration
This shouldn't be necessary; we should have returned error_mark_node f
On Thu, Jan 11, 2018 at 7:59 PM, Jakub Jelinek wrote:
> Hi!
>
> This patch improves insertion of a single scalar into the first element
> of otherwise empty vector for 256-bit and 512-bit vectors.
> As 128-bit vmovd/vmovq/vmovss/vinsertps all clear all the upper bits
> of the target, there is no n
>
> As long as the marked definition still satisfies the assumptions
> GCC makes about the function it won't be harmful. I don't know
> all the nuances of pointer aliasing in GCC that might rely on it
> but assuming they faithfully reflect the standard requirements
> it will be safe.
>
> The oth
On 01/11/2018 03:16 AM, Richard Biener wrote:
> On Thu, Jan 11, 2018 at 1:18 AM, Jeff Law wrote:
>> On 01/10/2018 06:14 AM, Jakub Jelinek wrote:
>>> On Wed, Jan 10, 2018 at 02:08:48PM +0100, Richard Biener wrote:
On Wed, Jan 10, 2018 at 11:18 AM, Eric Botcazou
wrote:
>> It's really
On 01/11/2018 03:04 AM, Alan Modra wrote:
> On Wed, Jan 10, 2018 at 05:13:36PM -0700, Jeff Law wrote:
>> On 01/08/2018 07:23 AM, Alan Modra wrote:
>>> On Sun, Jan 07, 2018 at 04:36:20PM -0700, Jeff Law wrote:
On 01/07/2018 03:58 PM, H.J. Lu wrote:
> This set of patches for GCC 8 mitigates
On 01/11/2018 12:10 PM, Jakub Jelinek wrote:
On Thu, Jan 11, 2018 at 11:41:19AM -0700, Martin Sebor wrote:
Declaring a function without a prototype has been deprecated
for nearly two decades (since C99) and may be removed from
the C language in C2X. To prompt programs to transition to
the more
On Thu, 11 Jan 2018, Bill Seurer wrote:
> PR sanitizer/65479
Wrong bug number.
> +/* { dg-skip-if "remove this when pr58684 is fixed" { powerpc64*-*-* } } */
As previously noted, testing powerpc64 like that in tests is always wrong
(because you can have 64-bit multilibs with a compiler d
Hi Steve,
It seems that one of the recent DTIO commits have fixed
the issues raised in PR Fortran/79383. I have converted
the submitted code into two testcases.
2018-01-11 Steven G. Kargl
PR fortran/79383
* gfortran.dg/dtio_31.f03: New test.
* gfortran.dg/dtio_32.f03
Code intended to work as both C and C++ may well use () for no arguments.
Maybe what's enabled by -Wextra should be a subset of the warning that
allows function definitions with ()? Especially since if C does remove
unprototyped functions at some point (and as I recall, people were happy
with
It seems that one of the recent DTIO commits have fixed
the issues raised in PR Fortran/79383. I have converted
the submitted code into two testcases.
2018-01-11 Steven G. Kargl
PR fortran/79383
* gfortran.dg/dtio_31.f03: New test.
* gfortran.dg/dtio_32.f03: New test.
On 01/11/2018 12:22 PM, Jeff Law wrote:
On 01/11/2018 11:56 AM, Martin Sebor wrote:
On 01/10/2018 04:20 PM, Jeff Law wrote:
On 01/09/2018 05:57 AM, Prathamesh Kulkarni wrote:
As Jakub pointed out for the case:
void *f()
{
return __builtin_malloc (0);
}
The malloc propagation would set f()
This libgo patch avoids an endless loop in a cgo test if we can parse
the notes. Thanks to Richi for identifying the problem. This may be
the cause of GCC PR 83794. Bootstrapped and ran cgo tests on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
... today I played a bit with the other idea inspired by your feedback.
Irrespective of the special issue at hand, it seems in principle
interesting to me that when we are sure that we aren't parsing
tentatively anymore we can do something more radical for the sake of
better error recovery. Any
Hi DJ,
I managed to reproduce the issue, it is in function test_7, sorry I'm not
sure how I missed it I always compare the logs carefully with and without
the patch.
After investigating this I found the problem is caused by a removal of 1
instruction due to wrong UNUSED note being
added(rl78_calc
[PATCH, rs6000] pr58684, pr83759 Disable test cases that fail on powerpc64.
This patch disables a few test cases on powerpc64 that fail after r256380
due to a longstanding issue with floating-point compares.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58684 for more information.
Bootstrappe
On Wed, Jan 10, 2018 at 11:48:30PM +, Joseph Myers wrote:
> On Wed, 10 Jan 2018, Michael Meissner wrote:
>
> > This patch is next in my series of patches to enable us to configure the
> > long
> > double type on PowerPC systems. This patch is only about the configuration
> > option. A futur
On 01/11/2018 11:56 AM, Martin Sebor wrote:
> On 01/10/2018 04:20 PM, Jeff Law wrote:
>> On 01/09/2018 05:57 AM, Prathamesh Kulkarni wrote:
>>>
>>> As Jakub pointed out for the case:
>>> void *f()
>>> {
>>> return __builtin_malloc (0);
>>> }
>>>
>>> The malloc propagation would set f() to malloc.
Hello!
Current gcc fails bootstrap on alpha-linux-gnu with:
/space/homedirs/uros/gcc-svn/trunk/gcc/hsa-dump.c: In function ‘void
dump_hsa_symbol(FILE*, hsa_symbol*)’:
/space/homedirs/uros/gcc-svn/trunk/gcc/hsa-dump.c:784:21: error: ‘%s’
directive writing up to 71 bytes into a region of size 62
[-
On 01/11/2018 12:10 PM, Jakub Jelinek wrote:
> On Thu, Jan 11, 2018 at 11:41:19AM -0700, Martin Sebor wrote:
>> Declaring a function without a prototype has been deprecated
>> for nearly two decades (since C99) and may be removed from
>> the C language in C2X. To prompt programs to transition to
>
On 01/11/2018 11:32 AM, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in this PR, we have effectively:
> (set (reg2) (expression))
> ...
> (set (reg1) (reg2))
> ...
> (set (reg2) (any_extend (reg1)))
> in pr50083.c with -O2 -m32, where the
On Thu, Jan 11, 2018 at 11:41:19AM -0700, Martin Sebor wrote:
> Declaring a function without a prototype has been deprecated
> for nearly two decades (since C99) and may be removed from
> the C language in C2X. To prompt programs to transition to
> the more modern and safer style, PR 82922 request
On Wed, Jan 10, 2018 at 9:40 PM, H.J. Lu wrote:
> When a function call is removed, it may become a leaf function. But if
> argument may be passed on stack, we need to align the stack frame when
> there is no tail call.
>
> Tested on Linux/i686 and Linux/x86-64.
>
> OK for trunk?
>
> H.J.
> ---
>
On Wed, Jan 10, 2018 at 11:59 AM, Jason Merrill wrote:
> On Wed, Jan 10, 2018 at 11:56 AM, Jakub Jelinek wrote:
>> On Wed, Jan 10, 2018 at 11:52:16AM -0500, Jason Merrill wrote:
>>> On Fri, Jan 5, 2018 at 5:14 PM, Jakub Jelinek wrote:
>>> > Jason's recent change removed a mark_rvalue_use call fr
Hi!
This patch improves insertion of a single scalar into the first element
of otherwise empty vector for 256-bit and 512-bit vectors.
As 128-bit vmovd/vmovq/vmovss/vinsertps all clear all the upper bits
of the target, there is no need to do anything but these instructions
(or, when tuning for amd
On 01/10/2018 04:20 PM, Jeff Law wrote:
On 01/09/2018 05:57 AM, Prathamesh Kulkarni wrote:
As Jakub pointed out for the case:
void *f()
{
return __builtin_malloc (0);
}
The malloc propagation would set f() to malloc.
However AFAIU, malloc(0) returns NULL (?) and the function shouldn't
be mar
The instructions on https://gcc.gnu.org/contribute.html#testing for
bootstrapping GCC are incorrect.
The instructions say to run 'make bootstrap' from the top level GCC
directory,
but this results in the below error.
$ make bootstrap
make: *** No rule to make target 'bootstrap'. Stop.
The instruc
Declaring a function without a prototype has been deprecated
for nearly two decades (since C99) and may be removed from
the C language in C2X. To prompt programs to transition to
the more modern and safer style, PR 82922 requests to enable
Wstrict-prototypes in -Wextra.
With the recent changes t
Hi Mike,
On Wed, Jan 10, 2018 at 04:53:57PM -0500, Michael Meissner wrote:
> This patch is next in my series of patches to enable us to configure the long
> double type on PowerPC systems. This patch is only about the configuration
> option. A future patch will contain the multilib support.
>
>
Hi!
As mentioned in this PR, we have effectively:
(set (reg2) (expression))
...
(set (reg1) (reg2))
...
(set (reg2) (any_extend (reg1)))
in pr50083.c with -O2 -m32, where the expression in this case is actually
a QImode memory read has an
Hi!
My recent C FE lval folding improvements apparently broke OpenMP/OpenACC
handling of constant size VLAs, e.g.
const int size = 4096;
int array[size];
The problem is that the OpenMP/ACC gimplification/lowering/expansion relies
on TREE_CODE (DECL_SIZE_UNIT ()) != INTEGER_CST, or !TREE_CONSTA
In working on the transition of PowerPC long double from using the IBM extended
double format to IEEE 128-bit floating point, I noticed that the long double
.gnu_attribute (#4) was not set if the compiler can handle long double directly
without doing the call to an emulator, such as using IEEE 128-
Hi Oleg,
> gcc/ChangeLog:
> PR target/81819
> * config/rx/rx.c (rx_is_restricted_memory_address):
> Handle SUBREG case.
Go ahead make my day^H^H^H^H^H^H
Approved - please apply.
Cheers
Nick
On Thu, Jan 11, 2018 at 05:20:35PM +, Paul Richard Thomas wrote:
> Ping!
>
OK
--
Steve
Ping!
On 8 January 2018 at 14:36, Paul Richard Thomas
wrote:
> I post this patch early last year and did not submit because I was up
> to my eyeballs with PR34640. I just forgot about it until it came up
> on clf a few days ago.
>
> Bootstraps and regtests on FC23/x86_64 - OK for trunk?
>
> Paul
On Jan 11, 2018, at 11:16 AM, Richard Biener wrote:
>
> On January 11, 2018 6:14:34 PM GMT+01:00, Segher Boessenkool
> wrote:
>> On Thu, Jan 11, 2018 at 10:25:25AM -0600, Bill Schmidt wrote:
>>> This patch adds a pattern for "ori 31,31,0" as a speculation barrier,
>> and
>>> an associated built
On January 11, 2018 6:14:34 PM GMT+01:00, Segher Boessenkool
wrote:
>On Thu, Jan 11, 2018 at 10:25:25AM -0600, Bill Schmidt wrote:
>> This patch adds a pattern for "ori 31,31,0" as a speculation barrier,
>and
>> an associated built-in function. This is currently restricted to
>Power7
>> and late
On Thu, Jan 11, 2018 at 10:25:25AM -0600, Bill Schmidt wrote:
> This patch adds a pattern for "ori 31,31,0" as a speculation barrier, and
> an associated built-in function. This is currently restricted to Power7
> and later. Documentation and test included.
>
> Bootstrapped and tested on powerpc
Hi,
Thanks again to everyone who's reviewed the large number of SVE-related
patches. I just wanted to list in one place the patches that haven't
yet been approved:
* Use poly_int rtx accessors instead of hwi accessors
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00661.html
* Use poly_int tree
Hi Ian,
>> This patch updates libgo to the Go1.10beta1 release. The final Go
>> 1.10 release is expected around February 1, so it's not clear how the
>> release timing is going to work with GCC 8. In any case this updates
>> GCC to something pretty close to the final Go 1.10 release.
>>
>> A few
I noticed this enum, it must have been dead for a long while!
nathan
--
Nathan Sidwell
2018-01-11 Nathan Sidwell
* method.c (enum mangling_flags): Delete long-dead enum.
Index: method.c
===
--- method.c (revision 256541)
+++ me
On 01/11/2018 05:02 AM, Prathamesh Kulkarni wrote:
On 11 January 2018 at 16:14, Prathamesh Kulkarni
wrote:
On 11 January 2018 at 14:52, Christophe Lyon wrote:
Hi
On 10 January 2018 at 19:42, Prathamesh Kulkarni
wrote:
Hi,
I have attached patch for PR81703 rebased on Martin's fix for PR8350
On 11 January 2018 at 17:29, Kyrill Tkachov
wrote:
> Hi Christophe,
>
> On 11/01/18 16:21, Christophe Lyon wrote:
>>
>> On 11 January 2018 at 16:33, Kyrill Tkachov
>> wrote:
>>>
>>> Hi all,
>>>
>>> This recently added test fails on arm. We haven't implemented these
>>> intrinsics for arm
>>> (a
Hi Christophe,
On 11/01/18 16:21, Christophe Lyon wrote:
On 11 January 2018 at 16:33, Kyrill Tkachov
wrote:
Hi all,
This recently added test fails on arm. We haven't implemented these
intrinsics for arm
(any volunteers?) so for now let's XFAIL these on that target.
Also, the float64 versions
Hi,
This patch adds a pattern for "ori 31,31,0" as a speculation barrier, and
an associated built-in function. This is currently restricted to Power7
and later. Documentation and test included.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is
this okay for trunk?
Thank
On 11 January 2018 at 16:33, Kyrill Tkachov
wrote:
> Hi all,
>
> This recently added test fails on arm. We haven't implemented these
> intrinsics for arm
> (any volunteers?) so for now let's XFAIL these on that target.
> Also, the float64 versions of these intrinsics are not supposed to be
> avai
On 01/10/2018 01:10 AM, Richard Biener wrote:
> On Tue, 9 Jan 2018, Jeff Law wrote:
>
>> On 01/05/2018 02:01 AM, Richard Biener wrote:
>>> On Tue, 28 Nov 2017, Richard Biener wrote:
>>>
The following adds a new target hook, targetm.vectorize.split_reduction,
which allows the target
On 01/11/2018 06:52 AM, Martin Jambor wrote:
> Hi,
>
> IPA-CP does an extra devirtualization in devirt-22.C now because Honza's
> profiling changes have caused an extra edge to be maybe_hot_p. The scan
> dump is guarded with scan-dump-times, I assume so that we are alerted to
> any changes in beh
Segher Boessenkool wrote:
> Of course I see that ldp is useful. I don't think that this particular
> way of forcing more pairs is a good idea. Needs testing / benchmarking /
> instrumentation, and we haven't seen any of that.
I wouldn't propose a patch if it caused slowdowns. In fact I am see
Hi all,
This recently added test fails on arm. We haven't implemented these intrinsics
for arm
(any volunteers?) so for now let's XFAIL these on that target.
Also, the float64 versions of these intrinsics are not supposed to be available
on arm
so this patch slightly adjusts the test to not inc
Hi,
The attached patch fixes PR 81819, which popped up on GCC 7. I assume
it's also there on trunk, but can't build my app with trunk compiler
because it's got other issues.
Unfortunately I can't add the reproducer test case since it happens
only when building a bigger app with LTO. But I have
On Thu, 2018-01-11 at 15:10 +, Nick Clifton wrote:
>
> > OK for trunk and GCC 7?
> Approved. Do you have access to the repository, or would you like me
> to apply the patch for you ?
Thanks. Committed as r256536 (trunk) and r256538 (GCC 7).
Cheers,
Oleg
Hi Oleg,
> OK for trunk and GCC 7?
Approved. Do you have access to the repository, or would you like me to apply
the patch for you ?
Cheers
Nick
On 10/01/18 12:53, Christophe Lyon wrote:
On 10 January 2018 at 12:05, Kyrill Tkachov
wrote:
Hi Christophe,
On 10/01/18 10:50, Christophe Lyon wrote:
Hi Kyrill,
On 8 January 2018 at 18:55, Kyrill Tkachov
wrote:
[resending due to mailer problems...]
Hi all,
This patch adds support fo
Hi,
The attached patch fixes PR 81821. It is the same as the patch
proposed in the PR. I have briefly checked it in a private application
that uses atomic variables and I think it's rather obvious.
I have added atomics support on RX in GCC 7 and that was an initial
bug. Thus I'd like to also a
Change 'microblaze_asm_output_ident' so that instead of just switching
section to .sdata2/.rodata it uses the assembler .pushsection and
.popsection directives to preserve the section context when emitting the
ident string content.
This resolves issues associated with the use of the .sdata2/.rodat
Hi,
IPA-CP does an extra devirtualization in devirt-22.C now because Honza's
profiling changes have caused an extra edge to be maybe_hot_p. The scan
dump is guarded with scan-dump-times, I assume so that we are alerted to
any changes in behavior of the patch, like now.
I have looked at the behav
On Thu, Jan 11, 2018 at 1:49 PM, Bin Cheng wrote:
> Hi,
> As explained in comment of PR83695, outdated cached scev info could be
> referred
> by later interchange of outer loops in nest. This simple patch fixes ICE by
> resetting cached scev info after interchange. It's expensive resetting all
The following fixes VRP to be less susceptible to TREE_OVERFLOW in the
GIMPLE IL (which we don't really want...). It also fixes fallout from
my earlier graphite fixes (look better at this stage than ignoring
fake edges when computing loop exists everywhere...).
Bootstrapped and tested on x86_64-
On Thu, Jan 11, 2018 at 2:16 AM, Richard Biener
wrote:
> On Thu, Jan 11, 2018 at 1:18 AM, Jeff Law wrote:
>> On 01/10/2018 06:14 AM, Jakub Jelinek wrote:
>>> On Wed, Jan 10, 2018 at 02:08:48PM +0100, Richard Biener wrote:
On Wed, Jan 10, 2018 at 11:18 AM, Eric Botcazou
wrote:
>> I
On Mon, Jan 8, 2018 at 3:37 AM, H.J. Lu wrote:
> On Sun, Jan 7, 2018 at 8:07 PM, Sandra Loosemore
> wrote:
>> On 01/07/2018 03:58 PM, H.J. Lu wrote:
>>>
>>> This set of patches for GCC 8 mitigates variant #2 of the speculative
>>> execution
>>> vulnerabilities on x86 processors identified by CVE-
In preparation for the switch to NUM_POLY_INT_COEFFS==2.
Tested on aarch64-linux-gnu and committed as obvious.
Richard
2018-01-11 Richard Sandiford
gcc/
* config/aarch64/aarch64.c (aarch64_reinterpret_float_as_int):
Use scalar_float_mode.
Index: gcc/config/aarch64/aarch64.c
This patch replaces GET_MODE_NUNITS in some of the v8.4 support
with equivalent values, in preparation for the switch to
NUM_POLY_INT_COEFFS==2.
Tested on aarch64-linux-gnu and committed as an obvious extension
of the previous patches.
Richard
2018-01-11 Richard Sandiford
gcc/
* con
On 01/10/2018 07:03 PM, Bernhard Reutner-Fischer wrote:
On 5 January 2018 22:06:10 CET, Tom de Vries wrote:
[ was: Re: [RFC] Add vec::ordered_remove_if ]
Tom,
s/an an/an/g
Fixed.
Also:
- added '()' around more macro args in VEC_ORDERED_REMOVE_IF
- added PR number ( https://gcc.gnu.org/bu
Hi,
As explained in comment of PR83695, outdated cached scev info could be referred
by later interchange of outer loops in nest. This simple patch fixes ICE by
resetting cached scev info after interchange. It's expensive resetting all scev
information but might not be a problem here given we only
1 - 100 of 148 matches
Mail list logo
