Hi Richard,
Thanks for the review.
On 6 July 2018 at 20:17, Richard Biener wrote:
> On Fri, Jul 6, 2018 at 11:45 AM Kugan Vivekanandarajah
> wrote:
>>
>> Hi Richard,
>>
>> > It was rewrite_to_non_trapping_overflow available in tree.h. Thus
>> > final value replacement
>> > could use that befo
On 07/05/2018 03:27 PM, Jeff Law wrote:
On 07/04/2018 02:12 AM, Aldy Hernandez wrote:
On 07/03/2018 08:16 PM, Jeff Law wrote:
On 07/03/2018 03:31 AM, Aldy Hernandez wrote:
On 07/02/2018 07:08 AM, Christophe Lyon wrote:
On 11/07/2017 10:33 AM, Aldy Hernandez wrote:
While poking around i
On Sun, Jul 08, 2018 at 02:39:40AM +0300, Grazvydas Ignotas wrote:
> > I guess we want to backport it soon, but would appreciate somebody testing
> > it on real AVX512-{BW,VL} hw before doing the backports.
>
> I've run the testsuite with this patch applied and all tests passed on
> i7-7800X.
Tha
Ok.
On Mon, Jul 9, 2018, 6:42 AM Paolo Carlini wrote:
> Hi,
>
> noticed three additional error messages where an additional range seems
> appropriate. Tested x86_64-linux.
>
> Thanks, Paolo.
>
> //
>
>
Hi.
I'm putting back what I accidentally removed.
Martin
gcc/ChangeLog:
2018-07-09 Martin Liska
* common.opt: Add back wrongly removed attribute.
---
gcc/common.opt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/common.opt b/gcc/common.opt
index 963c37f04c
On Mon, Jul 9, 2018 at 9:05 AM Kugan Vivekanandarajah
wrote:
>
> Hi Richard,
>
> Thanks for the review.
>
> On 6 July 2018 at 20:17, Richard Biener wrote:
> > On Fri, Jul 6, 2018 at 11:45 AM Kugan Vivekanandarajah
> > wrote:
> >>
> >> Hi Richard,
> >>
> >> > It was rewrite_to_non_trapping_overfl
On Mon, Jul 9, 2018 at 9:19 AM Aldy Hernandez wrote:
>
>
>
> On 07/05/2018 03:27 PM, Jeff Law wrote:
> > On 07/04/2018 02:12 AM, Aldy Hernandez wrote:
> >>
> >>
> >> On 07/03/2018 08:16 PM, Jeff Law wrote:
> >>> On 07/03/2018 03:31 AM, Aldy Hernandez wrote:
> On 07/02/2018 07:08 AM, Christoph
On 07/09/2018 04:29 AM, Richard Biener wrote:
On Mon, Jul 9, 2018 at 9:19 AM Aldy Hernandez wrote:
On 07/05/2018 03:27 PM, Jeff Law wrote:
On 07/04/2018 02:12 AM, Aldy Hernandez wrote:
Many tests should turn into gimple IL tests.
Yeah, though for tests like the threading ones, they'
On Mon, Jul 9, 2018 at 10:37 AM, Jakub Jelinek wrote:
> On Sun, Jul 08, 2018 at 02:39:40AM +0300, Grazvydas Ignotas wrote:
>> > I guess we want to backport it soon, but would appreciate somebody testing
>> > it on real AVX512-{BW,VL} hw before doing the backports.
>>
>> I've run the testsuite with
On Tue, 3 Jul 2018 at 16:11, Richard Biener wrote:
>
> On Tue, Jul 3, 2018 at 4:10 PM David Malcolm wrote:
> >
> > On Tue, 2018-07-03 at 15:53 +0200, Richard Biener wrote:
> > > On Tue, Jul 3, 2018 at 3:52 PM David Malcolm
> > > wrote:
> > > >
> > > > On Tue, 2018-07-03 at 09:37 +0200, Richard B
On Sat, 7 Jul 2018, Jakub Jelinek wrote:
> Hi!
>
> So, apparently I've misread when exceptions are raised by
> nextafter/nexttoward (and errno set).
> if(((ix>=0x7ff0)&&((ix-0x7ff0)|lx)!=0) || /* x is nan */
>((iy>=0x7ff0)&&((iy-0x7ff0)|ly)!=0)) /* y is n
On Sat, 7 Jul 2018, Marc Glisse wrote:
> On Sat, 7 Jul 2018, Jakub Jelinek wrote:
>
> > 2018-07-07 Jakub Jelinek
> >
> > PR c/86420
> > * real.c (real_nextafter): Return true if result is denormal.
>
> I have a question on the side: would it be hard / useful, in cases where
> nextaft
Hi,
this patches uses relative line numbers in gcc.dg/guality where obvious:
either the relative line number is '.', '.-1' or '.+1', or adjacent to
another obvious case.
Committed as obvious.
Thanks,
- Tom
[testsuite] Use relative line numbers in gcc.dg/guality
2018-07-09 Tom de Vries
Hi Aldy,
> On 07/05/2018 05:50 AM, Richard Biener wrote:
>> On Thu, Jul 5, 2018 at 9:35 AM Aldy Hernandez wrote:
>>>
>>> The reason for this patch are the changes showcased in tree-vrp.c.
>>> Basically I'd like to discourage rolling our own overflow and underflow
>>> calculation when doing wide i
On Mon, Jul 09, 2018 at 12:00:46PM +0300, Grazvydas Ignotas wrote:
> On Mon, Jul 9, 2018 at 10:37 AM, Jakub Jelinek wrote:
> > On Sun, Jul 08, 2018 at 02:39:40AM +0300, Grazvydas Ignotas wrote:
> >> > I guess we want to backport it soon, but would appreciate somebody
> >> > testing
> >> > it on r
Hi all,
The patch adds support for the TARGET_COMPUTE_FRAME_LAYOUT hook on AArch64
and removes unneeded frame layout recalculation.
Bootstrapped and regtested on aarch64-none-linux-gnu and there are no
regressions.
Thanks,
Vlad
gcc/
2018-07-02 Vlad Lazar
* config/aarch64/aarch64.h
On July 9, 2018 1:16:59 PM GMT+02:00, Rainer Orth
wrote:
>Hi Aldy,
>
>> On 07/05/2018 05:50 AM, Richard Biener wrote:
>>> On Thu, Jul 5, 2018 at 9:35 AM Aldy Hernandez
>wrote:
The reason for this patch are the changes showcased in tree-vrp.c.
Basically I'd like to discourage rolli
On Sun, Jul 8, 2018 at 4:56 AM Martin Sebor wrote:
>
> On 07/06/2018 09:52 AM, Richard Biener wrote:
> > On Fri, Jul 6, 2018 at 1:54 AM Martin Sebor wrote:
> >>
> >> GCC folds accesses to members of constant aggregates except
> >> for character arrays/strings. For example, the strlen() call
> >>
On Sun, Jul 8, 2018 at 11:27 AM Tom de Vries wrote:
>
> On Sun, Jul 08, 2018 at 11:22:41AM +0200, Tom de Vries wrote:
> > On Fri, Jul 06, 2018 at 04:38:50PM +0200, Richard Biener wrote:
> > > On Fri, Jul 6, 2018 at 12:47 PM Tom de Vries wrote:
> > > > On 07/05/2018 01:39 PM, Richard Biener wrote:
On Mon, Jul 2, 2018 at 10:51 PM David Malcolm wrote:
>
> This patch implements a way to consolidate dump_* calls into
> optinfo objects, as enabling work towards being able to write out
> optimization records to a file, or emit them as diagnostic "remarks".
>
> The patch adds the support for build
On Mon, Jul 2, 2018 at 10:51 PM David Malcolm wrote:
>
> This patch adds the first destination for optinfo instances to be
> emitted to: as "remarks" through the diagnostics subsystem.
>
> Examples can be seen at
> https://dmalcolm.fedorapeople.org/gcc/2018-06-18/test.cc.remarks.html
>
> Remarks
On Wed, Jul 4, 2018 at 8:46 PM Richard Sandiford
wrote:
>
> Finally getting back to this...
>
> Richard Biener writes:
> > On Wed, Jun 6, 2018 at 10:16 PM Richard Sandiford
> > wrote:
> >>
> >> > On Thu, May 24, 2018 at 11:36 AM Richard Sandiford
> >> > wrote:
> >> >>
> >> >> This patch adds ma
Hi,
This patch adds support for the Statistical Profiling Extension (SPE) on
AArch64. Even though the compiler will not generate code any differently
given this extension, it will need to pass it on to the assembler in
order to let it correctly assemble inline asm containing accesses to the
extens
Hi Andre,
On 09/07/18 14:20, Andre Vieira (lists) wrote:
Hi,
This patch adds support for the Statistical Profiling Extension (SPE) on
AArch64. Even though the compiler will not generate code any differently
given this extension, it will need to pass it on to the assembler in
order to let it cor
This patch improves the generated code for the pdp11 target.
Committed.
paul
ChangeLog:
2018-07-09 Paul Koning
* config/pdp11/pdp11.c (pdp11_addr_cost): New function.
(pdp11_insn_cost): New function.
(pdp11_md_asm_adjust): New function.
(TARGET_INVALI
On Sat, Jul 7, 2018 at 11:47 PM Martin Sebor wrote:
>
> While working on other string folding improvements (PR 77357)
> I came across another distinct case where GCC could do better:
> it doesn't consider as candidates strings that have as many
> elements as the size of the array they are stored i
{ dg-do run }
{ do-options "-O2 -fno-tree-strlen" } */
I don't think this is doing anything.
If you look at the test run you can see that -fno-tree-strlen is never
passed (I think you actually mean -fno-optimize-strlen for that
matter). Also, the builtins.exp harness runs your test f
On 07/09/2018 07:16 AM, Rainer Orth wrote:
and several more. This seems to be the only backend that uses the
additional bool * argument to wi::neg etc.
Fixed as follows, bootstrapped on sparc-sun-solaris2.11.
Thanks. Sorry for the oversight.
Aldy
On Mon, Jul 9, 2018 at 6:21 AM Andre Vieira (lists)
wrote:
>
> Hi,
>
> This patch adds support for the Statistical Profiling Extension (SPE) on
> AArch64. Even though the compiler will not generate code any differently
> given this extension, it will need to pass it on to the assembler in
> order
The patches I posted earlier this year for mitigating against
CVE-2017-5753 (Spectre variant 1) attracted some useful feedback, from
which it became obvious that a rethink was needed. This mail, and the
following patches attempt to address that feedback and present a new
approach to mitigating ag
This patch defines a speculation barrier for AArch32.
* config/arm/unspecs.md (unspecv): Add VUNSPEC_SPECULATION_BARRIER.
* config/arm/arm.md (speculation_barrier): New expand.
(speculation_barrier_insn): New pattern.
---
gcc/config/arm/arm.md | 21 +++
Similar to Arm, this adds an unconditional speculation barrier for AArch64.
* config/aarch64.md (unspecv): Add UNSPECV_SPECULAION_BARRIER.
(speculation_barrier): New insn.
---
gcc/config/aarch64/aarch64.md | 10 ++
1 file changed, 10 insertions(+)
diff --git a/gcc/config
This patch doesn't do anything useful, it simply adds a new command-line
option -mtrack-speculation to AArch64. Subsequent patches build on this.
* config/aarch64/aarch64.opt (mtrack-speculation): New target option.
---
gcc/config/aarch64/aarch64.opt | 4
1 file changed, 4 insertio
This patch defines a new intrinsic function
__builtin_speculation_safe_value. A generic default implementation is
defined which will attempt to use the backend pattern
"speculation_safe_barrier". If this pattern is not defined, or if it
is not available, then the compiler will emit a warning, bu
In this final patch, now that we can track speculation through conditional
branches, we can use this information to use a less expensive CSDB based
speculation barrier.
* config/aarch64/iterators.md (ALLI_TI): New iterator.
* config/aarch64/aarch64.md (despeculate_copy): New
This patch is the main part of the speculation tracking code. It adds
a new target-specific pass that is run just before the final branch
reorg pass (so that it can clean up any new edge insertions we make).
The pass is only run with -mtrack-speculation is passed on the command
line.
One thing t
The CB[N]Z and TB[N]Z instructions do not expose the comparison through
the condition code flags. This makes it impossible to track speculative
execution through such a branch. We can handle this relatively easily
by simply disabling the patterns in this case.
A side effect of this is that the
At the same time, merge several related frame computing functions.
Recall that HWI is now always 64-bit, so merge IMASK and FMASK,
which allows merging of several loops within prologue and epilogue.
Full regression testing will take some time, but a quick browse
suggests no change in generated cod
Hi,
Re-posting. Richard provided feedback on a previous version of this
patch, I wanted to make sure he was/is OK with the latest. :-)
Add support for Gimple folding for unaligned vector loads and stores.
Regtest completed across variety of systems, P6,P7,P8,P9.
[v2] Added the type f
Hi,
Add support for gimple folding for vec_pack(), vec_unpackh() and
vec_unpackl().
Testcases for vec_pack are already in tree. Tests for vec_unpack
have been posted separately.
OK for trunk?
Thanks,
-Will
[gcc]
2018-07-09 Will Schmidt
* config/rs6000/rs6000.c (rs6000_gimple
Hi,
Add support for early gimple folding of vec_perm. Testcases are already
in-tree as
gcc.target/powerpc/fold-vec-perm-*.c
OK for trunk?
Thanks,
-Will
[gcc]
2018-07-09 Will Schmidt
* gcc/config/rs6000/rs6000.c (rs6000_gimple_fold_builtin): Add support
for fol
Hi,
Testcases to exercise the vec_unpack intrinsics.
Tested clean across assorted systems.
OK for trunk?
Thanks,
-Will
[testsuite]
2018-07-09 Will Schmidt
* gcc.target/powerpc/fold-vec-unpack-char.c: New.
* gcc.target/powerpc/fold-vec-unpack-float.c: Ne
Hi, Martin,
thanks a lot for your comments.
> On Jul 5, 2018, at 11:30 AM, Martin Sebor wrote:
>
> One of the basic design principles that I myself have
> accidentally violated in the past is that warning options
> should not impact the emitted object code. I don't think
> your patch actually
On 07/09/2018 08:36 AM, Aldy Hernandez wrote:
>{ dg-do run }
>{ do-options "-O2 -fno-tree-strlen" } */
>
> I don't think this is doing anything.
>
> If you look at the test run you can see that -fno-tree-strlen is never
> passed (I think you actually mean -fno-optimize-strlen for th
On 07/09/2018 01:19 AM, Aldy Hernandez wrote:
>>
>> I'd like decisions about how to expand branches deferred until rtl
>> expansion. Kai was poking at this in the past but never really got any
>> traction.
>
> For the record, the problem in this testcase is that switch lowering is
> riddled with
On 07/09/2018 01:28 PM, Qing Zhao wrote:
Hi, Martin,
thanks a lot for your comments.
On Jul 5, 2018, at 11:30 AM, Martin Sebor wrote:
One of the basic design principles that I myself have
accidentally violated in the past is that warning options
should not impact the emitted object code. I
On 07/09/2018 01:51 PM, Jeff Law wrote:
On 07/09/2018 08:36 AM, Aldy Hernandez wrote:
{ dg-do run }
{ do-options "-O2 -fno-tree-strlen" } */
I don't think this is doing anything.
If you look at the test run you can see that -fno-tree-strlen is never
passed (I think you actually mea
On 07/06/2018 02:59 PM, Peter Bergner wrote:
> On 7/5/18 2:36 PM, Jeff Law wrote:
>> On 07/02/2018 03:50 PM, Peter Bergner wrote:
>>> I'd like to PING:
>>>
>>> https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01713.html
>>>
>>> I've included the entire patch below, since I missed the test cases in
>
On 07/09/2018 08:36 AM, Aldy Hernandez wrote:
{ dg-do run }
{ do-options "-O2 -fno-tree-strlen" } */
I don't think this is doing anything.
If you look at the test run you can see that -fno-tree-strlen is never
passed (I think you actually mean -fno-optimize-strlen for that
matter).
On 07/09/2018 06:40 AM, Richard Biener wrote:
On Sun, Jul 8, 2018 at 4:56 AM Martin Sebor wrote:
On 07/06/2018 09:52 AM, Richard Biener wrote:
On Fri, Jul 6, 2018 at 1:54 AM Martin Sebor wrote:
GCC folds accesses to members of constant aggregates except
for character arrays/strings. For e
On 07/09/2018 10:38 AM, Richard Earnshaw wrote:
>
> The patches I posted earlier this year for mitigating against
> CVE-2017-5753 (Spectre variant 1) attracted some useful feedback, from
> which it became obvious that a rethink was needed. This mail, and the
> following patches attempt to address
GCC Maintainers:
The following patch is a back port for a commit to mainline prior to
GCC 8 release. Note, the code fixed by this patch was later modified
in commit 256798 as part of adding vec_xst_len support. The sldi
instruction gets replaced by an ashift of the operand for the stxvl
instruct
On Mon, 2018-06-25 at 11:10 +0200, Richard Biener wrote:
> On Fri, 22 Jun 2018, David Malcolm wrote:
>
> > NightStrike and I were chatting on IRC last week about
> > issues with trying to vectorize the following code:
> >
> > #include
> > std::size_t f(std::vector> const & v) {
> > std::size
gcc/ChangeLog:
* tree-vectorizer.c: Include "opt-problem.h".
(try_vectorize_loop_1): Convert "loop_vinfo" from loop_vec_info to
opt_loop_vec_info loop_vinfo, and use opt_report to report any
opt_problem thus captured. Use opt_report ro report on successful
l
In particular, note how this allows us to highlight specific loops in
testcases (via dg-remark), and to highlight the specific lines that cause
problems to the vectorizer (via dg-message).
gcc/testsuite/ChangeLog:
* gcc.dg/vect/vect-alias-check-4.c: Add -fremarks to options. Add
d
gcc/ChangeLog:
* opt-problem.h: New file.
* tree-vectorizer.h (opt_loop_vec_info): New typedef.
---
gcc/opt-problem.h | 326 ++
gcc/tree-vectorizer.h | 6 +
2 files changed, 332 insertions(+)
create mode 100644 gcc/opt-problem.
gcc/ChangeLog:
* Makefile.in (OBJS): Add opt-problem.o.
* opt-problem.cc: New file.
---
gcc/Makefile.in| 1 +
gcc/opt-problem.cc | 96 ++
2 files changed, 97 insertions(+)
create mode 100644 gcc/opt-problem.cc
diff --git a/
This patch uses the opt_result framework throughout the vectorizer
(and a few other places) so that specific details on problems are
propagated back up to the top-level of the vectorizer.
The changes are mostly fairly mechanical.
There are various FIXMEs in the code: for example, in various place
This patch to the Go frontend by Cherry Zhang fixes the compiler to
avoid a double evaluation of an interface field expression. In
Interface_field_reference_expression, the interface expression is used
in two places, so a temporary variable is used. Previously, we used a
Set_and_use_temporary_exp
Ping #2: https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01509.html
On 07/03/2018 08:12 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01509.html
On 06/24/2018 03:05 PM, Martin Sebor wrote:
Storing integer command line option arguments in type int
limits options such
60 matches
Mail list logo
