On Thu, Apr 19, 2018 at 6:05 PM, Martin Sebor wrote:
> Ping: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00676.html
>
> Testing on x86_64-linux showed no regressions.
OK.
Richard.
>
> On 04/13/2018 10:49 AM, Martin Sebor wrote:
>>
>> PR 85365 is another example of a false positive caused by
>
> -Original Message-
> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> Sent: Friday, April 20, 2018 3:17 AM
> To: Jakub Jelinek
> Cc: Tsimbalist, Igor V ; Richard Biener
> ; Uros Bizjak ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs
>
> On
It's v2 patch for fixing stack align for rv32*c target.
gcc/ChangeLog:
2018-04-18 Kito Cheng
* config/riscv/riscv.c (riscv_first_stack_step): Round up min
step to make sure stack always aligned.
v1: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00877.html
From 3787f36a68922
On Thu, Apr 19, 2018 at 3:37 PM, Jakub Jelinek wrote:
> On Thu, Apr 19, 2018 at 03:08:06PM -0700, H.J. Lu wrote:
>> > As -fcf-protection and -mcet/-mibt/-mshstk are are disjoint and
>> > control different parts I agree with
>> >
>> > + if ((isa_flag & OPTION_MASK_ISA_SHSTK))
>> > +def_or_unde
Ok.
On Thu, Apr 19, 2018, 12:27 PM Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs starting with r259457 PR80290 fix.
>
> The problem is that the refcount is just 8-bit and if we need more than 256
> refcounts for one tinst_level, we fail an assertion.
>
> As discovered by Richard, th
> -Original Message-
> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> Sent: Friday, April 20, 2018 12:08 AM
> To: Tsimbalist, Igor V
> Cc: Jakub Jelinek ; Richard Biener
> ; Uros Bizjak ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs
>
> O
On Thu, Apr 19, 2018 at 01:23:51PM -0500, Peter Bergner wrote:
> On 3/9/18 4:25 PM, Peter Bergner wrote:
> > On 3/9/18 1:31 PM, Segher Boessenkool wrote:
> >> On Wed, Mar 07, 2018 at 06:50:41PM -0600, Peter Bergner wrote:
> >>> This passed bootstrap and regtesting on powerpc64-linux, running the
>
Hi Paul,
On Wed, Apr 18, 2018 at 05:06:05PM -0500, Paul Clarke wrote:
> 2018-04-18 Paul A. Clarke
>
> * MAINTAINERS (write after approval): Add myself.
It looks like you forgot to commit this? Looks fine btw.
Segher
> --- MAINTAINERS (revision 259480)
> +++ MAINTAINERS
On Thu, Apr 19, 2018 at 2:18 PM, Tsimbalist, Igor V
wrote:
>> -Original Message-
>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>> ow...@gcc.gnu.org] On Behalf Of H.J. Lu
>> Sent: Thursday, April 19, 2018 10:02 PM
>> To: Jakub Jelinek
>> Cc: Richard Biener ; Uros Bizjak
>> ;
On Wed, Apr 18, 2018 at 10:37:41AM -0700, Carl Love wrote:
> Please let me know if the patch looks OK for the GCC 7 branch.
I think it looks fine. But it should go to trunk, first?
Okay for trunk, and for the branches after a suitable delay. Thanks!
Segher
> 2018-04-17 Carl Love
>
>
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of H.J. Lu
> Sent: Thursday, April 19, 2018 10:02 PM
> To: Jakub Jelinek
> Cc: Richard Biener ; Uros Bizjak
> ; gcc-patches@gcc.gnu.org; Tsimbalist, Igor V
>
> Subject: Re: [PATC
On Thu, Apr 19, 2018 at 06:30:37AM -0700, H.J. Lu wrote:
> * config/i386/i386-c.c (ix86_target_macros_internal): Also
> define __IBT__ and __SHSTK__ for -fcf-protection.
> --- a/gcc/config/i386/i386-c.c
> +++ b/gcc/config/i386/i386-c.c
> @@ -499,13 +499,15 @@ ix86_target_macros_interna
On Thu, Apr 19, 2018 at 12:25 PM, Jakub Jelinek wrote:
> On Thu, Apr 19, 2018 at 06:30:37AM -0700, H.J. Lu wrote:
>> * config/i386/i386-c.c (ix86_target_macros_internal): Also
>> define __IBT__ and __SHSTK__ for -fcf-protection.
>
>> --- a/gcc/config/i386/i386-c.c
>> +++ b/gcc/config/i
On Thu, Apr 19, 2018 at 11:56 AM, Rainer Orth
wrote:
> "H.J. Lu" writes:
>
>> Replace ASM_OUTPUT_LABEL with fprintf so that internal labels in property
>> note section are unchanged -fleading-underscore.
>>
>> OK for trunk?
>>
>> H.J.
>> ---
>> gcc/
>>
>> PR target/85404
>> * config/i
"H.J. Lu" writes:
> Replace ASM_OUTPUT_LABEL with fprintf so that internal labels in property
> note section are unchanged -fleading-underscore.
>
> OK for trunk?
>
> H.J.
> ---
> gcc/
>
> PR target/85404
> * config/i386/cet.c (file_end_indicate_exec_stack_and_cet):
> Replace AS
On April 19, 2018 8:03:48 PM GMT+02:00, Toon Moene wrote:
>According to the Changes page for GCC 8, -floop-unroll-and-jam is
>enabled by default for -O3 optimization:
>
>"Two new classical loop nest optimization passes have been added.
>-floop-unroll-and-jam performs outer loop unrolling and fus
On April 19, 2018 8:33:13 PM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>This PR is the fold-const.c counterpart of the match.pd PR85195,
>we first check if the result type is either the element type or vector
>type
>with the same element type, and then for extraction of a single element
>simply assum
Hi!
The following testcase ICEs starting with r259457 PR80290 fix.
The problem is that the refcount is just 8-bit and if we need more than 256
refcounts for one tinst_level, we fail an assertion.
As discovered by Richard, the in_system_header_p member is write-only
since r138031:
grep in_system_
On Wed, Apr 18, 2018 at 09:32:53PM +0200, Jakub Jelinek wrote:
> In any case, this reinterpret_cast constexpr pedantic stuff looks too
> large/risky at this point to me, I wonder if we accept-invalid even the
> simple constexpr int a = reinterpret_cast (1); whether it is not ok for
> GCC8 to not er
Hi!
This PR is the fold-const.c counterpart of the match.pd PR85195,
we first check if the result type is either the element type or vector type
with the same element type, and then for extraction of a single element
simply assume that the result must be the element type; it could be single
elemen
On 3/9/18 4:25 PM, Peter Bergner wrote:
> On 3/9/18 1:31 PM, Segher Boessenkool wrote:
>> On Wed, Mar 07, 2018 at 06:50:41PM -0600, Peter Bergner wrote:
>>> This passed bootstrap and regtesting on powerpc64-linux, running the
>>> testsuite in both 32-bit and 64-bit modes with no regressions.
>>> Ok
According to the Changes page for GCC 8, -floop-unroll-and-jam is
enabled by default for -O3 optimization:
"Two new classical loop nest optimization passes have been added.
-floop-unroll-and-jam performs outer loop unrolling and fusing of the
inner loop copies. -floop-interchange exchanges loo
Am 19.04.2018 um 13:59 schrieb Thomas Schwinge:
The Fortran standard does not apply in this case. What does the OpenACC
standard say about STOP in an offloaded region?
Nothing explicitly, as far as I know. ;-/ Which means, that this either
a) has to be forbidden, or b) some common sense impleme
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of H.J. Lu
> Sent: Wednesday, April 18, 2018 3:21 PM
> To: GCC Patches
> Cc: Uros Bizjak ; Jeff Law
> Subject: PING: [PATCH] libgcc/CET: Skip signal frames when unwinding
> shado
On Thu, Apr 19, 2018 at 8:51 AM, Tsimbalist, Igor V
wrote:
>> -Original Message-
>> From: Lu, Hongjiu
>> Sent: Sunday, April 15, 2018 12:58 PM
>> To: gcc-patches@gcc.gnu.org
>> Cc: Uros Bizjak ; Tsimbalist, Igor V
>>
>> Subject: [PATCH] i386: Add save_stack_nonlocal and restore_stack_nonl
On Thu, Apr 19, 2018 at 10:21:32AM +0200, Richard Biener wrote:
>
> The following fixes the fact that the vectorizer doesn't bother to
> preserve restrict information on its generated loads/stores which
> in turn causes missed predictive commonings. The regression happened
> because there's now a
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00676.html
Testing on x86_64-linux showed no regressions.
On 04/13/2018 10:49 AM, Martin Sebor wrote:
PR 85365 is another example of a false positive caused by
the interaction between the instrumentation inserted by
sanitizers, jump threading,
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00650.html
This just suppresses a duplicate warning. Please let me know
if it's preferable to defer it until GCC 9. Otherwise, I'll
be traveling the next two weeks with only limited availability
(none the first week in May).
On 04/12/2018 02:
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00649.html
Andreas, I assumed you wanted to include a fix for this in GCC
8. I'm not sure if this is something you can/should approve as
one of the s360 maintainers or if it needs to be approved by
someone else (e.g., Jeff).
As a heads up, I'm
> -Original Message-
> From: Lu, Hongjiu
> Sent: Sunday, April 15, 2018 12:58 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Uros Bizjak ; Tsimbalist, Igor V
>
> Subject: [PATCH] i386: Add save_stack_nonlocal and restore_stack_nonlocal
>
> Define STACK_SAVEAREA_MODE to hold both shadow stack and
> On Thu, Apr 19, 2018 at 3:11 PM, Peryt, Sebastian
> wrote:
> >> On Thu, Apr 19, 2018 at 2:35 PM, Peryt, Sebastian
> >>
> >> wrote:
> >> >> On Wed, Apr 18, 2018 at 2:56 PM, Peryt, Sebastian
> >> >>
> >> >> wrote:
> >> >> > Hi,
> >> >> >
> >> >> > This patch enables new instructions - MOVDIRI an
> -Original Message-
> From: Lu, Hongjiu
> Sent: Sunday, April 15, 2018 1:06 PM
> To: gcc-patches@gcc.gnu.org; Uros Bizjak ; Tsimbalist,
> Igor V
> Subject: [PATCH] x86/cet: Properly output labels in property note section
>
> Replace ASM_OUTPUT_LABEL with fprintf so that internal labels i
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of H.J. Lu
> Sent: Wednesday, April 18, 2018 3:22 PM
> To: GCC Patches
> Cc: Uros Bizjak
> Subject: PING: [PATCH] libgcc/CET: Add _CET_ENDBR to __stack_split_initialize
>
> On T
> -Original Message-
> From: Uros Bizjak [mailto:ubiz...@gmail.com]
> Sent: Thursday, April 19, 2018 3:36 PM
> To: H.J. Lu
> Cc: Richard Biener ; gcc-
> patc...@gcc.gnu.org; Tsimbalist, Igor V
> Subject: Re: [PATCH] x86: Allow -fcf-protection with multi-byte NOPs
>
> On Thu, Apr 19, 2018
On Thu, Apr 19, 2018 at 3:30 PM, H.J. Lu wrote:
> On Wed, Apr 18, 2018 at 01:35:33PM +0200, Richard Biener wrote:
>> On Wed, Apr 18, 2018 at 1:24 PM, H.J. Lu wrote:
>> > On Tue, Apr 17, 2018 at 12:25 PM, H.J. Lu wrote:
>> >> On Tue, Apr 17, 2018 at 12:25 PM, H.J. Lu wrote:
>> >>> On Tue, Apr 17
Ok.
On Thu, Apr 19, 2018, 2:25 AM Paolo Carlini
wrote:
> Hi,
>
> the below is a rather low-key fix for this error-recovery regression:
> simply notice that pushtag is returning error_mark_node and avoid ICEing
> later. IMHO opinion it's correct and we may as well have it for 8.1.0
> but looking
Ok.
On Thu, Apr 19, 2018, 7:38 AM Jonathan Wakely wrote:
> On 19 April 2018 at 14:37, Jakub Jelinek wrote:
> > On Thu, Apr 19, 2018 at 02:29:37PM +0100, Jonathan Wakely wrote:
> >> The fix for PR c++/69733 caused a regression for conversion operators
> >> with redundant cv-qualifiers, changing
On 19 April 2018 at 14:37, Jakub Jelinek wrote:
> On Thu, Apr 19, 2018 at 02:29:37PM +0100, Jonathan Wakely wrote:
>> The fix for PR c++/69733 caused a regression for conversion operators
>> with redundant cv-qualifiers, changing an incorrect location to an
>> unknown location. This restores it to
On Thu, Apr 19, 2018 at 02:29:37PM +0100, Jonathan Wakely wrote:
> The fix for PR c++/69733 caused a regression for conversion operators
> with redundant cv-qualifiers, changing an incorrect location to an
> unknown location. This restores it to the incorrect location (as was
> already done on trun
On Thu, Apr 19, 2018 at 3:30 PM, H.J. Lu wrote:
> On Wed, Apr 18, 2018 at 01:35:33PM +0200, Richard Biener wrote:
>> On Wed, Apr 18, 2018 at 1:24 PM, H.J. Lu wrote:
>> > On Tue, Apr 17, 2018 at 12:25 PM, H.J. Lu wrote:
>> >> On Tue, Apr 17, 2018 at 12:25 PM, H.J. Lu wrote:
>> >>> On Tue, Apr 17
On Wed, Apr 18, 2018 at 01:35:33PM +0200, Richard Biener wrote:
> On Wed, Apr 18, 2018 at 1:24 PM, H.J. Lu wrote:
> > On Tue, Apr 17, 2018 at 12:25 PM, H.J. Lu wrote:
> >> On Tue, Apr 17, 2018 at 12:25 PM, H.J. Lu wrote:
> >>> On Tue, Apr 17, 2018 at 12:03 PM, H.J. Lu wrote:
> On Tue, Apr
The fix for PR c++/69733 caused a regression for conversion operators
with redundant cv-qualifiers, changing an incorrect location to an
unknown location. This restores it to the incorrect location (as was
already done on trunk by the fix for PR c++/65775).
Tested x86_64-linux, OK for gcc-7-branch
On Thu, Apr 19, 2018 at 3:11 PM, Peryt, Sebastian
wrote:
>> On Thu, Apr 19, 2018 at 2:35 PM, Peryt, Sebastian
>> wrote:
>> >> On Wed, Apr 18, 2018 at 2:56 PM, Peryt, Sebastian
>> >>
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > This patch enables new instructions - MOVDIRI and MOVDIR64B.
>> >> >
>> >
> On Thu, Apr 19, 2018 at 2:35 PM, Peryt, Sebastian
> wrote:
> >> On Wed, Apr 18, 2018 at 2:56 PM, Peryt, Sebastian
> >>
> >> wrote:
> >> > Hi,
> >> >
> >> > This patch enables new instructions - MOVDIRI and MOVDIR64B.
> >> >
> >> > Is it ok for trunk?
> >>
> >> Is there a reason that one flag go
On Thu, Apr 19, 2018 at 2:35 PM, Peryt, Sebastian
wrote:
>> On Wed, Apr 18, 2018 at 2:56 PM, Peryt, Sebastian
>> wrote:
>> > Hi,
>> >
>> > This patch enables new instructions - MOVDIRI and MOVDIR64B.
>> >
>> > Is it ok for trunk?
>>
>> Is there a reason that one flag goes to ix86_isa_flags and th
On Thu, 19 Apr 2018, Jakub Jelinek wrote:
> On Thu, Apr 19, 2018 at 10:21:32AM +0200, Richard Biener wrote:
> >
> > The following fixes the fact that the vectorizer doesn't bother to
> > preserve restrict information on its generated loads/stores which
> > in turn causes missed predictive commoni
> On Wed, Apr 18, 2018 at 2:56 PM, Peryt, Sebastian
> wrote:
> > Hi,
> >
> > This patch enables new instructions - MOVDIRI and MOVDIR64B.
> >
> > Is it ok for trunk?
>
> Is there a reason that one flag goes to ix86_isa_flags and the other to
> ix86_isa_flags2?
This is because of usage of OPTION_
Hi!
On Thu, 19 Apr 2018 13:32:16 +0200, Thomas König wrote:
> > Mapping exit to abort is weird,
>
> For Fortran, this is mapping STOP with a numeric code to abort.
>
> The Fortran standard does not apply in this case. What does the OpenACC
> standard say about STOP in an offloaded region?
Noth
> Mapping exit to abort is weird,
For Fortran, this is mapping STOP with a numeric code to abort.
The Fortran standard does not apply in this case. What does the OpenACC
standard say about STOP in an offloaded region?
Regards, Thomas
On Thu, 19 Apr 2018, Marc Glisse wrote:
> On Thu, 19 Apr 2018, Richard Biener wrote:
>
> > On Thu, 19 Apr 2018, Marc Glisse wrote:
> >
> > > On Thu, 19 Apr 2018, Jakub Jelinek wrote:
> > >
> > > > As mentioned in the PR, this optimization can't work if @0's precision
> > > > is higher than @1's
On Thu, 19 Apr 2018, Richard Biener wrote:
On Thu, 19 Apr 2018, Marc Glisse wrote:
On Thu, 19 Apr 2018, Jakub Jelinek wrote:
As mentioned in the PR, this optimization can't work if @0's precision
is higher than @1's precision, because originally it compares just some set
of lower bits, but i
On Wed, Apr 18, 2018 at 6:57 PM, Michael Eager wrote:
>
> Hi Andrew --
>
> Check indents in the following files:
> (Make sure that your tabs are set at 8 chars.)
> --- gcc/config/microblaze/microblaze.c
> --- gcc/config/microblaze/microblaze.md
>
I have re-run check_GNU_Style.sh and no are issues
Hi!
On Thu, 19 Apr 2018 11:25:30 +0200, Jakub Jelinek wrote:
> On Thu, Apr 19, 2018 at 11:19:31AM +0200, Thomas Schwinge wrote:
> > On Thu, 19 Apr 2018 11:14:38 +0200, Jakub Jelinek wrote:
> > > On Thu, Apr 19, 2018 at 11:06:18AM +0200, Thomas Schwinge wrote:
> > > > On Wed, 4 Apr 2018 11:30:34
This is an issue where clear_bb_flags clears BB_IRREDUCIBLE_LOOP and thus
wrecks loop info. I'm not entirely sure what kind of flags we want
to clear (all uses would need to be audited I guess), the function isn't
used much either. The following follows the function documentation
and adds BB_IRR
On Thu, Apr 19, 2018 at 11:19:31AM +0200, Thomas Schwinge wrote:
> Hi!
>
> On Thu, 19 Apr 2018 11:14:38 +0200, Jakub Jelinek wrote:
> > On Thu, Apr 19, 2018 at 11:06:18AM +0200, Thomas Schwinge wrote:
> > > On Wed, 4 Apr 2018 11:30:34 +0200, Thomas König wrote:
> > > > the recent patch to make t
Hi!
On Thu, 19 Apr 2018 11:14:38 +0200, Jakub Jelinek wrote:
> On Thu, Apr 19, 2018 at 11:06:18AM +0200, Thomas Schwinge wrote:
> > On Wed, 4 Apr 2018 11:30:34 +0200, Thomas König wrote:
> > > the recent patch to make the gfortran and libgomp testsuites more
> > > standard conforming, by replaci
On Thu, Apr 19, 2018 at 11:06:18AM +0200, Thomas Schwinge wrote:
> Hi!
>
> On Wed, 4 Apr 2018 11:30:34 +0200, Thomas König wrote:
> > the recent patch to make the gfortran and libgomp testsuites more
> > standard conforming, by replacing CALL ABORT() with STOP N, led
> > to numerous testsuite fai
Hi!
On Wed, 4 Apr 2018 11:30:34 +0200, Thomas König wrote:
> the recent patch to make the gfortran and libgomp testsuites more
> standard conforming, by replacing CALL ABORT() with STOP N, led
> to numerous testsuite failures on nvptx because stop_numeric
> was not implemented in minimal.c.
>
>
On 19 April 2018 at 10:37, Martin Liška wrote:
> On 04/18/2018 10:51 PM, Christophe Lyon wrote:
>> Hi,
>>
>>
>> On 17 April 2018 at 10:19, Jan Hubicka wrote:
On 04/17/2018 08:58 AM, Jakub Jelinek wrote:
> On Tue, Apr 17, 2018 at 07:39:20AM +0200, Martin Liška wrote:
>> + if
Hi.
This patch handles the lto-wrapper failure seen on multiple packages in
openSUSE OBS w/ -flto. It's explained here in more details:
https://sourceware.org/bugzilla/show_bug.cgi?id=23079
The patch is approved by Honza, I'm going to install it.
Martin
gcc/lto/ChangeLog:
2018-04-19 Martin Li
On 04/18/2018 10:51 PM, Christophe Lyon wrote:
> Hi,
>
>
> On 17 April 2018 at 10:19, Jan Hubicka wrote:
>>> On 04/17/2018 08:58 AM, Jakub Jelinek wrote:
On Tue, Apr 17, 2018 at 07:39:20AM +0200, Martin Liška wrote:
> + if (DECL_BIT_FIELD (f1) != DECL_BIT_FIELD (f2))
> +
Hi,
the below is a rather low-key fix for this error-recovery regression:
simply notice that pushtag is returning error_mark_node and avoid ICEing
later. IMHO opinion it's correct and we may as well have it for 8.1.0
but looking forward we really want a single error in such cases,
probably by
The following fixes the fact that the vectorizer doesn't bother to
preserve restrict information on its generated loads/stores which
in turn causes missed predictive commonings. The regression happened
because there's now a IPA-CP clone which wrecks points-to info,
but restrict is properly preser
On Thu, 19 Apr 2018, Marc Glisse wrote:
> On Thu, 19 Apr 2018, Jakub Jelinek wrote:
>
> > As mentioned in the PR, this optimization can't work if @0's precision
> > is higher than @1's precision, because originally it compares just some set
> > of lower bits, but in the new comparison compares al
On Thu, 19 Apr 2018, Jakub Jelinek wrote:
> On Wed, Apr 18, 2018 at 12:24:15PM -0700, H.J. Lu wrote:
> > >> So untested patch would be something like:
> > >
> > > Yes, this is what I think should be the most appropriate approach.
>
> Here is the patch with slightly tweaked install.texi and the al
On Thu, Apr 19, 2018 at 12:31 AM, Jakub Jelinek wrote:
> On Wed, Apr 18, 2018 at 12:24:15PM -0700, H.J. Lu wrote:
>> >> So untested patch would be something like:
>> >
>> > Yes, this is what I think should be the most appropriate approach.
>
> Here is the patch with slightly tweaked install.texi a
On Thu, 19 Apr 2018, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, this optimization can't work if @0's precision
> is higher than @1's precision, because originally it compares just some set
> of lower bits, but in the new comparison compares all bits.
> If @0's precision is smaller tha
67 matches
Mail list logo
