Committed as obvious after regression testing.
Regards,
Jerry
Author: jvdelisle
Date: Sat Mar 4 03:13:34 2017
New Revision: 245891
URL: https://gcc.gnu.org/viewcvs?rev=245891&root=gcc&view=rev
Log:
2017-03-03 Jerry DeLisle
PR fortran/79841
* openmp.c (check_symbol_not_poin
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators. The file is available at:
http://translationproject.org/latest/gcc/de.po
(This file, 'gcc-7.1-b20170226.de.po', h
On Fri, Mar 03, 2017 at 02:58:06PM -0600, Segher Boessenkool wrote:
> On Fri, Mar 03, 2017 at 03:43:03PM -0500, Michael Meissner wrote:
> > On Fri, Mar 03, 2017 at 02:19:57PM -0600, Segher Boessenkool wrote:
> > > On Fri, Mar 03, 2017 at 05:28:27PM +0100, Jakub Jelinek wrote:
> > > Yeah, it looks l
On Fri, Mar 03, 2017 at 03:43:03PM -0500, Michael Meissner wrote:
> On Fri, Mar 03, 2017 at 02:19:57PM -0600, Segher Boessenkool wrote:
> > On Fri, Mar 03, 2017 at 05:28:27PM +0100, Jakub Jelinek wrote:
> > Yeah, it looks like these patterns should use VSX_D instead of VSX_LE.
> > Mike, you know th
On Fri, Mar 03, 2017 at 02:19:57PM -0600, Segher Boessenkool wrote:
> Hi,
>
> On Fri, Mar 03, 2017 at 05:28:27PM +0100, Jakub Jelinek wrote:
> > E.g. in vsx.md the thing is that
> > the pattern uses an iterator with 2 V2?? modes in it and then V1TI mode,
> > and uses exactly two elements in parall
Hi,
On Fri, Mar 03, 2017 at 05:28:27PM +0100, Jakub Jelinek wrote:
> E.g. in vsx.md the thing is that
> the pattern uses an iterator with 2 V2?? modes in it and then V1TI mode,
> and uses exactly two elements in paralle, which doesn't make any sense
> for V1TI.
>
> ../../gcc/config/rs6000/vsx.md:
Hi!
In both cases starting with the UDR additions we are looking for any
identifiers, both min and max are identifiers, so no need to mention them
explicitly. They are just kind like predefined UDRs.
Committed to trunk.
2017-03-03 Jakub Jelinek
PR c/79837
* c-parser.c (c_par
Hi!
Missed % before > in 3 spots (strangely, all of them in the C FE).
The first hunk committed as obvious, the second two falls under OpenMP
maintainance, committed to trunk.
2017-03-03 Jakub Jelinek
PR c/79836
* c-parser.c (c_parser_generic_selection): Use %<_Generic%>
On Fri, Mar 03, 2017 at 12:18:09PM +0100, Uros Bizjak wrote:
> Yes. Although expander takes care not to generate two memory
> references, combine can propagate memory to the other operand,
> creating semi-invalid RTX that is later resolved by RA.
Here is a patch which does that.
Bootstrapped/regt
Hi!
vpermq/vpermpd instructions for 512-bit vectors use bogus RTL and if
we happen to simplify-rtx.c it, we ICE.
The problem is that for V8D[IF]mode VEC_SELECT we need to use a PARALLEL
with 8 elements, not 4.
The _vec_dup_1 change is unrelated to this, spotted
first by manual inspection and verif
Hi!
Seems callers of cxx_eval_constant_expression don't really like if it
returns NULL, which is what cxx_eval_statement_list returns for empty
STATEMENT_LIST. In statement expressions we treat those the same
as (void) 0 or any other statement with void value.
Bootstrapped/regtested on x86_64-li
On 03/03/2017 02:33 PM, Marek Polacek wrote:
2017-03-03 Marek Polacek
PR c/79758
* c-decl.c (store_parm_decls_oldstyle): Check if the element of
current_function_prototype_arg_types is error_mark_node. Fix
formatting. Use TREE_VALUE instead of TREE_TYPE.
Looking how our snapshots are secured in terms of checksums, I
noticed we're still using MD5 and SHA-1 hashes.
Which is unfortunate, given that MD5 has been considered weak for
what, a decade?, and SHA-1 has been considered weak for years as
well and now been demonstrated broken for real.
So I
On January 31st I commited a patch that improves conversion of signed/unsigned
char/short values to 32-bit and 64-bit floating point on Power9, particularly
when the values are coming from memory. This adds similar support to
_Float128/__float128 (i.e. IEEE 128-bit floating point). I have tested
ping
The MSP430 target supports the automatic placement of functions and
data in different memory regions when passing the
"-mdata-region=either" and "-mcode-region=either" options.
MSP430x devices support the large memory model, "-mlarge", which
enables 20 bit pointers, however the vector table
* Claudiu Zissulescu [2017-02-28 16:59:58
+0100]:
> Hi,
>
> fwprop step is placing in the REG_EQUIV notes constant pic unspecs
> expressions. Then, loop may use these notes for optimizations
> rezulting in complex patterns that are not supported by the current
> implementation.
>
> The patch
On 03/03/2017 08:36 AM, Bernd Schmidt wrote:
Reload is designed in a way to avoid cycles and to process all reloads
for an insn in order of ascending class so as to avoid this kind of
issue. With LRA I'm really not sure how to fix this properly, but the
following patch seems to cure the PR
We weren't replacing PLACEHOLDER_EXPR in the following testcase, leading to a
crash in the gimplifier. The fix seems to be to use replace_placeholders, the
question is where. These three functions have it:
cp_gimplify_init_expr
store_init_value
build_new_1
But we call neither so I tried adding t
Hi!
When working on PR79812 which was caused by bugs in x86 define_insn
(used vec_select with parallel as last operand with incorrect number of
operands), I wrote following sanity checking.
The thing is that e.g. simplify-rtx.c already has such assertions:
if (!VECTOR_MODE_P (mode))
Hi all,
This patch fixes the aarch64 bootstrap failure I've encountered.
Richi suggested on IRC that we should be using .ulow () on the wide_int insetad
of
accessing elt (0) as that doesn't play well with the uninit analysis.
Bootstrapped and tested on aarch64-none-linux-gnu.
Committing to tru
Hello!
While looking in this area, I've noticed that there are constraints
that allow wide immediate operands that result in unsupported
immediate->memory moves on 64bit targets. Since these immediates have
to be limited to 32bits, we have to use C constraint that allows only
all-bits-zero 0.0 FP
This patch caused a new regression on AIX.
- David
FAIL: 17_intro/names.cc (test for excess errors)
Excess errors:
/tmp/GCC/gcc/include-fixed/sys/types.h:600: error: expected
unqualified-id before '[' token
/tmp/GCC/gcc/include-fixed/sys/types.h:600: error: expected ')' before '[' token
/tmp/GCC/
On Fri, Mar 3, 2017 at 4:20 PM, Koval, Julia wrote:
> Hi,
> This patch fixes PR79731. Ok for trunk?
>
> gcc/
> * config/i386/i386.c (ix86_minimum_incoming_stack_boundary): Fix
> boundary for interrupt
...: Set incoming stack boundary to 128 for 64-bit targets.
> gcc/testsuite/
>
Hi,
This patch fixes PR79731. Ok for trunk?
gcc/
* config/i386/i386.c (ix86_minimum_incoming_stack_boundary): Fix
boundary for interrupt
gcc/testsuite/
* gcc.target/i386/interrupt-12.c: Fix test.
* gcc.target/i386/interrupt-13.c: Ditto.
* gcc.target/i386/interrupt
Hello,
I hit this compile warning running `make check` on AIX. Since -Werror is
enabled by default here it causes a build failure.
Tested on powerpc-ibm-aix7.2.0.0
This my first patch submission for GCC, so please let me know if I need
to do anything differently.
Thanks
Sam
>From a0d73b85afd
This is an ICE where setup_pressure_classes fails if xmm0 is a global
reg. Instead of GENERAL/FLOAT/SSE/MMX_REGS, it computes only
SSE_FIRST_REG as the third register class. The problem is that the costs
for moving between SSE_FIRST_REG and SSE_REGS are inflated because we
think we have no avai
In this PR, we have an endless cycle in LRA, generating ever more
instructions. The relevant portions of the dump seem to be these:
** Local #9: **
Creating newreg=130 from oldreg=128, assigning class CREG to r130
18:
{r117:DI=unspec/v[[r129:SI*0x8+r123:SI],r117:DI,r122
On Thu, Mar 02, 2017 at 08:47:57PM +0100, Bernd Schmidt wrote:
> On 03/02/2017 06:35 PM, Marek Polacek wrote:
> > While at it, I fixed wrong formatting in the nearby code. Also use
> > NULL_TREE
> > instead of 0 where appropriate. I really dislike those zeros-as-trees; one
> > day I'll just go a
> From: Matthew Fortune
> >
> > gcc/testsuite/
> >
> > * gcc.target/mips/pr68273.c (dg-final): Match SImode registers only for
> > ilp32 targets and match DImode registers for lp64 targets.
>
> OK, thanks.
>
> Matthew
Committed as r245874.
Thanks,
Toma
The missing patch.
>From d539ba1a94ab85445f54c1742ff8e924e915f06a Mon Sep 17 00:00:00 2001
From: marxin
Date: Fri, 3 Mar 2017 13:50:42 +0100
Subject: [PATCH] Remove unused variable.
gcc/ChangeLog:
2017-03-03 Martin Liska
* tree-ssa-loop-prefetch.c (pass_loop_prefetch::execute):
Remove unus
On Fri, 3 Mar 2017, Jakub Jelinek wrote:
> On Fri, Mar 03, 2017 at 09:21:55AM +0100, Richard Biener wrote:
> > > --- gcc/gimple-fold.c.jj 2017-02-07 16:40:45.0 +0100
> > > +++ gcc/gimple-fold.c 2017-03-02 16:04:51.304850077 +0100
> > > @@ -3533,6 +3533,8 @@ fold_builtin_atomic_compare
On Thu, Mar 02, 2017 at 06:49:32PM +0100, Martin Liška wrote:
> It can happen with inlining and -fno-tree-dce that VAR_DECL for a SSA
> NAME was removed and thus the poisoning should not have any usage.
>
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> Ready to be
Hello.
This fixes copy&paste error, it's trivial, thus I'm going to install it.
Thanks,
Martin
x32 does not support -mmpx.
2017-03-03 Uros Bizjak
* g++.dg/pr71624.C: Disable for x32.
* g++.dg/pr71633.C: Ditto.
Tested on x86_64-linux-gnu {,32}, committed.
Uros.
Index: g++.dg/pr71624.C
===
--- g++.dg/pr71624.C(r
On Fri, Mar 3, 2017 at 12:30 PM, Jakub Jelinek wrote:
>> Regarding the implementation, I'd rather see another flag for
>> i386-builtin.def entries, where we can mark if matching memory operand
>> is allowed. The expander can then look at the flag, and do some
>> special magic.
>
> I think maintai
Hello.
I'm sending Honza's patch (which is pre-approved) that I've just tested on
ppc64le-redhat-linux.
It also fixes the issue spotted in the PR.
Martin
>From 10050e47af7dbf217469da083666b16dbbbf606d Mon Sep 17 00:00:00 2001
From: marxin
Date: Thu, 2 Mar 2017 18:46:25 +0100
Subject: [PATCH] Pr
OK.
On Fri, Mar 3, 2017 at 12:26 AM, Paolo Carlini wrote:
> Hi,
>
> one more case of OVERLOAD filtering to cxx_eval_constant_expression and
> causing an ICE.
>
> In order to have a proper diagnostic early enough I think that in
> build_must_not_throw_expr we want to use perform_implicit_conversio
The following reverts uhigh back to elt (1) which are not 100%
semantically equivalent (and the change is not needed to avoid
the warning-prone elt (0)).
Bootstrapped / tested on x86_64-unknown-linux-gnu, applied.
Richard.
2017-03-03 Richard Biener
* fixed-value.c (fixed_from_string
On Fri, Mar 03, 2017 at 12:18:09PM +0100, Uros Bizjak wrote:
> > as the constraint require that both operands aren't memory, shall I create a
> > patch for that? This is the first category below.
>
> Yes. Although expander takes care not to generate two memory
> references, combine can propagate
On Fri, Mar 3, 2017 at 11:35 AM, Jakub Jelinek wrote:
> On Fri, Mar 03, 2017 at 09:10:03AM +0100, Uros Bizjak wrote:
>> > Or are there any define_insn/define_expand where it is desirable to have
>> > both input and output operand a MEM (and does it have to be matching)?
>> > For various scalar bin
On Fri, Mar 03, 2017 at 09:21:55AM +0100, Richard Biener wrote:
> > --- gcc/gimple-fold.c.jj2017-02-07 16:40:45.0 +0100
> > +++ gcc/gimple-fold.c 2017-03-02 16:04:51.304850077 +0100
> > @@ -3533,6 +3533,8 @@ fold_builtin_atomic_compare_exchange (gi
> >tree itype = TREE_VALUE (
On Thu, Mar 2, 2017 at 8:58 PM, Bernd Schmidt wrote:
> On 03/02/2017 06:50 PM, Martin Liška wrote:
>>
>> Hello.
>>
>> This is second part of fixes needed to not trigger integer overflow in
>> gcse pass.
>
>
> So, how is this intended to work? The min/max stored in the param is an int,
> and by usi
On Thu, Mar 2, 2017 at 10:33 PM, Martin Sebor wrote:
> On 03/02/2017 01:08 AM, Richard Biener wrote:
>>
>> On Thu, Mar 2, 2017 at 2:01 AM, Joseph Myers
>> wrote:
>>>
>>> On Wed, 1 Mar 2017, Martin Sebor wrote:
>>>
Joseph, since you commented on the bug, do you have a suggestion
for a di
On Fri, Mar 3, 2017 at 11:57 AM, Richard Biener
wrote:
> On Thu, Mar 2, 2017 at 6:48 PM, Martin Liška wrote:
>> Hello.
>>
>> I've just followed Richi's advises in the PR.
>>
>> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>>
>> Ready to be installed?
>
> I think the
On Thu, Mar 2, 2017 at 6:48 PM, Martin Liška wrote:
> Hello.
>
> I've just followed Richi's advises in the PR.
>
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> Ready to be installed?
I think the check tests for power-of two, not even. Also you should mention
thi
On Thu, Mar 2, 2017 at 4:39 PM, Robin Dapp wrote:
> Hi,
>
> the following patch defines the PARAM_MIN_VECT_LOOP_BOUND parameter in
> the s390 backend. It helps with the vectorization epilogue problem
> described here [1].
> I see an overall performance increase of > 1% in SPECfp2006, yet some
> c
If using -mwarn-cell-microcode, rs6000_final_prescan_insn calls
get_insn_template to get the name of the machine instruction. But,
get_insn_template calls the output template if that is code, and that
then can modify recog_data (it is normal to change the operands, for
example).
This patch saves
On Fri, Mar 03, 2017 at 09:10:03AM +0100, Uros Bizjak wrote:
> > Or are there any define_insn/define_expand where it is desirable to have
> > both input and output operand a MEM (and does it have to be matching)?
> > For various scalar binary and unary expanders the backend already uses a
> > help
On 03/02/2017 08:58 PM, Bernd Schmidt wrote:
> On 03/02/2017 06:50 PM, Martin Liška wrote:
>> Hello.
>>
>> This is second part of fixes needed to not trigger integer overflow in gcse
>> pass.
>
> So, how is this intended to work? The min/max stored in the param is an int,
> and by using a HOST_W
Hi,
one more case of OVERLOAD filtering to cxx_eval_constant_expression and
causing an ICE.
In order to have a proper diagnostic early enough I think that in
build_must_not_throw_expr we want to use
perform_implicit_conversion_flags on the condition before calling
cxx_constant_value for it.
On Fri, 3 Mar 2017, Richard Sandiford wrote:
> Richard Biener writes:
> > On Wed, 1 Mar 2017, Richard Sandiford wrote:
> >
> >> Richard Biener writes:
> >> > On Wed, 1 Mar 2017, Richard Sandiford wrote:
> >> >
> >> >> Richard Biener writes:
> >> >> > On Wed, 1 Mar 2017, Richard Sandiford wrote:
The following obvious patch fixes PR79825, we were not treating
EMPTY_CLASS_EXPR as simple_empty_class_p.
Bootstrap / regtest running on x86_64-unknown-linux-gnu.
Richard.
2017-03-03 Richard Biener
PR c++/79825
* cp-gimplify.c (simple_empty_class_p): Handle EMPTY_CLASS_EXPR.
This link broke, but I found a replacement that is actually more
in line with the other references in that section (in that it uses
the ShowIssue facility on www.dwarfstd.org).
Applied.
Gerald
Index: changes.html
===
RCS file: /cvs/
Richard Biener writes:
> On Wed, 1 Mar 2017, Richard Sandiford wrote:
>
>> Richard Biener writes:
>> > On Wed, 1 Mar 2017, Richard Sandiford wrote:
>> >
>> >> Richard Biener writes:
>> >> > On Wed, 1 Mar 2017, Richard Sandiford wrote:
>> >> >
>> >> >> Richard Biener writes:
>> >> >> > On Wed, 1
On Thu, Mar 2, 2017 at 7:52 PM, Uros Bizjak wrote:
> Attached patch adds new insn_and_split pattern to handle pre_modify
> XFmode push variant. -m96bit-long-double option sets XFmode size to 12
> bytes that is not divisible with push size (8 bytes), resulting in
> pre_modify push variant.
Attache
On Thu, 2 Mar 2017, Martin Sebor wrote:
> On 03/02/2017 12:58 AM, Richard Biener wrote:
> > On Wed, 1 Mar 2017, Martin Sebor wrote:
> >
> > > On 02/28/2017 11:41 PM, Richard Biener wrote:
> > > > On March 1, 2017 3:34:46 AM GMT+01:00, Martin Sebor
> > > > wrote:
> > > > > On 02/28/2017 01:41 PM,
On Thu, 2 Mar 2017, Jakub Jelinek wrote:
> Hi!
>
> The __atomic/__sync builtins have nothrow conditional on
> -fnon-call-exceptions, but internal fns have right now only constant flags.
> As per discussions on IRC, this patch removes ECF_NOTHROW from those 4 ifns
> and instead calls gimple_call_s
On Thu, Mar 2, 2017 at 10:44 PM, Jakub Jelinek wrote:
> Hi!
>
> For -O1 and above, we force all operands and targets of x86 builtins into
> registers during expansion, because we expect combiner will do its job.
> But for -O0, we try to keep them in MEM if the predicate allows it, we just
> make s
58 matches
Mail list logo