On 2018-01-31 00:27, Eric Botcazou wrote:
I would like to commit the following comment about LEON3-FT errata now
available in GCC-7.3.
Fine with me, thanks.
Thanks, I have now committed it.
On Wed, 31 Jan 2018, Jakub Jelinek wrote:
> Hi!
>
> Some spots in the vectorizer create generic COND_EXPRs that in one of the
> branches compute some +/-/* arithmetics. When -ftrapv, the gimplifier
> ICEs on this as it may trap, we can't emit code with multiple basic blocks
> from the APIs and d
When associating a variable of type character, if the length of the
target isn't known at compile time, generate an error. See PR 83344
for more details.
Regtested on x86_64-pc-linux-gnu, Ok for trunk?
gcc/fortran/ChangeLog:
2018-02-01 Janne Blomqvist
PR 83975
PR 83344
On Thu, Feb 01, 2018 at 09:47:23AM +0100, Richard Biener wrote:
> I wonder if you actually ran into the case of ABS_EXPR being
> passed to rewrite_to_non_trapping_overflow?
I haven't. In the first vrsion of the patch I wasn't using
operation_no_trapping_overflow and so just ignored ABS_EXPR,
with
> [ARC] Add JLI support.
> [ARC] Add SJLI support.
> [ARC] Add support for "register file 16" reduced register set
> [ARC] Rework delegitimate_address hook
> [ARC] Add 'uncached' attribute.
> [ARC] Add 'aux' variable attribute.
Thank you all for reviewing them.
//Claudiu
On 31/01/18 19:04, Richard Sandiford wrote:
> Eric Botcazou writes:
>>> Tested on SPARC64/Linux and ARM/EABI, applied on mainline and 7 branch.
>>
>> As discussed in the audit trail, this beefs up the internal documentation
>> about WORD_REGISTER_OPERATIONS.
>>
>> Tested with 'make doc', applied
On Wed, Jan 24, 2018 at 04:28:13PM +, Szabolcs Nagy wrote:
> Fix test failures with -mcmodel=tiny when adr is generated instead of adrp.
>
> FAIL: gcc.target/aarch64/sve/peel_ind_1.c -march=armv8.2-a+sve scan-assembler
> \\tadrp\\tx[0-9]+, x\\n
> FAIL: gcc.target/aarch64/sve/peel_ind_2.c -mar
On Tue, Jan 16, 2018 at 04:32:36PM +, Wilco Dijkstra wrote:
> v2: Rebased after the big SVE commits
>
> Remove the remaining uses of '*' from aarch64.md.
> Using '*' in alternatives is typically incorrect as it tells the register
> allocator to ignore those alternatives. Also add a missing '?
On Fri, Jan 26, 2018 at 01:47:48PM +, Richard Sandiford wrote:
> The current aarch64_simd_valid_immediate code predates the move
> to the new CONST_VECTOR representation, so for variable-length SVE
> it only handles duplicates of single elements, rather than duplicates
> of repeating patterns.
On Fri, Jan 26, 2018 at 01:34:31PM +, Richard Sandiford wrote:
> aarch64_secondary_reload enforced a secondary reload via
> aarch64_sve_reload_be for memory and pseudo registers, but failed
> to do the same for subregs of pseudo registers. To avoid this and
> any similar problems, the patch in
On Fri, Jan 26, 2018 at 02:25:02PM +, Richard Sandiford wrote:
> The SVE tests are split into code-quality compile tests and runtime
> tests. A lot of the former are geared towards LP64. It would be
> possible (but tedious!) to mark up every line that is expected to work
> only for LP64, but
On Wed, Jan 31, 2018 at 4:39 PM, David Malcolm wrote:
> PR 84136 reports an ICE within sccvn_dom_walker when handling a
> C/C++ source file that overuses the labels-as-values extension.
> The code in question stores a jump label into a global, and then
> jumps to it from another function, which IC
On 5 October 2017 at 13:38, Petr Ovtchenkov wrote:
> On Thu, 5 Oct 2017 12:56:36 +0200
> Yvan Roux wrote:
>
>> On 5 September 2017 at 12:04, Jakub Jelinek wrote:
>> > On Tue, Sep 05, 2017 at 10:58:22AM +0200, Yvan Roux wrote:
>> >> ping
>> >>
>> >> https://gcc.gnu.org/ml/gcc-patches/2017-06/msg0
This enhances the domwalk interface to allow disabling of RPO sorting
of dom children (after I've recently enhanced it to allow passing in
the RPO order). Then it attacks the most prominent and often-called
infrastructure helper - update_ssa - which doesn't really need any
special ordering of dom
Does any of you use print_class_statistics?
It seems most of these variables were set-but-unused even in gcc-2.95 (!). So
I think we can safely 86 all of this. Or is the "n_vtables" info interesting
in any way?
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2018-02-01 Marek Polacek
A recent patch has broken RTL checking builds on x86_64 fails during combine
RTL check: expected code 'reg' have 'lshirtrt' in rhs_regno at rtl.h:1891
builfing libgçc2.c in function __mulsc3
Hi Martin,
On 01/02/18 00:40, Martin Sebor wrote:
On 01/31/2018 10:36 AM, Renlin Li wrote:
Hi there,
I have a patch to fix to regressions we observed in armhf native
environment.
To effectively check out of range for format string, a target type
should be
used. And according to the standard,
On Wed, Jan 31, 2018 at 10:55 AM, Richard Biener
wrote:
> On Tue, Dec 19, 2017 at 4:36 PM, Bin Cheng wrote:
>> HI,
>> This patch backports r254778 and test case in r244815 to GCC6. Bootstrap and
>> test on x86_64. Is it OK?
>
> Ok.
Retested and applied on GCC6 branch.
Thanks,
bin
>
> Richard.
James Greenhalgh wrote:
> Please queue for GCC 9. OK when trunk is back open for new code.
This fixes the regressions introduced by the SVE merge conflicts and
the failures of aarch64/pr62178.c, both of which are new regressions,
so we should fix these now.
Wilco
On Thu, Feb 1, 2018 at 5:07 AM, Kugan Vivekanandarajah
wrote:
> Hi Richard,
>
> On 31 January 2018 at 21:39, Richard Biener
> wrote:
>> On Wed, Jan 31, 2018 at 11:28 AM, Kugan Vivekanandarajah
>> wrote:
>>> Hi Richard,
>>>
>>> Thanks for the review.
>>> On 25 January 2018 at 20:04, Richard Bien
On 02/01/2018 06:51 AM, Marek Polacek wrote:
Does any of you use print_class_statistics?
It seems most of these variables were set-but-unused even in gcc-2.95 (!). So
I think we can safely 86 all of this. Or is the "n_vtables" info interesting
in any way?
Bootstrapped/regtested on x86_64-linu
Hi,
Please find below a patch to fix PR83789.
The altivec builtin '__builtin_altivec_lvx' fails for the 32-bit powerpc-linux
target.
This is observed in gcc-7 onwards and does not affect powerpc64-linux target.
This is regression tested for powerpc-linux.
Please let me know if this patch is OK.
On Thu, Feb 01, 2018 at 12:09:09PM +, Wilco Dijkstra wrote:
> James Greenhalgh wrote:
>
> > Please queue for GCC 9. OK when trunk is back open for new code.
>
> This fixes the regressions introduced by the SVE merge conflicts and
> the failures of aarch64/pr62178.c, both of which are new regr
On Wed, Jan 31, 2018 at 4:06 PM, Richard Sandiford
wrote:
> This patch implements the original suggestion for fixing PR 81635:
> use range info in split_constant_offset to see whether a conversion
> of a wrapping type can be split. The range info problem described in:
>
> https://gcc.gnu.org/ml
Richard Biener writes:
> On Wed, Jan 31, 2018 at 4:06 PM, Richard Sandiford
> wrote:
>> This patch implements the original suggestion for fixing PR 81635:
>> use range info in split_constant_offset to see whether a conversion
>> of a wrapping type can be split. The range info problem described i
On Thu, Feb 1, 2018 at 2:18 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Wed, Jan 31, 2018 at 4:06 PM, Richard Sandiford
>> wrote:
>>> This patch implements the original suggestion for fixing PR 81635:
>>> use range info in split_constant_offset to see whether a conversion
>>> of
On Thu, Feb 01, 2018 at 11:52:42AM +, graham stott wrote:
> A recent patch has broken RTL checking builds on x86_64 fails during combine
> RTL check: expected code 'reg' have 'lshirtrt' in rhs_regno at rtl.h:1891
> builfing libgçc2.c in function __mulsc3
This is PR84157. It has a patch.
Hi!
This is a first set of release notes for Power for GCC 8.
Is this okay to commit?
Segher
Index: htdocs/gcc-8/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/changes.html,v
retrieving revision 1.31
diff -u -3 -p -r1.3
On Wed, Jan 31, 2018 at 11:42 PM, Uros Bizjak wrote:
> On Thu, Feb 1, 2018 at 1:16 AM, H.J. Lu wrote:
>>
>> We currently read and write beyond the builtin jmpbuf on ILP32 targets
>> where Pmode == DImode and ptr_mode == SImode. Since the builtin jmpbuf
>> is an array of 5 pointers, ptr_mode shou
On Thu, Feb 01, 2018 at 08:49:09AM +0100, Uros Bizjak wrote:
> > gcc/c-family/
> > * c-common.h (omp_clause_mask): Move to wide_int_bitmask.h.
> >
> > gcc/
> > * config/i386/i386.c (ix86_option_override_internal): Change flags
> > type to
> > wide_int_bitmask.
> > *
On Thu, Feb 1, 2018 at 7:25 AM, Nathan Sidwell wrote:
> On 02/01/2018 06:51 AM, Marek Polacek wrote:
>>
>> Does any of you use print_class_statistics?
>>
>> It seems most of these variables were set-but-unused even in gcc-2.95 (!).
>> So
>> I think we can safely 86 all of this. Or is the "n_vta
Hi!
On Thu, Feb 01, 2018 at 12:26:41PM +, Kaushik Phatak wrote:
> --- gcc/config/rs6000/rs6000.c(revision 256400)
> +++ gcc/config/rs6000/rs6000.c(working copy)
> @@ -15799,8 +15799,10 @@
> exp, target, false);
> case ALTIVEC_BUILTIN_L
Hi James,
Thanks for the review! I committed it on trunk.
Is it Okay to backport this patch to release branch 5, 6,7?
It applies cleanly without any logic changes.
Regards,
Renlin
On 31/01/18 17:56, James Greenhalgh wrote:
On Tue, Jan 30, 2018 at 03:45:17PM +, Renlin Li wrote:
Hi Richard
On Thu, Feb 01, 2018 at 02:43:17PM +, Renlin Li wrote:
> Hi James,
>
> Thanks for the review! I committed it on trunk.
>
> Is it Okay to backport this patch to release branch 5, 6,7?
> It applies cleanly without any logic changes.
6 and 7 yes, OK.
5 is no longer supported so may be a waste
On Wed, Jan 31, 2018 at 12:16:37PM -0600, Peter Bergner wrote:
> On 1/31/18 11:39 AM, Segher Boessenkool wrote:
> > On Mon, Jan 29, 2018 at 08:55:35PM -0600, Peter Bergner wrote:
> >>
> >> Either that, or I could still call candidates_list_and_hint() and just
> >> throw the hint away, since it's me
On Wed, Jan 31, 2018 at 2:55 PM, Paolo Carlini wrote:
> Hi again,
>
> On 24/01/2018 16:58, Paolo Carlini wrote:
>>
>> Hi,
>>
>> I'm looking into this rather mild regression, which should be relatively
>> easy to fix. In short, Jason's fix for c++/54325 moved an
>> abstract_virtuals_error_sfinae ch
This libgo patch declares the return type of the C getaddrinfo
function, when called from Go, as int32 rather than int. That is
important because getaddrinfo returns negative numbers on error, and
so numbers like -2 in int32 were being treated as 0xfffe in int,
which in Go is a 64 bit type. T
This patch to the Go frontend omits the field name for embedded fields
in the reflect string. This matches the gc compiler. The test case
was sent for the master repo as https://golang.org/cl/91138. This
fixes https://golang.org/issue/23620. Bootstrapped and ran Go
testsuite on x86_64-pc-linux-
Hi,
On 01/02/2018 15:54, Jason Merrill wrote:
I'm gently "pinging" this message of mine... Definitely not an high priority
regression (in any case it's only a P3) but I'm still wondering if we want
to do something about the issue at this time. Lately I noticed that in terms
of testsuite even som
Applied the following patch that moves disabling of
-fno-disable-null-pointer-checks to a different place so that it can be
overwritten on the command-line (as opposed to TARGET_OVERRIDE_OPTIONS).
This allows some more test cases to pass that set
-fdisable-null-pointer-checks.
gcc/
*
Richard Sandiford wrote:
> But why wasn't the index 0 as expected for the insns outside of the block?
Well it seems it checks for index 0 and sets the model_index as the current
maximum model_index count. This means the target_bb check isn't
strictly required - I build all of SPECINT2017 using t
2018-02-01 Uros Bizjak
PR rtl-optimization/84157
* combine.c (change_zero_ext): Use REG_P predicate in
front of HARD_REGISTER_P predicate.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Committed to mainline SVN.
Uros.
diff --git a/gcc/combine.c b/gcc/combine.c
i
On Thu, 1 Feb 2018, Segher Boessenkool wrote:
> This is a first set of release notes for Power for GCC 8.
>
> Is this okay to commit?
Yes, thank you!
Just the move ofseems
unclear to me? Can you omit that?
Gerald
On 02/01/2018 06:21 AM, Segher Boessenkool wrote:
> On Thu, Feb 01, 2018 at 11:52:42AM +, graham stott wrote:
>> A recent patch has broken RTL checking builds on x86_64 fails during combine
>> RTL check: expected code 'reg' have 'lshirtrt' in rhs_regno at rtl.h:1891
>> builfing libgçc2.c in
Hi Joseph, aarch64 maintainers,
On 28/09/17 13:31, Joseph Myers wrote:
Many GCC tests fail for AArch64 with current binutils because of
assembler warnings of the form "Warning: ignoring incorrect section
type for .init_array.00100". The same issue was fixed for ARM in
r247015 by using SECTION_N
On Fri, Feb 02, 2018 at 01:06:59AM +0900, Gerald Pfeifer wrote:
> On Thu, 1 Feb 2018, Segher Boessenkool wrote:
> > This is a first set of release notes for Power for GCC 8.
> >
> > Is this okay to commit?
>
> Yes, thank you!
>
> Just the move ofseems
> unclear to me? Can you omit that?
T
Vladimir Makarov writes:
> Index: ira.c
> ===
> --- ira.c (revision 257157)
> +++ ira.c (working copy)
> @@ -1578,7 +1578,8 @@ ira_init_register_move_cost (machine_mod
>ira_assert (ira_register_move_cost[mode] == NULL
>
Hi Sterling,
On Wed, Jan 31, 2018 at 11:17 AM, Max Filippov wrote:
> On Wed, Jan 31, 2018 at 11:11 AM, augustine.sterl...@gmail.com
> wrote:
>> On Tue, Jan 30, 2018 at 8:02 PM, Max Filippov wrote:
>>>
>>> libgcc/
>>> 2018-01-31 Max Filippov
>>>
>>> * config/xtensa/ieee754-df.S (__ad
Wilco Dijkstra writes:
> Richard Sandiford wrote:
>
>> But why wasn't the index 0 as expected for the insns outside of the block?
>
> Well it seems it checks for index 0 and sets the model_index as the current
> maximum model_index count. This means the target_bb check isn't
> strictly required -
Before r196122, a VOIDmode would return the default value of false in
base14_operand, but when S?mode and D?mode's were collapsed with the
aforementioned patch, we started handling E_VOIDmode which has a size of
0. The zero is causes a division by zero in the PR's testcase.
Dave has suggested
On Thu, 1 Feb 2018, Kyrill Tkachov wrote:
> Hi Joseph, aarch64 maintainers,
>
> On 28/09/17 13:31, Joseph Myers wrote:
> > Many GCC tests fail for AArch64 with current binutils because of
> > assembler warnings of the form "Warning: ignoring incorrect section
> > type for .init_array.00100". Th
Hi Janne,
When associating a variable of type character, if the length of the
target isn't known at compile time, generate an error. See PR 83344
for more details.
Regtested on x86_64-pc-linux-gnu, Ok for trunk?
I think this is the most reasonable course of action,
given the circumstances.
O
Since my patch isn't the easy one liner I wanted it to be, perhaps we
should concentrate on Martin's patch, which is more robust, and has
testcases to boot! His patch from last week also fixes a couple other
PRs.
Richard, would this be acceptable? That is, could you or Jakub review
Martin's all-
On 2018-02-01 12:20 PM, Aldy Hernandez wrote:
Perhaps someone with access to a PA box can run further tests.
I have a couple of tests running.
Thanks,
Dave
--
John David Anglin dave.ang...@bell.net
On 02/01/2018 04:54 AM, Renlin Li wrote:
Hi Martin,
On 01/02/18 00:40, Martin Sebor wrote:
On 01/31/2018 10:36 AM, Renlin Li wrote:
Hi there,
I have a patch to fix to regressions we observed in armhf native
environment.
To effectively check out of range for format string, a target type
shou
In a partial instantiation of a pack expansion we can have a situation
where we have arguments for some of the packs but not all. We deal
with this by leaving the pattern uninstantiated and remembering the
arguments passed to the partial specialization so we can use them
later in doing a full inst
On 2/1/18 8:50 AM, Segher Boessenkool wrote:
> I think we also want this for 7 (after a bit of burn in). I wouldn't
> bother with 6 though (the problem has existed since 4.7).
Ok, committed. I'll wait a few days before committing the FSF 7 back port.
Thanks!
Peter
On 02/01/2018 12:10 PM, Richard Sandiford wrote:
Vladimir Makarov writes:
Not sure about the E_/genmodes reference here. Isn't it simply
"because it might be the mode a pseudo register"?
Is it OK to expand the explanation a bit, as below?
Yes, it is OK. It is a better explanation. Thank
This patch fixes the optimization regression that occurred on GCC 7 where
conversions from the various floating point types to small integers would at
times generate a store and a load.
For example, converting from double to unsigned char generated the following
code on GCC 6 for -mcpu=power8:
GCC maintainers:
The following patch contains fixes for the builtins to add and extract
a word from a char vector. The existing names for the builtins that do
this are not consistent with the ABI. Additionally, the supported
arguments are not all consistent with the ABI. This patch fixes the
s
On Tue, Jan 30, 2018 at 3:18 PM, Marek Polacek wrote:
> This testcase breaks since r256550 because we end up trying to build_address
> of
> a CONSTRUCTOR, but that doesn't work because we hit
> gcc_checking_assert (TREE_CODE (t) != CONSTRUCTOR);
>
> finish_static_assert gets {} as 'condition'.
Hello world,
this patch fixes a regression by removing a KIND argument
(which is encoded into the function name anyway) from the
call to the library function. This extra argument led to
an argument mismatch between the front end and the library
and between different instances of the same function
On Thu, Feb 01, 2018 at 02:35:08PM -0500, Jason Merrill wrote:
> On Tue, Jan 30, 2018 at 3:18 PM, Marek Polacek wrote:
> > This testcase breaks since r256550 because we end up trying to
> > build_address of
> > a CONSTRUCTOR, but that doesn't work because we hit
> > gcc_checking_assert (TREE_CO
OK.
On Thu, Feb 1, 2018 at 3:23 PM, Marek Polacek wrote:
> On Thu, Feb 01, 2018 at 02:35:08PM -0500, Jason Merrill wrote:
>> On Tue, Jan 30, 2018 at 3:18 PM, Marek Polacek wrote:
>> > This testcase breaks since r256550 because we end up trying to
>> > build_address of
>> > a CONSTRUCTOR, but th
The libgo configury sets special flags to use when compiling the math
package, to get more efficient output. Unfortunately, it did not use
those flags when testing the math package. This patch fixes that.
Fixing that revealed that the flags weren't OK for the current math
package, so this patch s
Hi
As we just bump version namespace it might be interesting to do the
following change now. What do you think ?
François
diff --git a/libstdc++-v3/include/bits/forward_list.h b/libstdc++-v3/include/bits/forward_list.h
index 56b3ac5..05abd43 100644
--- a/libstdc++-v3/include/bits/forward_
The previous patch didn't resolve all the false positives
in the Linux kernel. The attached is an update that fixes
the remaining one having to do with multidimensional array
members:
struct S { char a[2][4]; };
void f (struct S *p, int i)
{
strcpy (p->a[0], "012");
strcpy (p->a[i
This patch by Cherry Zhang turns on escape analysis by default in the
Go frontend. It's late for this change but I'd like this work to get
out. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.
Committed to mainline.
Ian
2018-02-01 Ian Lance Taylor
* lang.opt (fgo-optimize): Remove
This libgo patch by James Clarke scans the register backing store on
ia64 when doing a Go garbage collection. On ia64, a separate stack is
used for saving/restoring register frames, occupying the other end of
the stack mapping. This must also be scanned for pointers into the
heap. Bootstrapped an
This patch by Cherry Zhang enables some tests in the reflect package
that depend on escape analysis being enabled by default. Bootstrapped
and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
==
In dealing with variadic capture, we've historically not bothered
trying to track the capture proxies and just dealt with the
COMPONENT_REFs directly. This was breaking the new DECL_CAPTURED_VAR
code. The simplest solution for now is to make an exception for this
case; this doesn't actually cause
71 matches
Mail list logo
