[Patch, fortran] PR57710 - [OOP] [F08] _vptr not set for allocatable CLASS component inside BLOCK
This patch is relatively trivial and represents my first foray into
gitland. Thus far, it has been... well, "interesting" compared with
svn.
Class components of derived types are initialized by calls to
trans-array.c(gfc_trans_deferred_array) from
trans-decl.c(gfc_trans_deferred_vars). The components are nullified in
trans-array.c(structure_alloc_comps). The 'same_type_as' intrinsic
requires that nullified class components either point to the declared
type vtable or, in the case of unlimited polymorphic components, the
vptr should be null. See Note 16.28 in the F2018 standard. The
attached patch implements that requirement.
Regtested on FC31/x86_64 - OK for head?
Paul
2020-02-23 Paul Thomas
PR fortran/57710
* trans-array.c (structure_alloc_comps): When nullifying class
components, the vptr must point to the declared type or, in the
case of unlimited polymorphic components, it should be null.
2020-02-23 Paul Thomas
PR fortran/57710
* gfortran.dg/same_type_as_3.f03 : New test.
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 66598161fd8..0449d281bf7 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -8827,7 +8827,7 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
cdesc = gfc_create_var (cdesc, "cdesc");
DECL_ARTIFICIAL (cdesc) = 1;
-
+
gfc_add_modify (&tmpblock, gfc_conv_descriptor_dtype (cdesc),
gfc_get_dtype_rank_type (1, tmp));
gfc_conv_descriptor_lbound_set (&tmpblock, cdesc,
@@ -8838,7 +8838,7 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
gfc_index_one_node);
gfc_conv_descriptor_ubound_set (&tmpblock, cdesc,
gfc_index_zero_node, ubound);
-
+
if (attr->dimension)
comp = gfc_conv_descriptor_data_get (comp);
else
@@ -9116,10 +9116,14 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
&& (CLASS_DATA (c)->attr.allocatable
|| CLASS_DATA (c)->attr.class_pointer))
{
+ tree vptr_decl;
+
/* Allocatable CLASS components. */
comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
decl, cdecl, NULL_TREE);
+ vptr_decl = gfc_class_vptr_get (comp);
+
comp = gfc_class_data_get (comp);
if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (comp)))
gfc_conv_descriptor_data_set (&fnblock, comp,
@@ -9131,6 +9135,24 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
build_int_cst (TREE_TYPE (comp), 0));
gfc_add_expr_to_block (&fnblock, tmp);
}
+
+ /* The dynamic type of a disassociated pointer or unallocated
+ allocatable variable is its declared type. An unlimited
+ polymorphic entity has no declared type. */
+ if (!UNLIMITED_POLY (c))
+ {
+ vtab = gfc_find_derived_vtab (c->ts.u.derived);
+ if (!vtab->backend_decl)
+ gfc_get_symbol_decl (vtab);
+ tmp = gfc_build_addr_expr (NULL_TREE, vtab->backend_decl);
+ }
+ else
+ tmp = build_int_cst (TREE_TYPE (vptr_decl), 0);
+
+ tmp = fold_build2_loc (input_location, MODIFY_EXPR,
+ void_type_node, vptr_decl, tmp);
+ gfc_add_expr_to_block (&fnblock, tmp);
+
cmp_has_alloc_comps = false;
}
/* Coarrays need the component to be nulled before the api-call
diff --git a/gcc/testsuite/gfortran.dg/same_type_as_3.f03 b/gcc/testsuite/gfortran.dg/same_type_as_3.f03
new file mode 100644
index 000..3a81e749763
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/same_type_as_3.f03
@@ -0,0 +1,27 @@
+! { dg-do run }
+!
+! Test the fix for PR57710.
+!
+! Contributed by Tobias Burnus
+!
+module m
+ type t
+ end type t
+ type t2
+integer :: ii
+class(t), allocatable :: x
+ end type t2
+contains
+ subroutine fini(x)
+ type(t) :: x
+ end subroutine fini
+end module m
+
+use m
+block
+ type(t) :: z
+ type(t2) :: y
+ y%ii = 123
+ if (.not. same_type_as(y%x, z)) call abort ()
+end block
+end
[PATCH] libstd++: Library-side tests for parenthesized aggregate init (c++/92878, c++/92947)
This shebang adds library tests for all cases of parenthesized aggregate initialization that I could find. Tested locally on Linux-x64, going to test with full suite on Linux-PPC64, OK for trunk if tests pass? 2020-02-23 Ville Voutilainen Library-side tests for parenthesized aggregate init PR c++/92878 PR c++/92947 * testsuite/20_util/allocator_traits/members/92878_92947.cc: New. * testsuite/20_util/any/assign/92878_92947.cc: Likewise. * testsuite/20_util/any/cons/92878_92947.cc: Likewise. * testsuite/20_util/is_constructible/92878_92947.cc: Likewise. * testsuite/20_util/optional/assignment/92878_92947.cc: Likewise. * testsuite/20_util/optional/cons/92878_92947.cc: Likewise. * testsuite/20_util/pair/cons/92878_92947.cc: Likewise. * testsuite/20_util/shared_ptr/creation/92878_92947.cc: Likewise. * testsuite/20_util/specialized_algorithms/construct_at/92878_92947.cc: Likewise. * testsuite/20_util/unique_ptr/creation/92878_92947.cc: Likewise. * testsuite/20_util/uses_allocator/92878_92947.cc: Likewise. * testsuite/20_util/variant/92878_92947.cc: Likewise. * testsuite/23_containers/deque/modifiers/emplace/92878_92947.cc: Likewise. * testsuite/23_containers/forward_list/modifiers/92878_92947.cc: Likewise. * testsuite/23_containers/list/modifiers/emplace/92878_92947.cc: Likewise. * testsuite/23_containers/map/modifiers/emplace/92878_92947.cc: Likewise. * testsuite/23_containers/multimap/modifiers/emplace/92878_92947.cc: Likewise. * testsuite/23_containers/multiset/modifiers/emplace/92878_92947.cc: Likewise. * testsuite/23_containers/priority_queue/92878_92947.cc: Likewise. * testsuite/23_containers/queue/92878_92947.cc: Likewise. * testsuite/23_containers/set/modifiers/emplace/92878_92947.cc: Likewise. * testsuite/23_containers/stack/92878_92947.cc: Likewise. * testsuite/23_containers/unordered_map/modifiers/92878_92947.cc: Likewise. * testsuite/23_containers/unordered_multimap/modifiers/92878_92947.cc: Likewise. * testsuite/23_containers/unordered_multiset/modifiers/92878_92947.cc: Likewise. * testsuite/23_containers/unordered_set/modifiers/92878_92947.cc: Likewise. * testsuite/23_containers/vector/modifiers/emplace/92878_92947.cc: Likewise. aggr-init-lib-tests.diff.gz Description: application/gzip
Re: [Patch, fortran] PR57710 - [OOP] [F08] _vptr not set for allocatable CLASS component inside BLOCK
Hi Paul, Regtested on FC31/x86_64 - OK for head? Looks good. Best of luck committing! Regards Thomas
Re: [Patch, fortran] PR57710 - [OOP] [F08] _vptr not set for allocatable CLASS component inside BLOCK
Committed as r10-6801-g61c8d9e4e5f540501eaa98aae1d6c74bde7d4299 Thanks Paul On Sun, 23 Feb 2020 at 14:25, Thomas Koenig wrote: > > Hi Paul, > > > Regtested on FC31/x86_64 - OK for head? > > Looks good. > > Best of luck committing! > > Regards > > Thomas -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
[patch, committed] Fix trailing space in diagnostic
Committed as simple and obvious, r10-6802-g7260547dbffd8e6442f99da8adf98ab0ce294e4e. Regards Thomas Fix error message. 2020-02-23 Thomas Koenig PR fortran/93890 * interface.c: Replace "can not" by "cannot" and remove trailing space. 2020-02-23 Thomas Koenig PR fortran/93890 * gfortran.dg/argument_checking_24.f90: Correct test case.
[patch, fortran, committed] Add missing closing parenthises in error message.
Another trival patch. Regards Thomas Add missing closing parenthises in error message. 2020-02-23 Thomas Koenig PR fortran/93889 * interface.c (compare_parameter): Fix error message. diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog index 5f889fb3120..1ed6a97366e 100644 --- a/gcc/fortran/ChangeLog +++ b/gcc/fortran/ChangeLog @@ -1,3 +1,8 @@ +2020-02-23 Thomas Koenig + + PR fortran/93889 + * interface.c (compare_parameter): Fix error message. + 2020-02-23 Thomas Koenig PR fortran/93890 diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c index 4106fe5831b..14d03c27759 100644 --- a/gcc/fortran/interface.c +++ b/gcc/fortran/interface.c @@ -2223,7 +2223,7 @@ argument_rank_mismatch (const char *name, locus *where, where, where_formal, rank1); else gfc_error_opt (0, "Rank mismatch between actual argument at %L " - "and actual argument at %L (rank-%d and rank-%d", where, + "and actual argument at %L (rank-%d and rank-%d)", where, where_formal, rank1, rank2); } }
Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.
On 2/14/20 4:09 PM, Jakub Jelinek wrote: On Fri, Feb 14, 2020 at 10:02:39PM +, GT wrote: Function rs6000_simd_clone_adjust, even though it's body is empty, cannot simply be removed. I tried it. It resulted in ICE. In my view, leaving it empty is preferable to modifying other files unrelated to rs6000.c in order to avoid having a function whose body is empty. So shouldn't the callback set target attribute (on definitions) to "vsx"? I did consider doing something similar to aarch64_simd_clone_adjust. But the reason Aarch64 has a new attribute aarch64_vector_pcs is that they implemented a modified function calling sequence for vector functions. PPC64 vector functions use the existing function calling sequence spelled out in the 64-bit ELFv2 ABI. So with no new attribute here, the function body ends up empty. Have I missed something crucial? I haven't seen anything in the patch that would only enable it for ELFv2, and while powerpc64le-linux probably assumes TARGET_VSX unconditionally (haven't verified), powerpc64-linux or powerpc-linux certainly doesn't. And it is just fine to have the ABI for those pass/return vectors in VSX registers too, after all, it won't be used if the vectorized caller isn't TARGET_VSX, the definitions of the declare simd functions could be compiled with different ISA options. And, if the ABI sais that the 'b' stuff assumes certain ISA extensions, if the declare simd function definition is compiled with e.g. -mno-vsx -mno-altivec, it would either not be able to get the arguments/return values at all, or wouldn't benefit from the ISA guarantees the ABI gives to it. It's a problem with the patch that it doesn't limit the ABI to ELFv2. That is necessary, because there are aspects of the vector ABI that are incompatible with ELFv1. In particular, ELFv1 doesn't support returning homogeneous aggregates of vectors in vector registers, which is called for in the proposed sincos interface, and would also be needed for vectorized complex functions. Bill BTW, in the ABI document there isn't just 'b', but also 'c' ABI, it is unclear if one needs to always emit both (e.g. like on x86 we emit 'b', 'c', 'd' and 'e') and then let the vectorized callers choose based on what ISA options it is compiled with. Jakub
Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.
On 2/20/20 1:14 PM, GT wrote: ‐‐‐ Original Message ‐‐‐ On Wednesday, February 19, 2020 12:33 PM, Bill Schmidt wrote: The reason 'c' was added to the ABI is this mailing list discussion: https://sourceware.org/ml/libc-alpha/2019-11/msg00765.html As long as 'b' specifies that the VSX functionality is that specified in ISA v2.07, I suggest that we delete the reference to 'c' in the ABI. Bill, Tulio? No, I don't think that's the right call. We want to leverage ISA 3.0 instructionsin vector implementations when they are available, so we need the 'c' ABI for that purpose. In future we are likely to add a 'd' ABI for a future processor if it adds more vector capability. So emitting both and letting the vectorized callers choose, as Jakub suggests, seems like the right way to go. This is true even if the current implementations are identical (i.e., don't exploit any ISA 3.0 instructions). Because of the issue at https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01171.html, I am coming back to whether or not to include VSX extensions for ISA 3.0 in the Vector Function ABI Specification. If we retain 'c' in the ABI Spec., then GCC will expect libmvec functions such as _ZGVcN2v_sin. The changes made to GLIBC for POWER libmvec don't have these functions with == 'c'. Only those with == 'b' have been implemented. So we have to do either of: 1. Create all those 'c' variants in GLIBC libmvec, even though they will be identical to the existing 'b' versions. 2. Remove all references to 'c' in the ABI Specification, and leave GCC expecting to find only 'b' variants in libmvec. If/when it becomes necessary to have 'c' variants of functions, then a new version of the Vector Function ABI document will be created. And GLIBC and GCC modifications to comply with that new ABI will be made then. Though I'm usually uncomfortable with kicking the can down the road on these sorts of things, I can probably be convinced in this case. Tulio and I were wondering why the libmvec interface doesn't make use of ifunc capability for this sort of thing. Something to look into when more advanced implementations are added later, I guess, and a valid reason to not lock ourselves into the 'c' ABI today. Tulio, any concerns? Bill Bert.
Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.
On Sun, Feb 23, 2020 at 10:55:53AM -0600, Bill Schmidt wrote: > > If/when it becomes necessary to have 'c' variants of functions, then a new > > version of > > the Vector Function ABI document will be created. And GLIBC and GCC > > modifications to > > comply with that new ABI will be made then. > > Though I'm usually uncomfortable with kicking the can down the road on these > sorts of things, I can probably be convinced in this case. Tulio and I were > wondering why the libmvec interface doesn't make use of ifunc capability for > this sort of thing. Something to look into when more advanced implementations > are added later, I guess, and a valid reason to not lock ourselves into the > 'c' ABI today. Whether simd attribute or declare simd emits by default just 'b' or both 'b' and 'c' or whatever other set is part of the ABI, so if/when that will change, it will be an ABI break. >From this POV, handling faster (higher ISA), but same ABI, power9 optimized code through ifuncs rather than a separate set of entrypoints might be better. It is true that it won't affect that way non-glibc code which won't use ifunc manually like libmvec would, on the other side, OpenMP 5.0 has now ways to handle such specialization through #pragma omp declare variant. Jakub
Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.
On Sun, Feb 23, 2020 at 10:42:17AM -0600, Bill Schmidt wrote: > > > Have I missed something crucial? > > I haven't seen anything in the patch that would only enable it for ELFv2, > > and while powerpc64le-linux probably assumes TARGET_VSX unconditionally > > (haven't verified), powerpc64-linux or powerpc-linux certainly doesn't. > > And it is just fine to have the ABI for those pass/return vectors in VSX > > registers too, after all, it won't be used if the vectorized caller isn't > > TARGET_VSX, the definitions of the declare simd functions could be compiled > > with different ISA options. And, if the ABI sais that the 'b' stuff assumes > > certain ISA extensions, if the declare simd function definition is compiled > > with e.g. -mno-vsx -mno-altivec, it would either not be able to get the > > arguments/return values at all, or wouldn't benefit from the ISA guarantees > > the ABI gives to it. > > It's a problem with the patch that it doesn't limit the ABI to ELFv2. That is > necessary, because there are aspects of the vector ABI that are incompatible > with ELFv1. In particular, ELFv1 doesn't support returning homogeneous > aggregates of vectors in vector registers, which is called for in the proposed > sincos interface, and would also be needed for vectorized complex functions. Is it really a problem? I mean, it is perfectly fine if the declare simd variants have a different ABI from the normal ABI, just for #pragma omp declare variant it will be desirable if there is some attribute for such different (or just slightly amended) ABI. And vector complex is not an issue right now, we punt on those on all architectures. Jakub
Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.
On Sun, Feb 23, 2020 at 10:55:53AM -0600, Bill Schmidt wrote: > Though I'm usually uncomfortable with kicking the can down the road on these > sorts of things, I can probably be convinced in this case. Tulio and I were > wondering why the libmvec interface doesn't make use of ifunc capability for > this sort of thing. Something to look into when more advanced > implementations > are added later, I guess, and a valid reason to not lock ourselves into the > 'c' ABI today. I have some questions, too. Why is this called an ABI at all? Why will it not work with *any* underlying ABI? What *is* this, what is it *for*, where is the documentation, where is the design documentation? Etc. Segher
patch to fix PR93564
The following patch is for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93564
The patch was successfully bootstrapped on x86-64 and benchmarked on
SPEC2000.
commit 3133bed5d0327e8a9cd0a601b7ecdb9de4fc825d
Author: Vladimir N. Makarov
Date: Sun Feb 23 16:20:05 2020 -0500
Changing cost propagation and ordering colorable bucket heuristics for PR93564.
2020-02-23 Vladimir Makarov
PR rtl-optimization/93564
* ira-color.c (struct update_cost_queue_elem): New member start.
(queue_update_cost, get_next_update_cost): Add new arg start.
(allocnos_conflict_p): New function.
(update_costs_from_allocno): Add new arg conflict_cost_update_p.
Add checking conflicts with allocnos_conflict_p.
(update_costs_from_prefs, restore_costs_from_copies): Adjust
update_costs_from_allocno calls.
(update_conflict_hard_regno_costs): Add checking conflicts with
allocnos_conflict_p. Adjust calls of queue_update_cost and
get_next_update_cost.
(assign_hard_reg): Adjust calls of queue_update_cost. Add
debugging print.
(bucket_allocno_compare_func): Restore previous version.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index cea52f00523..b3b9d92a1ec 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,20 @@
+2020-02-23 Vladimir Makarov
+
+ PR rtl-optimization/93564
+ * ira-color.c (struct update_cost_queue_elem): New member start.
+ (queue_update_cost, get_next_update_cost): Add new arg start.
+ (allocnos_conflict_p): New function.
+ (update_costs_from_allocno): Add new arg conflict_cost_update_p.
+ Add checking conflicts with allocnos_conflict_p.
+ (update_costs_from_prefs, restore_costs_from_copies): Adjust
+ update_costs_from_allocno calls.
+ (update_conflict_hard_regno_costs): Add checking conflicts with
+ allocnos_conflict_p. Adjust calls of queue_update_cost and
+ get_next_update_cost.
+ (assign_hard_reg): Adjust calls of queue_update_cost. Add
+ debugging print.
+ (bucket_allocno_compare_func): Restore previous version.
+
2020-02-21 John David Anglin
* gcc/config/pa/pa.c (pa_function_value): Fix check for word and
diff --git a/gcc/ira-color.c b/gcc/ira-color.c
index 0bcc80463b0..0ffdd192020 100644
--- a/gcc/ira-color.c
+++ b/gcc/ira-color.c
@@ -1199,6 +1199,10 @@ struct update_cost_queue_elem
connecting this allocno to the one being allocated. */
int divisor;
+ /* Allocno from which we started chaining costs of connected
+ allocnos. */
+ ira_allocno_t start;
+
/* Allocno from which we are chaining costs of connected allocnos.
It is used not go back in graph of allocnos connected by
copies. */
@@ -1258,10 +1262,11 @@ start_update_cost (void)
update_cost_queue = NULL;
}
-/* Add (ALLOCNO, FROM, DIVISOR) to the end of update_cost_queue, unless
+/* Add (ALLOCNO, START, FROM, DIVISOR) to the end of update_cost_queue, unless
ALLOCNO is already in the queue, or has NO_REGS class. */
static inline void
-queue_update_cost (ira_allocno_t allocno, ira_allocno_t from, int divisor)
+queue_update_cost (ira_allocno_t allocno, ira_allocno_t start,
+ ira_allocno_t from, int divisor)
{
struct update_cost_queue_elem *elem;
@@ -1270,6 +1275,7 @@ queue_update_cost (ira_allocno_t allocno, ira_allocno_t from, int divisor)
&& ALLOCNO_CLASS (allocno) != NO_REGS)
{
elem->check = update_cost_check;
+ elem->start = start;
elem->from = from;
elem->divisor = divisor;
elem->next = NULL;
@@ -1282,10 +1288,11 @@ queue_update_cost (ira_allocno_t allocno, ira_allocno_t from, int divisor)
}
/* Try to remove the first element from update_cost_queue. Return
- false if the queue was empty, otherwise make (*ALLOCNO, *FROM,
- *DIVISOR) describe the removed element. */
+ false if the queue was empty, otherwise make (*ALLOCNO, *START,
+ *FROM, *DIVISOR) describe the removed element. */
static inline bool
-get_next_update_cost (ira_allocno_t *allocno, ira_allocno_t *from, int *divisor)
+get_next_update_cost (ira_allocno_t *allocno, ira_allocno_t *start,
+ ira_allocno_t *from, int *divisor)
{
struct update_cost_queue_elem *elem;
@@ -1294,6 +1301,7 @@ get_next_update_cost (ira_allocno_t *allocno, ira_allocno_t *from, int *divisor)
*allocno = update_cost_queue;
elem = &update_cost_queue_elems[ALLOCNO_NUM (*allocno)];
+ *start = elem->start;
*from = elem->from;
*divisor = elem->divisor;
update_cost_queue = elem->next;
@@ -1325,18 +1333,41 @@ update_allocno_cost (ira_allocno_t allocno, int hard_regno,
return true;
}
+/* Return TRUE if allocnos A1 and A2 conflicts. Here we are
+ interesting only in conflicts of allocnos with intersected allocno
+ classes. */
+static bool
+allocnos_conflict_p (ira_allocno_t a1, ira_allocno_t a2)
+{
+ ira_object_t obj, conflict_obj;
+ ira_object_conflict_iterator oci;
+ int word, nwo
Re: One more patch for PR91333
On 2020-02-18 10:39 a.m., Maxim Kuvyrkov wrote: On Feb 18, 2020, at 6:30 PM, Vladimir Makarov wrote: On 2/17/20 10:08 AM, Maxim Kuvyrkov wrote: Hi Vladimir, This patch increases code size at -Os on arm-linux-gnueabihf by 1% (with no code-size reductions) on several SPEC CPU2006 benchmarks: 400.perlbench,perlbench_base.default ,580842,583842 429.mcf,mcf_base.default ,7867,7955 403.gcc,gcc_base.default ,1726449,1736149 433.milc,milc_base.default ,66328,66816 456.hmmer,hmmer_base.default ,148394,149434 482.sphinx3,sphinx_livepretend_base.default ,99183,99863 Could you look into whether these regressions can be avoided? Sure, Maxim. I'll look into it. If I can not solve the problem, I probably revert the patch. Thanks, Vladimir. Forgot to mention that this is for Thumb2 (--target=arm-linux-gnueabihf --with-mode=thumb). I've committed a patch which I think should solve the code size increase problem. Could you check it, Maxim. Thanks.
Re: [patch, committed] Fix trailing space in diagnostic
Am 23.02.20 um 17:11 schrieb Thomas Koenig:
Committed as simple and obvious,
r10-6802-g7260547dbffd8e6442f99da8adf98ab0ce294e4e.
Better with the patch, of course.
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 429abc79ca2..4106fe5831b 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -2660,8 +2660,8 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
{
if (formal->attr.artificial)
gfc_error ("Element of assumed-shape or pointer array "
- "as actual argument at %L can not correspond to "
- "actual argument at %L ",
+ "as actual argument at %L cannot correspond to "
+ "actual argument at %L",
&actual->where, &formal->declared_at);
else
gfc_error ("Element of assumed-shape or pointer "
diff --git a/gcc/testsuite/gfortran.dg/argument_checking_24.f90 b/gcc/testsuite/gfortran.dg/argument_checking_24.f90
index a5f3abee3a8..79096cd59af 100644
--- a/gcc/testsuite/gfortran.dg/argument_checking_24.f90
+++ b/gcc/testsuite/gfortran.dg/argument_checking_24.f90
@@ -33,14 +33,14 @@ contains
call invalid_4 (b) ! { dg-error "Rank mismatch" }w
call invalid_5 (b) ! { dg-error "Rank mismatch" }
call invalid_5 (vv(1)%x) ! { dg-error "Rank mismatch" }
-call invalid_6 (x) ! { dg-error "can not correspond to actual argument" }
-call invalid_6 (pointer_v%x(1)) ! { dg-error "can not correspond to actual argument" }
+call invalid_6 (x) ! { dg-error "cannot correspond to actual argument" }
+call invalid_6 (pointer_v%x(1)) ! { dg-error "cannot correspond to actual argument" }
call invalid_7 (pointer_v%x(1)) ! { dg-error "Rank mismatch" }
call invalid_7 (x) ! { dg-error "Rank mismatch" }
call invalid_8 (p(1)) ! { dg-error "Rank mismatch" }
call invalid_8 (x) ! { dg-error "Rank mismatch" }
-call invalid_9 (x) ! { dg-error "can not correspond to actual argument" }
-call invalid_9 (p(1)) ! { dg-error "can not correspond to actual argument" }
+call invalid_9 (x) ! { dg-error "cannot correspond to actual argument" }
+call invalid_9 (p(1)) ! { dg-error "cannot correspond to actual argument" }
end subroutine foo
subroutine bar(a, alloc)
Re: [PATCH v2] RISC-V: Adjust floating point code gen for LTGT compare
Thanks, committed :) On Sat, Feb 22, 2020 at 6:10 AM Jim Wilson wrote: > > On Fri, Feb 21, 2020 at 1:04 AM Kito Cheng wrote: > > * config/riscv/riscv.c (riscv_emit_float_compare): Change the code > > gen > > for LTGT. > > (riscv_rtx_costs): Update cost model for LTGT. > > Thanks. This looks good to me. > > Jim
Re: [PATCH] rs6000: Fix infinite loop building ghostscript and icu [PR93658]
On 2/22/20 6:49 PM, Segher Boessenkool wrote: > On Sat, Feb 22, 2020 at 06:25:43PM -0600, Peter Bergner wrote: >> Is this still ok for GCC 8 & 9? > > Please do each of those backports as separate commits (so that if there > is a problem with them, we can bisect it; it also should be easier to do > this way, even :-) ) Ok, done. Although, I committed the get_vector_offset() addition and typo fix together, since they are tied to each other. >> PR target/93568 >> * config/rs6000/rs6000.c (get_vector_offset): Fix > > (This changelog was committed truncated like this... If you can find a > fuller version, please use that, but don't bother too much). I couldn't find any non-truncated text for the ChangeLog entry, so I just wrote some verbiage for it myself. > All those are okay to backport. Thanks! Committed and pushed as 3 separate commits to each release branch. Thanks! Peter
Re: [PATCH] Fix PR66552, Missed optimization when shift amount is result of signed modulus
Hi,
On 2020/2/22 11:12 PM, Marc Glisse wrote:
On Tue, 18 Feb 2020, Li Jia He wrote:
Also the pattern doing the standalone transform does
/* Optimize TRUNC_MOD_EXPR by a power of two into a BIT_AND_EXPR,
i.e. "X % C" into "X & (C - 1)", if X and C are positive.
Also optimize A % (C << N) where C is a power of 2,
to A & ((C << N) - 1). */
(match (power_of_two_cand @1)
INTEGER_CST@1)
(match (power_of_two_cand @1)
(lshift INTEGER_CST@1 @2))
(for mod (trunc_mod floor_mod)
(simplify
(mod @0 (convert?@3 (power_of_two_cand@1 @2)))
(if ((TYPE_UNSIGNED (type)
|| tree_expr_nonnegative_p (@0))
&& tree_nop_conversion_p (type, TREE_TYPE (@3))
&& integer_pow2p (@2) && tree_int_cst_sgn (@2) > 0)
(bit_and @0 (convert (minus @1 { build_int_cst (TREE_TYPE (@1), 1);
}))
so it also checks whether @2 is not negative, the new pattern lacks
this and could make use of power_of_two_cand as well (in fact I'd
place it next to the pattern above.
Thank you for your suggestions. I have modified the code according to
your
suggestions. But power_of_two_cand is not used, it will cause pr70354-2.c
failed ((0x1234ULL << (i % 54)) will transfer to (0x1234ULL << (i &
54))).
How exactly did you use power_of_two_cand? As shown in the
transformation above, it combines with integer_pow2p, it doesn't replace
it.
I used power_of_two_cand as follows：
diff --git a/gcc/match.pd b/gcc/match.pd
index 73834c25593..a90e93d8af0 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -598,12 +598,19 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
/* Optimize TRUNC_MOD_EXPR by a power of two into a BIT_AND_EXPR,
i.e. "X % C" into "X & (C - 1)", if X and C are positive.
Also optimize A % (C << N) where C is a power of 2,
- to A & ((C << N) - 1). */
+ to A & ((C << N) - 1). And optimize "A shift (N % C)" where C
+ is a power of 2 and shift operation included "<<" and ">>",
+ to "A shift (N & (C - 1))". */
(match (power_of_two_cand @1)
INTEGER_CST@1)
(match (power_of_two_cand @1)
(lshift INTEGER_CST@1 @2))
(for mod (trunc_mod floor_mod)
+ (for shift (lshift rshift)
+ (simplify
+ (shift @0 (mod @1 (power_of_two_cand @2)))
+ (if (tree_expr_nonnegative_p (@2))
+ (shift @0 (bit_and @1 (minus @2 { build_int_cst (TREE_TYPE (@2), 1);
}))
(simplify
(mod @0 (convert?@3 (power_of_two_cand@1 @2)))
(if ((TYPE_UNSIGNED (type)
I found that there will be a generated tree_power_of_two_cand function in
generic-match.c and gimple_power_of_two_cand function in gimple-match.c.
bool
tree_power_of_two_cand (tree t, tree *res_ops)
{
const tree type = TREE_TYPE (t);
if (TREE_SIDE_EFFECTS (t)) return false;
switch (TREE_CODE (t))
{
case INTEGER_CST:
{
{
/* #line 604 "../../gcc-mirror/gcc/match.pd" */
tree captures[1] ATTRIBUTE_UNUSED = { t };
if (__builtin_expect (dump_file && (dump_flags &
TDF_FOLDING), 0)) fprintf (dump_file, "Matching expression %s:%d,
%s:%d\n", "match.pd", 604, __FILE__, __LINE__);
res_ops[0] = captures[0];
return true;
}
break;
}
case LSHIFT_EXPR:
{
tree _p0 = TREE_OPERAND (t, 0);
tree _p1 = TREE_OPERAND (t, 1);
switch (TREE_CODE (_p0))
{
case INTEGER_CST:
{
{
/* #line 606 "../../gcc-mirror/gcc/match.pd" */
tree captures[2] ATTRIBUTE_UNUSED = { _p0, _p1 };
if (__builtin_expect (dump_file && (dump_flags &
TDF_FOLDING), 0)) fprintf (dump_file, "Matching expression %s:%d,
%s:%d\n", "match.pd", 606, __FILE__, __LINE__);
res_ops[0] = captures[0];
return true;
}
break;
}
default:;
}
break;
}
default:;
}
return false;
}
In the tree_power_of_two_cand function, we can see that if t is an
INTEGER_CST, it will be captured directly, so using power_of_two_cand
may not be appropriate here.
--
BR,
Lijia He
Re: [PR47785] COLLECT_AS_OPTIONS
On Wed, 19 Feb 2020 at 19:54, Richard Biener wrote: > > On Wed, Feb 19, 2020 at 12:19 AM Prathamesh Kulkarni > wrote: > > > > On Tue, 18 Feb 2020 at 19:40, Richard Biener > > wrote: > > > > > > On Tue, Feb 18, 2020 at 1:52 PM Prathamesh Kulkarni > > > wrote: > > > > > > > > On Mon, 17 Feb 2020 at 19:52, Richard Biener > > > > wrote: > > > > > > > > > > On Mon, Feb 17, 2020 at 10:28 AM Prathamesh Kulkarni > > > > > wrote: > > > > > > > > > > > > On Thu, 6 Feb 2020 at 20:03, Prathamesh Kulkarni > > > > > > wrote: > > > > > > > > > > > > > > On Thu, 6 Feb 2020 at 18:42, Richard Biener > > > > > > > wrote: > > > > > > > > > > > > > > > > On Thu, Feb 6, 2020 at 1:48 PM Prathamesh Kulkarni > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Tue, 4 Feb 2020 at 19:44, Richard Biener > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Mon, Feb 3, 2020 at 12:37 PM Prathamesh Kulkarni > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > On Thu, 30 Jan 2020 at 19:10, Richard Biener > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Jan 30, 2020 at 5:31 AM Prathamesh Kulkarni > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 28 Jan 2020 at 17:17, Richard Biener > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jan 24, 2020 at 7:04 AM Prathamesh Kulkarni > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, 20 Jan 2020 at 15:44, Richard Biener > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jan 8, 2020 at 11:20 AM Prathamesh > > > > > > > > > > > > > > > > Kulkarni > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 5 Nov 2019 at 17:38, Richard Biener > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Nov 5, 2019 at 12:17 AM Kugan > > > > > > > > > > > > > > > > > > Vivekanandarajah > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > Thanks for the review. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 5 Nov 2019 at 03:57, H.J. Lu > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Nov 3, 2019 at 6:45 PM Kugan > > > > > > > > > > > > > > > > > > > > Vivekanandarajah > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for the reviews. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sat, 2 Nov 2019 at 02:49, H.J. Lu > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Oct 31, 2019 at 6:33 PM > > > > > > > > > > > > > > > > > > > > > > Kugan Vivekanandarajah > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 30 Oct 2019 at 03:11, > > > > > > > > > > > > > > > > > > > > > > > H.J. Lu > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Oct 27, 2019 at 6:33 PM > > > > > > > > > > > > > > > > > > > > > > > > Kugan Vivekanandarajah > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Richard, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for the review. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 23 Oct 2019 at 23:07, > > > > > > > > > > > > > > > > > > > > > > > > > Richard Biener > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Oct 21, 2019 at > > > > > > > > > > > > > > > > > > > > > > > > > > 10:04 AM Kugan > > > > > > > > > > > > > > > > > > > > > > > > > > Vivekanandarajah > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Richard, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
