Hi!
The following testcase used to be miscompiled by RTL jump threading
on s390x-linux with -march=zEC12 at -O2 before r269302 which made it latent.
The problem is we had:
(jump_insn 26 25 87 4 (parallel [
(set (pc)
(if_then_else (eq (reg/v:DI 5 %r5 [orig:74 e ] [74])
On Sat, Mar 09, 2019 at 03:12:28AM -0300, Alexandre Oliva wrote:
> Ugh. That's more fallout from the concurrent implementations of v5 and
> LVU, ISTM. My bad for not catching, no doubt, since LVU landed later; I
> don't mean to excuse it, just to explain how it came about.
>
>
> I'm afraid I ha
On Mar 6, 2019, Jakub Jelinek wrote:
> On Tue, Mar 05, 2019 at 04:06:59PM -0500, Jason Merrill wrote:
>> > Assuming output_view_list_offset is correct, the following patch adjusts
>> > size_of_die/value_format accordingly.
>>
>> I would guess that omitting the handling from output_view_list_off
This libgo patch, based on one by Rainer Orth, uses more largefile
functions. With this patch we consistently call __go_openat for
openat and we use fstatat64, creat64, sendfile64, and getdents64
where needed. This is for PR 89447. Bootstrapped and ran Go
testsuite on x86_64-pc-linux-gnu. Comm
On Fri, Mar 08, 2019 at 03:03:07PM +0100, Martin Liška wrote:
> I'm going to install Jakub's test-case for a PR that's fixed
> on trunk.
This fails on i686-linux regtest when linker plugin is disabled (I use that
in my setup, because my ld is 64-bit and 32-bit plugins don't really work
very well w
This is a patch to fix the register allocation in SIMD functions. In
normal functions registers V16 to V31 are all caller saved. In SIMD
functions V16 to V23 are callee saved and V24 to V31 are caller saved.
This means that SIMD functions should use V24 to V31 before V16 to V23
in order to avoid
Hi!
The PR complained about lack of terminating dot at the end of one option
description, but I've found many others.
The patch ensures that normal option descriptions start with a capital
letter (unless it starts with a keyword, number, or - with tab in the middle of
description, etc.) and ends w
On March 8, 2019 5:57:35 PM GMT+01:00, Martin Jambor wrote:
>Hi,
>
>BTW, we have dropped the gcc-patches from the CC quite some emails ago
>:-/
>
>On Fri, Mar 08 2019, Richard Biener wrote:
>> yOn Thu, 7 Mar 2019, Martin Jambor wrote:
>>
>>> Hello again,
>>>
>>> On Thu, Mar 07 2019, Martin Jambor
Hi Kelvin,
On Fri, Mar 08, 2019 at 10:59:35AM -0600, Kelvin Nilsen wrote:
> This problem report, though initially motivated by differences in behavior
> between constant and non-constant selector arguments, uncovered a number of
> inconsistencies in the implementation of vec_extract.
>
> This p
Hi!
This got fixed with r257057 aka PR84031 fix, but the committed testcase
doesn't resemble anything close to this one.
Tested on x86_64-linux, committed to trunk as obvious.
2019-03-08 Jakub Jelinek
PR c++/82075
* g++.dg/cpp1z/decomp49.C: New test.
--- gcc/testsuite/g++.dg
Tested on aarch64-linux-gnu (with SVE) and x86_64-linux-gnu.
Applied as obvious.
Richard
2019-03-08 Richard Sandiford
gcc/
PR debug/89631
* dwarf2cfi.c (dwarf2out_frame_debug_expr): Use CONST_POLY_INT
instead of POLY_INT_CST.
--
Am 08.03.19 um 08:04 schrieb Bernhard Reutner-Fischer:
Please change call abort to stop N in the test?
Done.
Anything else? OK for trunk?
Regards
Thomas
Hi,
vcvtb.f16.f64 and vcvtb.f64.f16 were being made available even for FPUs
that do not support double precision. This patch fixes that.
Regression tested for arm-none-eabi.
Committed in r269499.
Cheers,
Andre
gcc/ChangeLog:
2019-03-08 Andre Vieira
* config/arm/arm.h (TARGET_FP
On Fri, Mar 10, 2017 at 09:21:53PM -0500, David Malcolm wrote:
> Martin pointed out that the wording of these messages could be improved
> by adding an article, and by adding quotes to "no_caller_saved_registers"
>
> Here's a revised version that makes those changes (in addition to
> the ones you
This problem report, though initially motivated by differences in behavior
between constant and non-constant selector arguments, uncovered a number of
inconsistencies in the implementation of vec_extract.
This patch provides several fixes to make handling of constant selector
expressions the sa
Hi Bill,
On Thu, Mar 07, 2019 at 06:33:48PM -0600, Bill Schmidt wrote:
> We recently discovered a problem in swap optimization where the du- and
> ud-chains
> were getting corrupted after a preliminary modification phase and prior to the
> main body of the pass. The fix for this is to rebuild th
Hi Kewen,
Just one quick note:
On Fri, Mar 08, 2019 at 09:40:30AM +0800, Kewen.Lin wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr88497.c
> @@ -0,0 +1,18 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -ffast-math -fdump-tree-reassoc1" } */
> +typedef double v2df __attribute
On 3/8/19 10:30 AM, Jason Merrill wrote:
The comment for push_operator_bindings already says "push the bindings
we saved away in maybe_save_op_lookup into the function parameter
binding level", are you thinking of something else/more detailed?
good enough, thanks
--
Nathan Sidwell
On March 8, 2019 3:52:36 PM GMT+01:00, Jeff Law wrote:
>On 3/8/19 7:23 AM, Richard Biener wrote:
>>
>> There's an old comment
>>
>> /* When cleanup_tree_cfg merges consecutive blocks, it may
>> perform some simplistic propagation when removing single
>> valued PHI nodes.
On Fri, Mar 8, 2019 at 8:04 AM Nathan Sidwell wrote:
>
> On 3/7/19 9:54 PM, Jason Merrill wrote:
> > For named function calls in a template, the result of unqualified lookup is
> > safed in CALL_EXPR_FN. But for operator expressions, no unqualified lookup
> > is performed until we know whether th
On 3/8/19 7:23 AM, Richard Biener wrote:
>
> There's an old comment
>
> /* When cleanup_tree_cfg merges consecutive blocks, it may
> perform some simplistic propagation when removing single
> valued PHI nodes. This propagation may, in turn, cause the
> SSA form t
There's an old comment
/* When cleanup_tree_cfg merges consecutive blocks, it may
perform some simplistic propagation when removing single
valued PHI nodes. This propagation may, in turn, cause the
SSA form to become out-of-date (see PR 22037). So, even
On Fri, Mar 08, 2019 at 02:50:26PM +0100, Martin Liška wrote:
> On 3/8/19 1:44 PM, Jan Hubicka wrote:
> >> Hi.
> >>
> >> Thanks to Intel guys, we've done some re-measurement in PR86952
> >> about usage of jump tables when retpolines are used.
> >> Numbers prove that disabling of JT should be the be
On 3/8/19 2:58 PM, Jan Hubicka wrote:
>> On 3/8/19 1:44 PM, Jan Hubicka wrote:
Hi.
Thanks to Intel guys, we've done some re-measurement in PR86952
about usage of jump tables when retpolines are used.
Numbers prove that disabling of JT should be the best for now.
P
Hi.
I'm going to install Jakub's test-case for a PR that's fixed
on trunk.
Martin
gcc/testsuite/ChangeLog:
2019-03-08 Jakub Jelinek
PR c/85870
* gcc.dg/lto/pr85870_0.c: New test.
* gcc.dg/lto/pr85870_1.c: New test.
---
gcc/testsuite/gcc.dg/lto/pr85870_0.c | 34 +
> On 3/8/19 1:44 PM, Jan Hubicka wrote:
> >> Hi.
> >>
> >> Thanks to Intel guys, we've done some re-measurement in PR86952
> >> about usage of jump tables when retpolines are used.
> >> Numbers prove that disabling of JT should be the best for now.
> >>
> >> Patch can bootstrap on x86_64-linux-gnu
* doc/xml/manual/using.xml: Use link element instead of xref.
* doc/html/*: Regenerate.
Committed to trunk.
commit 756ccc4dcdcc318d811b67e027202251d7dac57f
Author: Jonathan Wakely
Date: Fri Mar 8 13:38:31 2019 +
Fix text of hyperlink in manual
* doc/x
* include/bits/fs_path.h (path::format): Add fixed underlying type.
Tested powerpc64le-linux, committed to trunk.
commit 9bb37d0b7196d4a97d65ff597af884e2fa4ebb52
Author: Jonathan Wakely
Date: Thu Mar 7 15:00:56 2019 +
Add fixed underlying type to enum path::format
On Fri, Mar 8, 2019 at 1:35 PM Bill Schmidt wrote:
>
> On 3/8/19 4:40 AM, Richard Biener wrote:
>
> On Fri, Mar 8, 2019 at 1:34 AM Bill Schmidt wrote:
>
> Hi,
>
> We recently discovered a problem in swap optimization where the du- and
> ud-chains
> were getting corrupted after a preliminary modi
On Fri, Mar 8, 2019 at 12:45 PM Jakub Jelinek wrote:
>
> On Fri, Mar 08, 2019 at 12:25:31PM +0100, Jakub Jelinek wrote:
> > Maybe. The question is what exactly should we count. We could count only
> > in the cxx_eval_statement_list loop individual non-debug statements,
> > but that would miss st
On 3/8/19 1:44 PM, Jan Hubicka wrote:
>> Hi.
>>
>> Thanks to Intel guys, we've done some re-measurement in PR86952
>> about usage of jump tables when retpolines are used.
>> Numbers prove that disabling of JT should be the best for now.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives reg
On 3/7/19 9:54 PM, Jason Merrill wrote:
For named function calls in a template, the result of unqualified lookup is
safed in CALL_EXPR_FN. But for operator expressions, no unqualified lookup
is performed until we know whether the operands have class type. So when we
see in a lambda a use of an
> Hi.
>
> Thanks to Intel guys, we've done some re-measurement in PR86952
> about usage of jump tables when retpolines are used.
> Numbers prove that disabling of JT should be the best for now.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
On 3/8/19 4:40 AM, Richard Biener wrote:
> On Fri, Mar 8, 2019 at 1:34 AM Bill Schmidt wrote:
>> Hi,
>>
>> We recently discovered a problem in swap optimization where the du- and
>> ud-chains
>> were getting corrupted after a preliminary modification phase and prior to
>> the
>> main body of the
A small patch that deals with:
gcc/config/i386/i386.c:39427:11:Semantic Issue: comparison of two values with
different enumeration types in switch statement ('enum built_in_function' and
'ix86_builtins'): -Wenum-compare-switch
Is it fine to install it?
Thanks,
Martin
gcc/ChangeLog:
2019-03-08
> Hi.
>
> This is quite old hunk that Honza forgot to install:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63560#c1
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> Ready to be installed? Or should I wait for next stage1?
>
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
On Fri, Mar 08, 2019 at 12:25:31PM +0100, Jakub Jelinek wrote:
> Maybe. The question is what exactly should we count. We could count only
> in the cxx_eval_statement_list loop individual non-debug statements,
> but that would miss statements that aren't in STATEMENT_LISTs.
> Or we could count num
On Fri, Mar 08, 2019 at 11:36:36AM +0100, Richard Biener wrote:
> Shouldn't we somehow limit the number of stmt evaluations instead?
> I can imagine using constexpr templates you can do "loops" easily
> without actually writing loops ...
Maybe. The question is what exactly should we count. We co
Hi.
This is quite old hunk that Honza forgot to install:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63560#c1
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed? Or should I wait for next stage1?
Thanks,
Martin
gcc/ChangeLog:
2019-03-08 Jan Hubicka
On Fri, Mar 8, 2019 at 9:49 AM H.J. Lu wrote:
>
> On Thu, Mar 7, 2019 at 9:51 AM H.J. Lu wrote:
> >
> > On Wed, Mar 6, 2019 at 8:33 PM Richard Biener
> > wrote:
> > >
> > > On Wed, Mar 6, 2019 at 8:46 AM H.J. Lu wrote:
> > > >
> > > > On Tue, Mar 5, 2019 at 1:46 AM H.J. Lu wrote:
> > > > >
> >
On Fri, Mar 8, 2019 at 2:40 AM Kewen.Lin wrote:
>
> Hi,
>
> As PR88497 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88497),
> when we meet some code pattern like:
>
>V1[0] + V1[1] + ... + V1[k] + V2[0] + ... + V2[k] + ... Vn[k]
>// V1...Vn of VECTOR_TYPE
>
> We can teach reassoc to transf
On Fri, Mar 8, 2019 at 1:34 AM Bill Schmidt wrote:
>
> Hi,
>
> We recently discovered a problem in swap optimization where the du- and
> ud-chains
> were getting corrupted after a preliminary modification phase and prior to the
> main body of the pass. The fix for this is to rebuild the chains b
On Thu, Mar 7, 2019 at 8:53 PM Jakub Jelinek wrote:
>
> Hi!
>
> As mentioned in the PR, using HOST_WIDE_INT_PRINT_* in the middle of
> translatable message is highly undesirable, we end up with:
> #: config/s390/s390.c:737
> #, gcc-internal-format
> msgid "constant argument %d for builtin %qF is o
On Thu, Mar 7, 2019 at 8:32 PM Jakub Jelinek wrote:
>
> Hi!
>
> The following patch fixes two diagnostics issues in ipa-devirt.c, one
> is trailing space in one warning, the other is lack of articles in another
> warning, both reported by the translation team.
>
> Bootstrapped/regtested on x86_64-
On Thu, Mar 7, 2019 at 8:22 PM Jakub Jelinek wrote:
>
> Hi!
>
> We have -fconstexpr-loop-limit= option to have an upper bound for constexpr
> evaluation of a single loop. Even with that limit in place, if we have
> several nested loops during constexpr evaluation, even when each could have
> a fe
Looks good to me.
Thanks.
On Fri, Mar 8, 2019, 6:04 PM Uros Bizjak wrote:
> Attached patch adds missing _mm_loadu_si64 and _mm_storeu_si64 intrinsics.
>
> 2019-03-08 Uroš Bizjak
>
> PR target/68924
> PR target/78782
> PR target/87558
> * config/i386/emmintrin.h (_mm_loadu_si6
On Thu, 7 Mar 2019, Jakub Jelinek wrote:
> Hi!
>
> The following patch fixes a couple of cases where two or more spaces
> are introduced in a middle of diagnostic message because we've split source
> line and left a space both at the end of one line and at the start of next
> one.
>
> Fixed thus
On Thu, 7 Mar 2019, Jakub Jelinek wrote:
> Hi!
>
> While looking at why we didn't warn before Richi's commit, I've discovered
> is that the change is that in a different pass we used to call c_strlen too,
> but at that point with a location from system headers, so no warning has
> been printed, b
On Thu, 7 Mar 2019, Jakub Jelinek wrote:
> Hi!
>
> When looking at the diagnostics PRs, I've noticed that several diagnostic
> calls
> in gimple-ssa-warn-alloca.c use G_(...) uselessly, it is only needed if the
> argument is not a string literal.
>
> Fixed thusly, bootstrapped/regtested on x86_
Attached patch adds missing _mm_loadu_si64 and _mm_storeu_si64 intrinsics.
2019-03-08 Uroš Bizjak
PR target/68924
PR target/78782
PR target/87558
* config/i386/emmintrin.h (_mm_loadu_si64): New intrinsic.
(_mm_storeu_si64): Ditto.
testsuite/ChangeLog:
2019-03-08 Uroš Biz
Ping.
Link for possible convenience :-)
https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01899.html
On Thu, Mar 7, 2019 at 9:51 AM H.J. Lu wrote:
>
> On Wed, Mar 6, 2019 at 8:33 PM Richard Biener
> wrote:
> >
> > On Wed, Mar 6, 2019 at 8:46 AM H.J. Lu wrote:
> > >
> > > On Tue, Mar 5, 2019 at 1:46 AM H.J. Lu wrote:
> > > >
> > > > On Mon, Mar 04, 2019 at 12:55:04PM +0100, Richard Biener wrote
On Thu, Mar 7, 2019 at 4:09 PM Jakub Jelinek wrote:
>
> On Thu, Mar 07, 2019 at 08:11:53AM +0100, Uros Bizjak wrote:
> > > +(define_insn "*avx512f_load_mask"
> > > + [(set (match_operand: 0 "register_operand" "=v")
> > > + (vec_merge:
> > > + (vec_merge:
> > > + (vec_dupli
53 matches
Mail list logo
