Re: [PATCH] Add some REG_POINTER flags during ix86 memcpy/memset expansion (PR target/65504)
On 03/23/2015 03:33 PM, Eric Botcazou wrote: FWIW, you have to be very careful depending on REG_POINTER. I believe Ada can still set REG_POINTER on things that are not pointers (via virtual origins) and cross jumping can cause problems too where one arm has x + y with X as the pointer and the other arm has x + y with Y as the pointer. Can you elaborate a bit about Ada here? Front-ends don't fiddle directly with RTL for years so I'm a little at a loss here. It's been years since I looked at this, but my recollection was that the Ada front end could set REG_POINTER for virtual origins. From a correctness standpoint it only matters on a few obscure targets and only causes a failure when the flag is set on a pseudo with a value on a different, unmapped, page than the full effective address. Jeff
Re: [patch c++]: Fix for PR/65390
On 03/20/2015 10:53 AM, Kai Tietz wrote: * tree.c (strip_typedefs): Ignore alignment difference during processing template. + || (processing_template_decl + && TYPE_ALIGN (t) != TYPE_ALIGN (result))) Your change is actually ignoring alignment differences when *not* processing a template, which isn't what we want. The problem is that the type is considered dependent in a template but is not actually dependent, so we can see the exact same type outside a template and it's not dependent. So, this code is creating the difference: /* We can only call value_dependent_expression_p on integral constant expressions; treat non-constant expressions as dependent, too. */ if (processing_template_decl && (type_dependent_expression_p (size) || !TREE_CONSTANT (size) || value_dependent_expression_p (size))) Now that we have instantiation_dependent_expression_p, we should be able to use that instead of checking type/value dependency separately. Jason
Re: [GOOGLE] Avoid calling walk_aliased_vdefs in O0 function
ok. On Mon, Mar 23, 2015 at 5:37 PM, Carrot Wei wrote: > This patch fixes google internal bug b/19277289. It can only be > reproduced in google 4.9 branch. > > In function param_change_prob, there is following function call > > walk_aliased_vdefs (&refd, gimple_vuse (stmt), record_modified, &info, NULL); > > If the source code is compiled with optimization, but cfun is compiled > with -O0, gimple_vuse (stmt) can be null, and walk_aliased_vdefs will > crash. > > Previously we didn't reach walk_aliased_vdefs because bb->frequency is > 0, and following code always return early. > > if (!bb->frequency) > return REG_BR_PROB_BASE; > > Dehao's patch r210989 propagates some non-zero value into > bb->frequency, so now it doesn't return early and reaches the crash > point. > > An obvious fix is skipping O0 functions in inline_generate_summary, > but many other places will access data structures created in > inline_analyze_function without check O0 for individual functions, and > will crash. So this patch simply checks if O0 is specified then return > early in function param_change_prob, same behavior as previous. > > Boot strapped on x86-64, passed regression test on x86-64 and arm. > > OK for google 4.9 branch?
[patch, doc] clean up index entries for attributes
I've checked in this patch to add missing @cindex entries for many
attributes listed in extend.texi, and make the format of the existing
entries consistent. Along the way I noticed some obsolete or
miscategorized target-specific attribute documentation, which I fixed
along with a few typos and such like.
The organization of the attribute documentation is still a big mess.
Contrary to the admonition in the comments at the top of the table in
the Function Attributes section, its contents are not alphabetized, nor
is that section broken up into subsections to cover target-specific
attributes as the Variable Attributes and Type Attributes sections are.
I'm planning to work on that next, but if it gets too messy (e.g., with
rewrites to split up the interrupt handler discussion) it may be better
to wait until Stage 1. In the meantime getting the indexing fixed will
at least make it easier to find the documentation if you already have
some idea of what the attribute name is.
-Sandra
2015-03-23 Sandra Loosemore
gcc/
* doc/extend.texi (Function Attributes): Add @cindex entries
for all attributes and regularize their format. Delete text
about long-obsolete 68HC11 and 68HC12 targets. Move misplaced
information about "eightbit_data", "tiny_data", and "model"
variable attributes to the Variable Attributes section. Fix
some obvious typos and copy-editing issues.
(Variable Attributes, Type Attributes): Likewise add/fix
@cindex entries for all attributes.
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 221583)
+++ gcc/doc/extend.texi (working copy)
@@ -2208,7 +2208,7 @@ attributes.
@c Keep this table alphabetized by attribute name. Treat _ as space.
@item alias ("@var{target}")
-@cindex @code{alias} attribute
+@cindex @code{alias} function attribute
The @code{alias} attribute causes the declaration to be emitted as an
alias for another symbol, which must be specified. For instance,
@@ -2225,7 +2225,7 @@ is not defined in the same translation u
Not all target machines support this attribute.
@item aligned (@var{alignment})
-@cindex @code{aligned} attribute
+@cindex @code{aligned} function attribute
This attribute specifies a minimum alignment for the function,
measured in bytes.
@@ -2246,7 +2246,7 @@ The @code{aligned} attribute can also be
(@pxref{Variable Attributes}.)
@item alloc_size
-@cindex @code{alloc_size} attribute
+@cindex @code{alloc_size} function attribute
The @code{alloc_size} attribute is used to tell the compiler that the
function return value points to memory, where the size is given by
one or two of the functions parameters. GCC uses this
@@ -2271,7 +2271,7 @@ the product of parameter 1 and 2 and tha
of the size given by parameter 2.
@item alloc_align
-@cindex @code{alloc_align} attribute
+@cindex @code{alloc_align} function attribute
The @code{alloc_align} attribute is used to tell the compiler that the
function return value points to memory, where the returned pointer minimum
alignment is given by one of the functions parameters. GCC uses this
@@ -2292,7 +2292,7 @@ declares that @code{my_memalign} returns
given by parameter 1.
@item assume_aligned
-@cindex @code{assume_aligned} attribute
+@cindex @code{assume_aligned} function attribute
The @code{assume_aligned} attribute is used to tell the compiler that the
function return value points to memory, where the returned pointer minimum
alignment is given by the first argument.
@@ -2367,7 +2367,7 @@ or using the caller location for all ins
body.
@item bank_switch
-@cindex interrupt handler functions
+@cindex @code{bank_switch} function attribute, M32C
When added to an interrupt handler with the M32C port, causes the
prologue and epilogue to use bank switching to preserve the registers
rather than saving them on the stack.
@@ -2404,6 +2404,7 @@ is diagnosed earlier and with exact loca
of inline functions or when not emitting debugging information.
@item cdecl
+@cindex @code{cdecl} function attribute, x86-32
@cindex functions that do pop the argument stack on x86-32
@opindex mrtd
On the x86-32 targets, the @code{cdecl} attribute causes the compiler to
@@ -2453,7 +2454,7 @@ These attributes are not currently imple
@item deprecated
@itemx deprecated (@var{msg})
-@cindex @code{deprecated} attribute.
+@cindex @code{deprecated} function attribute
The @code{deprecated} attribute results in a warning if the function
is used anywhere in the source file. This is useful when identifying
functions that are expected to be removed in a future version of a
@@ -2477,12 +2478,14 @@ The @code{deprecated} attribute can also
types (@pxref{Variable Attributes}, @pxref{Type Attributes}.)
@item disinterrupt
-@cindex @code{disinterrupt} attribute
+@cindex @code{disinterrupt} function attribute, Epiphany
+@cindex @code{disinterrupt} function attribute, MeP
On Epiphany and MeP targets, this attribute ca
Re: Ping: [PATCH V2] IRA: Speed up setup_left_conflict_sizes_p
On 2015-03-23 9:50 PM, Zhouyi Zhou wrote: > Hi Vladimir, > I am studying IRA in my offer hours because it is marvellous and very > educative. Thanks. If you are interesting in RA whose code is available, you could also look at Fred Chow's RA code in Pathscale compiler. > Did you get a chance to look at the below patch. > The elements of allocno_hard_regs_subnode_index are setup in function > setup_allocno_hard_regs_subnode_index where elements representing subnodes of > a node > are nonegative. I think we can avoid involving the parent itself into the > loop below > because when the loop invariant i == 0, allocno_hard_regs_nodes[i + > node_preorder_num] > will be current node, I guess we are not interested in computing left > conflict subnodes > size of current node's parent in current function context. > Thanks for the patch. I believe your patch is doing a right thing. It should be committed but I'd rather wait for stage1 start which probably will happen in 2-3 weeks. I'll commit your patch right after stage1 start. If I don't do this at this time, please ping me again, Zhouyi.
Re: [PATCH] pr 63354 - gcc -pg -mprofile-kernel creates unused stack frames on leaf functions on ppc64le
On 03/21/2015 01:48 PM, Iain Sandoe wrote:
Hi Martin,
I've applied your latest patch to top of trunk and looked at the code gen on
powerpc-darwin9 (and a cross from x86-64-darwin12 => powerpc64-linux-gnu).
Thanks for the review!
2015-03-13 Anton Blanchard
PR target/63354
* gcc/config/rs6000/linux64.h (ARGET_KEEP_LEAF_WHEN_PROFILED): Define.
^ typo
It's fixed in version 2 of the patch posted here:
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00793.html
This ^ will cause a bootstrap fail for every rs6000 target that doesn't include
linux64.h.
(because rs6000_keep_leaf_when_profiled will be "defined but unused").
Since ISTM you intend this to apply to all rs6000 sub-targets, you might as
well move it to rs6000.h?
The powerpc-darwin9 and powerpc64-darwin9 targets both built
successfully with this patch. I also tried powerpc64-freebsd,
which succeeded as well (though I had to work around pr65535).
What target do you suggest I try to reproduce the failure?
(I don't mind moving the macro definition as you suggest,
but I'd like to understand how to trigger the problem so
that I can reproduce it and verify that I've fixed it.)
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr63354.c
@@ -0,0 +1,10 @@
+/* { dg-do compile { target { powerpc*-*-* } } } */
...
a bare register # will, indeed, fail for Darwin's native assembler (which
expects r#).
Thanks. I don't have access to Darwin but I changed the target
in version 2 of the patch to powerpc64*-linux* to make the test
unsupported only on Linux but now that I've tried running it on
a non-linux target I see it fails with:
dg-process-target-1: `{target powerpc64*-linux*}'
ERROR: gcc.target/powerpc/pr63354.c: syntax error in target selector
"target powerpc64*-linux*" for " dg-do 1 compile { target {
powerpc64*-linux* } } "
Changing the target to powerpc64*-*-linux* eliminates the
error and results in an unsupported test as intended. I'll
post a new patch with the fix for this and with one linux64.h
problem you mentioned above once I reproduce it and verify
that the suggested solution fixes it.
Martin
Re: [PATCH] Fix PR65494
On Mon, Mar 23, 2015 at 5:42 AM, Richard Biener wrote: > > This fixes PR65494 - I don't remember why I re-allocated matches > before recursing into operands. But that at least breaks backtracking. > > Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. > > Richard. > > 2015-03-23 Richard Biener > > PR tree-optimization/65494 > * tree-vect-slp.c (vect_build_slp_tree): Do not (re-)allocate > matches here. > (vect_analyze_slp_instance): But do that here, always and once. This caused: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65533 -- H.J.
Ping: [PATCH V2] IRA: Speed up setup_left_conflict_sizes_p
Hi Vladimir,
I am studying IRA in my offer hours because it is marvellous and very
educative.
Did you get a chance to look at the below patch.
The elements of allocno_hard_regs_subnode_index are setup in function
setup_allocno_hard_regs_subnode_index where elements representing subnodes of a
node
are nonegative. I think we can avoid involving the parent itself into the loop
below
because when the loop invariant i == 0, allocno_hard_regs_nodes[i +
node_preorder_num]
will be current node, I guess we are not interested in computing left conflict
subnodes
size of current node's parent in current function context.
Thanks and Regards
Zhouyi
-- Forwarded message --
From: Zhouyi Zhou
Date: Thu, Mar 12, 2015 at 9:34 AM
Subject: [PATCH V2] IRA: Speed up setup_left_conflict_sizes_p
To: gcc-patches@gcc.gnu.org, richard.guent...@gmail.com
Cc: Zhouyi Zhou , Zhouyi Zhou
From: Zhouyi Zhou
In function setup_left_conflict_sizes_p, left conflict subnodes sizes
are computed in a bottom-to-up fashion through the regnodes foreast.
Speed up the process from prevent node itself to involve in this
computation.
I have no write access to GCC SVN repository, if it OK, can you commit
for me?
(Thanks Richard for reviewing)
Bootstrap and regtest scheduled on x86_64 GNU/Linux
Signed-off-by: Zhouyi Zhou
---
gcc/ChangeLog |5 +
gcc/ira-color.c |8 +++-
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 53f582b..a495dfc 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2015-03-12 Zhouyi Zhou
+
+ * ira-color.c (setup_left_conflict_sizes_p): Prevent node itself
+ from computing left conflict subnodes size.
+
2015-03-10 Jan Hubicka
* cgraph.c (cgraph_node::release_body): Free function_in_decl_state.
diff --git a/gcc/ira-color.c b/gcc/ira-color.c
index ff1fe8a..d2d5102 100644
--- a/gcc/ira-color.c
+++ b/gcc/ira-color.c
@@ -938,7 +938,7 @@ setup_left_conflict_sizes_p (ira_allocno_t a)
subnodes[i].left_conflict_subnodes_size = 0;
}
start = node_preorder_num * allocno_hard_regs_nodes_num;
- for (i = data->hard_regs_subnodes_num - 1; i >= 0; i--)
+ for (i = data->hard_regs_subnodes_num - 1; i > 0; i--)
{
int size, parent_i;
allocno_hard_regs_node_t parent;
@@ -948,12 +948,10 @@ setup_left_conflict_sizes_p (ira_allocno_t a)
- subnodes[i].left_conflict_subnodes_size,
subnodes[i].left_conflict_size));
parent = allocno_hard_regs_nodes[i + node_preorder_num]->parent;
- if (parent == NULL)
- continue;
+ gcc_checking_assert(parent);
parent_i
= allocno_hard_regs_subnode_index[start + parent->preorder_num];
- if (parent_i < 0)
- continue;
+ gcc_checking_assert(parent_i >= 0);
subnodes[parent_i].left_conflict_subnodes_size += size;
}
left_conflict_subnodes_size = subnodes[0].left_conflict_subnodes_size;
--
1.7.10.4
[GOOGLE] Avoid calling walk_aliased_vdefs in O0 function
This patch fixes google internal bug b/19277289. It can only be reproduced in google 4.9 branch. In function param_change_prob, there is following function call walk_aliased_vdefs (&refd, gimple_vuse (stmt), record_modified, &info, NULL); If the source code is compiled with optimization, but cfun is compiled with -O0, gimple_vuse (stmt) can be null, and walk_aliased_vdefs will crash. Previously we didn't reach walk_aliased_vdefs because bb->frequency is 0, and following code always return early. if (!bb->frequency) return REG_BR_PROB_BASE; Dehao's patch r210989 propagates some non-zero value into bb->frequency, so now it doesn't return early and reaches the crash point. An obvious fix is skipping O0 functions in inline_generate_summary, but many other places will access data structures created in inline_analyze_function without check O0 for individual functions, and will crash. So this patch simply checks if O0 is specified then return early in function param_change_prob, same behavior as previous. Boot strapped on x86-64, passed regression test on x86-64 and arm. OK for google 4.9 branch? patch Description: Binary data
New French PO file for 'cpplib' (version 5.1-b20150208)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the French team of translators. The file is available at: http://translationproject.org/latest/cpplib/fr.po (This file, 'cpplib-5.1-b20150208.fr.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/cpplib/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/cpplib.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: [Patch] OPT: Update heuristics for loop-invariant for address arithmetic.
On 2015-03-23 12:35 PM, Ajit Kumar Agarwal wrote: > Hello All: > > Did you get a chance to look at the below patch. > > Thanks & Regards > Ajit > > -Original Message- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On > Behalf Of Ajit Kumar Agarwal > Sent: Wednesday, March 04, 2015 3:57 PM > To: vmaka...@redhat.com; GCC Patches > Cc: Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala > Subject: [Patch] OPT: Update heuristics for loop-invariant for address > arithmetic. > > Hello All: > > The changes are made in the patch to update the heuristics for loop invariant > for address arithemetic at RTL Level. > The heuristics are updated with the consideration of single def and use for > register pressure calculation instead Of ignoring it and also to update the > estimated register pressure cost along with the check of actual uses with > Address uses. > > With the above change, gains are seen in the Geomean for Mibench/EEMBC > benchmarks for microblaze target. No Regression is seen in deja GNU > regressions tests for microblaze. > > Sorry, I am not a maintainer/reviewer of loop invariant motion pass. I had no power to approve this, especially when you change mostly code for ! flag_ira_loop_pressure. I only should say that microblaze is not a primary target. You should demonstrate improvement on a primary target, x86/x86-64 the best. SPEC2000 or SPEC2006 would be a good benchmark for this.
Re: [Patch] IRA: Update heuristics for optimal coalescing
Sorry, for postponing it. I was going to do this when stage1 starts. After reading this today I have some comments. I believe the copy frequency should be not changed. If you want coalesce copies according the frequency of loop back edges on which the allocno involved in given copy lives you should implement sorting according it w/o changes the copy frequency. I don't see a logical sense to sort copies according to your criteria and don't understand why you consider only one allocno involved in the copy on its back-edge frequencies (as another allocno can live on back edges too). But sometime heuristics work opposite to rational sense. It might be this case. But still I need a prove that there is an improvement on x86/x86-64 SPEC too. If you can not run x86/x86-64 SPEC2000, I can do this but it will take some time and I can do this in Apr when probably stage1 starts. Besides these 2 important comments, some work needs to be done to make the patch conforming GNU coding standards used in GCC: a necessary comment for ira_loop_back_edge_freq. But there is no sense to fix this as probably the patch will be rewritten. On 2015-03-23 12:18 PM, Ajit Kumar Agarwal wrote: > Hello Vladimir: > > Did you get a chance to look at the below patch. > > Thanks & Regards > Ajit > > -Original Message- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On > Behalf Of Ajit Kumar Agarwal > Sent: Friday, February 27, 2015 11:25 AM > To: vmaka...@redhat.com; Jeff Law; GCC Patches > Cc: Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala > Subject: [Patch] IRA: Update heuristics for optimal coalescing > > Hello Vladimir: > > The changes in the patch are made in the frequency heuristics for optimal > coalescing. The Loop back edge frequencies are taken instead of the block > frequency for optimal coalescing. Ignores the frequency for the loop for the > allocno not having references inside the loops but spans the loops and live > at the exit block of the loop. Another similar change are made not to > consider allcono frequency at the cost calculation but to consider the loop > back edge frequencies having references and spans through the loop and live > at the exit of the block. > > We have tested the changes with MIBench and EEMBC benchmarks and there is a > gain in the Geomean for the overall benchmarks for Microblaze target. Also no > regressions are seen in deja GNU tests run for microblaze. > > Please let us know with your feedbacks. > > commit e6a2edd3794080a973695f80e77df3e7de55452d > Author: Ajit Kumar Agarwal > Date: Fri Feb 27 11:15:48 2015 +0530 > > IRA: Update heuristics for optimal coalescing. > > The changes are made in the frequency heuristics for optimal coalescing. > The Loop back edge frequencies are taken instead of the block frequency > for optimal coalescing. Ignores the frequency for the loop having not any > references but spans the loop and live at the exit block of the loop. > Another similar change not to consider allcono frequency at the cost > calculation but to consider the loop back edge frequencies having > references > and spans through the loop and live at the exit of the block. > > ChangeLog: > 2015-02-27 Ajit Agarwal > > * ira-color.c (ira_loop_back_edge_freq): New. > (coalesce_allocnos): Use of ira_loop_back_edge_freq to update > the back edge frequencies. > (setup_coalesced_allocno_costs_and_nums): Use of > ira_loop_back_edge_freq to update the cost. > > Signed-off-by:Ajit Agarwal ajit...@xilinx.com > > Thanks & Regards > Ajit
Re: [PATCH] Add some REG_POINTER flags during ix86 memcpy/memset expansion (PR target/65504)
> FWIW, you have to be very careful depending on REG_POINTER. I believe > Ada can still set REG_POINTER on things that are not pointers (via > virtual origins) and cross jumping can cause problems too where one arm > has x + y with X as the pointer and the other arm has x + y with Y as > the pointer. Can you elaborate a bit about Ada here? Front-ends don't fiddle directly with RTL for years so I'm a little at a loss here. -- Eric Botcazou
Re: [PATCH] Fix a -fcheck-pointer-bounds -mmpx ICE (PR target/65523)
On March 23, 2015 8:54:54 PM GMT+01:00, Jakub Jelinek wrote:
>Hi!
>
>On the following testcase we ICE, because we don't verify we have the
>ERF_RETURNS_ARG argument, on non-verified builtins that is possible.
>Other uses of ERF_RETURNS_ARG seem to verify it.
>Also, there was an unneeded extra gimple_call_return_flags call,
>the condition has already checked that ERF_RETURNS_ARG flag is set.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
Thanks,
Richard.
>2015-03-23 Jakub Jelinek
>
> PR target/65523
> * tree-chkp.c (chkp_build_returned_bound): Ignore
> ERF_RETURNS_ARG calls if they have fewer than needed arguments.
>
> * gcc.target/i386/pr65523.c: New test.
>
>--- gcc/tree-chkp.c.jj 2015-03-09 08:05:05.0 +0100
>+++ gcc/tree-chkp.c2015-03-23 14:37:52.469289930 +0100
>@@ -2153,6 +2153,7 @@ chkp_build_returned_bound (gcall *call)
> tree bounds;
> gimple stmt;
> tree fndecl = gimple_call_fndecl (call);
>+ unsigned int retflags;
>
> /* To avoid fixing alloca expands in targets we handle
> it separately. */
>@@ -2196,12 +2197,11 @@ chkp_build_returned_bound (gcall *call)
> }
> /* Do not use retbnd when returned bounds are equal to some
> of passed bounds. */
>- else if (gimple_call_return_flags (call) & ERF_RETURNS_ARG)
>+ else if (((retflags = gimple_call_return_flags (call)) &
>ERF_RETURNS_ARG)
>+ && (retflags & ERF_RETURN_ARG_MASK) < gimple_call_num_args (call))
> {
> gimple_stmt_iterator iter = gsi_for_stmt (call);
>- unsigned int retarg = 0, argno;
>- if (gimple_call_return_flags (call) & ERF_RETURNS_ARG)
>- retarg = gimple_call_return_flags (call) & ERF_RETURN_ARG_MASK;
>+ unsigned int retarg = retflags & ERF_RETURN_ARG_MASK, argno;
> if (gimple_call_with_bounds_p (call))
> {
> for (argno = 0; argno < gimple_call_num_args (call); argno++)
>--- gcc/testsuite/gcc.target/i386/pr65523.c.jj 2015-03-23
>14:44:36.977729292 +0100
>+++ gcc/testsuite/gcc.target/i386/pr65523.c2015-03-23
>14:45:17.518071777 +0100
>@@ -0,0 +1,11 @@
>+/* PR target/65523 */
>+/* { dg-do compile } */
>+/* { dg-options "-fcheck-pointer-bounds -mmpx" } */
>+
>+void *memmove ();
>+
>+void *
>+bar ()
>+{
>+ return memmove ();
>+}
>
> Jakub
Re: [PATCH] Update pr29215.c testcase for recent gimplify.c changes (PR testsuite/65506)
On March 23, 2015 8:56:32 PM GMT+01:00, Jakub Jelinek wrote:
>Hi!
>
>Since recent gimplifier changes, memcpy at least on some architectures
>might
>not be folded already during gimplification, so we need to wait until
>ccp1.
>
>Regtested on x86_64-linux and i686-linux, tested with hppa-linux
>cross-compiler too, ok for trunk?
OK
Thanks,
Richard.
>2015-03-23 Jakub Jelinek
>
> PR testsuite/65506
> * gcc.dg/pr29215.c: Dump and analyse ccp1 dump instead of
> gimple dump.
>
>--- gcc/testsuite/gcc.dg/pr29215.c.jj 2008-11-21 14:05:09.0
>+0100
>+++ gcc/testsuite/gcc.dg/pr29215.c 2015-03-23 15:02:06.252770764 +0100
>@@ -1,6 +1,6 @@
> /* PR middle-end/29215 */
> /* { dg-do compile } */
>-/* { dg-options "-O2 -fdump-tree-gimple" } */
>+/* { dg-options "-O2 -fdump-tree-ccp1" } */
>
>char buf[5 * sizeof (int) + 1] __attribute__((aligned (__alignof__
>(int;
>
>@@ -29,5 +29,5 @@ main (void)
> return 0;
> }
>
>-/* { dg-final { scan-tree-dump-not "memcpy" "gimple" } } */
>-/* { dg-final { cleanup-tree-dump "gimple" } } */
>+/* { dg-final { scan-tree-dump-not "memcpy" "ccp1" } } */
>+/* { dg-final { cleanup-tree-dump "ccp1" } } */
>
> Jakub
[PATCH] Update pr29215.c testcase for recent gimplify.c changes (PR testsuite/65506)
Hi!
Since recent gimplifier changes, memcpy at least on some architectures might
not be folded already during gimplification, so we need to wait until ccp1.
Regtested on x86_64-linux and i686-linux, tested with hppa-linux
cross-compiler too, ok for trunk?
2015-03-23 Jakub Jelinek
PR testsuite/65506
* gcc.dg/pr29215.c: Dump and analyse ccp1 dump instead of
gimple dump.
--- gcc/testsuite/gcc.dg/pr29215.c.jj 2008-11-21 14:05:09.0 +0100
+++ gcc/testsuite/gcc.dg/pr29215.c 2015-03-23 15:02:06.252770764 +0100
@@ -1,6 +1,6 @@
/* PR middle-end/29215 */
/* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-gimple" } */
+/* { dg-options "-O2 -fdump-tree-ccp1" } */
char buf[5 * sizeof (int) + 1] __attribute__((aligned (__alignof__ (int;
@@ -29,5 +29,5 @@ main (void)
return 0;
}
-/* { dg-final { scan-tree-dump-not "memcpy" "gimple" } } */
-/* { dg-final { cleanup-tree-dump "gimple" } } */
+/* { dg-final { scan-tree-dump-not "memcpy" "ccp1" } } */
+/* { dg-final { cleanup-tree-dump "ccp1" } } */
Jakub
[PATCH] Fix a -fcheck-pointer-bounds -mmpx ICE (PR target/65523)
Hi!
On the following testcase we ICE, because we don't verify we have the
ERF_RETURNS_ARG argument, on non-verified builtins that is possible.
Other uses of ERF_RETURNS_ARG seem to verify it.
Also, there was an unneeded extra gimple_call_return_flags call,
the condition has already checked that ERF_RETURNS_ARG flag is set.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2015-03-23 Jakub Jelinek
PR target/65523
* tree-chkp.c (chkp_build_returned_bound): Ignore
ERF_RETURNS_ARG calls if they have fewer than needed arguments.
* gcc.target/i386/pr65523.c: New test.
--- gcc/tree-chkp.c.jj 2015-03-09 08:05:05.0 +0100
+++ gcc/tree-chkp.c 2015-03-23 14:37:52.469289930 +0100
@@ -2153,6 +2153,7 @@ chkp_build_returned_bound (gcall *call)
tree bounds;
gimple stmt;
tree fndecl = gimple_call_fndecl (call);
+ unsigned int retflags;
/* To avoid fixing alloca expands in targets we handle
it separately. */
@@ -2196,12 +2197,11 @@ chkp_build_returned_bound (gcall *call)
}
/* Do not use retbnd when returned bounds are equal to some
of passed bounds. */
- else if (gimple_call_return_flags (call) & ERF_RETURNS_ARG)
+ else if (((retflags = gimple_call_return_flags (call)) & ERF_RETURNS_ARG)
+ && (retflags & ERF_RETURN_ARG_MASK) < gimple_call_num_args (call))
{
gimple_stmt_iterator iter = gsi_for_stmt (call);
- unsigned int retarg = 0, argno;
- if (gimple_call_return_flags (call) & ERF_RETURNS_ARG)
- retarg = gimple_call_return_flags (call) & ERF_RETURN_ARG_MASK;
+ unsigned int retarg = retflags & ERF_RETURN_ARG_MASK, argno;
if (gimple_call_with_bounds_p (call))
{
for (argno = 0; argno < gimple_call_num_args (call); argno++)
--- gcc/testsuite/gcc.target/i386/pr65523.c.jj 2015-03-23 14:44:36.977729292
+0100
+++ gcc/testsuite/gcc.target/i386/pr65523.c 2015-03-23 14:45:17.518071777
+0100
@@ -0,0 +1,11 @@
+/* PR target/65523 */
+/* { dg-do compile } */
+/* { dg-options "-fcheck-pointer-bounds -mmpx" } */
+
+void *memmove ();
+
+void *
+bar ()
+{
+ return memmove ();
+}
Jakub
Re: libgomp nvptx plugin: rework initialisation and support the proposed load/unload hooks (was: Merge current set of OpenACC changes from gomp-4_0-branch)
On Mon, Mar 09, 2015 at 14:45:55 +, Julian Brown wrote:
> On Fri, 6 Mar 2015 17:01:13 +0300
> Ilya Verbin wrote:
>
> > On Thu, Feb 26, 2015 at 20:25:11 +0300, Ilya Verbin wrote:
> > > On Wed, Feb 25, 2015 at 10:36:08 +0100, Thomas Schwinge wrote:
> > > > > Julian Brown wrote:
> > > > > This is a version of the previously-posted patch to rework
> > > > > initialisation and support the proposed load/unload hooks,
> > > > > merged to gomp4 branch and tested alongside the two patches
> > > > > (from
> > >
> > > Currently the 'struct gomp_memory_mapping' contains 'lock' and
> > > 'is_initialized'. Do you still need them? Or we can use
> > > gomp_device_descr::lock and is_initialized instead? If yes, then
> > > we can replace the gomp_memory_mapping structure with a splay_tree,
> > > as it was before the OpenACC merge.
> >
> > Ping?
>
> Apologies, I've been distracted with travel and other things. I
> suspect, as you suggest, that the gomp_memory_mapping
> lock/is_initialized fields may no longer be required. I haven't yet had
> time to address that nor all of Thomas's comments on the patch (mostly
> breakage with multiple devices), and I'm unlikely to have time this
> week either due to vacation...
If it is too late for such global changes (rework initialization in libgomp,
change mic and ptx plugins), then here is a small workaround patch to fix
offloading from libraries. Likely, it will not affect OpenACC programs with one
image. make check-target-libgomp passed.
PR libgomp/65338
libgomp/
* libgomp.h (struct gomp_device_descr): Remove
offload_regions_registered.
* oacc-host.c (host_dispatch): Do not initialize
offload_regions_registered.
* target.c (gomp_register_image_for_device): Do not check for
offload_regions_registered.
(gomp_target_init): Do not initialize offload_regions_registered.
diff --git a/libgomp/libgomp.h b/libgomp/libgomp.h
index 3089401..f45fdba 100644
--- a/libgomp/libgomp.h
+++ b/libgomp/libgomp.h
@@ -793,9 +793,6 @@ struct gomp_device_descr
/* Set to true when device is initialized. */
bool is_initialized;
- /* True when offload regions have been registered with this device. */
- bool offload_regions_registered;
-
/* OpenACC-specific data and functions. */
/* This is mutable because of its mutable data_environ and target_data
members. */
diff --git a/libgomp/oacc-host.c b/libgomp/oacc-host.c
index 6aeb1e7..2763f44 100644
--- a/libgomp/oacc-host.c
+++ b/libgomp/oacc-host.c
@@ -56,7 +56,6 @@ static struct gomp_device_descr host_dispatch =
.mem_map.is_initialized = false,
.mem_map.splay_tree.root = NULL,
.is_initialized = false,
-.offload_regions_registered = false,
.openacc = {
.open_device_func = GOMP_OFFLOAD_openacc_open_device,
diff --git a/libgomp/target.c b/libgomp/target.c
index 50baa4d..db1f509 100644
--- a/libgomp/target.c
+++ b/libgomp/target.c
@@ -1035,13 +1035,8 @@ static void
gomp_register_image_for_device (struct gomp_device_descr *device,
struct offload_image_descr *image)
{
- if (!device->offload_regions_registered
- && (device->type == image->type
- || device->type == OFFLOAD_TARGET_TYPE_HOST))
-{
- device->register_image_func (image->host_table, image->target_data);
- device->offload_regions_registered = true;
-}
+ if (device->type == image->type || device->type == OFFLOAD_TARGET_TYPE_HOST)
+device->register_image_func (image->host_table, image->target_data);
}
/* This function initializes the runtime needed for offloading.
@@ -1105,7 +1100,6 @@ gomp_target_init (void)
current_device.mem_map.is_initialized = false;
current_device.mem_map.splay_tree.root = NULL;
current_device.is_initialized = false;
- current_device.offload_regions_registered = false;
current_device.openacc.data_environ = NULL;
current_device.openacc.target_data = NULL;
for (i = 0; i < new_num_devices; i++)
-- Ilya
Re: [Patch 1/2, Fortran, pr60322] [OOP] Incorrect bounds on polymorphic dummy array
Le 23/03/2015 16:49, Andre Vehreschild a écrit : > I see your point. Currently I am bootstraping and regtesting some patches for > commit. While this is running, my machine is nearly unusable. I will look into > this as soon, as my machine allows, but probably not before tomorrow. > There is no hurry, the patch(es) will probably have to wait for next stage 1.
PATCH: Add bootstrap-mpx.mk
Hi, This patch adds bootstrap-mpx.mk so that we test mpx in gcc build by configuring GCC with --enable-libmpx --with-build-config="bootstrap-mpx" OK to install? H.J. --- 2015-03-23 H.J. Lu * bootstrap-mpx.mk: New file. diff --git a/config/bootstrap-mpx.mk b/config/bootstrap-mpx.mk new file mode 100644 index 000..ed97826 --- /dev/null +++ b/config/bootstrap-mpx.mk @@ -0,0 +1,9 @@ +# This option enables -fcheck-pointer-bounds -mmpx for stage2 and stage3. + +STAGE2_CFLAGS += -fcheck-pointer-bounds -mmpx +STAGE3_CFLAGS += -fcheck-pointer-bounds -mmpx +POSTSTAGE1_LDFLAGS += -fcheck-pointer-bounds -mmpx \ + -static-libmpx -static-libmpxwrappers \ + -B$$r/prev-$(TARGET_SUBDIR)/libmpx \ + -B$$r/prev-$(TARGET_SUBDIR)/libmpx/mpxrt/.libs \ + -B$$r/prev-$(TARGET_SUBDIR)/libmpx/mpxwrap/.libs
[SH][committed] Fix PR 65505
Hi,
The attached patch is the same as posted in the PR with a test case
added. Tested with on sh-elf with
make -k check RUNTESTFLAGS="--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
and on sh4-linux by Kaz. Committed as r221604.
Cheers,
Oleg
gcc/ChangeLog:
PR target/65505
* config/sh/predicates.md (simple_mem_operand,
displacement_mem_operand): Add test for reg.
(short_displacement_mem_operand): Test for displacement_mem_operand
before invoking sh_disp_addr_displacement.
* config/sh/constraints.md (Sdd, Sra): Simplify.
* config/sh/sync.md (atomic_mem_operand_0, atomic_mem_operand_1):
Remove redundant displacement_mem_operand tests.
gcc/testsuite/ChangeLog:
PR target/65505
* gcc.target/sh/torture/pr65505.c: New.
Index: gcc/testsuite/gcc.target/sh/torture/pr65505.c
===
--- gcc/testsuite/gcc.target/sh/torture/pr65505.c (revision 0)
+++ gcc/testsuite/gcc.target/sh/torture/pr65505.c (revision 0)
@@ -0,0 +1,122 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-std=gnu99" } */
+/* { dg-skip-if "" { "sh*-*-*" } { "-m5*" } { "" } } */
+
+struct thread_info {
+ struct task_struct *task;
+};
+
+static inline __attribute__((always_inline))
+ __attribute__((no_instrument_function))
+struct thread_info *current_thread_info(void)
+{
+ struct thread_info *ti;
+
+ unsigned long __dummy;
+
+ __asm__ __volatile__ (
+ "mov r15, %0\n\t"
+ "and %1, %0\n\t"
+ : "=&r" (ti), "=r" (__dummy)
+ : "1" (~((1 << 13) - 1))
+ : "memory");
+
+ return ti;
+}
+
+typedef struct seqcount {
+ unsigned sequence;
+} seqcount_t;
+
+struct inode;
+
+struct dentry {
+ seqcount_t d_seq;
+ struct inode *d_inode;
+};
+
+struct path {
+ struct vfsmount *mnt;
+ struct dentry *dentry;
+};
+
+struct file {
+ struct path f_path;
+} __attribute__((aligned(4)));
+
+struct task_struct
+{
+ int link_count, total_link_count;
+ struct fs_struct *fs;
+};
+
+struct fd {
+ struct file *file;
+ unsigned int flags;
+};
+
+static inline __attribute__((always_inline))
+ __attribute__((no_instrument_function))
+struct fd
+fdget_raw(unsigned int fd)
+{
+ return (struct fd){(struct file *)(fd & ~3),fd & 3};
+}
+
+
+struct fs_struct;
+
+struct nameidata {
+ struct path path;
+ struct path root;
+ struct inode *inode;
+ unsigned int flags;
+ unsigned seq, m_seq;
+ struct file *base;
+};
+
+int read_seqcount_retry(const seqcount_t *s, unsigned start);
+
+int
+path_init(int dfd, const char *name, unsigned int flags,
+ struct nameidata *nd)
+{
+ int retval = 0;
+
+ if (*name=='/') {
+ nd->path = nd->root;
+ } else if (dfd == -100) {
+
+ if (flags & 0x0040) {
+ struct fs_struct *fs = (current_thread_info()->task)->fs;
+ }
+ } else {
+
+ struct fd f = fdget_raw(dfd);
+ struct dentry *dentry;
+
+ if (!f.file)
+ return -9;
+
+ dentry = f.file->f_path.dentry;
+
+ nd->path = f.file->f_path;
+ if (flags & 0x0040) {
+ if (f.flags & 1)
+nd->base = f.file;
+ }
+ }
+
+ nd->inode = nd->path.dentry->d_inode;
+ if (!(flags & 0x0040))
+ goto done;
+ if (__builtin_expect(!!(!read_seqcount_retry(&nd->path.dentry->d_seq, nd->seq)), 1))
+ goto done;
+ if (!(nd->flags & 0x2000))
+ nd->root.mnt = ((void *)0);
+
+ return -10;
+done:
+ (current_thread_info()->task)->total_link_count = 0;
+ return 0;
+}
Index: gcc/config/sh/predicates.md
===
--- gcc/config/sh/predicates.md (revision 221537)
+++ gcc/config/sh/predicates.md (working copy)
@@ -437,12 +437,14 @@
;; Returns 1 if OP is a simple register address.
(define_predicate "simple_mem_operand"
(and (match_code "mem")
+ (match_code "reg" "0")
(match_test "arith_reg_operand (XEXP (op, 0), SImode)")))
;; Returns 1 if OP is a valid displacement address.
(define_predicate "displacement_mem_operand"
(and (match_code "mem")
- (match_test "GET_CODE (XEXP (op, 0)) == PLUS")
+ (match_code "plus" "0")
+ (match_code "reg" "00")
(match_test "arith_reg_operand (XEXP (XEXP (op, 0), 0), SImode)")
(match_test "sh_legitimate_index_p (GET_MODE (op),
XEXP (XEXP (op, 0), 1),
@@ -451,8 +453,10 @@
;; Returns true if OP is a displacement address that can fit into a
;; 16 bit (non-SH2A) memory load / store insn.
(define_predicate "short_displacement_mem_operand"
- (match_test "sh_disp_addr_displacement (op)
- <= sh_max_mov_insn_displacement (GET_MODE (op), false)"))
+ (and (match_code "mem")
+ (match_operand 0 "displacement_mem_operand")
+ (match_test "sh_disp_addr_displacement (op)
+ <= sh_max_mov_insn_displacement (GET_MODE (op), false)")))
;; Returns 1 if the operand can be used in an SH2A movu.{b|w} insn.
(define_predicate "zero_extend_movu_operand"
Index: gcc/config/sh/constraints.md
==
[patch, avr, applied] ad PR65296: Allow specifying the same MCU more than once.
http://gcc.gnu.org/r221602
Applied this path so that it is allowed to specify the same -mmcu=MCU more than
once. This is the easiest way to manage situation where it is hard to control
the command line arguments, in particular when the compiler is called by linker
plugin.
Johann
PR target/65296
* config/avr/driver-avr.c (avr_devicespecs_file): Allow to specify
the same -mmcu=MCU more than once.
Index: config/avr/driver-avr.c
===
--- config/avr/driver-avr.c (revision 221601)
+++ config/avr/driver-avr.c (revision 221602)
@@ -55,9 +55,10 @@ avr_diagnose_devicespecs_error (const ch
/* Implement spec function `device-specs-file´.
- Compose -specs=. If everything went well then argv[0]
- is the inflated specs directory and argv[1] is a device or core name as
- supplied to -mmcu=*. */
+ Compose -specs=%s. If everything went well then argv[0]
+ is the inflated (absolute) specs directory and argv[1] is a device or
+ core name as supplied by -mmcu=*. When building GCC the path might
+ be relative. */
const char*
avr_devicespecs_file (int argc, const char **argv)
@@ -82,13 +83,19 @@ avr_devicespecs_file (int argc, const ch
mmcu = AVR_MMCU_DEFAULT;
break;
-case 2:
+default:
mmcu = argv[1];
- break;
-default:
- error ("specified option %qs more than once", "-mmcu=");
- return X_NODEVLIB;
+ // Allow specifying the same MCU more than once.
+
+ for (int i = 2; i < argc; i++)
+if (0 != strcmp (mmcu, argv[i]))
+ {
+error ("specified option %qs more than once", "-mmcu");
+return X_NODEVLIB;
+ }
+
+ break;
}
specfile_name = concat (argv[0], dir_separator_str, "specs-", mmcu, NULL);
Re: [PATCH, ARM, PR64208] LRA ICE Fix
Hi,
On 23 March 2015 at 17:08, Ramana Radhakrishnan
wrote:
> On Wed, Mar 18, 2015 at 10:19 AM, Yvan Roux wrote:
>> Hi,
>>
>> This is a fix for PR64208 where LRA loops when dealing with
>> iwmmxt_arm_movdi insn. As explain in the PR, the issue was introduced
>> on trunk and 4.9 branch by fix of PR rtl-optimization/60969 and then
>> workaround by r211798 (-fuse-caller-save enable for ARM).
>>
>> The changes in IRA cost made by PR60969, changed the register class of
>> this insn output from GENERAL_REGS to IWMMXT_REGS, and the
>> redundancies in the insn pattern alternatives description force LRA to
>> reload the pseudo, which generates the same iwmmxt_arm_movdi insn,
>> which can't be resolved, and so on ...
>>
>> Removing the redundancies fixes the issue, as LRA find that
>> alternative 8 (Uy => y) matches.
>>
>> This issue is present in 4.9 branch, but latent on trunk (the
>> clobbering of IP and CC information added during -fuse-caller-save
>> patch changed the register allocation).
>>
>> Cross compiled and regression tested on ARM targets (but not on an
>> IWMMXT one), is it ok for trunk and 4.9 branch ?
>
>
> This looks sane. It doesn't look reasonable for alternatives to be
> duplicating each other.
>
> Given I have neither the time nor the hardware to test this patch on,
> I'd rather someone with an interest in iwMMX possibly folks from
> Marvell can pick up testing for this patch.
Ok, Thanks Ramana, I'll wait for somebody able to test it. Notice,
that without this patch on the 4.9 branch, building a cross compiler
which default to iWMMXT architectures ICE on that during LRA while
building of libgcc.
Cheers,
Yvan
> regards
> Ramana
>
>>
>> Rq: I think that adding IP and CC clobbers to
>> CALL_INSN_FUNCTION_USAGE, as specified by AAPCS, in 4.9 branch is
>> something we need too, I've a patch for that if you agree on that.
>>
>> Thanks,
>> Yvan
>>
>> 2105-03-17 Yvan Roux
>>
>> PR target/64208
>> * config/arm/iwmmxt.md ("*iwmmxt_arm_movdi"): Cleanup redundant
>> alternatives.
Re: [PATCH] Add some REG_POINTER flags during ix86 memcpy/memset expansion (PR target/65504)
> On 03/23/2015 09:07 AM, Jakub Jelinek wrote: > >Hi! > > > >As expand_set_or_movmem_prologue_epilogue_by_misaligned_moves uses > >src = src - (adjusted_dest - dest) > >without proper REG_POINTER flags the aliasing code is very easily confused > >on what is really a pointer and what is not - as REG_POINTER was used > >after forwprop only on dest, but not on anything else, aliasing code thinks > >that the memcpy reads dest based memory, when it really reads src based > >memory (in the testcase frame pointer based in the end, but CSE did not see > >it through). > > > >Fixed by marking pseudos that must hold pointers with REG_POINTER during > >the expansion. Bootstrapped/regtested on x86_64-linux and i686-linux, ok > >for trunk? > FWIW, you have to be very careful depending on REG_POINTER. I > believe Ada can still set REG_POINTER on things that are not > pointers (via virtual origins) and cross jumping can cause problems > too where one arm has x + y with X as the pointer and the other arm > has x + y with Y as the pointer. > > But yes, in general, if we're marking things that must be pointers > with REG_POINTER, that is a good thing. Yep, the patch is OK. Even if Ada gets things partly wrong it seems independent issue. Honza > > jeff >
Re: Fix ICEs on ODR violating programs and improve ODR mismatch diagnostic
> On Mon, Mar 23, 2015 at 04:07:10PM +0100, Richard Biener wrote:
> > On Mon, Mar 23, 2015 at 3:59 PM, Jakub Jelinek wrote:
> > > On Sun, Mar 22, 2015 at 11:11:24PM +0100, Jan Hubicka wrote:
> > >> --- testsuite/g++.dg/lto/pr65475b_0.C (revision 0)
> > >> +++ testsuite/g++.dg/lto/pr65475b_0.C (revision 0)
> > >> @@ -0,0 +1,9 @@
> > >> +/* { dg-lto-do link } */
> > >> +/* { dg-options "-O2 -Wno-odr" } */
> > >
> > > Wasn't this supposed to be dg-lto-options instead?
> > > I'm getting
> > > WARNING: lto.exp does not support dg-options in primary source file
> > > otherwise.
> >
> > Yep - dg-options works in secondary files only (and applies to
> > compile-time).
>
> Here is a fix then. Both
> WARNING: lto.exp does not support dg-options in primary source file
> messages go away with it. Ok for trunk?
OK, thanks! I remember I first got the testcase by mistake to ipa directory
and thus
I probably copied markings from wrong source.
Honza
>
> 2015-03-23 Jakub Jelinek
>
> PR ipa/65475
> * g++.dg/lto/pr65475_0.C: Use dg-lto-options instead of
> dg-options.
> * g++.dg/lto/pr65475b_0.C: Likewise.
>
> --- gcc/testsuite/g++.dg/lto/pr65475_0.C.jj 2015-03-23 08:47:52.0
> +0100
> +++ gcc/testsuite/g++.dg/lto/pr65475_0.C 2015-03-23 16:24:36.024316627
> +0100
> @@ -1,5 +1,5 @@
> /* { dg-lto-do link } */
> -/* { dg-options "-O2 -Wno-odr" } */
> +/* { dg-lto-options "-O2 -Wno-odr" } */
> /* { dg-extra-ld-options { -O2 -Wno-odr -r -nostdlib } } */
> namespace std {
> class ios_base {
> @@ -7,4 +7,3 @@ class ios_base {
>class __attribute((__abi_tag__("cxx11"))) failure : A {};
> } a;
> }
> -
> --- gcc/testsuite/g++.dg/lto/pr65475b_0.C.jj 2015-03-23 08:47:52.432180556
> +0100
> +++ gcc/testsuite/g++.dg/lto/pr65475b_0.C 2015-03-23 16:21:44.524084847
> +0100
> @@ -1,5 +1,5 @@
> /* { dg-lto-do link } */
> -/* { dg-options "-O2 -Wno-odr" } */
> +/* { dg-lto-options "-O2 -Wno-odr" } */
> /* { dg-extra-ld-options { -O2 -Wno-odr -r -nostdlib } } */
> namespace std {
> class exception {};
>
>
> Jakub
Re: [PATCH] Fix Ada bootstrap (PR bootstrap/65522)
> > In any case, for compatibility, this patch just changes the guard so that
> > adadecode.c's ada_demangle is compiled only into libgnat*.{a,so} and not
> > into gnat1, which can then successfully link against libiberty
> > cplus-dem.o.
> >
> > The ipa-devirt.c change is obvious IMHO, the same header is included a few
> > lines above this.
> >
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> The Ada part looks OK to me.
.. and the ipa-devirt part is obvious - I just did not notice demangler is among
includs we drag in. Thanks!
Honza
>
> Arno
Re: [PATCH] testsuite/63175 - fix powerpc64 test failure
Martin Sebor writes:
> -/* { dg-final { scan-assembler "\t\(lxv|lvsr|stxv\)" } } */
> +/* { dg-final { scan-assembler "\t\(lvx|lxv|lvsr|stxv\)" } } */
You might want to remove the backslashes before the parens, which are
ignored anyway.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Re: [PATCH] testsuite/63175 - fix powerpc64 test failure
The patch below fixes a failure of the test on powerpc64. The test looks for the lxv (Load VSX Vector) instruction which is emitted on powerpc64le but on powerpc64 gcc emits an lvx (Load Vector Indexed). Both are correct here. Is this okay to commit to trunk? + PR testsuite/63175 + * gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c: Scan + assembly for lvx in addition to lxv. Okay. Thanks, David
[PATCH][AArch64] Fix geniterators.sh to use standard BRE syntax in sed
GCC can be compiled for aarch64 target with busybox sed except for
the geniterators.sh script which uses nonstandard basic regex.
I explicitly set LC_ALL=C too because the regex depends on collation
order.
I tested that the script gives the same result on iterators.md.
Ok?
gcc/Changelog:
2015-03-23 Szabolcs Nagy
* config/aarch64/geniterators.sh: Use standard BRE in sed.diff --git a/gcc/config/aarch64/geniterators.sh b/gcc/config/aarch64/geniterators.sh
index de9dfd2..f908e89 100644
--- a/gcc/config/aarch64/geniterators.sh
+++ b/gcc/config/aarch64/geniterators.sh
@@ -32,14 +32,15 @@ echo "#define GCC_AARCH64_ITERATORS_H"
# which does not have a matching brace because it contains characters we
# don't want to or can't handle (e.g P, PTR iterators change depending on
# Pmode and ptr_mode).
+export LC_ALL=C
cat $1 | tr "\n" " " \
| sed 's/(define_mode_iterator \([A-Za-z0-9_]*\) \([]\[A-Z0-9 \t]*\)/\n#define BUILTIN_\1(T, N, MAP) \\ \2\n/g' \
| grep '#define [A-Z0-9_(), \\]* \[[A-Z0-9[:space:]]*]' \
| sed 's/\t//g' \
- | sed 's/ \+/ /g' \
- | sed 's/ \[\([A-Z0-9 ]*\)]/\n\L\1/' \
+ | sed 's/ */ /g' \
+ | sed 's/ \[\([A-Z0-9 ]*\)]/\n\1/' \
| awk ' BEGIN { FS = " " ; OFS = ", "} \
/#/ { print } \
- ! /#/ { $1 = $1 ; printf " VAR%d (T, N, MAP, %s)\n", NF, $0 }'
+ ! /#/ { $1 = $1 ; printf " VAR%d (T, N, MAP, %s)\n", NF, tolower($0) }'
echo "#endif /* GCC_AARCH64_ITERATORS_H */"
Re: [PATCH] Add some REG_POINTER flags during ix86 memcpy/memset expansion (PR target/65504)
On 03/23/2015 09:07 AM, Jakub Jelinek wrote: Hi! As expand_set_or_movmem_prologue_epilogue_by_misaligned_moves uses src = src - (adjusted_dest - dest) without proper REG_POINTER flags the aliasing code is very easily confused on what is really a pointer and what is not - as REG_POINTER was used after forwprop only on dest, but not on anything else, aliasing code thinks that the memcpy reads dest based memory, when it really reads src based memory (in the testcase frame pointer based in the end, but CSE did not see it through). Fixed by marking pseudos that must hold pointers with REG_POINTER during the expansion. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? FWIW, you have to be very careful depending on REG_POINTER. I believe Ada can still set REG_POINTER on things that are not pointers (via virtual origins) and cross jumping can cause problems too where one arm has x + y with X as the pointer and the other arm has x + y with Y as the pointer. But yes, in general, if we're marking things that must be pointers with REG_POINTER, that is a good thing. jeff
[PATCH] testsuite/63175 - fix powerpc64 test failure
The patch below fixes a failure of the test on powerpc64.
The test looks for the lxv (Load VSX Vector) instruction
which is emitted on powerpc64le but on powerpc64 gcc emits
an lvx (Load Vector Indexed). Both are correct here.
Is this okay to commit to trunk?
Martin
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 884fb62..d781c02 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,9 @@
+2015-03-23 Martin Sebor
+
+ PR testsuite/63175
+ * gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c: Scan
+ assembly for lvx in addition to lxv.
+
2015-03-20 Richard Biener
PR middle-end/64715
diff --git
a/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c
b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c
index 73c0afa..9f3c89c 100644
--- a/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c
+++ b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c
@@ -25,6 +25,6 @@ main1 (void)
with no word loads (lw, lwu, lwz, lwzu, or their indexed forms)
or word stores (stw, stwu, stwx, stwux, or their indexed forms). */
-/* { dg-final { scan-assembler "\t\(lxv|lvsr|stxv\)" } } */
+/* { dg-final { scan-assembler "\t\(lvx|lxv|lvsr|stxv\)" } } */
/* { dg-final { scan-assembler-not "\tlwz?u?x? " } } */
/* { dg-final { scan-assembler-not "\tstwu?x? " } } */
[patch] libstdc++/64967 disable new std::string for gnu-versioned-namespace
This restores bootstrap for --enable-symvers=gnu-versioned-namespace
by disabling the new std::string ABI.
After GCC 5.1 (probably for GCC 6, rather than 5.2) I will make
another attempt to make gnu-versioned-namespace use the new
std::string only (and bump the soname from libstdc++.so.7 to .so.8)
Tested x86_64-linux, both with and without
--enable-symvers=gnu-versioned-namespace.
There are loads of test failures with gnu-versioned-namespace, but
they are unrelated to the std::string ABI changes (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59256 and
https://gcc.gnu.org/ml/libstdc++/2015-03/msg00058.html for the biggest
causes of test failures).
Committed to trunk.
commit 0f3295873da44bded61f0bd4eb0542795bf92c0a
Author: Jonathan Wakely
Date: Fri Mar 20 15:12:40 2015 +
PR libstdc++/64967
* acinclude.m4: Disable dual ABI when gnu-versioned-namespace in use.
* configure: Regenerate.
* src/c++11/compatibility-c++0x.cc (error_category), generic_category,
system_category): Use macros for versioned namespace.
* src/c++11/futex.cc: Add missing end macro for versioned namespace.
diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 74f5a65..a1e301f 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -3859,6 +3859,10 @@ dnl _GLIBCXX_USE_DUAL_ABI (always defined, either to 1 or 0)
dnl
AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_DUAL_ABI], [
GLIBCXX_ENABLE(libstdcxx-dual-abi,$1,,[support two versions of std::string])
+ if test x$enable_symvers = xgnu-versioned-namespace; then
+# gnu-versioned-namespace is incompatible with the dual ABI.
+enable_libstdcxx_dual_abi="no"
+ fi
if test x"$enable_libstdcxx_dual_abi" != xyes; then
AC_MSG_NOTICE([dual ABI is disabled])
default_libstdcxx_abi="c++98"
diff --git a/libstdc++-v3/src/c++11/compatibility-c++0x.cc b/libstdc++-v3/src/c++11/compatibility-c++0x.cc
index 9ed367b..01a9690 100644
--- a/libstdc++-v3/src/c++11/compatibility-c++0x.cc
+++ b/libstdc++-v3/src/c++11/compatibility-c++0x.cc
@@ -130,6 +130,7 @@ namespace std _GLIBCXX_VISIBILITY(default)
constexpr bool system_clock::is_monotonic;
} // namespace chrono
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
// gcc-5 replaces this with _V2::error_category
class error_category
{
@@ -168,6 +169,7 @@ namespace std _GLIBCXX_VISIBILITY(default)
operator!=(const error_category& __other) const noexcept
{ return this != &__other; }
};
+_GLIBCXX_END_NAMESPACE_VERSION
// gcc-4.9.0
// LWG 2145 changes this constructor to constexpr i.e. inline
@@ -213,6 +215,7 @@ namespace std _GLIBCXX_VISIBILITY(default)
const system_error_category system_category_instance{};
}
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
const error_category&
system_category() noexcept { return system_category_instance; }
@@ -224,6 +227,7 @@ namespace std _GLIBCXX_VISIBILITY(default)
_GLIBCXX_CONST const error_categoryxx& system_category() noexcept;
_GLIBCXX_CONST const error_categoryxx& generic_category() noexcept;
}
+_GLIBCXX_END_NAMESPACE_VERSION
error_condition
error_category::default_error_condition(int __i) const noexcept
diff --git a/libstdc++-v3/src/c++11/futex.cc b/libstdc++-v3/src/c++11/futex.cc
index a7f0200..e04dba8 100644
--- a/libstdc++-v3/src/c++11/futex.cc
+++ b/libstdc++-v3/src/c++11/futex.cc
@@ -93,6 +93,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
syscall (SYS_futex, __addr, futex_wake_op, INT_MAX);
}
+_GLIBCXX_END_NAMESPACE_VERSION
}
#endif
#endif
RE: [Patch] OPT: Update heuristics for loop-invariant for address arithmetic.
Hello All: Did you get a chance to look at the below patch. Thanks & Regards Ajit -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On Behalf Of Ajit Kumar Agarwal Sent: Wednesday, March 04, 2015 3:57 PM To: vmaka...@redhat.com; GCC Patches Cc: Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala Subject: [Patch] OPT: Update heuristics for loop-invariant for address arithmetic. Hello All: The changes are made in the patch to update the heuristics for loop invariant for address arithemetic at RTL Level. The heuristics are updated with the consideration of single def and use for register pressure calculation instead Of ignoring it and also to update the estimated register pressure cost along with the check of actual uses with Address uses. With the above change, gains are seen in the Geomean for Mibench/EEMBC benchmarks for microblaze target. No Regression is seen in deja GNU regressions tests for microblaze. Please let us know your feedback. commit 039b95028c93f99fc1da7fa255f9b5fff4e17223 Author: Ajit Kumar Agarwal Date: Wed Mar 4 15:46:45 2015 +0530 [Patch] OPT: Update heuristics for loop-invariant for address arithmetic. The changes are made in the patch to update the heuristics for loop invariant for address arithmetic. The heuristics is changed to incorporate the single def and use in the register pressure calculation in order to move the invariant out of loop. The heuristics are further changed to not to use the check for addr uses with actual uses. Also changes are done in the heuristics of estimated register pressure cost. ChangeLog: 2015-03-04 Ajit Agarwal * loop-invariant.c (gain_for_invariant): update the heuristics for estimate_reg_pressure_cost. (get_inv_cost): Remove the check for addr uses with actual uses. Add the single def and use in the register pressure for invariants. Signed-off-by:Ajit Agarwal ajit...@xilinx.com Thanks & Regards Ajit
RE: [Patch] IRA: Update heuristics for optimal coalescing
Hello Vladimir: Did you get a chance to look at the below patch. Thanks & Regards Ajit -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On Behalf Of Ajit Kumar Agarwal Sent: Friday, February 27, 2015 11:25 AM To: vmaka...@redhat.com; Jeff Law; GCC Patches Cc: Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala Subject: [Patch] IRA: Update heuristics for optimal coalescing Hello Vladimir: The changes in the patch are made in the frequency heuristics for optimal coalescing. The Loop back edge frequencies are taken instead of the block frequency for optimal coalescing. Ignores the frequency for the loop for the allocno not having references inside the loops but spans the loops and live at the exit block of the loop. Another similar change are made not to consider allcono frequency at the cost calculation but to consider the loop back edge frequencies having references and spans through the loop and live at the exit of the block. We have tested the changes with MIBench and EEMBC benchmarks and there is a gain in the Geomean for the overall benchmarks for Microblaze target. Also no regressions are seen in deja GNU tests run for microblaze. Please let us know with your feedbacks. commit e6a2edd3794080a973695f80e77df3e7de55452d Author: Ajit Kumar Agarwal Date: Fri Feb 27 11:15:48 2015 +0530 IRA: Update heuristics for optimal coalescing. The changes are made in the frequency heuristics for optimal coalescing. The Loop back edge frequencies are taken instead of the block frequency for optimal coalescing. Ignores the frequency for the loop having not any references but spans the loop and live at the exit block of the loop. Another similar change not to consider allcono frequency at the cost calculation but to consider the loop back edge frequencies having references and spans through the loop and live at the exit of the block. ChangeLog: 2015-02-27 Ajit Agarwal * ira-color.c (ira_loop_back_edge_freq): New. (coalesce_allocnos): Use of ira_loop_back_edge_freq to update the back edge frequencies. (setup_coalesced_allocno_costs_and_nums): Use of ira_loop_back_edge_freq to update the cost. Signed-off-by:Ajit Agarwal ajit...@xilinx.com Thanks & Regards Ajit
[PATCH][ARM] PR 65489: Accept VSTRUCT constants in arm_legitimate_constant_p
Hi all, The ICE in the PR happens on arm during the hoist pass when the code generates a SET rtx of the form: (set (reg:OI) (const_int 0)). It checks whether const_int 0 is a general_operand for OImode which involves asking the backend whether it's a legitimate constant. arm_legitimate_constant_p_1 explicitly rejects OImode constants as a result of the fix for PR 46329 https://gcc.gnu.org/ml/gcc-patches/2011-04/msg00200.html This results in gcse using an emit_insn of the SET rtx rather than trying to do an emit_move_insn which would have worked in this case. >From reading the thread I get the impression that the ICE there was caused by reload and coproc_secondary_reload_class behaving weirdly. We're now using LRA and SECONDARY_INPUT_RELOAD_CLASS and SECONDARY_OUTPUT_RELOAD_CLASS which are the only users of coproc_secondary_reload_class are no longer used. I removed the restriction on constants for these large modes in arm_legitimate_constant_p_1 and the testcases in PR 46329 all work fine. Bootstrap, testing and building various vector workloads also didn't show any problems. Is this the right way to go for this? If so, ok for trunk? The ICE in this PR happens on a recently added testcase to gcc.c-torture/execute/ and this patch fixes that, so no new testcase is added. Jakub mentioned that maybe the testcase can be modified to manually perform the lowering done in his patch to potentially trigger this on older gcc versions, but I'm not sure how that would be done. The problem is that something is generating OImode moves that I think can only be done in the vector form of the testcase, so I'm not entirely convinced that it's reproducible on 4.9 and 4.8. Thanks, Kyrill Thanks, Kyrill 2015-03-23 Kyrylo Tkachov PR target/65489 * config/arm/arm.c (arm_legitimate_constant_p_1): Remove restriction on constants for NEON VSTRUCT modes. arm-vstruct-const.patch Description: Binary data
Re: [PATCH ARM]Fix memset-inline-* failures on cortex-a9 tune by checking tune information.
On Tue, Mar 17, 2015 at 3:34 AM, Bin.Cheng wrote:
> On Fri, Mar 13, 2015 at 7:56 PM, Ramana Radhakrishnan
> wrote:
>> On Fri, Mar 6, 2015 at 7:46 AM, Bin Cheng wrote:
>>> Hi,
>>> This patch is the second part fixing memset-inline-{4,5,6,8,9}.c failures on
>>> cortex-a9. It adds a function checking CPU tuning information in dejagnu,
>>> it also uses that function to skip related testcase when we are compiling
>>> for cortex-a9 tune.
>>
>> Skips the related testcase for all tests where the tuning information
>> doesn't use neon. I think this technique can be used to clean up a
>> number of multilib related failures in the gcc.target/arm testsuite.
> Actually these are all related cases. Cases {1,2,3} are intended for
> non-neon target inlining test, case 7 is an executable test which
> should be run what ever the target supports.
>
>>
>>>
>>> Build and test on arm-none-eabi. Is it OK?
>>>
>>> gcc/testsuite/ChangeLog
>>> 2015-03-06 Bin Cheng
>>>
>>> * lib/target-supports.exp (arm_tune_string_ops_prefer_neon): New.
>>> * gcc.target/arm/memset-inline-4.c: Skip for
>>> arm_tune_string_ops_prefer_neon.
>>> * gcc.target/arm/memset-inline-5.c: Ditto.
>>> * gcc.target/arm/memset-inline-6.c: Ditto.
>>> * gcc.target/arm/memset-inline-8.c: Ditto.
>>> * gcc.target/arm/memset-inline-9.c: Ditto.
>>
>> Ok, please document the new dejagnu helper routine in sourcebuild.texi
> Done. Patch updated, I will push both patches in if you are ok with it.
>
> Thanks,
> bin
>
> 2015-03-17 Bin Cheng
> * doc/sourcebuild.texi (arm_tune_string_ops_prefer_neon): New.
>
> gcc/testsuite/ChangeLog
> 2015-03-17 Bin Cheng
>
> * lib/target-supports.exp (arm_tune_string_ops_prefer_neon): New.
> * gcc.target/arm/memset-inline-4.c: Skip for
> arm_tune_string_ops_prefer_neon.
> * gcc.target/arm/memset-inline-5.c: Ditto.
> * gcc.target/arm/memset-inline-6.c: Ditto.
> * gcc.target/arm/memset-inline-8.c: Ditto.
> * gcc.target/arm/memset-inline-9.c: Ditto.
OK.
Ramana
Re: [PATCH, ARM, PR64208] LRA ICE Fix
On Wed, Mar 18, 2015 at 10:19 AM, Yvan Roux wrote:
> Hi,
>
> This is a fix for PR64208 where LRA loops when dealing with
> iwmmxt_arm_movdi insn. As explain in the PR, the issue was introduced
> on trunk and 4.9 branch by fix of PR rtl-optimization/60969 and then
> workaround by r211798 (-fuse-caller-save enable for ARM).
>
> The changes in IRA cost made by PR60969, changed the register class of
> this insn output from GENERAL_REGS to IWMMXT_REGS, and the
> redundancies in the insn pattern alternatives description force LRA to
> reload the pseudo, which generates the same iwmmxt_arm_movdi insn,
> which can't be resolved, and so on ...
>
> Removing the redundancies fixes the issue, as LRA find that
> alternative 8 (Uy => y) matches.
>
> This issue is present in 4.9 branch, but latent on trunk (the
> clobbering of IP and CC information added during -fuse-caller-save
> patch changed the register allocation).
>
> Cross compiled and regression tested on ARM targets (but not on an
> IWMMXT one), is it ok for trunk and 4.9 branch ?
This looks sane. It doesn't look reasonable for alternatives to be
duplicating each other.
Given I have neither the time nor the hardware to test this patch on,
I'd rather someone with an interest in iwMMX possibly folks from
Marvell can pick up testing for this patch.
regards
Ramana
>
> Rq: I think that adding IP and CC clobbers to
> CALL_INSN_FUNCTION_USAGE, as specified by AAPCS, in 4.9 branch is
> something we need too, I've a patch for that if you agree on that.
>
> Thanks,
> Yvan
>
> 2105-03-17 Yvan Roux
>
> PR target/64208
> * config/arm/iwmmxt.md ("*iwmmxt_arm_movdi"): Cleanup redundant
> alternatives.
Re: [Patch 1/2, Fortran, pr60322] [OOP] Incorrect bounds on polymorphic dummy array
Hi Mikael, > This pointer stuff is very difficult to swallow to me. I totally understand. When doing the patch I had to restart twice, because I mixed up the development on the class arrays so completely, that I couldn't get it right again. > I understand that for classes, the CLASS_DATA (sym)->pointer is always > set, but almost everywhere the checks for pointerness are like > (sym->ts.type != BT_CLASS && sym->attr.pointer) > || (sym->ts.type == BT_CLASS && CLASS_DATA (sym)->attr.class_pointer) > and I don't see a convincing reason to have it different here. I see your point. Currently I am bootstraping and regtesting some patches for commit. While this is running, my machine is nearly unusable. I will look into this as soon, as my machine allows, but probably not before tomorrow. > At least gfc_is_nodesc_array should return 0 if sym->ts.type == BT_CLASS > which solves the problem there; for the other cases, I think that > class_pointer should be looked at. gfc_build_class_symbol clears the > sym->attr.pointer flag for class containers so it doesn't make sense to > test that flag. Completely right again. But I figured, that because sym->attr.pointer is never set for BT_CLASS there is no harm to check it and furthermore no need to guard it by checking whether ts.type == BT_CLASS. Fortunately not checking for class_pointer in _data's attr, didn't throw any regressions. Thinking about it now, I also think that it is probably safer to add the check for the class_pointer attribute were attr.pointer is checked on the sym, having the expression like you pointed out: > (sym->ts.type != BT_CLASS && sym->attr.pointer) > || (sym->ts.type == BT_CLASS && CLASS_DATA (sym)->attr.class_pointer) Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [PATCH] Fix Ada bootstrap (PR bootstrap/65522)
> In any case, for compatibility, this patch just changes the guard so that
> adadecode.c's ada_demangle is compiled only into libgnat*.{a,so} and not
> into gnat1, which can then successfully link against libiberty
> cplus-dem.o.
>
> The ipa-devirt.c change is obvious IMHO, the same header is included a few
> lines above this.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
The Ada part looks OK to me.
Arno
Re: Fix ICEs on ODR violating programs and improve ODR mismatch diagnostic
On Mon, Mar 23, 2015 at 04:07:10PM +0100, Richard Biener wrote:
> On Mon, Mar 23, 2015 at 3:59 PM, Jakub Jelinek wrote:
> > On Sun, Mar 22, 2015 at 11:11:24PM +0100, Jan Hubicka wrote:
> >> --- testsuite/g++.dg/lto/pr65475b_0.C (revision 0)
> >> +++ testsuite/g++.dg/lto/pr65475b_0.C (revision 0)
> >> @@ -0,0 +1,9 @@
> >> +/* { dg-lto-do link } */
> >> +/* { dg-options "-O2 -Wno-odr" } */
> >
> > Wasn't this supposed to be dg-lto-options instead?
> > I'm getting
> > WARNING: lto.exp does not support dg-options in primary source file
> > otherwise.
>
> Yep - dg-options works in secondary files only (and applies to compile-time).
Here is a fix then. Both
WARNING: lto.exp does not support dg-options in primary source file
messages go away with it. Ok for trunk?
2015-03-23 Jakub Jelinek
PR ipa/65475
* g++.dg/lto/pr65475_0.C: Use dg-lto-options instead of
dg-options.
* g++.dg/lto/pr65475b_0.C: Likewise.
--- gcc/testsuite/g++.dg/lto/pr65475_0.C.jj 2015-03-23 08:47:52.0
+0100
+++ gcc/testsuite/g++.dg/lto/pr65475_0.C2015-03-23 16:24:36.024316627
+0100
@@ -1,5 +1,5 @@
/* { dg-lto-do link } */
-/* { dg-options "-O2 -Wno-odr" } */
+/* { dg-lto-options "-O2 -Wno-odr" } */
/* { dg-extra-ld-options { -O2 -Wno-odr -r -nostdlib } } */
namespace std {
class ios_base {
@@ -7,4 +7,3 @@ class ios_base {
class __attribute((__abi_tag__("cxx11"))) failure : A {};
} a;
}
-
--- gcc/testsuite/g++.dg/lto/pr65475b_0.C.jj2015-03-23 08:47:52.432180556
+0100
+++ gcc/testsuite/g++.dg/lto/pr65475b_0.C 2015-03-23 16:21:44.524084847
+0100
@@ -1,5 +1,5 @@
/* { dg-lto-do link } */
-/* { dg-options "-O2 -Wno-odr" } */
+/* { dg-lto-options "-O2 -Wno-odr" } */
/* { dg-extra-ld-options { -O2 -Wno-odr -r -nostdlib } } */
namespace std {
class exception {};
Jakub
Re: [PATCH] Add some REG_POINTER flags during ix86 memcpy/memset expansion (PR target/65504)
On Mon, Mar 23, 2015 at 4:07 PM, Jakub Jelinek wrote: > As expand_set_or_movmem_prologue_epilogue_by_misaligned_moves uses > src = src - (adjusted_dest - dest) > without proper REG_POINTER flags the aliasing code is very easily confused > on what is really a pointer and what is not - as REG_POINTER was used > after forwprop only on dest, but not on anything else, aliasing code thinks > that the memcpy reads dest based memory, when it really reads src based > memory (in the testcase frame pointer based in the end, but CSE did not see > it through). > > Fixed by marking pseudos that must hold pointers with REG_POINTER during > the expansion. Bootstrapped/regtested on x86_64-linux and i686-linux, ok > for trunk? > > 2015-03-23 Jakub Jelinek > > PR target/65504 > * config/i386/i386.c (ix86_copy_addr_to_reg): Set REG_POINTER > on the pseudo. > (expand_set_or_movmem_prologue_epilogue_by_misaligned_moves): Set > REG_POINTER on *destptr after adjusting it for prologue size. > > * gfortran.dg/pr65504.f90: New test. OK. Thanks, Uros.
[PATCH] Fix Ada bootstrap (PR bootstrap/65522)
Hi!
Honza's recent change to use the libiberty demangler inside of gcc
broke Ada bootstrap. The issue is that there is a symbol clash,
libiberty contains ada_demangle symbol (with one API), and ada/adadecode.c
(since around 3.3 time, claimed for compatibility) contains another one,
with incompatible API, guarded with IN_GCC. IN_GCC for some strange reason
in Ada means that it is linked both into gnat1 and libgnat*.{a,so}.
This means that current trunk fails to bootstrap, because there are
two ada_demangle definitions being linked in.
gnat1 doesn't use ada_demangle for anything, libgnat*.{a,so} only exports it
but there are no direct users, and ada_demangle in libiberty is used froim
the same file, but not elsewhere from what I could find.
In any case, for compatibility, this patch just changes the guard so that
adadecode.c's ada_demangle is compiled only into libgnat*.{a,so} and not
into gnat1, which can then successfully link against libiberty cplus-dem.o.
The ipa-devirt.c change is obvious IMHO, the same header is included a few
lines above this.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2015-03-23 Jakub Jelinek
PR bootstrap/65522
* ipa-devirt.c: Remove duplicate demangle.h include.
* adadecode.c (ada_demangle): Guard with IN_RTS instead of IN_GCC.
--- gcc/ipa-devirt.c.jj 2015-03-23 08:47:53.0 +0100
+++ gcc/ipa-devirt.c2015-03-23 13:52:49.937174740 +0100
@@ -166,7 +166,6 @@ along with GCC; see the file COPYING3.
#include "gimple-pretty-print.h"
#include "stor-layout.h"
#include "intl.h"
-#include "demangle.h"
/* Hash based set of pairs of types. */
typedef struct
--- gcc/ada/adadecode.c.jj 2012-01-23 18:23:54.0 +0100
+++ gcc/ada/adadecode.c 2015-03-23 13:53:35.869429888 +0100
@@ -6,7 +6,7 @@
* *
* C Implementation File *
* *
- * Copyright (C) 2001-2012, Free Software Foundation, Inc.*
+ * Copyright (C) 2001-2015, Free Software Foundation, Inc.*
* *
* GNAT is free software; you can redistribute it and/or modify it under *
* terms of the GNU General Public License as published by the Free Soft- *
@@ -368,7 +368,7 @@ __gnat_decode (const char *coded_name, c
extern "C" {
#endif
-#ifdef IN_GCC
+#ifdef IN_RTS
char *
ada_demangle (const char *coded_name)
{
Jakub
[PATCH] Add some REG_POINTER flags during ix86 memcpy/memset expansion (PR target/65504)
Hi!
As expand_set_or_movmem_prologue_epilogue_by_misaligned_moves uses
src = src - (adjusted_dest - dest)
without proper REG_POINTER flags the aliasing code is very easily confused
on what is really a pointer and what is not - as REG_POINTER was used
after forwprop only on dest, but not on anything else, aliasing code thinks
that the memcpy reads dest based memory, when it really reads src based
memory (in the testcase frame pointer based in the end, but CSE did not see
it through).
Fixed by marking pseudos that must hold pointers with REG_POINTER during
the expansion. Bootstrapped/regtested on x86_64-linux and i686-linux, ok
for trunk?
2015-03-23 Jakub Jelinek
PR target/65504
* config/i386/i386.c (ix86_copy_addr_to_reg): Set REG_POINTER
on the pseudo.
(expand_set_or_movmem_prologue_epilogue_by_misaligned_moves): Set
REG_POINTER on *destptr after adjusting it for prologue size.
* gfortran.dg/pr65504.f90: New test.
--- gcc/config/i386/i386.c.jj 2015-03-23 08:47:53.0 +0100
+++ gcc/config/i386/i386.c 2015-03-23 13:38:40.573983052 +0100
@@ -23457,12 +23457,19 @@ counter_mode (rtx count_exp)
static rtx
ix86_copy_addr_to_reg (rtx addr)
{
+ rtx reg;
if (GET_MODE (addr) == Pmode || GET_MODE (addr) == VOIDmode)
-return copy_addr_to_reg (addr);
+{
+ reg = copy_addr_to_reg (addr);
+ REG_POINTER (reg) = 1;
+ return reg;
+}
else
{
gcc_assert (GET_MODE (addr) == DImode && Pmode == SImode);
- return gen_rtx_SUBREG (SImode, copy_to_mode_reg (DImode, addr), 0);
+ reg = copy_to_mode_reg (DImode, addr);
+ REG_POINTER (reg) = 1;
+ return gen_rtx_SUBREG (SImode, reg, 0);
}
}
@@ -24354,6 +24361,8 @@ expand_set_or_movmem_prologue_epilogue_b
*destptr = expand_simple_binop (GET_MODE (*destptr), PLUS, *destptr,
GEN_INT (prolog_size),
NULL_RTX, 1, OPTAB_DIRECT);
+ if (REG_P (*destptr) && REG_P (saveddest) && REG_POINTER (saveddest))
+ REG_POINTER (*destptr) = 1;
*destptr = expand_simple_binop (GET_MODE (*destptr), AND, *destptr,
GEN_INT (-desired_align),
*destptr, 1, OPTAB_DIRECT);
@@ -24363,8 +24372,8 @@ expand_set_or_movmem_prologue_epilogue_b
saveddest, 1, OPTAB_DIRECT);
/* Adjust srcptr and count. */
if (!issetmem)
- *srcptr = expand_simple_binop (GET_MODE (*srcptr), MINUS, *srcptr,
saveddest,
- *srcptr, 1, OPTAB_DIRECT);
+ *srcptr = expand_simple_binop (GET_MODE (*srcptr), MINUS, *srcptr,
+ saveddest, *srcptr, 1, OPTAB_DIRECT);
*count = expand_simple_binop (GET_MODE (*count), PLUS, *count,
saveddest, *count, 1, OPTAB_DIRECT);
/* We copied at most size + prolog_size. */
--- gcc/testsuite/gfortran.dg/pr65504.f90.jj2015-03-23 13:39:44.050945860
+0100
+++ gcc/testsuite/gfortran.dg/pr65504.f90 2015-03-23 13:39:57.707722713
+0100
@@ -0,0 +1,28 @@
+! PR target/65504
+! { dg-do run }
+
+program pr65504
+ implicit none
+ type :: T
+character (len=256) :: a
+character (len=256) :: b
+ end type T
+ type (T) :: c
+ type (T) :: d
+ c = foo ("test")
+ d = foo ("test")
+ if (trim(c%b) .ne. "foo") call abort
+ contains
+ type (T) function foo (x) result (v)
+character(len=*), intent(in) :: x
+select case (x)
+case ("test")
+ v%b = 'foo'
+case ("bazx")
+ v%b = 'barx'
+case default
+ print *, "unknown"
+ stop
+end select
+ end function foo
+end program pr65504
Jakub
Re: Fix ICEs on ODR violating programs and improve ODR mismatch diagnostic
On Mon, Mar 23, 2015 at 3:59 PM, Jakub Jelinek wrote:
> On Sun, Mar 22, 2015 at 11:11:24PM +0100, Jan Hubicka wrote:
>> --- testsuite/g++.dg/lto/pr65475b_0.C (revision 0)
>> +++ testsuite/g++.dg/lto/pr65475b_0.C (revision 0)
>> @@ -0,0 +1,9 @@
>> +/* { dg-lto-do link } */
>> +/* { dg-options "-O2 -Wno-odr" } */
>
> Wasn't this supposed to be dg-lto-options instead?
> I'm getting
> WARNING: lto.exp does not support dg-options in primary source file
> otherwise.
Yep - dg-options works in secondary files only (and applies to compile-time).
Richard.
> Jakub
Re: [PATCH] Don't hash pointers for IPA ICF, instead hash ->order ints (PR ipa/65521)
On Mon, 23 Mar 2015, Jakub Jelinek wrote:
> Hi!
>
> The recent IPA ICF hashing changes broke -fcompare-debug, hashing in
> pointers is not stable not just for -fcompare-debug, but supposedly even
> just different runs with the exact same options could yield different
> assembly. Hashing on DECL_UID is not good either, that is not guaranteed to
> be the same for -g/-g0.
> symtab_node::order is printed in the -fdump-final-insns= dumps, so I assume
> it must be stable across -g/-g0.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok.
Thanks,
Richard.
> 2014-03-23 Jakub Jelinek
>
> PR ipa/65521
> * ipa-icf.c (sem_item::update_hash_by_addr_refs): Hash
> ultimate_alias_target ()->order ints instead of
> ultimate_alias_target () pointers.
>
> * gcc.dg/pr65521.c: New test.
>
> --- gcc/ipa-icf.c.jj 2015-03-23 08:47:53.0 +0100
> +++ gcc/ipa-icf.c 2015-03-23 11:02:53.129630089 +0100
> @@ -575,7 +575,7 @@ sem_item::update_hash_by_addr_refs (hash
> {
>ref = node->iterate_reference (i, ref);
>if (ref->address_matters_p () || !m_symtab_node_map.get
> (ref->referred))
> - hstate.add_ptr (ref->referred->ultimate_alias_target ());
> + hstate.add_int (ref->referred->ultimate_alias_target ()->order);
> }
>
>if (is_a (node))
> @@ -585,7 +585,7 @@ sem_item::update_hash_by_addr_refs (hash
> {
> sem_item **result = m_symtab_node_map.get (e->callee);
> if (!result)
> - hstate.add_ptr (e->callee->ultimate_alias_target ());
> + hstate.add_int (e->callee->ultimate_alias_target ()->order);
> }
> }
>
> --- gcc/testsuite/gcc.dg/pr65521.c.jj 2015-03-23 11:03:16.190252436 +0100
> +++ gcc/testsuite/gcc.dg/pr65521.c2015-03-23 11:02:07.0 +0100
> @@ -0,0 +1,39 @@
> +/* PR ipa/65521 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fcompare-debug" } */
> +
> +struct S { int s; };
> +int f6 (void *, unsigned long);
> +int f7 (int, int *, unsigned long);
> +int f8 (void);
> +int f9 (void (*) (void));
> +
> +int
> +f1 (void *p)
> +{
> + return f6 (p, 256UL);
> +}
> +
> +int
> +f2 (void *p)
> +{
> + return f6 (p, 256UL);
> +}
> +
> +int
> +f3 (struct S *x)
> +{
> + return f7 (f8 (), &x->s, 16UL);
> +}
> +
> +int
> +f4 (struct S *x)
> +{
> + return f7 (f8 (), &x->s, 16UL);
> +}
> +
> +void
> +f5 (void)
> +{
> + f9 (f5);
> +}
>
> Jakub
>
>
--
Richard Biener
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Jennifer Guild,
Dilip Upmanyu, Graham Norton HRB 21284 (AG Nuernberg)
[PATCH] Don't hash pointers for IPA ICF, instead hash ->order ints (PR ipa/65521)
Hi!
The recent IPA ICF hashing changes broke -fcompare-debug, hashing in
pointers is not stable not just for -fcompare-debug, but supposedly even
just different runs with the exact same options could yield different
assembly. Hashing on DECL_UID is not good either, that is not guaranteed to
be the same for -g/-g0.
symtab_node::order is printed in the -fdump-final-insns= dumps, so I assume
it must be stable across -g/-g0.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2014-03-23 Jakub Jelinek
PR ipa/65521
* ipa-icf.c (sem_item::update_hash_by_addr_refs): Hash
ultimate_alias_target ()->order ints instead of
ultimate_alias_target () pointers.
* gcc.dg/pr65521.c: New test.
--- gcc/ipa-icf.c.jj2015-03-23 08:47:53.0 +0100
+++ gcc/ipa-icf.c 2015-03-23 11:02:53.129630089 +0100
@@ -575,7 +575,7 @@ sem_item::update_hash_by_addr_refs (hash
{
ref = node->iterate_reference (i, ref);
if (ref->address_matters_p () || !m_symtab_node_map.get (ref->referred))
- hstate.add_ptr (ref->referred->ultimate_alias_target ());
+ hstate.add_int (ref->referred->ultimate_alias_target ()->order);
}
if (is_a (node))
@@ -585,7 +585,7 @@ sem_item::update_hash_by_addr_refs (hash
{
sem_item **result = m_symtab_node_map.get (e->callee);
if (!result)
- hstate.add_ptr (e->callee->ultimate_alias_target ());
+ hstate.add_int (e->callee->ultimate_alias_target ()->order);
}
}
--- gcc/testsuite/gcc.dg/pr65521.c.jj 2015-03-23 11:03:16.190252436 +0100
+++ gcc/testsuite/gcc.dg/pr65521.c 2015-03-23 11:02:07.0 +0100
@@ -0,0 +1,39 @@
+/* PR ipa/65521 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fcompare-debug" } */
+
+struct S { int s; };
+int f6 (void *, unsigned long);
+int f7 (int, int *, unsigned long);
+int f8 (void);
+int f9 (void (*) (void));
+
+int
+f1 (void *p)
+{
+ return f6 (p, 256UL);
+}
+
+int
+f2 (void *p)
+{
+ return f6 (p, 256UL);
+}
+
+int
+f3 (struct S *x)
+{
+ return f7 (f8 (), &x->s, 16UL);
+}
+
+int
+f4 (struct S *x)
+{
+ return f7 (f8 (), &x->s, 16UL);
+}
+
+void
+f5 (void)
+{
+ f9 (f5);
+}
Jakub
Re: [PATCH] Fix warnings from including fdl.texi into gnat-style.texi
On Fri, 20 Mar 2015, Tom de Vries wrote: >> The gnat-style.texi part is OK. I cannot approve the fdl part though. > Gerald, > > Can you approve the fdl part? Let's assume I can. Okay. Can you just describe the _why_ a bit in a @comment (in simple words beyond showing the error message), that is, what the issue is and how you avoid it? That should help someone coming in later, trying to understand. Gerald
Re: Fix ICEs on ODR violating programs and improve ODR mismatch diagnostic
On Sun, Mar 22, 2015 at 11:11:24PM +0100, Jan Hubicka wrote:
> --- testsuite/g++.dg/lto/pr65475b_0.C (revision 0)
> +++ testsuite/g++.dg/lto/pr65475b_0.C (revision 0)
> @@ -0,0 +1,9 @@
> +/* { dg-lto-do link } */
> +/* { dg-options "-O2 -Wno-odr" } */
Wasn't this supposed to be dg-lto-options instead?
I'm getting
WARNING: lto.exp does not support dg-options in primary source file
otherwise.
Jakub
Re: [Patch 1/2, Fortran, pr60322] [OOP] Incorrect bounds on polymorphic dummy array
Le 23/03/2015 13:43, Andre Vehreschild a écrit : > Hi Mikael, > > thanks for looking at the patch. Please note, that Paul has sent an addendum > to > the patches for 60322, which I deliberately have attached. > >> 26/02/2015 18:17, Andre Vehreschild a écrit : >>> This first patch is only preparatory and does not change any of the >>> semantics of gfortran at all. >> Sure? > > With the counterexample you found below, this of course is a wrong statement. > >>> diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c >>> index ab6f7a5..d28cf77 100644 >>> --- a/gcc/fortran/expr.c >>> +++ b/gcc/fortran/expr.c >>> @@ -4059,10 +4060,10 @@ gfc_lval_expr_from_sym (gfc_symbol *sym) >>>lval->symtree = gfc_find_symtree (sym->ns->sym_root, sym->name); >>> >>>/* It will always be a full array. */ >>> - lval->rank = sym->as ? sym->as->rank : 0; >>> + as = sym->as; >>> + lval->rank = as ? as->rank : 0; >>>if (lval->rank) >>> -gfc_add_full_array_ref (lval, sym->ts.type == BT_CLASS ? >>> - CLASS_DATA (sym)->as : sym->as); >>> +gfc_add_full_array_ref (lval, as); >> >> This is a change of semantics. Or do you know that sym->ts.type != >> BT_CLASS? > > You are completely right. I have made a mistake here. I have to tell the > truth, > I never ran a regtest with only part 1 of the patches applied. The second part > of the patch will correct this, by setting the variable as depending on > whether > type == BT_CLASS or not. Sorry for the mistake. > >>> diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c >>> index 3664824..e571a17 100644 >>> --- a/gcc/fortran/trans-decl.c >>> +++ b/gcc/fortran/trans-decl.c >>> @@ -1013,16 +1017,24 @@ gfc_build_dummy_array_decl (gfc_symbol * sym, tree >>> dummy) tree decl; >>>tree type; >>>gfc_array_spec *as; >>> + symbol_attribute *array_attr; >>>char *name; >>>gfc_packed packed; >>>int n; >>>bool known_size; >>> >>> - if (sym->attr.pointer || sym->attr.allocatable >>> - || (sym->as && sym->as->type == AS_ASSUMED_RANK)) >>> + /* Use the array as and attr. */ >>> + as = sym->as; >>> + array_attr = &sym->attr; >>> + >>> + /* The pointer attribute is always set on a _data component, therefore >>> check >>> + the sym's attribute only. */ >>> + if (sym->attr.pointer || array_attr->allocatable >>> + || (as && as->type == AS_ASSUMED_RANK)) >>> return dummy; >>> >> Any reason to sometimes use array_attr, sometimes not, like here? >> By the way, the comment is misleading: for classes, there is the >> class_pointer attribute (and it is a pain, I know). > > Yes, and a good one. Array_attr is sometimes sym->attr and sometimes > CLASS_DATA(sym)->attr aka sym->ts.u.derived->components->attr. In the later > case .pointer is always set to 1 in the _data component's attr. I.e., the > above > if, would always yield true for a class_array, which is not intended, but > rather > destructive. I know about the class_pointer attribute, but I figured, that it > is not relevant here. Any idea how to formulate the comment better, to reflect > what I just explained? > This pointer stuff is very difficult to swallow to me. I understand that for classes, the CLASS_DATA (sym)->pointer is always set, but almost everywhere the checks for pointerness are like (sym->ts.type != BT_CLASS && sym->attr.pointer) || (sym->ts.type == BT_CLASS && CLASS_DATA (sym)->attr.class_pointer) and I don't see a convincing reason to have it different here. At least gfc_is_nodesc_array should return 0 if sym->ts.type == BT_CLASS which solves the problem there; for the other cases, I think that class_pointer should be looked at. gfc_build_class_symbol clears the sym->attr.pointer flag for class containers so it doesn't make sense to test that flag. Mikael
[PATCH] Fix PR65518
This fixes PR65518 where the vectorizer builds a gigantic
load/interleaving chain for single element interleaving with
a very large distance. This situation isn't really "supported"
(and works by luck with generating absymal code), thus the following
simply disables support for it.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2015-03-23 Richard Biener
PR tree-optimization/65518
* tree-vect-stmts.c (vectorizable_load): Reject single-element
interleaving cases we generate absymal code for.
* gcc.dg/vect/pr65518.c: New testcase.
Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c (revision 221532)
+++ gcc/tree-vect-stmts.c (working copy)
@@ -5780,6 +5780,22 @@ vectorizable_load (gimple stmt, gimple_s
gcc_assert (! nested_in_vect_loop && !STMT_VINFO_GATHER_P (stmt_info));
first_stmt = GROUP_FIRST_ELEMENT (stmt_info);
+
+ /* If this is single-element interleaving with an element distance
+ that leaves unused vector loads around punt - we at least create
+very sub-optimal code in that case (and blow up memory,
+see PR65518). */
+ if (first_stmt == stmt
+ && !GROUP_NEXT_ELEMENT (stmt_info)
+ && GROUP_SIZE (stmt_info) > TYPE_VECTOR_SUBPARTS (vectype))
+ {
+ if (dump_enabled_p ())
+ dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
+"single-element interleaving not supported "
+"for not adjacent vector loads\n");
+ return false;
+ }
+
if (!slp && !PURE_SLP_STMT (stmt_info))
{
group_size = GROUP_SIZE (vinfo_for_stmt (first_stmt));
Index: gcc/testsuite/gcc.dg/vect/pr65518.c
===
--- gcc/testsuite/gcc.dg/vect/pr65518.c (revision 0)
+++ gcc/testsuite/gcc.dg/vect/pr65518.c (working copy)
@@ -0,0 +1,43 @@
+/* { dg-do run } */
+
+extern void abort (void);
+
+typedef struct giga
+{
+ unsigned int g[16];
+} giga;
+
+unsigned long __attribute__((noinline,noclone))
+addfst(giga const *gptr, int num)
+{
+ unsigned int retval = 0;
+ int i;
+ for (i = 0; i < num; i++)
+retval += gptr[i].g[0];
+ return retval;
+}
+
+int main ()
+{
+ struct giga g[8];
+ unsigned int n = 1;
+ int i, j;
+ for (i = 0; i < 8; ++i)
+for (j = 0; j < 16; ++j)
+ {
+ g[i].g[j] = n++;
+ __asm__ volatile ("");
+ }
+ if (addfst (g, 8) != 456)
+abort ();
+ return 0;
+}
+
+/* We don't want to vectorize the single-element interleaving in the way
+ we currently do that (without ignoring not needed vectors in the
+ gap between gptr[0].g[0] and gptr[1].g[0]), because that's very
+ sub-optimal and causes memory explosion (even though the cost model
+ should reject that in the end). */
+
+/* { dg-final { scan-tree-dump-times "vectorized 0 loops in function" 2 "vect"
} } */
+/* { dg-final { cleanup-tree-dump "vect" } } */
Re: [Patch 1/2, Fortran, pr60322] [OOP] Incorrect bounds on polymorphic dummy array
Hi Mikael, thanks for looking at the patch. Please note, that Paul has sent an addendum to the patches for 60322, which I deliberately have attached. > 26/02/2015 18:17, Andre Vehreschild a écrit : > > This first patch is only preparatory and does not change any of the > > semantics of gfortran at all. > Sure? With the counterexample you found below, this of course is a wrong statement. > > diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c > > index ab6f7a5..d28cf77 100644 > > --- a/gcc/fortran/expr.c > > +++ b/gcc/fortran/expr.c > > @@ -4059,10 +4060,10 @@ gfc_lval_expr_from_sym (gfc_symbol *sym) > >lval->symtree = gfc_find_symtree (sym->ns->sym_root, sym->name); > > > >/* It will always be a full array. */ > > - lval->rank = sym->as ? sym->as->rank : 0; > > + as = sym->as; > > + lval->rank = as ? as->rank : 0; > >if (lval->rank) > > -gfc_add_full_array_ref (lval, sym->ts.type == BT_CLASS ? > > - CLASS_DATA (sym)->as : sym->as); > > +gfc_add_full_array_ref (lval, as); > > This is a change of semantics. Or do you know that sym->ts.type != > BT_CLASS? You are completely right. I have made a mistake here. I have to tell the truth, I never ran a regtest with only part 1 of the patches applied. The second part of the patch will correct this, by setting the variable as depending on whether type == BT_CLASS or not. Sorry for the mistake. > > diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c > > index 3664824..e571a17 100644 > > --- a/gcc/fortran/trans-decl.c > > +++ b/gcc/fortran/trans-decl.c > > @@ -1013,16 +1017,24 @@ gfc_build_dummy_array_decl (gfc_symbol * sym, tree > > dummy) tree decl; > >tree type; > >gfc_array_spec *as; > > + symbol_attribute *array_attr; > >char *name; > >gfc_packed packed; > >int n; > >bool known_size; > > > > - if (sym->attr.pointer || sym->attr.allocatable > > - || (sym->as && sym->as->type == AS_ASSUMED_RANK)) > > + /* Use the array as and attr. */ > > + as = sym->as; > > + array_attr = &sym->attr; > > + > > + /* The pointer attribute is always set on a _data component, therefore > > check > > + the sym's attribute only. */ > > + if (sym->attr.pointer || array_attr->allocatable > > + || (as && as->type == AS_ASSUMED_RANK)) > > return dummy; > > > Any reason to sometimes use array_attr, sometimes not, like here? > By the way, the comment is misleading: for classes, there is the > class_pointer attribute (and it is a pain, I know). Yes, and a good one. Array_attr is sometimes sym->attr and sometimes CLASS_DATA(sym)->attr aka sym->ts.u.derived->components->attr. In the later case .pointer is always set to 1 in the _data component's attr. I.e., the above if, would always yield true for a class_array, which is not intended, but rather destructive. I know about the class_pointer attribute, but I figured, that it is not relevant here. Any idea how to formulate the comment better, to reflect what I just explained? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de --- Begin Message --- Dear Andre and Dominique, I have found that LOC is returning the address of the class container rather than the _data component for class scalars. See the source below, which you will recognise! A fix is attached. Note that the scalar allocate fails with MOLD= and so I substituted SOURCE=. Cheers Paul class(*), allocatable :: a(:), e ! Change 'e' to an array and second memcpy works correctly ! Problem is with loc(e), which returns the address of the ! class container. allocate (e, source = 99.0) allocate (a(2), source = [1.0, 2.0]) call add_element_poly (a,e) select type (a) type is (real) print *, a end select contains subroutine add_element_poly(a,e) use iso_c_binding class(*),allocatable,intent(inout),target :: a(:) class(*),intent(in),target :: e class(*),allocatable,target :: tmp(:) type(c_ptr) :: dummy interface function memcpy(dest,src,n) bind(C,name="memcpy") result(res) import type(c_ptr) :: res integer(c_intptr_t),value :: dest integer(c_intptr_t),value :: src integer(c_size_t),value :: n end function end interface if (.not.allocated(a)) then allocate(a(1), source=e) else allocate(tmp(size(a)),source=a) deallocate(a) allocate(a(size(tmp)+1),source=e) ! mold gives a segfault dummy = memcpy(loc(a(1)),loc(tmp),sizeof(tmp)) dummy = memcpy(loc(a(size(tmp)+1)),loc(e),sizeof(e)) end if end subroutine end Index: gcc/fortran/trans-intrinsic.c === *** gcc/fortran/trans-intrinsic.c (revision 221500) --- gcc/fortran/trans-intrinsic.c (working copy) *** gfc_conv_intrinsic_l
[PATCH] Fix PR65494
This fixes PR65494 - I don't remember why I re-allocated matches
before recursing into operands. But that at least breaks backtracking.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2015-03-23 Richard Biener
PR tree-optimization/65494
* tree-vect-slp.c (vect_build_slp_tree): Do not (re-)allocate
matches here.
(vect_analyze_slp_instance): But do that here, always and once.
* gcc.dg/vect/pr65494.c: New testcase.
Index: gcc/tree-vect-slp.c
===
--- gcc/tree-vect-slp.c (revision 221532)
+++ gcc/tree-vect-slp.c (working copy)
@@ -926,14 +926,9 @@ vect_build_slp_tree (loop_vec_info loop_
bool *matches, unsigned *npermutes, unsigned *tree_size,
unsigned max_tree_size)
{
- unsigned nops, i, this_npermutes = 0, this_tree_size = 0;
+ unsigned nops, i, this_tree_size = 0;
gimple stmt;
- if (!matches)
-matches = XALLOCAVEC (bool, group_size);
- if (!npermutes)
-npermutes = &this_npermutes;
-
matches[0] = false;
stmt = SLP_TREE_SCALAR_STMTS (*node)[0];
@@ -1012,7 +1007,6 @@ vect_build_slp_tree (loop_vec_info loop_
return false;
}
- bool *matches = XALLOCAVEC (bool, group_size);
if (vect_build_slp_tree (loop_vinfo, bb_vinfo, &child,
group_size, max_nunits, loads,
vectorization_factor, matches,
@@ -1637,9 +1631,11 @@ vect_analyze_slp_instance (loop_vec_info
loads.create (group_size);
/* Build the tree for the SLP instance. */
+ bool *matches = XALLOCAVEC (bool, group_size);
+ unsigned npermutes = 0;
if (vect_build_slp_tree (loop_vinfo, bb_vinfo, &node, group_size,
&max_nunits, &loads,
- vectorization_factor, NULL, NULL, NULL,
+ vectorization_factor, matches, &npermutes, NULL,
max_tree_size))
{
/* Calculate the unrolling factor based on the smallest type. */
Index: gcc/testsuite/gcc.dg/vect/pr65494.c
===
--- gcc/testsuite/gcc.dg/vect/pr65494.c (revision 0)
+++ gcc/testsuite/gcc.dg/vect/pr65494.c (working copy)
@@ -0,0 +1,28 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-Ofast -funroll-loops" } */
+
+typedef unsigned char uchar;
+typedef struct rgb_ {uchar r; uchar g; uchar b;} rgb;
+#define N 512
+rgb in[N], out[N];
+float c[N];
+void foo(int n)
+{
+ int i, j;
+ for (i = 0; i < n; i++) //in and out are RGB byte arrays
+{
+ float r = 0, g = 0, b = 0;
+ for (j = 0; j < 5; j++)
+ {
+ r += (float)in[i + j].r * c[j];
+ g += (float)in[i + j].g * c[j];
+ b += (float)in[i + j].b * c[j];
+ }
+ out[i].r = (uchar)r;
+ out[i].g = (uchar)g;
+ out[i].b = (uchar)b;
+}
+}
+
+/* { dg-final { scan-tree-dump "vectorized 1 loops in function" "vect" {
target { vect_float && vect_intfloat_cvt } } } } */
+/* { dg-final { cleanup-tree-dump "vect" } } */
Re: [Patch 1/2, Fortran, pr60322] [OOP] Incorrect bounds on polymorphic dummy array
26/02/2015 18:17, Andre Vehreschild a écrit : > This first patch is only preparatory and does not change any of the semantics > of > gfortran at all. Sure? > diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c > index ab6f7a5..d28cf77 100644 > --- a/gcc/fortran/expr.c > +++ b/gcc/fortran/expr.c > @@ -4059,10 +4060,10 @@ gfc_lval_expr_from_sym (gfc_symbol *sym) >lval->symtree = gfc_find_symtree (sym->ns->sym_root, sym->name); > >/* It will always be a full array. */ > - lval->rank = sym->as ? sym->as->rank : 0; > + as = sym->as; > + lval->rank = as ? as->rank : 0; >if (lval->rank) > -gfc_add_full_array_ref (lval, sym->ts.type == BT_CLASS ? > - CLASS_DATA (sym)->as : sym->as); > +gfc_add_full_array_ref (lval, as); This is a change of semantics. Or do you know that sym->ts.type != BT_CLASS? > diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c > index 3664824..e571a17 100644 > --- a/gcc/fortran/trans-decl.c > +++ b/gcc/fortran/trans-decl.c > @@ -1013,16 +1017,24 @@ gfc_build_dummy_array_decl (gfc_symbol * sym, tree > dummy) >tree decl; >tree type; >gfc_array_spec *as; > + symbol_attribute *array_attr; >char *name; >gfc_packed packed; >int n; >bool known_size; > > - if (sym->attr.pointer || sym->attr.allocatable > - || (sym->as && sym->as->type == AS_ASSUMED_RANK)) > + /* Use the array as and attr. */ > + as = sym->as; > + array_attr = &sym->attr; > + > + /* The pointer attribute is always set on a _data component, therefore > check > + the sym's attribute only. */ > + if (sym->attr.pointer || array_attr->allocatable > + || (as && as->type == AS_ASSUMED_RANK)) > return dummy; > Any reason to sometimes use array_attr, sometimes not, like here? By the way, the comment is misleading: for classes, there is the class_pointer attribute (and it is a pain, I know). Mikael
Re: [Patch, Fortran, v1] Cosmetics and code simplify
Le 20/03/2015 14:51, Andre Vehreschild a écrit : > Hi all, > > during checking that pr 61275 is really fixed, I found a indentation issue and > a piece of my former code, that could be done nicer and more readable. This > patch addresses both these issues. > > Bootstraps and regtests ok on x86_64-linux-gnu/F20. > > Ok for trunk? > OK, thanks. Mikael
Re: [commited, Fortran, Backport to 4.9, pr60255] [OOP] Deferred character length variable at (1) cannot yet be associated with unlimited polymorphic entities
Hi all,
commited as r221591 to gcc_4.9-branch. Okayed by Paul via IRC on 2015-03-22.
Thanks, Paul.
gcc/fortran/ChangeLog
2015-03-23 Andre Vehreschild
Janus Weil
Backported from mainline
PR fortran/60255
Initial patch version: Janus Weil
* class.c (gfc_get_len_component): New.
(gfc_build_class_symbol): Add _len component to unlimited
polymorphic entities.
(find_intrinsic_vtab): Removed emitting of error message.
* gfortran.h: Added prototype for gfc_get_len_component.
* simplify.c (gfc_simplify_len): Use _len component where
available.
* trans-expr.c (gfc_class_len_get): New.
(gfc_conv_intrinsic_to_class): Add handling for deferred
character arrays.
(gfc_conv_structure): Treat _len component correctly.
(gfc_conv_expr): Prevent bind_c handling when not required.
(gfc_trans_pointer_assignment): Propagate _len component.
* trans-stmt.c (class_has_len_component): New.
(trans_associate_var): _len component treatement for associate
context.
(gfc_trans_allocate): Same as for trans_associate_var()
* trans.h: Add prototype for gfc_class_len_get.
gcc/testsuite/ChangeLog
2015-03-20 Andre Vehreschild
Backport from mainline
PR fortran/60255
* gfortran.dg/unlimited_polymorphic_2.f03: Removed error.
Converted from dos to unix line endings.
* gfortran.dg/unlimited_polymorphic_20.f03: New test.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (Revision 221590)
+++ gcc/testsuite/ChangeLog (Arbeitskopie)
@@ -1,3 +1,11 @@
+2015-03-20 Andre Vehreschild
+
+ Backport from mainline
+ PR fortran/60255
+ * gfortran.dg/unlimited_polymorphic_2.f03: Removed error.
+ Converted from dos to unix line endings.
+ * gfortran.dg/unlimited_polymorphic_20.f03: New test.
+
2015-03-23 Yvan Roux
Backport from trunk r216841.
Index: gcc/testsuite/gfortran.dg/unlimited_polymorphic_2.f03
===
--- gcc/testsuite/gfortran.dg/unlimited_polymorphic_2.f03 (Revision 221590)
+++ gcc/testsuite/gfortran.dg/unlimited_polymorphic_2.f03 (Arbeitskopie)
@@ -1,80 +1,80 @@
-! { dg-do compile }
-!
-! Test the most important constraints unlimited polymorphic entities
-!
-! Contributed by Paul Thomas
-!and Tobias Burnus
-!
- CHARACTER(:), allocatable, target :: chr ! { dg-error "TODO: Deferred character length variable" }
-! F2008: C5100
- integer :: i(2)
- logical :: flag
- class(*), pointer :: u1, u2(:) ! { dg-error "cannot appear in COMMON" }
- common u1
- u1 => chr
-! F2003: C625
- allocate (u1) ! { dg-error "requires either a type-spec or SOURCE tag" }
- allocate (real :: u1)
- Allocate (u1, source = 1.0)
-
-! F2008: C4106
- u2 = [u1] ! { dg-error "shall not be unlimited polymorphic" }
-
- i = u2 ! { dg-error "Can\\'t convert CLASS\\(\\*\\)" }
-
-! Repeats same_type_as_1.f03 for unlimited polymorphic u2
- flag = same_type_as (i, u2) ! { dg-error "cannot be of type INTEGER" }
- flag = extends_type_of (i, u2) ! { dg-error "cannot be of type INTEGER" }
-
-contains
-
-! C717 (R735) If data-target is unlimited polymorphic,
-! data-pointer-object shall be unlimited polymorphic, of a sequence
-! derived type, or of a type with the BIND attribute.
-!
- subroutine bar
-
-type sq
- sequence
- integer :: i
-end type sq
-
-type(sq), target :: x
-class(*), pointer :: y
-integer, pointer :: tgt
-
-x%i = 42
-y => x
-call foo (y)
-
-y => tgt ! This is OK, of course.
-tgt => y ! { dg-error "must be unlimited polymorphic" }
-
-select type (y) ! This is the correct way to accomplish the previous
- type is (integer)
-tgt => y
-end select
-
- end subroutine bar
-
-
- subroutine foo(tgt)
-class(*), pointer, intent(in) :: tgt
-type t
- sequence
- integer :: k
-end type t
-
-type(t), pointer :: ptr
-
-ptr => tgt ! C717 allows this.
-
-select type (tgt)
-! F03:C815 or F08:C839
- type is (t) ! { dg-error "shall not specify a sequence derived type" }
-ptr => tgt ! { dg-error "Expected TYPE IS" }
-end select
-
-print *, ptr%k
- end subroutine foo
-END
+! { dg-do compile }
+!
+! Test the most important constraints unlimited polymorphic entities
+!
+! Contributed by Paul Thomas
+!and Tobias Burnus
+!
+ CHARACTER(:), allocatable, target :: chr
+! F2008: C5100
+ integer :: i(2)
+ logical :: flag
+ class(*), pointer :: u1, u2(:) ! { dg-error "cannot appear in COMMON" }
+ common u1
+ u1 => chr
+! F2003: C625
+ allocate (u1) ! { dg-error "requires either a type-spec or SOURCE tag" }
+ allocate (real :: u1)
+ Allocate (u1, source = 1.0)
+
+! F2008: C4106
+ u2 = [u1] !
Re: [PATCH, GCC, stage1] Fallback to copy-prop if constant-prop not possible
On Mon, Mar 23, 2015 at 12:01 PM, Thomas Preud'homme wrote: > What about the cprop_reg_p that needs to be negated? Did I miss something > that makes it ok? You didn't miss anything. I sent the wrong patch. The one I tested on ppc64 also has the condition reversed: @@ -1328,9 +1329,8 @@ implicit_set_cond_p (const_rtx cond) if (GET_CODE (cond) != EQ && GET_CODE (cond) != NE) return false; - /* The first operand of COND must be a pseudo-reg. */ - if (! REG_P (XEXP (cond, 0)) - || HARD_REGISTER_P (XEXP (cond, 0))) + /* The first operand of COND must be a register we can propagate. */ + if (! cprop_reg_p (XEXP (cond, 0))) return false; /* The second operand of COND must be a suitable constant. */
RE: ARC length attribute patch
>> > >> I have a small patch for ARC backend that fixes the value of > >> instruction length attribute when the instruction is predicated. Ok > >> to apply? > > > > Assuming you tested it, this patch is OK. > > Sorry, I replied to the wrong patch - I meant to reply to your email with the > patch that only adds a COND_EXEC check for the maybe_limm case. > The patch is tested with the latest gcc-head (dg.exp). It also has been in place for at least the past year in the Synopsys' git gcc-4.8 branch. Thank you, Claudiu
Re: ARC length attribute patch
On 23/03/15 11:22, Joern Wolfgang Rennecke wrote: On 20/03/15 16:02, Claudiu Zissulescu wrote: Hi Joern, I have a small patch for ARC backend that fixes the value of instruction length attribute when the instruction is predicated. Ok to apply? Assuming you tested it, this patch is OK. Sorry, I replied to the wrong patch - I meant to reply to your email with the patch that only adds a COND_EXEC check for the maybe_limm case. And we've beeen discussing this on the wrong mailing list - this thread should been started gcc-patches@gcc.gnu.org; As this is not netnews where you can meaningfully set a followup-to, I changed the To: accordingly and put g...@gnu.org only in the Bcc
Re: Fix ICEs on ODR violating programs and improve ODR mismatch diagnostic
On Sun, Mar 22, 2015 at 11:11:24PM +0100, Jan Hubicka wrote: > PR ipa/65475 > * ipa-devirt.c: Include demangle.h > === > --- ipa-devirt.c (revision 221572) > +++ ipa-devirt.c (working copy) > @@ -166,6 +166,7 @@ along with GCC; see the file COPYING3. > #include "gimple-pretty-print.h" > #include "stor-layout.h" > #include "intl.h" > +#include "demangle.h" Why? demangle.h has been already included a few lines above this: #include "tree-dfa.h" #include "demangle.h" #include "dbgcnt.h" #include "gimple-pretty-print.h" #include "stor-layout.h" #include "intl.h" #include "demangle.h" Jakub
Re: [Patch, Fortran, pr55901, v1] [OOP] type is (character(len=*)) misinterpreted as array
Dear Andre, Yes, that's right. The first three (vtab rework 1/2 and pr64787) are combined and reformatted in the .diff file that I sent you. Please use that and then apply the pr55901 patch. This is what I am okaying. Cheers Paul On 23 March 2015 at 10:45, Andre Vehreschild wrote: > Hi Paul, > > thanks for the reviews. Let me ask one questions before I do something wrong. > You have reviewed and approved (with changes) the patches: > > - vtab_access_rework1_v1.patch > https://gcc.gnu.org/ml/fortran/2015-03/msg00074.html > - vtab_access_rework2_v1.patch > https://gcc.gnu.org/ml/fortran/2015-03/msg00075.html > - pr64787_v2.patch > https://gcc.gnu.org/ml/fortran/2015-03/msg00085.html > and > - pr55901_v1.patch > https://gcc.gnu.org/ml/fortran/2015-03/msg00086.html > , right? > > I am asking so explicitly, because there are four more patches from me in the > wild, that await review (not necessarily from you, Paul), namely: > > - pr60322_base_1.patch > https://gcc.gnu.org/ml/fortran/2015-02/msg00105.html > - pr60322_3.patch > https://gcc.gnu.org/ml/fortran/2015-03/msg00032.html > - crashfix2_v1.patch (small patch, ~100 loc)) > https://gcc.gnu.org/ml/fortran/2015-03/msg00063.html > and > - cosm_simp.patch (tiny patch, ~20 loc) > https://gcc.gnu.org/ml/fortran/2015-03/msg00088.html > > Please don't get me wrong on this. I just want to prevent misunderstandings > here. The latter four patches are not yet approved, right? > > I will now apply the 4.9-trunk patch and wait for your answer before applying > the above four on vtab_rework pr64787 and pr55901. > > Regards, > Andre > > > > On Mon, 23 Mar 2015 08:33:51 +0100 > Paul Richard Thomas wrote: > >> Dear Andre, >> >> I am persuaded by the arguments of Jerry and Dominique that this is >> good for trunk. Please commit as early as possible in order that any >> regressions can be caught, if possible, before release. >> >> Thanks >> >> Paul >> >> On 21 March 2015 at 15:11, Paul Richard Thomas >> wrote: >> > Dear Andre, >> > >> > I have applied the three preliminary patches but have not yet applied >> > the attached one for PR55901. As advertised the composite patch >> > bootstraps and regtests on FC21,x86_64. >> > >> > I went through gfc_trans_allocate and cleaned up the formatting and >> > some of the text in the comments. You did a heroic job to tidy up this >> > function and so I thought that I should do my bit - one of the >> > feature, previously, was that the line length often went well in >> > excess of the gcc style guide limit of 72 and this tended to make it >> > somewhat unreadable. I have not been rigorous about this, especially >> > when readability would be impaired thereby, but it does look a lot >> > better now. The composite diff is attached. >> > >> > Not only does the Metcalf example run correctly but also the PGI >> > Insider linked list example. I have attached a version of this >> > modified to function as a gfortran.dg testcase. With the attributions >> > in there, I do not think that there are any copyright issues. The >> > article itself has no copyright notice. >> > >> > I would very much like to say that this is OK for trunk but we are >> > hard up against the end of stage 4 and so it should really wait for >> > backporting to 5.2. >> > >> > Thanks for the patches >> > >> > Paul >> > >> > On 19 March 2015 at 16:13, Andre Vehreschild wrote: >> >> Hi all, >> >> >> >> please find attached the parts missing to stop valgrind's complaining >> >> about the use of uninitialized memory. The issue was, that when >> >> constructing a temporary class-object to call a routine with unlimited >> >> polymorphic arguments, the _len component was never set. This is fixed by >> >> this patch now. >> >> >> >> Note, the patch is based on all these preliminary patches: >> >> >> >> https://gcc.gnu.org/ml/fortran/2015-03/msg00074.html >> >> https://gcc.gnu.org/ml/fortran/2015-03/msg00075.html >> >> https://gcc.gnu.org/ml/fortran/2015-03/msg00085.html >> >> >> >> Bootstraps and regtests ok on x86_64-linux-gnu/F20. >> >> >> >> Please review! >> >> >> >> - Andre >> >> -- >> >> Andre Vehreschild * Email: vehre ad gmx dot de >> > >> > >> > >> > -- >> > Outside of a dog, a book is a man's best friend. Inside of a dog it's >> > too dark to read. >> > >> > Groucho Marx >> >> >> > > > -- > Andre Vehreschild * Email: vehre ad gmx dot de -- Outside of a dog, a book is a man's best friend. Inside of a dog it's too dark to read. Groucho Marx
RE: [PATCH, GCC, stage1] Fallback to copy-prop if constant-prop not possible
> From: Steven Bosscher [mailto:stevenb@gmail.com]
> Sent: Friday, March 20, 2015 8:14 PM
>
> I put the cprop_reg_p check there instead of !HARD_REGISTER_P
> because
> I like to be able to quickly find all places where a similar check is
> performed. The check is whether the reg is something that copy
> propagation can handle, and that is what I added cprop_reg_p for.
Makes sense indeed. I didn't think about the meaning of it.
> (Note that cprop can _currently_ handle only pseudos but there is no
> reason why a limited set of hard regs can't be handled also, e.g. the
> flag registers like in targetm.fixed_condition_code_regs).
>
> In this case, the result is that REG_P is checked twice.
> But then again, cprop_reg_p will be inlined and the double check
> optimized away.
True.
>
> Anyway, I guess we've bikeshedded long enough over this patch as it is
> :-) Let's post a final form and declare it OK for stage1.
What about the cprop_reg_p that needs to be negated? Did I miss something
that makes it ok?
>
> As for PSEUDO_REG_P: If it were up to me, I'd like to have in rtl.h:
>
> static bool
> hard_register_p (rtx x)
> {
> return (REG_P (x) && HARD_REGISTER_NUM_P (REGNO (x)));
> }
>
> static bool
> pseudo_register_p (rtx x)
> {
> return (REG_P (x) && !HARD_REGISTER_NUM_P (REGNO (x)));
> }
>
> and do away with all the FIRST_PSEUDO_REGISTER tests. But I've
> proposed this in the past and there was opposition. Perhaps when we
> introduce a rtx_reg class...
Ok I'll try to dig up what was the reasons presented. Anyway, it would
be done in a separate patch so not a problem for this one.
FYI testing your patch with the one cprop_reg_p negated as said in my
previous email shows no regression on arm-none-eabi cross-compiler
targeting Cortex-M3. Testing for x86_64 is ongoing.
Best regards,
Thomas
Re: [PATCH, libmpx, i386, PR driver/65444] Pass '-z bndplt' when building dynamic objects with MPX
Hi,
May this patch go into trunk at this point? It is very important for
dynamic MPX codes.
Thanks,
Ilya
2015-03-18 14:56 GMT+03:00 Ilya Enkovich :
> Hi,
>
> This patch fixes PR target/65444 by passing '-z bndplt' to linker when
> appropriate. Bootstrapped and tested on x86_64-unknown-linux-gnu. Will
> commit it to trunk in a couple of days if no objections arise.
>
> Thanks,
> Ilya
> --
> gcc/
>
> 2015-03-18 Ilya Enkovich
>
> PR driver/65444
> * config/i386/linux-common.h (MPX_SPEC): New.
> (CHKP_SPEC): Add MPX_SPEC.
>
> libmpx/
>
> 2015-03-18 Ilya Enkovich
>
> PR driver/65444
> * configure.ac: Add check for '-z bndplt' support
> by linker. Add link_mpx output variable.
> * libmpx.spec.in (link_mpx): New.
> * configure: Regenerate.
>
>
> diff --git a/gcc/config/i386/linux-common.h b/gcc/config/i386/linux-common.h
> index 9c6560b..dd79ec6 100644
> --- a/gcc/config/i386/linux-common.h
> +++ b/gcc/config/i386/linux-common.h
> @@ -59,6 +59,11 @@ along with GCC; see the file COPYING3. If not see
> %:include(libmpx.spec)%(link_libmpx)"
> #endif
>
> +#ifndef MPX_SPEC
> +#define MPX_SPEC "\
> +
> %{mmpx:%{fcheck-pointer-bounds:%{!static:%:include(libmpx.spec)%(link_mpx)}}}"
> +#endif
> +
> #ifndef LIBMPX_SPEC
> #if defined(HAVE_LD_STATIC_DYNAMIC)
> #define LIBMPX_SPEC "\
> @@ -89,5 +94,5 @@ along with GCC; see the file COPYING3. If not see
>
> #ifndef CHKP_SPEC
> #define CHKP_SPEC "\
> -%{!nostdlib:%{!nodefaultlibs:" LIBMPX_SPEC LIBMPXWRAPPERS_SPEC "}}"
> +%{!nostdlib:%{!nodefaultlibs:" LIBMPX_SPEC LIBMPXWRAPPERS_SPEC "}}" MPX_SPEC
> #endif
> diff --git a/libmpx/configure.ac b/libmpx/configure.ac
> index fe0d3f2..3f8b50f 100644
> --- a/libmpx/configure.ac
> +++ b/libmpx/configure.ac
> @@ -40,7 +40,18 @@ AC_MSG_RESULT($LIBMPX_SUPPORTED)
> AM_CONDITIONAL(LIBMPX_SUPPORTED, [test "x$LIBMPX_SUPPORTED" = "xyes"])
>
> link_libmpx="-lpthread"
> +link_mpx=""
> +AC_MSG_CHECKING([whether ld accepts -z bndplt])
> +echo "int main() {};" > conftest.c
> +if AC_TRY_COMMAND([${CC} ${CFLAGS} -Wl,-z,bndplt -o conftest conftest.c
> 1>&AS_MESSAGE_LOG_FD])
> +then
> +AC_MSG_RESULT([yes])
> +link_mpx="$link_mpx -z bndplt"
> +else
> +AC_MSG_RESULT([no])
> +fi
> AC_SUBST(link_libmpx)
> +AC_SUBST(link_mpx)
>
> AM_INIT_AUTOMAKE(foreign no-dist no-dependencies)
> AM_ENABLE_MULTILIB(, ..)
> diff --git a/libmpx/libmpx.spec.in b/libmpx/libmpx.spec.in
> index a265e28..34d0bdf 100644
> --- a/libmpx/libmpx.spec.in
> +++ b/libmpx/libmpx.spec.in
> @@ -1,3 +1,5 @@
> # This spec file is read by gcc when linking. It is used to specify the
> -# standard libraries we need in order to link with libcilkrts.
> +# standard libraries we need in order to link with libmpx.
> *link_libmpx: @link_libmpx@
> +
> +*link_mpx: @link_mpx@
Re: [Patch, Fortran, pr55901, v1] [OOP] type is (character(len=*)) misinterpreted as array
Hi Paul, thanks for the reviews. Let me ask one questions before I do something wrong. You have reviewed and approved (with changes) the patches: - vtab_access_rework1_v1.patch https://gcc.gnu.org/ml/fortran/2015-03/msg00074.html - vtab_access_rework2_v1.patch https://gcc.gnu.org/ml/fortran/2015-03/msg00075.html - pr64787_v2.patch https://gcc.gnu.org/ml/fortran/2015-03/msg00085.html and - pr55901_v1.patch https://gcc.gnu.org/ml/fortran/2015-03/msg00086.html , right? I am asking so explicitly, because there are four more patches from me in the wild, that await review (not necessarily from you, Paul), namely: - pr60322_base_1.patch https://gcc.gnu.org/ml/fortran/2015-02/msg00105.html - pr60322_3.patch https://gcc.gnu.org/ml/fortran/2015-03/msg00032.html - crashfix2_v1.patch (small patch, ~100 loc)) https://gcc.gnu.org/ml/fortran/2015-03/msg00063.html and - cosm_simp.patch (tiny patch, ~20 loc) https://gcc.gnu.org/ml/fortran/2015-03/msg00088.html Please don't get me wrong on this. I just want to prevent misunderstandings here. The latter four patches are not yet approved, right? I will now apply the 4.9-trunk patch and wait for your answer before applying the above four on vtab_rework pr64787 and pr55901. Regards, Andre On Mon, 23 Mar 2015 08:33:51 +0100 Paul Richard Thomas wrote: > Dear Andre, > > I am persuaded by the arguments of Jerry and Dominique that this is > good for trunk. Please commit as early as possible in order that any > regressions can be caught, if possible, before release. > > Thanks > > Paul > > On 21 March 2015 at 15:11, Paul Richard Thomas > wrote: > > Dear Andre, > > > > I have applied the three preliminary patches but have not yet applied > > the attached one for PR55901. As advertised the composite patch > > bootstraps and regtests on FC21,x86_64. > > > > I went through gfc_trans_allocate and cleaned up the formatting and > > some of the text in the comments. You did a heroic job to tidy up this > > function and so I thought that I should do my bit - one of the > > feature, previously, was that the line length often went well in > > excess of the gcc style guide limit of 72 and this tended to make it > > somewhat unreadable. I have not been rigorous about this, especially > > when readability would be impaired thereby, but it does look a lot > > better now. The composite diff is attached. > > > > Not only does the Metcalf example run correctly but also the PGI > > Insider linked list example. I have attached a version of this > > modified to function as a gfortran.dg testcase. With the attributions > > in there, I do not think that there are any copyright issues. The > > article itself has no copyright notice. > > > > I would very much like to say that this is OK for trunk but we are > > hard up against the end of stage 4 and so it should really wait for > > backporting to 5.2. > > > > Thanks for the patches > > > > Paul > > > > On 19 March 2015 at 16:13, Andre Vehreschild wrote: > >> Hi all, > >> > >> please find attached the parts missing to stop valgrind's complaining > >> about the use of uninitialized memory. The issue was, that when > >> constructing a temporary class-object to call a routine with unlimited > >> polymorphic arguments, the _len component was never set. This is fixed by > >> this patch now. > >> > >> Note, the patch is based on all these preliminary patches: > >> > >> https://gcc.gnu.org/ml/fortran/2015-03/msg00074.html > >> https://gcc.gnu.org/ml/fortran/2015-03/msg00075.html > >> https://gcc.gnu.org/ml/fortran/2015-03/msg00085.html > >> > >> Bootstraps and regtests ok on x86_64-linux-gnu/F20. > >> > >> Please review! > >> > >> - Andre > >> -- > >> Andre Vehreschild * Email: vehre ad gmx dot de > > > > > > > > -- > > Outside of a dog, a book is a man's best friend. Inside of a dog it's > > too dark to read. > > > > Groucho Marx > > > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [PATCH, rtl-optimization]: Fix PR60851, ICE: in extract_constrain_insn_cached, at recog.c
On Thu, Mar 19, 2015 at 9:38 AM, Uros Bizjak wrote:
> On Thu, Mar 19, 2015 at 8:44 AM, Jakub Jelinek wrote:
>> On Wed, Mar 18, 2015 at 08:00:33PM +0100, Uros Bizjak wrote:
>>> 2015-03-18 Uros Bizjak
>>>
>>> PR rtl-optimization/60851
>>> * recog.c (constrain_operands): Accept a pseudo register before reload
>>> for LRA enabled targets.
>
>> As the two adjacent conditions are mostly the same, perhaps it might be
>> better written as
>>|| ((/* Before reload, accept a pseudo, since
>>LRA can turn it into a mem.
>> (targetm.lra_p () && strict < 0)
>> /* During reload, accept a pseudo. */
>> || reload_in_progress)
>>&& REG_P (op)
>>&& REGNO (op) >= FIRST_PSEUDO_REGISTER)))
>>
>> or put REG_P && REGNO checks first and only then test when.
>
> Yeah, I thought about this particular CSE a bit. But since these are
> two conceptually different conditions, and the formatting (and
> comments) just didn't fit into available space, I wrote it this way.
> IMO, it is more readable, better follows the intended logic, and
> avoids even more indents.
>
> Also, I am pretty sure that any decent compiler can CSE this part on its own.
>
> However, the condition can be slightly improved by rewriting it to:
>
>/* Before reload, accept a pseudo,
> since LRA can turn it into a mem. */
>|| (strict < 0 && targetm.lra_p () && REG_P (op)
>&& REGNO (op) >= FIRST_PSEUDO_REGISTER)
>
> so, we have cheaper tests in the front to shortcut more expensive tests later.
>
>> For 4.9 backport, please wait a few days after it goes into the trunk.
Attached is the 4.9 branch version of the patch. There were
substantial cleanups [1] in this area for 5.0, so comparing to trunk
version, the patch includes two more places that have to be changed.
Patch was bootstrapped and regression tested on x86_64-linux-gnu
{,-m32}. If there are no objections, I plan to commit this version to
the branch in a couple of days.
[1] https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00530.html
Uros.
Index: testsuite/gcc.target/i386/pr60851.c
===
--- testsuite/gcc.target/i386/pr60851.c (revision 0)
+++ testsuite/gcc.target/i386/pr60851.c (revision 0)
@@ -0,0 +1,7 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -flive-range-shrinkage -mtune=bdver4
-mdispatch-scheduler" } */
+
+long double ld (char c)
+{
+ return c;
+}
Index: recog.c
===
--- recog.c (revision 221587)
+++ recog.c (working copy)
@@ -2627,9 +2627,14 @@ constrain_operands (int strict)
break;
win = 1;
}
- /* Before reload, accept what reload can turn into mem. */
+ /* Before reload, accept what reload can turn into a mem. */
else if (strict < 0 && CONSTANT_P (op))
win = 1;
+ /* Before reload, accept a pseudo,
+ since LRA can turn it into a mem. */
+ else if (strict < 0 && targetm.lra_p () && REG_P (op)
+&& REGNO (op) >= FIRST_PSEUDO_REGISTER)
+ win = 1;
/* During reload, accept a pseudo */
else if (reload_in_progress && REG_P (op)
&& REGNO (op) >= FIRST_PSEUDO_REGISTER)
@@ -2708,6 +2713,10 @@ constrain_operands (int strict)
/* Before reload, accept what reload can handle. */
|| (strict < 0
&& (CONSTANT_P (op) || MEM_P (op)))
+ /* Before reload, accept a pseudo,
+ since LRA can turn it into a mem. */
+ || (strict < 0 && targetm.lra_p () && REG_P (op)
+ && REGNO (op) >= FIRST_PSEUDO_REGISTER)
/* During reload, accept a pseudo */
|| (reload_in_progress && REG_P (op)
&& REGNO (op) >= FIRST_PSEUDO_REGISTER))
@@ -2739,8 +2748,12 @@ constrain_operands (int strict)
/* Every memory operand can be reloaded to fit. */
&& ((strict < 0 && MEM_P (op))
/* Before reload, accept what reload can turn
- into mem. */
+ into a mem. */
|| (strict < 0 && CONSTANT_P (op))
+ /* Before reload, accept a pseudo,
+ since LRA can turn it into a mem. */
+ || (strict < 0 && targetm.lra_p () && REG_P (op)
+
[PING] [PATCH] Fix another wrong-code bug with -fstrict-volatile-bitfields
Hi,
I'd like to ping for this patch, which I hope can still go in the gcc-5 release:
See https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00817.html for the
patch files.
Thanks,
Bernd.
> Date: Mon, 16 Mar 2015 11:53:00 +0100
>
>
> Hi,
>
>
> when looking at the m68k I realized the following, which is
> a general problem...
>
> If the alignment of the structure is less than sizeof(field), the
> strict volatile bitfields code may read beyond the end of the
> structure!
>
> Consider this example:
>
> struct s
> {
> char x : 8;
> volatile unsigned int y : 31;
> volatile unsigned int z : 1;
> } __attribute__((packed));
>
> struct s global;
>
>
> Here we have sizeof(struct s) = 5, alignment(global) == 1,
> However when we access global.z we read a 32-bit word
> at offset 4, which touches 3 bytes that are not safe to use.
>
> Something like that does never happen with -fno-strict-volatile-bitfields,
> because IIRC, with the only exception of the simple_mem_bitfield_p code path,
> there is never an access mode used which is larger than MEM_ALIGN(x).
>
> In this example, if I want to use the packed attribute,
> I also have to use the aligned(4) attribute, this satisfies the
> check "MEM_ALIGN (op0) < modesize", which is IMO always necessary
> for strict volatile bitfields, not only on STRICT_ALIGNMENT targets.
>
> On a target, that has BIGGEST_ALIGNMENT < BITS_PER_WORD,
> to use the strict volatile bitfields, you have to add the
> __attribute__((aligned(4)))
> to the structure.
>
> I had to do that on the pr23623.c test case, to have it passed on m68k for
> instance.
>
>
> I have attached the updated patch. As explained before, the check
> MEM_ALIGN (op0) < modesize should always be done in
> strict_volatile_bitfield_p.
>
> For the targets, that usually enable -fstrict-volatile-bitfields, nothing
> changes,
> Except when we use "packed" on the structure, we need to add also an
> aligned(4)
> attribute. For m68k where the natural alignment of any structure is <=2 we
> need to
> force aligned(4) if we want to ensure the access is in SImode.
>
> Boot-strapped and reg-tested on x86_64-linux-gnu.
> OK for trunk?
>
>
> Thanks
> Bernd.
>
Re: Fix ICEs on ODR violating programs and improve ODR mismatch diagnostic
Jan Hubicka writes: > * ipa-devirt.c: Include demangle.h This breaks ada. ../libiberty/libiberty.a(cplus-dem.o): In function `ada_demangle': /usr/local/gcc/gcc-20150323/Build/libiberty/../../libiberty/cplus-dem.c:895: multiple definition of `ada_demangle' ada/adadecode.o:/usr/local/gcc/gcc-20150323/Build/gcc/../../gcc/ada/adadecode.c:373: first defined here collect2: ld returned 1 exit status Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: [PATCH] Make split_block and create_basic_block type-safe
On Fri, 20 Mar 2015, David Malcolm wrote:
> On Thu, 2015-03-12 at 14:20 +0100, Richard Biener wrote:
> > After noticing tree-parloop.c passing crap to split_block (a tree
> > rather than a gimple or an rtx) I noticed those CFG functions simply
> > take void * pointers. The following patch fixes that and adds
> > two overloads, one for GIMPLE use and one for RTL use.
> >
> > Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
> >
> > Ok at this stage?
> >
> > Thanks,
> > Richard.
> >
> > 2015-03-12 Richard Biener
> >
> > * cfghooks.h (create_basic_block): Replace with two overloads
> > for RTL and GIMPLE.
> > (split_block): Likewise.
> > * cfghooks.c (split_block): Rename to ...
> > (split_block_1): ... this.
> > (split_block): Add two type-safe overloads for RTL and GIMPLE.
> > (split_block_after_labels): Call split_block_1.
> > (create_basic_block): Rename to ...
> > (create_basic_block_1): ... this.
> > (create_basic_block): Add two type-safe overloads for RTL and GIMPLE.
> > (create_empty_bb): Call create_basic_block_1.
> > * cfgrtl.c (fixup_fallthru_exit_predecessor): Use
> > split_block_after_labels.
> > * omp-low.c (expand_parallel_call): Likewise.
> > (expand_omp_target): Likewise.
> > (simd_clone_adjust): Likewise.
> > * tree-chkp.c (chkp_get_entry_block): Likewise.
> > * cgraphunit.c (init_lowered_empty_function): Use the GIMPLE
> > create_basic_block overload.
> > (cgraph_node::expand_thunk): Likewise.
> > * tree-cfg.c (make_blocks): Likewise.
> > (handle_abnormal_edges): Likewise.
> > * tree-inline.c (copy_bb): Likewise.
> >
> > Index: gcc/cfghooks.c
> > ===
> > --- gcc/cfghooks.c (revision 221379)
> > +++ gcc/cfghooks.c (working copy)
>
> [...snip...]
>
> > +edge
> > +split_block (basic_block bb, rtx i)
> > +{
> > + return split_block_1 (bb, i);
> > +}
>
> Possibly a dumb question, but could this take an rtx_insn * rather than
> a plain rtx?
Well, as you noted below...
> > +basic_block
> > +create_basic_block (rtx head, rtx end, basic_block after)
> > +{
> > + return create_basic_block_1 (head, end, after);
> > +}
>
> Likewise for head and end... though I see a fix would be needed in
> bfin.c:hwloop_optimize, at least.
...it would have required building all sorts of targets.
But sure, as this is now stage1 stuff I'll see to make it rtx_insns.
Richard.
Re: [Patch, Fortran, pr55901, v1] [OOP] type is (character(len=*)) misinterpreted as array
Dear Andre, I am persuaded by the arguments of Jerry and Dominique that this is good for trunk. Please commit as early as possible in order that any regressions can be caught, if possible, before release. Thanks Paul On 21 March 2015 at 15:11, Paul Richard Thomas wrote: > Dear Andre, > > I have applied the three preliminary patches but have not yet applied > the attached one for PR55901. As advertised the composite patch > bootstraps and regtests on FC21,x86_64. > > I went through gfc_trans_allocate and cleaned up the formatting and > some of the text in the comments. You did a heroic job to tidy up this > function and so I thought that I should do my bit - one of the > feature, previously, was that the line length often went well in > excess of the gcc style guide limit of 72 and this tended to make it > somewhat unreadable. I have not been rigorous about this, especially > when readability would be impaired thereby, but it does look a lot > better now. The composite diff is attached. > > Not only does the Metcalf example run correctly but also the PGI > Insider linked list example. I have attached a version of this > modified to function as a gfortran.dg testcase. With the attributions > in there, I do not think that there are any copyright issues. The > article itself has no copyright notice. > > I would very much like to say that this is OK for trunk but we are > hard up against the end of stage 4 and so it should really wait for > backporting to 5.2. > > Thanks for the patches > > Paul > > On 19 March 2015 at 16:13, Andre Vehreschild wrote: >> Hi all, >> >> please find attached the parts missing to stop valgrind's complaining about >> the >> use of uninitialized memory. The issue was, that when constructing a >> temporary >> class-object to call a routine with unlimited polymorphic arguments, the _len >> component was never set. This is fixed by this patch now. >> >> Note, the patch is based on all these preliminary patches: >> >> https://gcc.gnu.org/ml/fortran/2015-03/msg00074.html >> https://gcc.gnu.org/ml/fortran/2015-03/msg00075.html >> https://gcc.gnu.org/ml/fortran/2015-03/msg00085.html >> >> Bootstraps and regtests ok on x86_64-linux-gnu/F20. >> >> Please review! >> >> - Andre >> -- >> Andre Vehreschild * Email: vehre ad gmx dot de > > > > -- > Outside of a dog, a book is a man's best friend. Inside of a dog it's > too dark to read. > > Groucho Marx -- Outside of a dog, a book is a man's best friend. Inside of a dog it's too dark to read. Groucho Marx
