Re: [PATCH, fortran ieee]: PR 88678, Many gfortran.dg/ieee/ieee_X.f90 test cases fail starting with r267465
On Wed, Jan 30, 2019 at 9:51 PM Janne Blomqvist
wrote:
>
> On Wed, Jan 30, 2019 at 9:12 PM Uros Bizjak wrote:
>>
>> On Wed, Jan 30, 2019 at 10:37 AM Uros Bizjak wrote:
>>
>> > > Your decription suggests that this fixes PR fortran/88678.
>> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88678
>> >
>> > Actually, additional patch is needed to fully fix PR88678.
>> > support_fpu_trap enables and disables exceptions and this may fire
>> > spurious exceptions. Just assume that all supported flags can generate
>> > exceptions, as is done in the additional patch, posted to PR88678.
>>
>> The remaining ieee_*.f90 tests and large_1.f90 test failures on
>> powerpc64 are fixed by the attached patch.
>>
>> 2019-01-30 Uroš Bizjak
>>
>> PR fortran/88678
>> * config/fpu-glibc.h (support_fpu_trap): Do not try to enable
>> exceptions to determine if exception is supported.
>>
>> Bootstrapped and regression tested on x86_64-linux-gnu {,-m32} (with
>> appropriate config.host tweak to select fpu-glibc.header),
>> alphaev68-linux-gnu and as reported in the PR, on
>> powerpc64le-linux-gnu by Peter.
>>
>> OK for mainline?
>
>
> This seems to change the only user of support_fpu_trap() that is different
> from support_fpu_flag(), so with this change one could remove
> support_fpu_trap() entirely and modify all callers (since it's an internal
> function it's not used outside libgfortran) to call support_fpu_flag()
> directly. Otherwise Ok.
Some targets only support IEEE flags (so, flags in some FP status
register), but not exceptions (traps) based on these flags that halt
the program. Currently, fpu-glibc.h assumes that all flags can
generate exceptions (that is true for the current set of gfortran
targets), but some future target wants to return 0 from
support_fpu_trap.
Uros.
[PR middle-end/85598] make -Wprintf* pass use loop info for PHI's
Hi folks.
The problem here is that Wprintf* uses the evrp_range_analyzer engine,
and doesn't understand that the x_5 != 256 conditional below should make
the RANGE [0, 255], not [0, 256].
[local count: 1063004407]:
# RANGE [0, 256] NONZERO 511
# x_10 = PHI <0(2), x_5(3)>
snprintf (, 4, "%%%02X", x_10);
# RANGE [1, 256] NONZERO 511
x_5 = x_10 + 1;
if (x_5 != 256)
goto ; [98.99%]
else
goto ; [1.01%]
This PR is handled quite easily in the ranger work, but alas there is
nothing for this release. Therefore, I'd like to dedicate as little
time as possible to this PR this time around.
Various possible solutions are discussed in the PR. I think an easy way
is to lean on loop analysis to refine the PHI result. It turns out the
evrp engine already does this if SCEV data is available.
As Richard mentioned in the PR, we should avoid code differences
dependent on -W* flags. I have put the loop init code in the pass
itself, but am open to moving it outside, perhaps early in the gate
function ??.
I also took the liberty of calling loop_optimizer_init() with the
smallest subset of LOOPS_NORMAL which could still fix the problem
(LOOPS_HAVE_PREHEADERS). This avoids unnecessary changes to the CFG.
But really, I'm just guessing here. LOOPS_NORMAL would also work,
albeit creating forwarder blocks.
Tested on x86-64 Linux.
What do you think?
Aldy
commit 189e32856dc4656931a66d4da0be81abb2eceb46
Author: Aldy Hernandez
Date: Wed Jan 30 12:25:25 2019 +0100
PR middle-end/85598
* gimple-ssa-sprintf.c (pass_sprintf_length::execute): Build
optimizer info when running late and optimizing.
diff --git a/gcc/gimple-ssa-sprintf.c b/gcc/gimple-ssa-sprintf.c
index 8e6016fc42f..973452fd209 100644
--- a/gcc/gimple-ssa-sprintf.c
+++ b/gcc/gimple-ssa-sprintf.c
@@ -65,6 +65,8 @@ along with GCC; see the file COPYING3. If not see
#include "tree-ssa-propagate.h"
#include "calls.h"
#include "cfgloop.h"
+#include "tree-scalar-evolution.h"
+#include "tree-ssa-loop.h"
#include "intl.h"
#include "langhooks.h"
@@ -4200,10 +4202,34 @@ pass_sprintf_length::execute (function *fun)
init_target_to_host_charmap ();
calculate_dominance_info (CDI_DOMINATORS);
+ bool optimizing_late = optimize > 0 && fold_return_value;
+ if (optimizing_late)
+{
+ /* ?? We should avoid changing the CFG as much as possible.
+ This is a warning pass, after all. Thus, use
+ LOOPS_HAVE_PREHEADERS instead of LOOPS_NORMAL. This avoids
+ extensive changes to the CFG, without the full hammer of
+ AVOID_CFG_MANIPULATIONS which would cripple SCEV.
+
+ ?? Should we run this outside of the pass (early in the gate
+ function).
+
+ FIXME: This should go away, when we have finer grained or
+ on-demand range information. */
+ loop_optimizer_init (LOOPS_HAVE_PREHEADERS);
+ scev_initialize ();
+}
+
sprintf_dom_walker sprintf_dom_walker;
sprintf_dom_walker.walk (ENTRY_BLOCK_PTR_FOR_FN (fun));
+ if (optimizing_late)
+{
+ scev_finalize ();
+ loop_optimizer_finalize ();
+}
+
/* Clean up object size info. */
fini_object_sizes ();
return 0;
diff --git a/gcc/testsuite/gcc.dg/pr85598.c b/gcc/testsuite/gcc.dg/pr85598.c
new file mode 100644
index 000..c84b63f8084
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr85598.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -Wall" } */
+
+typedef __SIZE_TYPE__ size_t;
+extern void __chk_fail (void);
+extern int snprintf (char *, size_t, const char *, ...);
+
+int main()
+{
+char temp[100];
+unsigned int x;
+char *str = temp;
+for(x=0; x<256; ++x) {
+ snprintf(str, 4, "%%%02X", x);
+}
+}
Re: [patch, fortran] PR52564 Accepts invalid: Missing I/O list after comma
On Wed, Jan 30, 2019 at 05:29:52PM -0800, Jerry DeLisle wrote: > The attached patch is straight-forward and self explanatory. > > Regression tested on x86-64-pc-linux-gnu. Test case attached. > > OK for trunk? > Yes. Thanks for patch. -- Steve
Re: [PATCH/doc] correct cast to a union description (PR 89106)
On Wed, 30 Jan 2019, Martin Sebor wrote: > A change I made a couple of years ago to the Cast To a Union section > of the manual incorrectly stated that the cast yields an lvalue when > it, in fact, yields an rvalue. The attached patch corrects this > mistake and expands the description to further clarify the construct > based on a discussion with Alexander in the PR. OK. -- Joseph S. Myers jos...@codesourcery.com
[patch, fortran] PR52564 Accepts invalid: Missing I/O list after comma
The attached patch is straight-forward and self explanatory.
Regression tested on x86-64-pc-linux-gnu. Test case attached.
OK for trunk?
2019-01-31 Jerry DeLisle
PR fortran/52564
* io.c (match_io): Add check for comma after '*' without subsequent
IO list.
diff --git a/gcc/fortran/io.c b/gcc/fortran/io.c
index fce9228c302..95b30132203 100644
--- a/gcc/fortran/io.c
+++ b/gcc/fortran/io.c
@@ -4172,6 +4172,23 @@ match_io (io_kind k)
else
gfc_current_locus = where;
}
+
+ if (gfc_match_char ('*') == MATCH_YES
+ && gfc_match_char(',') == MATCH_YES)
+ {
+ locus where2 = gfc_current_locus;
+ if (gfc_match_eos () == MATCH_YES)
+ {
+ gfc_current_locus = where2;
+ gfc_error ("Comma after * at %C not allowed without I/O list");
+ m = MATCH_ERROR;
+ goto cleanup;
+ }
+ else
+ gfc_current_locus = where;
+ }
+ else
+ gfc_current_locus = where;
}
if (gfc_current_form == FORM_FREE)
! { dg-do compile }
! PR52564 Accepts invalid: Missing I/O list after comma
program printbug
print *, 'hello world'
! the following line should not compile:
print *, ! { dg-error "not allowed" }
end program
[C++PATCH] [PR86379] do not use TREE_TYPE for USING_DECL_SCOPE
It's too risk to reuse the type field for USING_DECL_SCOPE.
Language-independent parts of the compiler, such as location and
non-lvalue wrappers, happily take the TREE_TYPE of a USING_DECL as if
it was a type rather than an unrelated scope.
For better or worse, USING_DECLs use the non-common struct so we can
use the otherwise unused result field. Adjust fallout, from uses of
TREE_TYPE that were supposed to be USING_DECL_SCOPE, to other
accidental uses of TREE_TYPE of a USING_DECL.
Regstrapped on x86_64- and i686-linux-gnu. Ok to install?
(but see the additional patchlet below)
for gcc/cp/ChangeLog
PR c++/86379
* cp-tree.h (USING_DECL_SCOPE): Use result rather than type.
* name-lookup.c (strip_using_decl): Use USING_DECL_SCOPE.
* search.c (protected_accessible_p): Follow USING_DECL_DECLS.
(shared_member_p): Likewise.
(lookup_member): Likewise.
* decl.c (copy_fn_p): Likewise.
(grok_special_member_properties): Do not test USING_DECL for
staticness.
* semantics.c (finish_omp_declare_simd_methods): Likewise.
for gcc/testsuite/ChangeLog
PR c++/86379
* g++.dg/cpp0x/pr86379.C: New.
---
gcc/cp/cp-tree.h |2
gcc/cp/decl.c| 10 +-
gcc/cp/name-lookup.c |2
gcc/cp/search.c | 23 +++-
gcc/cp/semantics.c |3
gcc/testsuite/g++.dg/cpp0x/pr86379.C | 207 ++
6 files changed, 240 insertions(+), 7 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/pr86379.C
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 77e1425b4357b..053ed5ace6d42 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -3288,7 +3288,7 @@ struct GTY(()) lang_decl {
#define DECL_DEPENDENT_P(NODE) DECL_LANG_FLAG_0 (USING_DECL_CHECK (NODE))
/* The scope named in a using decl. */
-#define USING_DECL_SCOPE(NODE) TREE_TYPE (USING_DECL_CHECK (NODE))
+#define USING_DECL_SCOPE(NODE) DECL_RESULT_FLD (USING_DECL_CHECK (NODE))
/* The decls named by a using decl. */
#define USING_DECL_DECLS(NODE) DECL_INITIAL (USING_DECL_CHECK (NODE))
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 79eeac177b64c..86101d3bc3b45 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -13174,6 +13174,13 @@ copy_fn_p (const_tree d)
tree arg_type;
int result = 1;
+ while (TREE_CODE (d) == USING_DECL)
+{
+ d = USING_DECL_DECLS (d);
+ if (!d)
+ return result;
+}
+
gcc_assert (DECL_FUNCTION_MEMBER_P (d));
if (TREE_CODE (d) == TEMPLATE_DECL
@@ -13288,7 +13295,8 @@ grok_special_member_properties (tree decl)
{
tree class_type;
- if (!DECL_NONSTATIC_MEMBER_FUNCTION_P (decl))
+ if (TREE_CODE (decl) != USING_DECL
+ && !DECL_NONSTATIC_MEMBER_FUNCTION_P (decl))
return;
class_type = DECL_CONTEXT (decl);
diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index d7b9029b0a3a5..959f43b023844 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -2100,7 +2100,7 @@ strip_using_decl (tree decl)
using typename :: [opt] nested-name-specifier unqualified-id ;
*/
- decl = make_typename_type (TREE_TYPE (decl),
+ decl = make_typename_type (USING_DECL_SCOPE (decl),
DECL_NAME (decl),
typename_type, tf_error);
if (decl != error_mark_node)
diff --git a/gcc/cp/search.c b/gcc/cp/search.c
index 0367e49521380..4e0a9b722ea64 100644
--- a/gcc/cp/search.c
+++ b/gcc/cp/search.c
@@ -623,6 +623,14 @@ protected_accessible_p (tree decl, tree derived, tree
type, tree otype)
if (!DERIVED_FROM_P (type, derived))
return 0;
+ /* DECL_NONSTATIC_MEMBER_P won't work for USING_DECLs. */
+ while (TREE_CODE (decl) == USING_DECL)
+{
+ decl = USING_DECL_DECLS (decl);
+ if (!decl)
+ break;
+}
+
/* [class.protected]
When a friend or a member function of a derived class references
@@ -634,7 +642,7 @@ protected_accessible_p (tree decl, tree derived, tree type,
tree otype)
derived from that class) (_expr.ref_). If the access is to form
a pointer to member, the nested-name-specifier shall name the
derived class (or any class derived from that class). */
- if (DECL_NONSTATIC_MEMBER_P (decl)
+ if (decl && DECL_NONSTATIC_MEMBER_P (decl)
&& !DERIVED_FROM_P (derived, otype))
return 0;
@@ -928,7 +936,10 @@ shared_member_p (tree t)
if (is_overloaded_fn (t))
{
for (ovl_iterator iter (get_fns (t)); iter; ++iter)
- if (DECL_NONSTATIC_MEMBER_FUNCTION_P (*iter))
+ if (TREE_CODE (*iter) != USING_DECL
+ ? DECL_NONSTATIC_MEMBER_FUNCTION_P (*iter)
+ : (USING_DECL_DECLS (*iter)
+ && !shared_member_p (USING_DECL_DECLS (*iter
return 0;
return 1;
}
@@ -1177,7 +1188,13 @@ lookup_member (tree xbasetype, tree name, int protect,
bool
Re: [PATCH][wwwdocs][Arm][AArch64] Update changes with new features and flags.
On Wed, 23 Jan 2019, Tamar Christina wrote: > This patch adds the documentation for Stack clash protection and > Armv8.3-a support to changes.html for GCC 9. Some additional notes, all minor, for consideration before you commit. +The probing interval/guard size can be set by using +--param stack-clash-protection-guard-size=12|16. +The value of this parameter must be in bytes represented as a power of two. +The only two supported values for this parameter are 12 and 16 being +4Kb (2^12) and 64Kb (2^16) respectively. This one keeps making me think every time I read it. What do you think of changing the second and third sentences to "The two supported values for this paramter are 12 (for a 4KiB size, 2^12) and 16 (for a 64KiB size, 2^16)." or something like that? Shorter and about the same contents? (Note, uppercase B or we'd refer to bits.) +The Armv8.3-A complex number instructions are now supported via intrinsics +when the option -march=armv8.3-a or equivalent is specified. +For the half-precision floating-point variants of these instructions use the +architecture extension flag +fp16, e.g. +-march=armv8.3-a+fp16. + +The intrinsics are defined by the ACLE specification. Note that these two visual paragraphs in HTML source will be merged into just one unless you add ... around the two. Just pointing it out. + +The Armv8.3-A complex number instructions are now supported via intrinsics +when the option -march=armv8.3-a or equivalent is specified. +For the half-precision floating-point variants of these instructions use the +architecture extension flag +fp16, e.g. +-march=armv8.3-a+fp16. + +The intrinsics are defined by the ACLE specification. + I guess this duplication is hard to avoid between Arm and AArch64? Gerald
[PATCH/doc] correct cast to a union description (PR 89106)
A change I made a couple of years ago to the Cast To a Union section
of the manual incorrectly stated that the cast yields an lvalue when
it, in fact, yields an rvalue. The attached patch corrects this
mistake and expands the description to further clarify the construct
based on a discussion with Alexander in the PR.
Martin
PR other/89106 - cast-to-union documentation incorrect w.r.t. lvalueness
gcc/ChangeLog:
PR other/89106
* doc/extend.texi (cast to a union): Correct and expand.
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 268398)
+++ gcc/doc/extend.texi (working copy)
@@ -2275,27 +2275,46 @@ case 1...5:
@cindex cast to a union
@cindex union, casting to a
-A cast to union type looks similar to other casts, except that the type
-specified is a union type. You can specify the type either with the
-@code{union} keyword or with a @code{typedef} name that refers to
-a union. A cast to a union actually creates a compound literal and
-yields an lvalue, not an rvalue like true casts do.
+A cast to a union type is a C extension not available in C++. It looks
+just like ordinary casts with the constraint that the type specified is
+a union type. You can specify the type either with the @code{union}
+keyword or with a @code{typedef} name that refers to a union. The result
+of a cast to a union is a temporary rvalue of the union type with a member
+whose type matches that of the operand initialized to the value of
+the operand. The effect of a cast to a union is similar to a compound
+literal except that it yields an rvalue like standard casts do.
@xref{Compound Literals}.
-The types that may be cast to the union type are those of the members
-of the union. Thus, given the following union and variables:
+Expressions that may be cast to the union type are those whose type matches
+at least one of the members of the union. Thus, given the following union
+and variables:
@smallexample
union foo @{ int i; double d; @};
int x;
double y;
+union foo z;
@end smallexample
@noindent
-both @code{x} and @code{y} can be cast to type @code{union foo}.
+both @code{x} and @code{y} can be cast to type @code{union foo} and
+the following assignments
+@smallexample
+ z = (union foo) x;
+ z = (union foo) y;
+@end smallexample
+are shorthand equivalents of these
+@smallexample
+ z = (union foo) @{ .i = x @};
+ z = (union foo) @{ .d = y @};
+@end smallexample
+However, @code{(union foo) FLT_MAX;} is not a valid cast because the union
+has no member of type @code{float}.
+
Using the cast as the right-hand side of an assignment to a variable of
-union type is equivalent to storing in a member of the union:
+union type is equivalent to storing in a member of the union with
+the same type
@smallexample
union foo u;
Re: [C++ PATCH] Revert pretty-printing change for enumerators for debug info (PR libstdc++/88170)
On 1/30/19 6:37 PM, Jakub Jelinek wrote: Hi! The r265077 changes broke +FAIL: libstdc++-prettyprinters/cxx17.cc print p +FAIL: libstdc++-prettyprinters/cxx17.cc print p +FAIL: libstdc++-prettyprinters/cxx17.cc print q +FAIL: libstdc++-prettyprinters/cxx17.cc print q +FAIL: libstdc++-prettyprinters/cxx17.cc print wp +FAIL: libstdc++-prettyprinters/cxx17.cc print wp +FAIL: libstdc++-prettyprinters/cxx17.cc print wq +FAIL: libstdc++-prettyprinters/cxx17.cc print wq +FAIL: libstdc++-prettyprinters/shared_ptr.cc print sp1 +FAIL: libstdc++-prettyprinters/shared_ptr.cc print sp1 +FAIL: libstdc++-prettyprinters/shared_ptr.cc print wp1 +FAIL: libstdc++-prettyprinters/shared_ptr.cc print wp1 +FAIL: libstdc++-prettyprinters/shared_ptr.cc print wp2 +FAIL: libstdc++-prettyprinters/shared_ptr.cc print wp2 where GDB isn't able to cope with the enumerators rather than (enumerated_type) constant_integer e.g. in template arguments. While printing enumerators might be more user-friendly in diagnostics (though, if there are several enumerators with the same value, we don't really preserve which one has been used in the source, just the first matching one is printed), for debug info purposes I think the old way is more expressive, requires less work from the debugger to find out what exact value it has. We have other spots where we change the pretty printing decisions based on whether it is a debug info string (decl_as_dwarf_string or lang_decl_dwarf_name) or some other one. Bootstrapped/regtested on x86_64-linux and i686-linux, fixes the above tests, ok for trunk? 2019-01-30 Jakub Jelinek PR libstdc++/88170 * c-pretty-print.c (pp_c_enumeration_constant): Print always as a C cast in pp_c_flag_gnu_v3 mode. * cxx-pretty-print.c (pp_cxx_enumeration_constant): Print always as a C cast in pp_c_flag_gnu_v3 mode. OK. Jason
[PATCH] Allow inlining always_inline functions into no_sanitize_address ones with -fsanitize=address
Hi!
As mentioned in the PR, we refuse to inline with -fsanitize=address
no_sanitize_address functions into functions without that attribute,
which is good and has been requested in PR59600.
We also refuse to inline functions without that attribute into
no_sanitize_address functions, which is ok if it is optimization matter
only, we will just address sanitize the callee and not the caller.
But if such callee has always_inline attribute, this causes errors, and
e.g. means one can't use target intrinsics in functions with
no_sanitize_address attribute, as we refuse to inline any of those.
The following patch allows inlining always_inline functions in that
situation, the end result is that both the caller and callee which becomes
one function will not be sanitized (still errors if always_inline,
no_sanitize_address is being inlined into normal function, that is just user
error).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2019-01-30 Jakub Jelinek
PR sanitizer/89124
* ipa-inline.c (sanitize_attrs_match_for_inline_p): Allow inlining
always_inline callees into no_sanitize_address callers.
* c-c++-common/asan/pr89124.c: New test.
--- gcc/ipa-inline.c.jj 2019-01-10 11:43:08.956466913 +0100
+++ gcc/ipa-inline.c2019-01-30 22:21:57.319026848 +0100
@@ -264,6 +264,12 @@ sanitize_attrs_match_for_inline_p (const
if (!caller || !callee)
return true;
+ /* Allow inlining always_inline functions into no_sanitize_address
+ functions. */
+ if (!sanitize_flags_p (SANITIZE_ADDRESS, caller)
+ && lookup_attribute ("always_inline", DECL_ATTRIBUTES (callee)))
+return true;
+
return ((sanitize_flags_p (SANITIZE_ADDRESS, caller)
== sanitize_flags_p (SANITIZE_ADDRESS, callee))
&& (sanitize_flags_p (SANITIZE_POINTER_COMPARE, caller)
--- gcc/testsuite/c-c++-common/asan/pr89124.c.jj2019-01-30
22:23:27.018546142 +0100
+++ gcc/testsuite/c-c++-common/asan/pr89124.c 2019-01-30 22:23:05.568900221
+0100
@@ -0,0 +1,14 @@
+/* PR sanitizer/89124 */
+/* { dg-do compile } */
+
+static int inline __attribute__ ((always_inline))
+foo (int x)
+{
+ return x + 1;
+}
+
+__attribute__ ((no_sanitize_address)) int
+bar (int x)
+{
+ return foo (x);
+}
Jakub
[C++ PATCH] Revert pretty-printing change for enumerators for debug info (PR libstdc++/88170)
Hi!
The r265077 changes broke
+FAIL: libstdc++-prettyprinters/cxx17.cc print p
+FAIL: libstdc++-prettyprinters/cxx17.cc print p
+FAIL: libstdc++-prettyprinters/cxx17.cc print q
+FAIL: libstdc++-prettyprinters/cxx17.cc print q
+FAIL: libstdc++-prettyprinters/cxx17.cc print wp
+FAIL: libstdc++-prettyprinters/cxx17.cc print wp
+FAIL: libstdc++-prettyprinters/cxx17.cc print wq
+FAIL: libstdc++-prettyprinters/cxx17.cc print wq
+FAIL: libstdc++-prettyprinters/shared_ptr.cc print sp1
+FAIL: libstdc++-prettyprinters/shared_ptr.cc print sp1
+FAIL: libstdc++-prettyprinters/shared_ptr.cc print wp1
+FAIL: libstdc++-prettyprinters/shared_ptr.cc print wp1
+FAIL: libstdc++-prettyprinters/shared_ptr.cc print wp2
+FAIL: libstdc++-prettyprinters/shared_ptr.cc print wp2
where GDB isn't able to cope with the enumerators rather than
(enumerated_type) constant_integer e.g. in template arguments.
While printing enumerators might be more user-friendly in diagnostics
(though, if there are several enumerators with the same value, we don't
really preserve which one has been used in the source, just the first
matching one is printed), for debug info purposes I think the old
way is more expressive, requires less work from the debugger to find out
what exact value it has. We have other spots where we change the pretty
printing decisions based on whether it is a debug info string
(decl_as_dwarf_string or lang_decl_dwarf_name) or some other one.
Bootstrapped/regtested on x86_64-linux and i686-linux, fixes the above
tests, ok for trunk?
2019-01-30 Jakub Jelinek
PR libstdc++/88170
* c-pretty-print.c (pp_c_enumeration_constant): Print always as
a C cast in pp_c_flag_gnu_v3 mode.
* cxx-pretty-print.c (pp_cxx_enumeration_constant): Print always as
a C cast in pp_c_flag_gnu_v3 mode.
--- gcc/c-family/c-pretty-print.c.jj2019-01-01 12:37:51.297414807 +0100
+++ gcc/c-family/c-pretty-print.c 2019-01-30 15:18:14.687063006 +0100
@@ -976,14 +976,14 @@ static void
pp_c_enumeration_constant (c_pretty_printer *pp, tree e)
{
tree type = TREE_TYPE (e);
- tree value;
+ tree value = NULL_TREE;
/* Find the name of this constant. */
- for (value = TYPE_VALUES (type);
- value != NULL_TREE
- && !tree_int_cst_equal (DECL_INITIAL (TREE_VALUE (value)), e);
- value = TREE_CHAIN (value))
-;
+ if ((pp->flags & pp_c_flag_gnu_v3) == 0)
+for (value = TYPE_VALUES (type); value != NULL_TREE;
+value = TREE_CHAIN (value))
+ if (tree_int_cst_equal (DECL_INITIAL (TREE_VALUE (value)), e))
+ break;
if (value != NULL_TREE)
pp->id_expression (TREE_PURPOSE (value));
--- gcc/cp/cxx-pretty-print.c.jj2019-01-17 09:03:11.487787550 +0100
+++ gcc/cp/cxx-pretty-print.c 2019-01-30 15:22:00.867327307 +0100
@@ -309,14 +309,14 @@ static void
pp_cxx_enumeration_constant (cxx_pretty_printer *pp, tree e)
{
tree type = TREE_TYPE (e);
- tree value;
+ tree value = NULL_TREE;
/* Find the name of this constant. */
- for (value = TYPE_VALUES (type);
- value != NULL_TREE
- && !tree_int_cst_equal (DECL_INITIAL (TREE_VALUE (value)), e);
- value = TREE_CHAIN (value))
-;
+ if ((pp->flags & pp_c_flag_gnu_v3) == 0)
+for (value = TYPE_VALUES (type); value != NULL_TREE;
+value = TREE_CHAIN (value))
+ if (tree_int_cst_equal (DECL_INITIAL (TREE_VALUE (value)), e))
+ break;
if (value != NULL_TREE)
{
Jakub
[committed] Fix OpenMP ICE with firstprivate in lambda in a template (PR c++/88988)
Hi!
DECL_OMP_PRIVATIZED_MEMBER VAR_DECLs aren't capture proxies, handling them
that way results in various ICEs.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk.
2019-01-30 Jakub Jelinek
PR c++/88988
* lambda.c (is_capture_proxy): Don't return true for
DECL_OMP_PRIVATIZED_MEMBER artificial vars.
* testsuite/libgomp.c++/pr88988.C: New test.
--- gcc/cp/lambda.c.jj 2019-01-30 08:35:47.055054187 +0100
+++ gcc/cp/lambda.c 2019-01-30 14:22:45.324085959 +0100
@@ -263,6 +263,9 @@ is_capture_proxy (tree decl)
&& !DECL_ANON_UNION_VAR_P (decl)
&& !DECL_DECOMPOSITION_P (decl)
&& !DECL_FNAME_P (decl)
+ && !(DECL_ARTIFICIAL (decl)
+ && DECL_LANG_SPECIFIC (decl)
+ && DECL_OMP_PRIVATIZED_MEMBER (decl))
&& LAMBDA_FUNCTION_P (DECL_CONTEXT (decl)));
}
--- libgomp/testsuite/libgomp.c++/pr88988.C.jj 2019-01-30 14:33:42.134276321
+0100
+++ libgomp/testsuite/libgomp.c++/pr88988.C 2019-01-30 14:33:16.911696846
+0100
@@ -0,0 +1,28 @@
+// PR c++/88988
+// { dg-do compile }
+// { dg-additional-options "-std=c++14" }
+
+extern "C" void abort ();
+
+template
+struct A {
+ A () : a(), b()
+ {
+[&] ()
+{
+#pragma omp task firstprivate (a) shared (b)
+ b = ++a;
+#pragma omp taskwait
+} ();
+ }
+
+ T a, b;
+};
+
+int
+main ()
+{
+ A x;
+ if (x.a != 0 || x.b != 1)
+abort ();
+}
Jakub
[PATCH] PR libstdc++/89117 fix path::replace_extension("") case
Previously the operator+=(extension) call would have re-parsed the path
and recreated the components with the right extension. Since optimising
it to not re-parse the whole string, we need to actually remove the
extension from the final filename before appending anything to it, and
append the dot to that final component too.
PR libstdc++/89117
* src/c++17/fs_path.cc (path::replace_extension): Erase extension from
final component as well as from _M_pathname. Append the dot using
operator+= instead of only to _M_pathname.
(path::_M_find_extension): Reformat slightly.
* testsuite/27_io/filesystem/path/modifiers/replace_extension.cc:
Add more test cases.
Tested x86_64-linux, committed to trunk.
commit 84cc9f8045b43e8f1b07b24935fbc8a8c70e30ed
Author: Jonathan Wakely
Date: Wed Jan 30 15:53:08 2019 +
PR libstdc++/89117 fix path::replace_extension("") case
Previously the operator+=(extension) call would have re-parsed the path
and recreated the components with the right extension. Since optimising
it to not re-parse the whole string, we need to actually remove the
extension from the final filename before appending anything to it, and
append the dot to that final component too.
PR libstdc++/89117
* src/c++17/fs_path.cc (path::replace_extension): Erase extension
from
final component as well as from _M_pathname. Append the dot using
operator+= instead of only to _M_pathname.
(path::_M_find_extension): Reformat slightly.
* testsuite/27_io/filesystem/path/modifiers/replace_extension.cc:
Add more test cases.
diff --git a/libstdc++-v3/src/c++17/fs_path.cc
b/libstdc++-v3/src/c++17/fs_path.cc
index 34de52f3a0f..db6a1cb29d8 100644
--- a/libstdc++-v3/src/c++17/fs_path.cc
+++ b/libstdc++-v3/src/c++17/fs_path.cc
@@ -1258,17 +1258,16 @@ path::replace_extension(const path& replacement)
_M_pathname.erase(ext.second);
else
{
- const auto& back = _M_cmpts.back();
- if (ext.first != _M_pathname)
- _GLIBCXX_THROW_OR_ABORT(
- std::logic_error("path::replace_extension failed"));
+ auto& back = _M_cmpts.back();
+ __glibcxx_assert( ext.first == _M_pathname );
+ back._M_pathname.erase(ext.second);
_M_pathname.erase(back._M_pos + ext.second);
}
}
// If replacement is not empty and does not begin with a dot character,
// a dot character is appended
if (!replacement.empty() && replacement.native()[0] != dot)
-_M_pathname += dot;
+operator+=(".");
operator+=(replacement);
return *this;
}
@@ -1803,8 +1802,9 @@ path::_M_find_extension() const
{
if (sz <= 2 && (*s)[0] == dot)
return { s, string_type::npos };
- const auto pos = s->rfind(dot);
- return { s, pos ? pos : string_type::npos };
+ if (const auto pos = s->rfind(dot))
+ return { s , pos };
+ return { s, string_type::npos };
}
}
return {};
diff --git
a/libstdc++-v3/testsuite/27_io/filesystem/path/modifiers/replace_extension.cc
b/libstdc++-v3/testsuite/27_io/filesystem/path/modifiers/replace_extension.cc
index df4b77aa116..98f2e6e4c41 100644
---
a/libstdc++-v3/testsuite/27_io/filesystem/path/modifiers/replace_extension.cc
+++
b/libstdc++-v3/testsuite/27_io/filesystem/path/modifiers/replace_extension.cc
@@ -33,6 +33,15 @@ test01()
compare_paths( path("/foo.txt").replace_extension("cpp"), "/foo.cpp" );
compare_paths( path("/foo.txt").replace_extension(".cpp"), "/foo.cpp" );
compare_paths( path("/").replace_extension("bar"), "/.bar" );
+ compare_paths( path("/").replace_extension(".bar"), "/.bar" );
+ compare_paths( path("/dir/").replace_extension("bar"), "/dir/.bar" );
+ compare_paths( path("dir/foo").replace_extension("bar"), "dir/foo.bar" );
+
+ // PR 89117:
+ compare_paths( path("/foo.txt").replace_extension(), "/foo" );
+ compare_paths( path("foo.txt").replace_extension(), "foo" );
+ compare_paths( path("/foo").replace_extension(), "/foo" );
+ compare_paths( path("foo").replace_extension(), "foo" );
}
void
[PATCH] Fix bogus fix-it for FLT_MAX (PR c/89122)
PR c/89122 reports that we emit a bogus fix-it hint for the case where
the code uses FLT_MAX, but has included rather than :
x.c:3:11: error: 'FLT_MAX' undeclared here (not in a function); did you
mean 'INT_MAX'?
3 | float f = FLT_MAX;
| ^~~
| INT_MAX
This patch adds some knowledge of (and ) to
known-headers.cc, fixing the issue:
x.c:3:11: error: 'FLT_MAX' undeclared here (not in a function)
3 | float f = FLT_MAX;
| ^~~
x.c:2:1: note: 'FLT_MAX' is defined in header ''; did you forget
to '#include '?
1 | #include
+++ |+#include
2 |
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Is this OK for trunk in stage 4? (presumably very low risk)
gcc/c-family/ChangeLog:
PR c/89122
* known-headers.cc (get_stdlib_header_for_name): Add
{FLT|DBL|LDBL}_{MAX|MIN} to "hints" array.
gcc/testsuite/ChangeLog:
PR c/89122
* g++.dg/spellcheck-stdlib.C (test_FLT_MAX): New test.
* gcc.dg/spellcheck-stdlib.c (test_FLT_MAX): New test.
---
gcc/c-family/known-headers.cc| 8
gcc/testsuite/g++.dg/spellcheck-stdlib.C | 5 +
gcc/testsuite/gcc.dg/spellcheck-stdlib.c | 5 +
3 files changed, 18 insertions(+)
diff --git a/gcc/c-family/known-headers.cc b/gcc/c-family/known-headers.cc
index e3dcf73..c222f30 100644
--- a/gcc/c-family/known-headers.cc
+++ b/gcc/c-family/known-headers.cc
@@ -84,6 +84,14 @@ get_stdlib_header_for_name (const char *name, enum stdlib
lib)
{"ULONG_MAX", {"", ""} },
{"USHRT_MAX", {"", ""} },
+/* and . */
+{"DBL_MAX", {"", ""} },
+{"DBL_MIN", {"", ""} },
+{"FLT_MAX", {"", ""} },
+{"FLT_MIN", {"", ""} },
+{"LDBL_MAX", {"", ""} },
+{"LDBL_MIN", {"", ""} },
+
/* and . */
{"va_list", {"", ""} },
diff --git a/gcc/testsuite/g++.dg/spellcheck-stdlib.C
b/gcc/testsuite/g++.dg/spellcheck-stdlib.C
index 11a4e3e..31e91fe 100644
--- a/gcc/testsuite/g++.dg/spellcheck-stdlib.C
+++ b/gcc/testsuite/g++.dg/spellcheck-stdlib.C
@@ -77,6 +77,11 @@ int test_INT_MAX (void)
// { dg-message "'INT_MAX' is defined in header ''; did you forget
to '#include '?" "" { target *-*-* } INT_MAX_line }
}
+/* Missing . */
+float test_FLT_MAX = FLT_MAX; // { dg-line FLT_MAX_line }
+// { dg-error "'FLT_MAX' was not declared" "" { target *-*-* } FLT_MAX_line }
+// { dg-message "'FLT_MAX' is defined in header ''; did you forget to
'#include '?" "" { target *-*-* } FLT_MAX_line }
+
/* Missing . */
void test_cstring (char *dest, char *src)
diff --git a/gcc/testsuite/gcc.dg/spellcheck-stdlib.c
b/gcc/testsuite/gcc.dg/spellcheck-stdlib.c
index 7474c9a..1ae3b5e 100644
--- a/gcc/testsuite/gcc.dg/spellcheck-stdlib.c
+++ b/gcc/testsuite/gcc.dg/spellcheck-stdlib.c
@@ -62,3 +62,8 @@ int test_INT_MAX (void)
/* { dg-bogus "__INT_MAX__" "" { target *-*-* } INT_MAX_line } */
/* { dg-message "'INT_MAX' is defined in header ''; did you forget
to '#include '?" "" { target *-*-* } INT_MAX_line } */
}
+
+/* Missing . */
+float test_FLT_MAX = FLT_MAX; /* { dg-line FLT_MAX_line } */
+/* { dg-error "'FLT_MAX' undeclared" "" { target *-*-* } FLT_MAX_line } */
+/* { dg-message "'FLT_MAX' is defined in header ''; did you forget to
'#include '?" "" { target *-*-* } FLT_MAX_line } */
--
1.8.5.3
Re: C++ PATCH for c++/89083, c++/80864 - ICE with list initialization in template
On 1/30/19 4:15 PM, Marek Polacek wrote:
On Wed, Jan 30, 2019 at 04:11:11PM -0500, Marek Polacek wrote:
On Tue, Jan 29, 2019 at 09:40:18PM -0500, Jason Merrill wrote:
On Tue, Jan 29, 2019 at 6:53 PM Marek Polacek wrote:
My recent patch for 88815 and 78244 caused 89083, a P1 9 regression, which
happens to be the same problem as 80864 and its many dupes, something I'd
been meaning to fix for a long time.
Basically, the problem is repeated reshaping of a constructor, once when
parsing, and then again when substituting. With the recent fix, we call
reshape_init + digest_init in finish_compound_literal even in a template
if the expression is not instantiation-dependent, and then again when
tsubst_*.
For instance, in initlist107.C, when parsing a functional cast, we call
finish_compound_literal which calls reshape_init, which turns
{ NON_LVALUE_EXPR<1>, NON_LVALUE_EXPR<2> }
into
{ { NON_LVALUE_EXPR<1>, NON_LVALUE_EXPR<2> } }
and then digest_init turns that into
{ .x = { 1, 2 } }
which is a compound literal (TREE_HAS_CONSTRUCTOR set), but the subexpression
"{ 1, 2 }" isn't. "{ 1, 2 }" will now have the type int[3], so it's not
BRACE_ENCLOSED_INITIALIZER_P.
And then tsubst_* processes "{ .x = { 1, 2 } }". The case CONSTRUCTOR
in tsubst_copy_and_build will call finish_compound_literal on a copy of
"{ 1, 2 }" wrapped in a new { }, because the whole expr has
TREE_HAS_CONSTRUCTOR.
That crashes in reshape_init_r in the
6155 if (TREE_CODE (stripped_init) == CONSTRUCTOR)
block; we have a constructor, it's not COMPOUND_LITERAL_P, and because
digest_init had given it the type int[3], we hit
6172 gcc_assert (BRACE_ENCLOSED_INITIALIZER_P (stripped_init));
As expand_default_init explains in a comment, a CONSTRUCTOR of the target's type
is a previously digested initializer, so we should probably do a similar trick
here. This fixes all the variants of the problem I've come up with.
80864 is a similar case, we reshape when parsing and then second time in
fold_non_dependent_expr called from store_init_value, because of the
'constexpr'.
Also update a stale comment.
Bootstrapped/regtest running on x86_64-linux, ok for trunk and 8 after a while?
2019-01-29 Marek Polacek
PR c++/89083, c++/80864 - ICE with list initialization in template.
* decl.c (reshape_init_r): Don't reshape a digested initializer.
* g++.dg/cpp0x/initlist107.C: New test.
* g++.dg/cpp0x/initlist108.C: New test.
* g++.dg/cpp0x/initlist109.C: New test.
diff --git gcc/cp/decl.c gcc/cp/decl.c
index 79eeac177b6..da08ecc21aa 100644
--- gcc/cp/decl.c
+++ gcc/cp/decl.c
@@ -6161,11 +6161,17 @@ reshape_init_r (tree type, reshape_iter *d, bool
first_initializer_p,
;
else if (COMPOUND_LITERAL_P (stripped_init))
/* For a nested compound literal, there is no need to reshape since
-brace elision is not allowed. Even if we decided to allow it,
-we should add a call to reshape_init in finish_compound_literal,
-before calling digest_init, so changing this code would still
-not be necessary. */
+we called reshape_init in finish_compound_literal, before calling
+digest_init. */
gcc_assert (!BRACE_ENCLOSED_INITIALIZER_P (stripped_init));
+ /* Similarly, a CONSTRUCTOR of the target's type is a previously
+digested initializer. */
+ else if (same_type_ignoring_top_level_qualifiers_p (type,
+ TREE_TYPE (init)))
Hmm, aren't both of these tests true for a dependent compound literal,
which won't have been reshaped already?
I'm hoping that can't happen, but it's a good question. When we have a
dependent compound literal, finish_compound_literal just sets
TREE_HAS_CONSTRUCTOR and returns it, so then in tsubst_*, after substituting
each element of the constructor, we call finish_compound_literal. The
constructor is no longer dependent and since we operate on a copy on which
we didn't set TREE_HAS_CONSTRUCTOR, the first condition shouldn't be true.
And the second condition should also never be true for a compound literal
that hasn't been reshaped, because digest_init is only ever called after
reshape_init (and the comment for digest_init_r says it assumes that
reshape_init has already run).
And because, as above, tsubst_* builds up a CONSTRUCTOR with
init_list_type_node and feeds that to finish_compound_literal.
I suppose that means we do the same thing for a non-dependent
CONSTRUCTOR that has already been reshaped, but it should be harmless.
The type of a CONSTRUCTOR can also by changed
in tsubst_copy_and_build:
19269 TREE_TYPE (r) = type;
but I haven't been able to trigger any problem yet. Worst comes to worst this
patch changes the ICE to another ICE, but I'm not finding a testcase.
I'd expect that's where the { 1, 2 } goes through to produce this
[PATCH 4/4] [og8] Add tests for Fortran optional arguments in OpenACC 2.6
libgomp/
* testsuite/libgomp.oacc-fortran/optional-cache.f95
* testsuite/libgomp.oacc-fortran/optional-data-copyin-by-value.f90
* testsuite/libgomp.oacc-fortran/optional-data-copyin.f90
* testsuite/libgomp.oacc-fortran/optional-data-copyout.f90
* testsuite/libgomp.oacc-fortran/optional-data-enter-exit.f90
* testsuite/libgomp.oacc-fortran/optional-declare.f90
* testsuite/libgomp.oacc-fortran/optional-firstprivate.f90
* testsuite/libgomp.oacc-fortran/optional-host_data.f90
* testsuite/libgomp.oacc-fortran/optional-nested-calls.f90
* testsuite/libgomp.oacc-fortran/optional-private.f90
* testsuite/libgomp.oacc-fortran/optional-reduction.f90
* testsuite/libgomp.oacc-fortran/optional-update-device.f90
* testsuite/libgomp.oacc-fortran/optional-update-host.f90
Reviewed-by: Julian Brown
Reviewed-by: Thomas Schwinge
---
libgomp/ChangeLog.openacc | 16 +++
.../libgomp.oacc-fortran/optional-cache.f95| 23
.../optional-data-copyin-by-value.f90 | 29 +
.../libgomp.oacc-fortran/optional-data-copyin.f90 | 140
+
.../libgomp.oacc-fortran/optional-data-copyout.f90 | 96 ++
.../optional-data-enter-exit.f90 | 91 ++
.../libgomp.oacc-fortran/optional-declare.f90 | 87 +
.../libgomp.oacc-fortran/optional-firstprivate.f90 | 112 +
.../libgomp.oacc-fortran/optional-host_data.f90| 37 ++
.../libgomp.oacc-fortran/optional-nested-calls.f90 | 135
.../libgomp.oacc-fortran/optional-private.f90 | 118 +
.../libgomp.oacc-fortran/optional-reduction.f90| 69 ++
.../optional-update-device.f90 | 121
++
.../libgomp.oacc-fortran/optional-update-host.f90 | 115 +
14 files changed, 1189 insertions(+)
create mode 100644
libgomp/testsuite/libgomp.oacc-fortran/optional-cache.f95
create mode 100644
libgomp/testsuite/libgomp.oacc-fortran/optional-data-copyin-by-value.f90
create mode 100644
libgomp/testsuite/libgomp.oacc-fortran/optional-data-copyin.f90
create mode 100644
libgomp/testsuite/libgomp.oacc-fortran/optional-data-copyout.f90
create mode 100644
libgomp/testsuite/libgomp.oacc-fortran/optional-data-enter-exit.f90
create mode 100644
libgomp/testsuite/libgomp.oacc-fortran/optional-declare.f90
create mode 100644
libgomp/testsuite/libgomp.oacc-fortran/optional-firstprivate.f90
create mode 100644
libgomp/testsuite/libgomp.oacc-fortran/optional-host_data.f90
create mode 100644
libgomp/testsuite/libgomp.oacc-fortran/optional-nested-calls.f90
create mode 100644
libgomp/testsuite/libgomp.oacc-fortran/optional-private.f90
create mode 100644
libgomp/testsuite/libgomp.oacc-fortran/optional-reduction.f90
create mode 100644
libgomp/testsuite/libgomp.oacc-fortran/optional-update-device.f90
create mode 100644
libgomp/testsuite/libgomp.oacc-fortran/optional-update-host.f90
diff --git a/libgomp/ChangeLog.openacc b/libgomp/ChangeLog.openacc
index 69bd1ee..421e0c0 100644
--- a/libgomp/ChangeLog.openacc
+++ b/libgomp/ChangeLog.openacc
@@ -1,5 +1,21 @@
2019-01-30 Kwok Cheung Yeung
+ * testsuite/libgomp.oacc-fortran/optional-cache.f95
+ * testsuite/libgomp.oacc-fortran/optional-data-copyin-by-value.f90
+ * testsuite/libgomp.oacc-fortran/optional-data-copyin.f90
+ * testsuite/libgomp.oacc-fortran/optional-data-copyout.f90
+ * testsuite/libgomp.oacc-fortran/optional-data-enter-exit.f90
+ * testsuite/libgomp.oacc-fortran/optional-declare.f90
+ * testsuite/libgomp.oacc-fortran/optional-firstprivate.f90
+ * testsuite/libgomp.oacc-fortran/optional-host_data.f90
+ * testsuite/libgomp.oacc-fortran/optional-nested-calls.f90
+ * testsuite/libgomp.oacc-fortran/optional-private.f90
+ * testsuite/libgomp.oacc-fortran/optional-reduction.f90
+ * testsuite/libgomp.oacc-fortran/optional-update-device.f90
+ * testsuite/libgomp.oacc-fortran/optional-update-host.f90
+
+2019-01-30 Kwok Cheung Yeung
+
* oacc-mem.c (update_dev_host): Return early if the host address
is NULL.
diff --git a/libgomp/testsuite/libgomp.oacc-fortran/optional-cache.f95
b/libgomp/testsuite/libgomp.oacc-fortran/optional-cache.f95
new file mode 100644
index 000..d828497
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-fortran/optional-cache.f95
@@ -0,0 +1,23 @@
+! Test that the cache directives work with optional arguments. The effect
+! of giving a non-present argument to the cache directive is not tested as
+! it is undefined. The test is based on gfortran.dg/goacc/cache-1.f95.
+
+! { dg-additional-options "-std=f2008" }
+
+program cache_test
+ implicit none
+ integer :: d(10), e(5,13)
+
+ call do_test(d, e)
+contains
+ subroutine do_test(d, e)
+integer, optional :: d(10),
[PATCH 3/4] [og8] Add support for allocatable arrays as optional arguments
This patch allows allocatable arrays to be used as Fortran optional
arguments. When an optional argument is detected, the Fortran front-end
now generates extra code to test if the argument is null. If so, it sets
the size of the array contents to zero, and the pointers to data to
null. This prevents libgomp from trying to copy non-existant data, and
preserves the null pointer used by PRESENT to detect non-present arguments.
gcc/fortran/
* trans-openmp.c (gfc_build_conditional_assign): New.
(gfc_build_conditional_assign_expr): New.
(gfc_omp_finish_clause): Add conditionals to set the clause
declaration to null and size to zero if the declaration is a
non-present optional argument.
(gfc_trans_omp_clauses_1): Likewise.
Reviewed-by: Chung-Lin Tang
---
gcc/fortran/ChangeLog.openacc | 9 +++
gcc/fortran/trans-openmp.c| 164
+++---
2 files changed, 147 insertions(+), 26 deletions(-)
diff --git a/gcc/fortran/ChangeLog.openacc b/gcc/fortran/ChangeLog.openacc
index 05462a0..dba098b 100644
--- a/gcc/fortran/ChangeLog.openacc
+++ b/gcc/fortran/ChangeLog.openacc
@@ -1,3 +1,12 @@
+2019-01-30 Kwok Cheung Yeung
+
+ * trans-openmp.c (gfc_build_conditional_assign): New.
+ (gfc_build_conditional_assign_expr): New.
+ (gfc_omp_finish_clause): Add conditionals to set the clause
+ declaration to null and size to zero if the declaration is a
+ non-present optional argument.
+ (gfc_trans_omp_clauses_1): Likewise.
+
2019-01-29 Gergö Barany
* trans-openmp.c (gfc_privatize_nodesc_array_clauses): Renamed from
diff --git a/gcc/fortran/trans-openmp.c b/gcc/fortran/trans-openmp.c
index 5a444c3..6b20271 100644
--- a/gcc/fortran/trans-openmp.c
+++ b/gcc/fortran/trans-openmp.c
@@ -1042,6 +1042,62 @@ gfc_omp_clause_dtor (tree clause, tree decl)
return tem;
}
+/* Build a conditional expression in BLOCK. If COND_VAL is not
+ null, then the block THEN_B is executed, otherwise ELSE_VAL
+ is assigned to VAL. */
+
+static void
+gfc_build_conditional_assign (stmtblock_t *block,
+ tree val,
+ tree cond_val,
+ tree then_b,
+ tree else_val)
+{
+ stmtblock_t cond_block;
+ tree cond, else_b;
+ tree val_ty = TREE_TYPE (val);
+
+ gfc_init_block (_block);
+ gfc_add_modify (_block, val, fold_convert (val_ty, else_val));
+ else_b = gfc_finish_block (_block);
+ cond = fold_convert (pvoid_type_node, cond_val);
+ cond = fold_build2_loc (input_location, NE_EXPR,
+ logical_type_node,
+ cond, null_pointer_node);
+ gfc_add_expr_to_block (block,
+build3_loc (input_location,
+COND_EXPR,
+void_type_node,
+cond, then_b,
+else_b));
+}
+
+/* Build a conditional expression in BLOCK, returning a temporary
+ variable containing the result. If COND_VAL is not null, then
+ THEN_VAL will be assigned to the variable, otherwise ELSE_VAL
+ is assigned.
+ */
+
+static tree
+gfc_build_conditional_assign_expr (stmtblock_t *block,
+ tree cond_val,
+ tree then_val,
+ tree else_val)
+{
+ tree val;
+ tree val_ty = TREE_TYPE (then_val);
+ stmtblock_t cond_block;
+
+ val = create_tmp_var (val_ty);
+
+ gfc_init_block (_block);
+ gfc_add_modify (_block, val, then_val);
+ tree then_b = gfc_finish_block (_block);
+
+ gfc_build_conditional_assign (block, val, cond_val, then_b, else_val);
+
+ return val;
+}
void
gfc_omp_finish_clause (tree c, gimple_seq *pre_p)
@@ -1107,16 +1163,45 @@ gfc_omp_finish_clause (tree c, gimple_seq *pre_p)
stmtblock_t block;
gfc_start_block ();
tree type = TREE_TYPE (decl);
- tree ptr = gfc_conv_descriptor_data_get (decl);
+ bool optional_arg_p =
+ TREE_CODE (decl) == INDIRECT_REF
+ && TREE_CODE (TREE_OPERAND (decl, 0)) == PARM_DECL
+ && DECL_BY_REFERENCE (TREE_OPERAND (decl, 0))
+ && TREE_CODE (TREE_TYPE (TREE_OPERAND (decl, 0))) == POINTER_TYPE;
+ tree ptr;
+
+ if (optional_arg_p)
+ ptr = gfc_build_conditional_assign_expr (
+ ,
+ TREE_OPERAND (decl, 0),
+ gfc_conv_descriptor_data_get (decl),
+ null_pointer_node);
+ else
+ ptr = gfc_conv_descriptor_data_get (decl);
ptr = build_fold_indirect_ref (ptr);
OMP_CLAUSE_DECL (c) = ptr;
c2 = build_omp_clause (input_location, OMP_CLAUSE_MAP);
OMP_CLAUSE_SET_MAP_KIND (c2, GOMP_MAP_TO_PSET);
- OMP_CLAUSE_DECL (c2) = decl;
+ if (optional_arg_p)
+ {
+ ptr = create_tmp_var (TREE_TYPE (TREE_OPERAND
[PATCH 2/4] [og8] Calculate correct size for optional arguments used in the firstprivate clause
The lowering for firstprivate uses the pointer size rather than the size
of the referenced object when passed an optional argument. This patch
detects optional arguments as a special case and treats them as
reference types.
gcc/
* omp-general.c (omp_is_optional_argument): New.
* omp-general.h (omp_is_optional_argument): New.
* omp-low.c (lower_omp_target): Use size of referenced object when
optional argument used as argument to firstprivate.
---
gcc/ChangeLog.openacc | 7 +++
gcc/omp-general.c | 9 +
gcc/omp-general.h | 1 +
gcc/omp-low.c | 3 ++-
4 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/gcc/ChangeLog.openacc b/gcc/ChangeLog.openacc
index 744cf02..04d18c0 100644
--- a/gcc/ChangeLog.openacc
+++ b/gcc/ChangeLog.openacc
@@ -1,3 +1,10 @@
+2019-01-30 Kwok Cheung Yeung
+
+ * omp-general.c (omp_is_optional_argument): New.
+ * omp-general.h (omp_is_optional_argument): New.
+ * omp-low.c (lower_omp_target): Use size of referenced object when
+ optional argument used as argument to firstprivate.
+
2019-01-30 Thomas Schwinge
* doc/invoke.texi (C Language Options): List "-fopenacc-dim".
diff --git a/gcc/omp-general.c b/gcc/omp-general.c
index 1897f00..dd37c46 100644
--- a/gcc/omp-general.c
+++ b/gcc/omp-general.c
@@ -46,6 +46,15 @@ omp_find_clause (tree clauses, enum omp_clause_code kind)
return NULL_TREE;
}
+/* Return true if DECL is a Fortran optional argument. */
+
+bool
+omp_is_optional_argument (tree decl)
+{
+ return TREE_CODE (decl) == PARM_DECL && DECL_BY_REFERENCE (decl)
+&& TREE_CODE (TREE_TYPE (decl)) == POINTER_TYPE;
+}
+
/* Return true if DECL is a reference type. */
bool
diff --git a/gcc/omp-general.h b/gcc/omp-general.h
index b704427..c5e7446 100644
--- a/gcc/omp-general.h
+++ b/gcc/omp-general.h
@@ -72,6 +72,7 @@ struct omp_for_data
#define OACC_FN_ATTRIB "oacc function"
extern tree omp_find_clause (tree clauses, enum omp_clause_code kind);
+extern bool omp_is_optional_argument (tree decl);
extern bool omp_is_reference (tree decl);
extern void omp_adjust_for_condition (location_t loc, enum tree_code
*cond_code,
tree *n2);
diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index f48002e..ef71704 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -8749,7 +8749,8 @@ lower_omp_target (gimple_stmt_iterator *gsi_p,
omp_context *ctx)
else
{
s = TREE_TYPE (ovar);
- if (TREE_CODE (s) == REFERENCE_TYPE)
+ if (TREE_CODE (s) == REFERENCE_TYPE
+ || omp_is_optional_argument (ovar))
s = TREE_TYPE (s);
s = TYPE_SIZE_UNIT (s);
}
--
2.8.1
[PATCH 1/4] [og8] Allow NULL for update directives in OpenACC 2.6
A non-present passed-by-reference Fortran optional argument is represented by a null pointer. When passed to an update directive, it should be ignored as variable mappings are not created for null pointers. This should be safe as it is not possible to change a non-present argument into a present one (or vice-versa) in Fortran. libgomp/ * oacc-mem.c (update_dev_host): Return early if the host address is NULL. Reviewed-by: Julian Brown Reviewed-by: Thomas Schwinge --- libgomp/ChangeLog.openacc | 5 + libgomp/oacc-mem.c| 6 ++ 2 files changed, 11 insertions(+) diff --git a/libgomp/ChangeLog.openacc b/libgomp/ChangeLog.openacc index a9a30d2..69bd1ee 100644 --- a/libgomp/ChangeLog.openacc +++ b/libgomp/ChangeLog.openacc @@ -1,3 +1,8 @@ +2019-01-30 Kwok Cheung Yeung + + * oacc-mem.c (update_dev_host): Return early if the host address + is NULL. + 2019-01-30 Andrew Jenner * testsuite/libgomp.fortan/fortran.exp (lang_link_flags): Add diff --git a/libgomp/oacc-mem.c b/libgomp/oacc-mem.c index 9b70820..74d7ce9 100644 --- a/libgomp/oacc-mem.c +++ b/libgomp/oacc-mem.c @@ -819,6 +819,12 @@ update_dev_host (int is_dev, void *h, size_t s, int async) if (acc_dev->capabilities & GOMP_OFFLOAD_CAP_SHARED_MEM) return; + /* Fortran optional arguments that are non-present result in a + null host address here. This can safely be ignored as it is + not possible to 'update' a non-present optional argument. */ + if (h == NULL) +return; + gomp_mutex_lock (_dev->lock); acc_prof_info prof_info; -- 2.8.1
[PATCH 0/4] [og8] Add support for Fortran optional arguments in OpenACC
This patch series adds support for the use of Fortran optional arguments in OpenACC constructs as specified by the OpenACC 2.6 standard. I will shortly commit these to openacc-gcc-8-branch if there are no objections. Kwok
Re: [PATCH] print correct array sizes in errors (PR 87996)
On 1/29/19 7:15 PM, Martin Sebor wrote:
+ /* Try to convert the original SIZE to a ssizetype. */
+ if (orig_size != error_mark_node
+ && !TYPE_UNSIGNED (TREE_TYPE (orig_size)))
+ {
+ if (TREE_CODE (size) == INTEGER_CST
+ && tree_int_cst_sign_bit (size))
+ diagsize = build_converted_constant_expr (ssizetype, size,
+ tsubst_flags_t ());
+ else if (size == error_mark_node
+ && TREE_CODE (orig_size) == INTEGER_CST
+ && tree_int_cst_sign_bit (orig_size))
+ diagsize = build_converted_constant_expr (ssizetype, orig_size,
+ tsubst_flags_t ());
+ }
Using build_converted_constant_expr here looks odd; that's a
language-level notion, and we're dealing with compiler internals.
fold_convert seems more appropriate.
+ if (TREE_CONSTANT (size))
+ {
+ if (!diagsize && TREE_CODE (size) == INTEGER_CST)
+ diagsize = size;
+ }
+ else
size = osize;
}
@@ -9732,15 +9758,12 @@ compute_array_index_type_loc (location_t name_loc,
if (TREE_CODE (size) == INTEGER_CST)
{
/* An array must have a positive number of elements. */
- if (!valid_constant_size_p (size))
+ if (!diagsize)
+ diagsize = size;
It seems like the earlier hunk here is unnecessary; if size is an
INTEGER_CST, it will be unchanged, and so be used for diagsize in the
latter hunk without any changes to the earlier location. Actually, why
not do all of the diagsize logic down here? There doesn't seem to be
anything above that relies on information we will have lost at this point.
Jason
patch to fix PR87246
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87246
The patch was successfully bootstrapped and tested on x86-64 and ppc64.
Committed as rev. 268404
Index: ChangeLog
===
--- ChangeLog (revision 268403)
+++ ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2019-01-30 Vladimir Makarov
+
+ PR rtl-optimization/87246
+ * lra-constraints.c (simplify_operand_subreg): Reload memory
+ in subreg if the address became invalid.
+
2019-01-30 Bill Schmidt
PR target/87064
Index: lra-constraints.c
===
--- lra-constraints.c (revision 268117)
+++ lra-constraints.c (working copy)
@@ -1497,10 +1497,11 @@ simplify_operand_subreg (int nop, machin
alter_subreg (curr_id->operand_loc[nop], false);
rtx subst = *curr_id->operand_loc[nop];
lra_assert (MEM_P (subst));
-
+ const bool addr_is_valid = valid_address_p (GET_MODE (subst),
+ XEXP (subst, 0),
+ MEM_ADDR_SPACE (subst));
if (!addr_was_valid
- || valid_address_p (GET_MODE (subst), XEXP (subst, 0),
- MEM_ADDR_SPACE (subst))
+ || addr_is_valid
|| ((get_constraint_type (lookup_constraint
(curr_static_id->operand[nop].constraint))
!= CT_SPECIAL_MEMORY)
@@ -1529,12 +1530,17 @@ simplify_operand_subreg (int nop, machin
data into a register when the inner is narrower than outer or
missing important data from memory when the inner is wider than
outer. This rule only applies to modes that are no wider than
- a word. */
- if (!(maybe_ne (GET_MODE_PRECISION (mode),
- GET_MODE_PRECISION (innermode))
- && known_le (GET_MODE_SIZE (mode), UNITS_PER_WORD)
- && known_le (GET_MODE_SIZE (innermode), UNITS_PER_WORD)
- && WORD_REGISTER_OPERATIONS)
+ a word.
+
+ If valid memory becomes invalid after subreg elimination
+ we still have to reload memory.
+ */
+ if ((! addr_was_valid || addr_is_valid)
+ && !(maybe_ne (GET_MODE_PRECISION (mode),
+ GET_MODE_PRECISION (innermode))
+ && known_le (GET_MODE_SIZE (mode), UNITS_PER_WORD)
+ && known_le (GET_MODE_SIZE (innermode), UNITS_PER_WORD)
+ && WORD_REGISTER_OPERATIONS)
&& (!(MEM_ALIGN (subst) < GET_MODE_ALIGNMENT (mode)
&& targetm.slow_unaligned_access (mode, MEM_ALIGN (subst)))
|| (MEM_ALIGN (reg) < GET_MODE_ALIGNMENT (innermode)
@@ -1553,7 +1559,7 @@ simplify_operand_subreg (int nop, machin
enum reg_class rclass
= (enum reg_class) targetm.preferred_reload_class (reg, ALL_REGS);
if (get_reload_reg (curr_static_id->operand[nop].type, innermode,
- reg, rclass, TRUE, "slow mem", _reg))
+ reg, rclass, TRUE, "slow/invalid mem", _reg))
{
bool insert_before, insert_after;
bitmap_set_bit (_subreg_reload_pseudos, REGNO (new_reg));
@@ -1572,7 +1578,7 @@ simplify_operand_subreg (int nop, machin
rclass
= (enum reg_class) targetm.preferred_reload_class (reg, ALL_REGS);
if (get_reload_reg (curr_static_id->operand[nop].type, mode, reg,
- rclass, TRUE, "slow mem", _reg))
+ rclass, TRUE, "slow/invalid mem", _reg))
{
bool insert_before, insert_after;
bitmap_set_bit (_subreg_reload_pseudos, REGNO (new_reg));
@@ -1585,7 +1591,7 @@ simplify_operand_subreg (int nop, machin
}
*curr_id->operand_loc[nop] = new_reg;
lra_process_new_insns (curr_insn, before, after,
- "Inserting slow mem reload");
+ "Inserting slow/invalid mem reload");
return true;
}
Index: testsuite/ChangeLog
===
--- testsuite/ChangeLog (revision 268403)
+++ testsuite/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2019-01-30 Vladimir Makarov
+
+ PR rtl-optimization/87246
+ * gcc.target/i386/pr87246.c: New.
+
2019-01-30 Marek Polacek
PR c++/89119 - ICE with value-initialization in template.
@@ -15,7 +20,7 @@
* gcc.target/powerpc/vec-extract-uint128-1.c: New test.
* gcc.target/powerpc/vec-extract-ulong-1.c: New test.
* gcc.target/powerpc/vec-extract-ushort-1.c: New test.
-
+
2019-01-30 Richard Biener
PR tree-optimization/89111
Index: testsuite/gcc.target/i386/pr87246.c
===
--- testsuite/gcc.target/i386/pr87246.c (nonexistent)
+++ testsuite/gcc.target/i386/pr87246.c (working copy)
@@ -0,0 +1,22 @@
+/* PR rtl-optimization/87246 */
+/* { dg-do compile { target int128 } } */
+/* { dg-options "-O2 -w -fnon-call-exceptions -fno-split-wide-types" } */
+
+__int128 zd;
+int c1;
+
+void
+s2 (__int128 *qv)
+{
+ if (*qv != 0)
+{
+ zd = 0;
+ c1 = c1 <= *qv;
+}
+}
+
+void
+lt (unsigned int vb)
+{
+ s2 (vb + 1);
+}
Re: C++ PATCH for c++/89083, c++/80864 - ICE with list initialization in template
On Wed, Jan 30, 2019 at 04:11:11PM -0500, Marek Polacek wrote:
> On Tue, Jan 29, 2019 at 09:40:18PM -0500, Jason Merrill wrote:
> > On Tue, Jan 29, 2019 at 6:53 PM Marek Polacek wrote:
> > >
> > > My recent patch for 88815 and 78244 caused 89083, a P1 9 regression, which
> > > happens to be the same problem as 80864 and its many dupes, something I'd
> > > been meaning to fix for a long time.
> > >
> > > Basically, the problem is repeated reshaping of a constructor, once when
> > > parsing, and then again when substituting. With the recent fix, we call
> > > reshape_init + digest_init in finish_compound_literal even in a template
> > > if the expression is not instantiation-dependent, and then again when
> > > tsubst_*.
> > >
> > > For instance, in initlist107.C, when parsing a functional cast, we call
> > > finish_compound_literal which calls reshape_init, which turns
> > >
> > > { NON_LVALUE_EXPR<1>, NON_LVALUE_EXPR<2> }
> > >
> > > into
> > >
> > > { { NON_LVALUE_EXPR<1>, NON_LVALUE_EXPR<2> } }
> > >
> > > and then digest_init turns that into
> > >
> > > { .x = { 1, 2 } }
> > >
> > > which is a compound literal (TREE_HAS_CONSTRUCTOR set), but the
> > > subexpression
> > > "{ 1, 2 }" isn't. "{ 1, 2 }" will now have the type int[3], so it's not
> > > BRACE_ENCLOSED_INITIALIZER_P.
> > >
> > > And then tsubst_* processes "{ .x = { 1, 2 } }". The case CONSTRUCTOR
> > > in tsubst_copy_and_build will call finish_compound_literal on a copy of
> > > "{ 1, 2 }" wrapped in a new { }, because the whole expr has
> > > TREE_HAS_CONSTRUCTOR.
> > > That crashes in reshape_init_r in the
> > > 6155 if (TREE_CODE (stripped_init) == CONSTRUCTOR)
> > > block; we have a constructor, it's not COMPOUND_LITERAL_P, and because
> > > digest_init had given it the type int[3], we hit
> > > 6172 gcc_assert (BRACE_ENCLOSED_INITIALIZER_P
> > > (stripped_init));
> > >
> > > As expand_default_init explains in a comment, a CONSTRUCTOR of the
> > > target's type
> > > is a previously digested initializer, so we should probably do a similar
> > > trick
> > > here. This fixes all the variants of the problem I've come up with.
> > >
> > > 80864 is a similar case, we reshape when parsing and then second time in
> > > fold_non_dependent_expr called from store_init_value, because of the
> > > 'constexpr'.
> > >
> > > Also update a stale comment.
> > >
> > > Bootstrapped/regtest running on x86_64-linux, ok for trunk and 8 after a
> > > while?
> > >
> > > 2019-01-29 Marek Polacek
> > >
> > > PR c++/89083, c++/80864 - ICE with list initialization in
> > > template.
> > > * decl.c (reshape_init_r): Don't reshape a digested initializer.
> > >
> > > * g++.dg/cpp0x/initlist107.C: New test.
> > > * g++.dg/cpp0x/initlist108.C: New test.
> > > * g++.dg/cpp0x/initlist109.C: New test.
> > >
> > > diff --git gcc/cp/decl.c gcc/cp/decl.c
> > > index 79eeac177b6..da08ecc21aa 100644
> > > --- gcc/cp/decl.c
> > > +++ gcc/cp/decl.c
> > > @@ -6161,11 +6161,17 @@ reshape_init_r (tree type, reshape_iter *d, bool
> > > first_initializer_p,
> > > ;
> > > else if (COMPOUND_LITERAL_P (stripped_init))
> > > /* For a nested compound literal, there is no need to reshape
> > > since
> > > -brace elision is not allowed. Even if we decided to allow it,
> > > -we should add a call to reshape_init in
> > > finish_compound_literal,
> > > -before calling digest_init, so changing this code would still
> > > -not be necessary. */
> > > +we called reshape_init in finish_compound_literal, before
> > > calling
> > > +digest_init. */
> > > gcc_assert (!BRACE_ENCLOSED_INITIALIZER_P (stripped_init));
> > > + /* Similarly, a CONSTRUCTOR of the target's type is a previously
> > > +digested initializer. */
> > > + else if (same_type_ignoring_top_level_qualifiers_p (type,
> > > + TREE_TYPE
> > > (init)))
> >
> > Hmm, aren't both of these tests true for a dependent compound literal,
> > which won't have been reshaped already?
>
> I'm hoping that can't happen, but it's a good question. When we have a
> dependent compound literal, finish_compound_literal just sets
> TREE_HAS_CONSTRUCTOR and returns it, so then in tsubst_*, after substituting
> each element of the constructor, we call finish_compound_literal. The
> constructor is no longer dependent and since we operate on a copy on which
> we didn't set TREE_HAS_CONSTRUCTOR, the first condition shouldn't be true.
>
> And the second condition should also never be true for a compound literal
> that hasn't been reshaped, because digest_init is only ever called after
> reshape_init (and the comment for digest_init_r says it assumes that
> reshape_init has already run). The type of a CONSTRUCTOR can also by changed
> in tsubst_copy_and_build:
> 19269
Re: C++ PATCH for c++/89083, c++/80864 - ICE with list initialization in template
On Tue, Jan 29, 2019 at 09:40:18PM -0500, Jason Merrill wrote:
> On Tue, Jan 29, 2019 at 6:53 PM Marek Polacek wrote:
> >
> > My recent patch for 88815 and 78244 caused 89083, a P1 9 regression, which
> > happens to be the same problem as 80864 and its many dupes, something I'd
> > been meaning to fix for a long time.
> >
> > Basically, the problem is repeated reshaping of a constructor, once when
> > parsing, and then again when substituting. With the recent fix, we call
> > reshape_init + digest_init in finish_compound_literal even in a template
> > if the expression is not instantiation-dependent, and then again when
> > tsubst_*.
> >
> > For instance, in initlist107.C, when parsing a functional cast, we call
> > finish_compound_literal which calls reshape_init, which turns
> >
> > { NON_LVALUE_EXPR<1>, NON_LVALUE_EXPR<2> }
> >
> > into
> >
> > { { NON_LVALUE_EXPR<1>, NON_LVALUE_EXPR<2> } }
> >
> > and then digest_init turns that into
> >
> > { .x = { 1, 2 } }
> >
> > which is a compound literal (TREE_HAS_CONSTRUCTOR set), but the
> > subexpression
> > "{ 1, 2 }" isn't. "{ 1, 2 }" will now have the type int[3], so it's not
> > BRACE_ENCLOSED_INITIALIZER_P.
> >
> > And then tsubst_* processes "{ .x = { 1, 2 } }". The case CONSTRUCTOR
> > in tsubst_copy_and_build will call finish_compound_literal on a copy of
> > "{ 1, 2 }" wrapped in a new { }, because the whole expr has
> > TREE_HAS_CONSTRUCTOR.
> > That crashes in reshape_init_r in the
> > 6155 if (TREE_CODE (stripped_init) == CONSTRUCTOR)
> > block; we have a constructor, it's not COMPOUND_LITERAL_P, and because
> > digest_init had given it the type int[3], we hit
> > 6172 gcc_assert (BRACE_ENCLOSED_INITIALIZER_P
> > (stripped_init));
> >
> > As expand_default_init explains in a comment, a CONSTRUCTOR of the target's
> > type
> > is a previously digested initializer, so we should probably do a similar
> > trick
> > here. This fixes all the variants of the problem I've come up with.
> >
> > 80864 is a similar case, we reshape when parsing and then second time in
> > fold_non_dependent_expr called from store_init_value, because of the
> > 'constexpr'.
> >
> > Also update a stale comment.
> >
> > Bootstrapped/regtest running on x86_64-linux, ok for trunk and 8 after a
> > while?
> >
> > 2019-01-29 Marek Polacek
> >
> > PR c++/89083, c++/80864 - ICE with list initialization in template.
> > * decl.c (reshape_init_r): Don't reshape a digested initializer.
> >
> > * g++.dg/cpp0x/initlist107.C: New test.
> > * g++.dg/cpp0x/initlist108.C: New test.
> > * g++.dg/cpp0x/initlist109.C: New test.
> >
> > diff --git gcc/cp/decl.c gcc/cp/decl.c
> > index 79eeac177b6..da08ecc21aa 100644
> > --- gcc/cp/decl.c
> > +++ gcc/cp/decl.c
> > @@ -6161,11 +6161,17 @@ reshape_init_r (tree type, reshape_iter *d, bool
> > first_initializer_p,
> > ;
> > else if (COMPOUND_LITERAL_P (stripped_init))
> > /* For a nested compound literal, there is no need to reshape
> > since
> > -brace elision is not allowed. Even if we decided to allow it,
> > -we should add a call to reshape_init in
> > finish_compound_literal,
> > -before calling digest_init, so changing this code would still
> > -not be necessary. */
> > +we called reshape_init in finish_compound_literal, before
> > calling
> > +digest_init. */
> > gcc_assert (!BRACE_ENCLOSED_INITIALIZER_P (stripped_init));
> > + /* Similarly, a CONSTRUCTOR of the target's type is a previously
> > +digested initializer. */
> > + else if (same_type_ignoring_top_level_qualifiers_p (type,
> > + TREE_TYPE
> > (init)))
>
> Hmm, aren't both of these tests true for a dependent compound literal,
> which won't have been reshaped already?
I'm hoping that can't happen, but it's a good question. When we have a
dependent compound literal, finish_compound_literal just sets
TREE_HAS_CONSTRUCTOR and returns it, so then in tsubst_*, after substituting
each element of the constructor, we call finish_compound_literal. The
constructor is no longer dependent and since we operate on a copy on which
we didn't set TREE_HAS_CONSTRUCTOR, the first condition shouldn't be true.
And the second condition should also never be true for a compound literal
that hasn't been reshaped, because digest_init is only ever called after
reshape_init (and the comment for digest_init_r says it assumes that
reshape_init has already run). The type of a CONSTRUCTOR can also by changed
in tsubst_copy_and_build:
19269 TREE_TYPE (r) = type;
but I haven't been able to trigger any problem yet. Worst comes to worst this
patch changes the ICE to another ICE, but I'm not finding a testcase.
The following patch is the same but adds tests with dependent compound literals
for good measure.
Re: [PATCH, fortran ieee]: PR 88678, Many gfortran.dg/ieee/ieee_X.f90 test cases fail starting with r267465
On Wed, Jan 30, 2019 at 9:12 PM Uros Bizjak wrote:
> On Wed, Jan 30, 2019 at 10:37 AM Uros Bizjak wrote:
>
> > > Your decription suggests that this fixes PR fortran/88678.
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88678
> >
> > Actually, additional patch is needed to fully fix PR88678.
> > support_fpu_trap enables and disables exceptions and this may fire
> > spurious exceptions. Just assume that all supported flags can generate
> > exceptions, as is done in the additional patch, posted to PR88678.
>
> The remaining ieee_*.f90 tests and large_1.f90 test failures on
> powerpc64 are fixed by the attached patch.
>
> 2019-01-30 Uroš Bizjak
>
> PR fortran/88678
> * config/fpu-glibc.h (support_fpu_trap): Do not try to enable
> exceptions to determine if exception is supported.
>
> Bootstrapped and regression tested on x86_64-linux-gnu {,-m32} (with
> appropriate config.host tweak to select fpu-glibc.header),
> alphaev68-linux-gnu and as reported in the PR, on
> powerpc64le-linux-gnu by Peter.
>
> OK for mainline?
>
This seems to change the only user of support_fpu_trap() that is different
from support_fpu_flag(), so with this change one could remove
support_fpu_trap() entirely and modify all callers (since it's an internal
function it's not used outside libgfortran) to call support_fpu_flag()
directly. Otherwise Ok.
--
Janne Blomqvist
Re: [C++ PATCH] [PR87770] test partial specializations for type dependence
Hi, On 30/01/19 17:25, Alexandre Oliva wrote: +static inline bool +instantiates_primary_template_p (tree node) I'm rather surprised by the inline: as a general rule, we want functions this size all inline? I would say that in the C++ library we don't, sure, not very big but already too big. Paolo.
Re: [Patch, fortran] PR88685 - [8/9 regression] pointer class array argument indexing
Hi Paul, Are you sure about the && in + && ref->u.c.component->ts.type != BT_DERIVED)) should not it be ||? TIA Dominique
Re: [Patch, fortran] PR88685 - [8/9 regression] pointer class array argument indexing
Sorry about the premature 'send'.
This one is more or less obvious and is described in the ChangeLog.
The key point is that full or section array references to intrinsic
components were returning a false true from expr.c (is_subref_array).
Returning false if a component is intrinsic and following anything
other than an array element is an obvious remedy.
Bootstrapped and regtested on FC28/x86_64 - OK for trunk and 8-branch?
Paul
2019-01-30 Paul Thomas
PR fortran/88685
* expr.c (is_subref_array): Move the check for class pointer
dummy arrays to after the reference check. If we haven't seen
an array reference other than an element and a component is not
class or derived, return false.
2019-01-30 Paul Thomas
PR fortran/88685
* gfortran.dg/pointer_array_component_3.f90 : New test.
Index: gcc/fortran/expr.c
===
*** gcc/fortran/expr.c (revision 268230)
--- gcc/fortran/expr.c (working copy)
*** is_subref_array (gfc_expr * e)
*** 1072,1086
if (e->symtree->n.sym->attr.subref_array_pointer)
return true;
- if (e->symtree->n.sym->ts.type == BT_CLASS
- && e->symtree->n.sym->attr.dummy
- && CLASS_DATA (e->symtree->n.sym)->attr.dimension
- && CLASS_DATA (e->symtree->n.sym)->attr.class_pointer)
- return true;
-
seen_array = false;
for (ref = e->ref; ref; ref = ref->next)
{
if (ref->type == REF_ARRAY
&& ref->u.ar.type != AR_ELEMENT)
seen_array = true;
--- 1072,1086
if (e->symtree->n.sym->attr.subref_array_pointer)
return true;
seen_array = false;
+
for (ref = e->ref; ref; ref = ref->next)
{
+ if (!seen_array && ref->type == REF_COMPONENT
+ && (ref->u.c.component->ts.type != BT_CLASS
+ && ref->u.c.component->ts.type != BT_DERIVED))
+ return false;
+
if (ref->type == REF_ARRAY
&& ref->u.ar.type != AR_ELEMENT)
seen_array = true;
*** is_subref_array (gfc_expr * e)
*** 1089,1094
--- 1089,1101
&& ref->type != REF_ARRAY)
return seen_array;
}
+
+ if (e->symtree->n.sym->ts.type == BT_CLASS
+ && e->symtree->n.sym->attr.dummy
+ && CLASS_DATA (e->symtree->n.sym)->attr.dimension
+ && CLASS_DATA (e->symtree->n.sym)->attr.class_pointer)
+ return true;
+
return false;
}
Index: gcc/testsuite/gfortran.dg/pointer_array_component_3.f90
===
*** gcc/testsuite/gfortran.dg/pointer_array_component_3.f90 (nonexistent)
--- gcc/testsuite/gfortran.dg/pointer_array_component_3.f90 (working copy)
***
*** 0
--- 1,36
+ ! { dg-do run }
+ !
+ ! Test the fix for PR88685, in which the component array references in 'doit'
+ ! were being ascribed to the class pointer 'Cls' itself so that the stride
+ ! measure between elements was wrong.
+ !
+ ! Contributed by Antony Lewis
+ !
+ program tester
+ implicit none
+ Type TArr
+ integer, allocatable :: CL(:)
+ end Type TArr
+
+ type(TArr), allocatable, target :: arr(:,:)
+ class(TArr), pointer:: Cls(:,:)
+ integer i
+
+ allocate(arr(1,1))
+ allocate(arr(1,1)%CL(3))
+ arr(1,1)%CL=-1
+ cls => arr
+ call doit(cls)
+ if (any (arr(1,1)%cl .ne. [3,2,1])) stop 3
+ contains
+ subroutine doit(cls)
+ class(TArr), pointer :: Cls(:,:)
+
+ cls(1,1)%CL(1) = 3
+ cls(1,1)%CL(2:3) = [2,1]
+
+ if (any (Cls(1,1)%CL .ne. [3,2,1])) stop 1
+ if (Cls(1,1)%CL(2) .ne. 2) stop 2
+
+ end subroutine doit
+ end program tester
[Patch, fortran] PR88685 - [8/9 regression] pointer class array argument indexing
This one is more or less obvious and is described in the ChangeLog. The key point is that full or section array references to intrinsic components were returning a false true from expr.c (is_subref_array). Returning false if a component is intrinsic and following anything other than an array element is an obvious remedy. Bootstrapped and regtested on FC28/x86_64 - OK for trunk and 8-branch? Paul
[PATCH, fortran ieee]: PR 88678, Many gfortran.dg/ieee/ieee_X.f90 test cases fail starting with r267465
On Wed, Jan 30, 2019 at 10:37 AM Uros Bizjak wrote:
> > Your decription suggests that this fixes PR fortran/88678.
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88678
>
> Actually, additional patch is needed to fully fix PR88678.
> support_fpu_trap enables and disables exceptions and this may fire
> spurious exceptions. Just assume that all supported flags can generate
> exceptions, as is done in the additional patch, posted to PR88678.
The remaining ieee_*.f90 tests and large_1.f90 test failures on
powerpc64 are fixed by the attached patch.
2019-01-30 Uroš Bizjak
PR fortran/88678
* config/fpu-glibc.h (support_fpu_trap): Do not try to enable
exceptions to determine if exception is supported.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32} (with
appropriate config.host tweak to select fpu-glibc.header),
alphaev68-linux-gnu and as reported in the PR, on
powerpc64le-linux-gnu by Peter.
OK for mainline?
Uros.
diff --git a/libgfortran/config/fpu-glibc.h b/libgfortran/config/fpu-glibc.h
index c24bb6cbcd92..df2588e038d8 100644
--- a/libgfortran/config/fpu-glibc.h
+++ b/libgfortran/config/fpu-glibc.h
@@ -121,41 +129,7 @@ get_fpu_trap_exceptions (void)
int
support_fpu_trap (int flag)
{
- int exceptions = 0;
- int old;
-
- if (!support_fpu_flag (flag))
-return 0;
-
-#ifdef FE_INVALID
- if (flag & GFC_FPE_INVALID) exceptions |= FE_INVALID;
-#endif
-
-#ifdef FE_DIVBYZERO
- if (flag & GFC_FPE_ZERO) exceptions |= FE_DIVBYZERO;
-#endif
-
-#ifdef FE_OVERFLOW
- if (flag & GFC_FPE_OVERFLOW) exceptions |= FE_OVERFLOW;
-#endif
-
-#ifdef FE_UNDERFLOW
- if (flag & GFC_FPE_UNDERFLOW) exceptions |= FE_UNDERFLOW;
-#endif
-
-#ifdef FE_DENORMAL
- if (flag & GFC_FPE_DENORMAL) exceptions |= FE_DENORMAL;
-#endif
-
-#ifdef FE_INEXACT
- if (flag & GFC_FPE_INEXACT) exceptions |= FE_INEXACT;
-#endif
-
- old = feenableexcept (exceptions);
- if (old == -1)
-return 0;
- fedisableexcept (exceptions & ~old);
- return 1;
+ return support_fpu_flag (flag);
}
Re: [C++ PATCH] [PR87770] test partial specializations for type dependence
On 1/30/19 11:25 AM, Alexandre Oliva wrote: On Jan 30, 2019, Jason Merrill wrote: Hmm, I wouldn't expect that from a function named "instantiates_primary_template_p". Hmm, indeed. Perhaps another function that calls instantiates_primary_template_p and then checks for dependent innermost template args? Does that come up as often? If not, I'll just leave that part of the test where it was. We know tmpl is a decl, so we can unconditionally take its DECL_CONTEXT. Note that I'm talking about the "tmpl" variable, not "node". Ahh, sorry, I missed that. Nice! Here's what I regstrapped overnight. Ok to install? [PR87770] test partial specializations for type dependence From: Alexandre Oliva When instantiating a partial specialization of a template member function for a full specialization of a class template, we test whether the context of variables local to the partial specialization, i.e., the partial specialization itself, is dependent, and this ICEs in type_dependent_expression_p, when checking that the function type isn't type-dependent because it is not in a type-dependent scope. We shouldn't have got that far: the previous block in type_dependent_expression_p catches cases in which the function itself takes template arguments of its own, but it only did so for primary templates, not for partial specializations. This patch fixes that. for gcc/cp/ChangeLog PR c++/87770 * pt.c (instantiates_primary_template_p): New. (type_dependent_expression_p): Use it. OK. Jason
Re: C++ PATCH for c++/89119 - ICE with value-initialization in template
On 1/30/19 12:43 PM, Marek Polacek wrote:
While looking at the other PR I came across this ICE. We're substituting
{.a={[0 ... 3]=0}}
which contains a RANGE_EXPR that build_value_init_noctor created, but none
of the tsubst_* functions handle it. As discussed in the PR, a RANGE_EXPR
will always be created with constant operands, so there's no need to recurse
further.
Bootstrapped/regtest running on x86_64-linux, ok for trunk and 8/7?
2019-01-30 Marek Polacek
PR c++/89119 - ICE with value-initialization in template.
* pt.c (tsubst_copy_and_build): Handle RANGE_EXPR.
OK.
Jason
Re: C++ PATCH for c++/88325 - ICE with invalid out-of-line template member definition
On 1/28/19 9:46 PM, Marek Polacek wrote: This patch fixes an ICE-on-invalid (becase out-of-line constructors can't have template arguments and also because function templates can't be partially specialized) in C++2a: when we're parsing template template A::A () in the attached test we end up parsing "A::A" as a type name, and first we try a class-name. First we process "A::" as the nested name specifier and then we parse "A". In this test that results in a BASELINK. Because in this context we're supposed to treat it as a typename ([temp.res]/6), we call make_typename_type, but that crashes. Hmm. If we've done an actual lookup (that gave us a BASELINK), we aren't dealing with a member of an unknown specialization anymore, so we should just use the result of the lookup rather than speculate about what the name might mean. Why are we still trying to treat it as a typename? Jason
[PATCH, OpenACC og8] Use -lquadmath when compiling fortran with gcc driver
I have committed this patch to openacc-gcc-8-branch. When invoking gcc
to compile fortran code, fortran.exp is currently adding the options
-lgfortran -foffload=-lgfortran to the gcc command line. libgfortran
statically links to libquadmath and the gfortran driver invokes the
linker with -lquadmath as well as -lgfortran so fortran.exp should do so
too.
Ideally, fortran testsuites should invoke the compiler as gfortran
instead of gcc, but this is a stopgap measure to unblock testing until
this work is done.
Note that we do not add -foffload=-lquadmath as doing so causes
powerpc64le-none-linux-gnu-accel-nvptx-none-gcc to report "error opening
libquadmath.a".
libgomp/
* testsuite/libgomp.fortan/fortran.exp (lang_link_flags): Add
-lquadmath.
* testsuite/libgomp.oacc-fortran/fortran.exp (lang_link_flags):
Add -lquadmath.
diff --git a/libgomp/testsuite/libgomp.fortran/fortran.exp
b/libgomp/testsuite/libgomp.fortran/fortran.exp
index d848ed4..621000a 100644
--- a/libgomp/testsuite/libgomp.fortran/fortran.exp
+++ b/libgomp/testsuite/libgomp.fortran/fortran.exp
@@ -7,7 +7,7 @@ global ALWAYS_CFLAGS
set shlib_ext [get_shlib_extension]
set lang_library_path "../libgfortran/.libs"
-set lang_link_flags"-lgfortran -foffload=-lgfortran"
+set lang_link_flags"-lgfortran -foffload=-lgfortran -lquadmath"
if [info exists lang_include_flags] then {
unset lang_include_flags
}
diff --git a/libgomp/testsuite/libgomp.oacc-fortran/fortran.exp
b/libgomp/testsuite/libgomp.oacc-fortran/fortran.exp
index b746ab6..32da263 100644
--- a/libgomp/testsuite/libgomp.oacc-fortran/fortran.exp
+++ b/libgomp/testsuite/libgomp.oacc-fortran/fortran.exp
@@ -9,7 +9,7 @@ global ALWAYS_CFLAGS
set shlib_ext [get_shlib_extension]
set lang_library_path "../libgfortran/.libs"
-set lang_link_flags"-lgfortran -foffload=-lgfortran"
+set lang_link_flags"-lgfortran -foffload=-lgfortran -lquadmath"
if [info exists lang_include_flags] then {
unset lang_include_flags
}
C++ PATCH for c++/89119 - ICE with value-initialization in template
While looking at the other PR I came across this ICE. We're substituting
{.a={[0 ... 3]=0}}
which contains a RANGE_EXPR that build_value_init_noctor created, but none
of the tsubst_* functions handle it. As discussed in the PR, a RANGE_EXPR
will always be created with constant operands, so there's no need to recurse
further.
Bootstrapped/regtest running on x86_64-linux, ok for trunk and 8/7?
2019-01-30 Marek Polacek
PR c++/89119 - ICE with value-initialization in template.
* pt.c (tsubst_copy_and_build): Handle RANGE_EXPR.
* g++.dg/cpp0x/initlist-value3.C: New test.
diff --git gcc/cp/pt.c gcc/cp/pt.c
index cb06a570d48..f92fa1a1813 100644
--- gcc/cp/pt.c
+++ gcc/cp/pt.c
@@ -19412,6 +19412,11 @@ tsubst_copy_and_build (tree t,
case REQUIRES_EXPR:
RETURN (tsubst_requires_expr (t, args, complain, in_decl));
+case RANGE_EXPR:
+ /* No need to substitute further, a RANGE_EXPR will always be built
+with constant operands. */
+ RETURN (t);
+
case NON_LVALUE_EXPR:
case VIEW_CONVERT_EXPR:
if (location_wrapper_p (t))
diff --git gcc/testsuite/g++.dg/cpp0x/initlist-value3.C
gcc/testsuite/g++.dg/cpp0x/initlist-value3.C
new file mode 100644
index 000..03db25d1652
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp0x/initlist-value3.C
@@ -0,0 +1,23 @@
+// PR c++/89119
+// { dg-do compile { target c++11 } }
+
+struct S { int a[4]; };
+
+template
+struct R { int a[N]; };
+
+template
+void
+fn ()
+{
+ constexpr auto s = S();
+ constexpr auto s2 = S{};
+ constexpr auto r = R<4>();
+ constexpr auto r2 = R<4>{};
+}
+
+void
+foo ()
+{
+ fn();
+}
Re: [C++ PATCH] [PR87770] test partial specializations for type dependence
On Jan 30, 2019, Jason Merrill wrote:
> Hmm, I wouldn't expect that from a function named
> "instantiates_primary_template_p".
Hmm, indeed.
> Perhaps another function that calls instantiates_primary_template_p
> and then checks for dependent innermost template args?
Does that come up as often? If not, I'll just leave that part of the
test where it was.
>> > We know tmpl is a decl, so we can unconditionally take its DECL_CONTEXT.
> Note that I'm talking about the "tmpl" variable, not "node".
Ahh, sorry, I missed that. Nice!
Here's what I regstrapped overnight. Ok to install?
[PR87770] test partial specializations for type dependence
From: Alexandre Oliva
When instantiating a partial specialization of a template member
function for a full specialization of a class template, we test
whether the context of variables local to the partial specialization,
i.e., the partial specialization itself, is dependent, and this ICEs
in type_dependent_expression_p, when checking that the function type
isn't type-dependent because it is not in a type-dependent scope.
We shouldn't have got that far: the previous block in
type_dependent_expression_p catches cases in which the function itself
takes template arguments of its own, but it only did so for primary
templates, not for partial specializations. This patch fixes that.
for gcc/cp/ChangeLog
PR c++/87770
* pt.c (instantiates_primary_template_p): New.
(type_dependent_expression_p): Use it.
for gcc/testsuite/ChangeLog
PR c++/87770
* g++.dg/pr87770.C: New.
---
gcc/cp/pt.c| 32 +++-
gcc/testsuite/g++.dg/pr87770.C | 11 +++
2 files changed, 42 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/pr87770.C
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index f8b3054533e74..a3da1f4542b72 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -400,6 +400,36 @@ template_class_depth (tree type)
return depth;
}
+/* Return TRUE if NODE instantiates a template that has arguments of
+ its own, be it directly a primary template or indirectly through a
+ partial specializations. */
+static inline bool
+instantiates_primary_template_p (tree node)
+{
+ tree tinfo = get_template_info (node);
+ if (!tinfo)
+return false;
+
+ tree tmpl = TI_TEMPLATE (tinfo);
+ if (PRIMARY_TEMPLATE_P (tmpl))
+return true;
+
+ if (!DECL_TEMPLATE_SPECIALIZATION (tmpl))
+return false;
+
+ /* So now we know we have a specialization, but it could be a full
+ or a partial specialization. To tell which, compare the depth of
+ its template arguments with those of its context. */
+
+ tree ctxt = DECL_CONTEXT (tmpl);
+ tree ctinfo = get_template_info (ctxt);
+ if (!ctinfo)
+return true;
+
+ return (TMPL_ARGS_DEPTH (TI_ARGS (tinfo))
+ > TMPL_ARGS_DEPTH (TI_ARGS (ctinfo)));
+}
+
/* Subroutine of maybe_begin_member_template_processing.
Returns true if processing DECL needs us to push template parms. */
@@ -25622,7 +25652,7 @@ type_dependent_expression_p (tree expression)
that come from the template-id; the template arguments for the
enclosing class do not make it type-dependent unless they are used in
the type of the decl. */
- if (PRIMARY_TEMPLATE_P (DECL_TI_TEMPLATE (expression))
+ if (instantiates_primary_template_p (expression)
&& (any_dependent_template_arguments_p
(INNERMOST_TEMPLATE_ARGS (DECL_TI_ARGS (expression)
return true;
diff --git a/gcc/testsuite/g++.dg/pr87770.C b/gcc/testsuite/g++.dg/pr87770.C
new file mode 100644
index 0..69eff4a786fef
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr87770.C
@@ -0,0 +1,11 @@
+// { dg-do compile }
+
+template struct d {
+ template d(e);
+};
+template <> template d::d(e);
+template <> template d::d(e) {
+ long g;
+ (void)g;
+}
+template d::d(char);
--
Alexandre Oliva, freedom fighter https://FSFLA.org/blogs/lxo
Be the change, be Free! FSF Latin America board member
GNU Toolchain EngineerFree Software Evangelist
Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe
[PR86218] handle ck_aggr in compare_ics in both and either conversion
Because of rank compares, and checks for ck_list, we know that if we
see user_conv_p or ck_list in ics1, we'll also see it in ics2. This
reasoning does not extend to ck_aggr, however, so we might have
ck_aggr conversions starting both ics1 and ics2, which we handle
correctly, or either, which we likely handle by crashing on whatever
path we take depending on whether ck_aggr is in ics1 or ics2.
We crash because, as we search the conversion sequences, we may very
well fail to find what we are looking for, and reach the end of the
sequence, which is unexpected in all paths.
This patch arranges for us to take the same path when ck_aggr is in
ics2 only that we would if it was in ics1 (regardless of ics2), and it
deals with not finding the kind of conversion we look for there.
I've changed the type of the literal constant in the testcase, so as
to hopefully make it well-formed. We'd fail to reject the narrowing
conversion in the original testcase, but that's a separate bug.
Regstrapped on x86_64- and i686-linux-gnu. Ok to install?
for gcc/cp/ChangeLog
PR c++/86218
* call.c (compare_ics): Deal with ck_aggr in either cs.
for gcc/testsuite/ChangeLog
PR c++/86218
* g++.dg/cpp0x/pr86218.C: New.
---
gcc/cp/call.c|9 +
gcc/testsuite/g++.dg/cpp0x/pr86218.C | 11 +++
2 files changed, 16 insertions(+), 4 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/pr86218.C
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index c74d1b4ebdf60..7ae67004b9359 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -10033,21 +10033,22 @@ compare_ics (conversion *ics1, conversion *ics2)
Specifically, we need to do the reference binding comparison at the
end of this function. */
- if (ics1->user_conv_p || ics1->kind == ck_list || ics1->kind == ck_aggr)
+ if (ics1->user_conv_p || ics1->kind == ck_list
+ || ics1->kind == ck_aggr || ics2->kind == ck_aggr)
{
conversion *t1;
conversion *t2;
- for (t1 = ics1; t1->kind != ck_user; t1 = next_conversion (t1))
+ for (t1 = ics1; t1 && t1->kind != ck_user; t1 = next_conversion (t1))
if (t1->kind == ck_ambig || t1->kind == ck_aggr
|| t1->kind == ck_list)
break;
- for (t2 = ics2; t2->kind != ck_user; t2 = next_conversion (t2))
+ for (t2 = ics2; t2 && t2->kind != ck_user; t2 = next_conversion (t2))
if (t2->kind == ck_ambig || t2->kind == ck_aggr
|| t2->kind == ck_list)
break;
- if (t1->kind != t2->kind)
+ if (!t1 || !t2 || t1->kind != t2->kind)
return 0;
else if (t1->kind == ck_user)
{
diff --git a/gcc/testsuite/g++.dg/cpp0x/pr86218.C
b/gcc/testsuite/g++.dg/cpp0x/pr86218.C
new file mode 100644
index 0..9892ccde5be9c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/pr86218.C
@@ -0,0 +1,11 @@
+// { dg-do compile { target c++11 } }
+
+template
+void f (const char (&)[a]) { }
+void f (int) { }
+template
+void
+g ()
+{
+ f ({2u});
+}
Before getting to the simpler formulation above, I tried to model more
closely what's specified in the standard for braced initializer lists
used to initialize arrays and complex types, namely, to record the worst
conversion sequence in the ck_aggr conversion, and use that for
comparison purposes instead. It turned out to not be of much use,
because we already keep track of ranks and that's pretty much the only
relevant data for the compare, but I post it below, for the record, just
in case someone finds it useful.
[PR86218] save worst aggr conv in ck_aggr non-class conversions
---
gcc/cp/call.c | 29 ++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 7ae67004b9359..c6beda585327c 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -128,9 +128,14 @@ struct conversion {
variant is used only when KIN D is ck_list. */
conversion **list;
} u;
- /* The function candidate corresponding to this conversion
- sequence. This field is only used if KIND is ck_user. */
- struct z_candidate *cand;
+ union {
+/* The function candidate corresponding to this conversion
+ sequence. This field is only used if KIND is ck_user. */
+struct z_candidate *cand;
+/* The worst conversion sequence for the aggregate. This field is
+ onl used if KIND is ck_aggr. */
+conversion *aggr_worst;
+ };
};
#define CONVERSION_RANK(NODE) \
@@ -963,6 +968,7 @@ build_aggr_conv (tree type, tree ctor, int flags,
tsubst_flags_t complain)
c->user_conv_p = true;
c->check_narrowing = true;
c->u.next = NULL;
+ c->aggr_worst = NULL;
return c;
}
@@ -994,6 +1000,8 @@ build_array_conv (tree type, tree ctor, int flags,
tsubst_flags_t complain)
flags = LOOKUP_IMPLICIT|LOOKUP_NO_NARROWING;
+ conversion *worst = NULL;
+
FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (ctor), i, val)
Go patch committed: Support alias to pointer type as method receiver
This patch by Ben Shi to the Go frontend fixes it to support an aliases to a pointer type as a method receiver. This fixes https://golang.org/issue/28252. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. Ian Index: gcc/go/gofrontend/MERGE === --- gcc/go/gofrontend/MERGE (revision 268369) +++ gcc/go/gofrontend/MERGE (working copy) @@ -1,4 +1,4 @@ -5af8ee0693944c280b1f529450dbfd4ec1ee451d +2206f40fc1e0e1e2ba3eacb7388dd26b72729bde The first line of this file holds the git revision number of the last merge done from the gofrontend repository. Index: gcc/go/gofrontend/gogo.cc === --- gcc/go/gofrontend/gogo.cc (revision 268369) +++ gcc/go/gofrontend/gogo.cc (working copy) @@ -1944,6 +1944,10 @@ Gogo::start_function(const std::string& go_assert(at_top_level); Type* rtype = type->receiver()->type(); + while (rtype->named_type() != NULL +&& rtype->named_type()->is_alias()) + rtype = rtype->named_type()->real_type()->forwarded(); + // We want to look through the pointer created by the // parser, without getting an error if the type is not yet // defined.
Re: [PATCH, fortran] PR 52884 - double precision constants promoted to 16 byte by -fdefault-real-8
No objection, so committed as revision r268396 with the ChangeLog
2019-01-30 Dominique d'Humieres Le 27 janv. 2019 à 15:19, Dominique d'Humières a écrit :
>
> Hi,
>
> The following patch is an update of
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52884#c3,
> I am planning to commit with a suitable ChangeLog if there is no objection.
> Tested on darwin.
>
> TIA
>
> Dominique
>
> --- ../_clean/gcc/fortran/invoke.texi 2019-01-19 22:48:32.0 +0100
> +++ gcc/fortran/invoke.texi 2019-01-27 15:06:11.0 +0100
> @@ -416,36 +416,45 @@ kind declaration.
>
> @item -fdefault-real-8
> @opindex @code{fdefault-real-8}
> -Set the default real type to an 8 byte wide type. This option also affects
> -the kind of non-double real constants like @code{1.0}, and does promote
> -the default width of @code{DOUBLE PRECISION} to 16 bytes if possible, unless
> -@code{-fdefault-double-8} is given, too. Unlike @option{-freal-4-real-8},
> -it does not promote variables with explicit kind declaration.
> +Set the default real type to an 8 byte wide type. This option also affects
> +the kind of non-double real constants like @code{1.0}. This option promotes
> +the default width of @code{DOUBLE PRECISION} and double real constants
> +like @code{1.d0} to 16 bytes if possible. If @code{-fdefault-double-8}
> +is given along with @code{fdefault-real-8}, @code{DOUBLE PRECISION}
> +and double real constants are not promoted. Unlike @option{-freal-4-real-8},
> +@code{fdefault-real-8} does not promote variables with explicit kind
> +declarations.
>
> @item -fdefault-real-10
> @opindex @code{fdefault-real-10}
> -Set the default real type to a 10 byte wide type. This option also affects
> -the kind of non-double real constants like @code{1.0}, and does promote
> -the default width of @code{DOUBLE PRECISION} to 16 bytes if possible, unless
> -@code{-fdefault-double-8} is given. Unlike @option{-freal-4-real-10},
> -it does not promote variables with explicit kind declaration.
> +Set the default real type to an 10 byte wide type. This option also affects
> +the kind of non-double real constants like @code{1.0}. This option promotes
> +the default width of @code{DOUBLE PRECISION} and double real constants
> +like @code{1.d0} to 16 bytes if possible. If @code{-fdefault-double-8}
> +is given along with @code{fdefault-real-10}, @code{DOUBLE PRECISION}
> +and double real constants are not promoted. Unlike
> @option{-freal-4-real-10},
> +@code{fdefault-real-10} does not promote variables with explicit kind
> +declarations.
>
> @item -fdefault-real-16
> @opindex @code{fdefault-real-16}
> -Set the default real type to a 16 byte wide type. This option also affects
> -the kind of non-double real constants like @code{1.0}, and does promote
> -the default width of @code{DOUBLE PRECISION} to 16 bytes if possible, unless
> -@code{-fdefault-double-8} is given. Unlike @option{-freal-4-real-16},
> -it does not promote variables with explicit kind declaration.
> +Set the default real type to an 16 byte wide type. This option also affects
> +the kind of non-double real constants like @code{1.0}. This option promotes
> +the default width of @code{DOUBLE PRECISION} and double real constants
> +like @code{1.d0} to 16 bytes if possible. If @code{-fdefault-double-8}
> +is given along with @code{fdefault-real-16}, @code{DOUBLE PRECISION}
> +and double real constants are not promoted. Unlike
> @option{-freal-4-real-16},
> +@code{fdefault-real-16} does not promote variables with explicit kind
> +declarations.
>
> @item -fdefault-double-8
> @opindex @code{fdefault-double-8}
> -Set the @code{DOUBLE PRECISION} type to an 8 byte wide type. Do nothing if
> this
> -is already the default. If @option{-fdefault-real-8} is given,
> -@code{DOUBLE PRECISION} would instead be promoted to 16 bytes if possible,
> and
> -@option{-fdefault-double-8} can be used to prevent this. The kind of real
> -constants like @code{1.d0} will not be changed by @option{-fdefault-real-8}
> -though, so also @option{-fdefault-double-8} does not affect it.
> +Set the @code{DOUBLE PRECISION} type and double real constants
> +like @code{1.d0} to an 8 byte wide type. Do nothing if this
> +is already the default. This option prevents @option{-fdefault-real-8},
> +@option{-fdefault-real-10}, and @option{-fdefault-real-16},
> +from promoting @code{DOUBLE PRECISION} and double real constants like
> +@code{1.d0} to 16 bytes.
>
> @item -finteger-4-integer-8
> @opindex @code{finteger-4-integer-8}
>
Re: [PATCH][wwwdocs][Arm][AArch64] Update changes with new features and flags.
Hi Gerald, Yup that's fine :) I won't be able to commit it before Monday anyway. Cheers, Tamar From: Gerald Pfeifer Sent: Wednesday, January 30, 2019 3:37 PM To: James Greenhalgh Cc: Tamar Christina; gcc-patches@gcc.gnu.org; nd; Richard Earnshaw; Marcus Shawcroft; Ramana Radhakrishnan; ni...@redhat.com; Kyrylo Tkachov Subject: Re: [PATCH][wwwdocs][Arm][AArch64] Update changes with new features and flags. On Wed, 30 Jan 2019, James Greenhalgh wrote: > Otherwise OK, though I don't remember if that is for me to OK, or > someone else. Yes, it is. :-) (But I'll also have a look tonight if you want to wait for that Tamar, but that's only an offer. We can always iterate.) Gerald
Re: [PATCH][wwwdocs][Arm][AArch64] Update changes with new features and flags.
On Wed, 30 Jan 2019, James Greenhalgh wrote: > Otherwise OK, though I don't remember if that is for me to OK, or > someone else. Yes, it is. :-) (But I'll also have a look tonight if you want to wait for that Tamar, but that's only an offer. We can always iterate.) Gerald
Re: [PATCH][wwwdocs][Arm][AArch64] Update changes with new features and flags.
On 30/01/19 15:29, James Greenhalgh wrote: On Wed, Jan 23, 2019 at 04:43:02AM -0600, Tamar Christina wrote: > Hi All, > > This patch adds the documentation for Stack clash protection and Armv8.3-a support to > changes.html for GCC 9. > I have validated the html using the W3C validator. > > Ok for cvs? Almost OK by me. > > Thanks, > Tamar > > -- > Index: htdocs/gcc-9/changes.html > === > RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v > retrieving revision 1.35 > diff -u -r1.35 changes.html > --- htdocs/gcc-9/changes.html 15 Jan 2019 13:17:49 - 1.35 > +++ htdocs/gcc-9/changes.html 22 Jan 2019 11:16:07 - > @@ -214,6 +214,27 @@ > -mtune=cortex-a76.cortex-a55 or as arguments to the equivalent target > attributes and pragmas. > > + > +The AArch64 port now has support for stack clash protection using the > +-fstack-clash-protection option. The protection also works for > +SVE systems. The probing interval/guard size can be set by using I would drop this "also works" part. The option is just available for AArch64, SVE is a part of AArch64. Otherwise OK, though I don't remember if that is for me to OK, or someone else. Maintainers can approve the relevant wwwdocs parts. The arm parts LGTM FWIW. Kyrill Thanks, James > +--param stack-clash-protection-guard-size=12|16. > +The value of this parameter must be in bytes represented as a power of two. > +The only two supported values for this parameter are 12 and 16 being > +4Kb (2^12) and 64Kb (2^16) respectively. > + > +The default value is 16 (64Kb) and can be changed at configure > +time using the flag --with-stack-clash-protection-guard-size=12|16. > + > + > +The Armv8.3-A complex number instructions are now supported via intrinsics > +when the option -march=armv8.3-a or equivalent is specified. > +For the half-precision floating-point variants of these instructions use the > +architecture extension flag +fp16, e.g. > +-march=armv8.3-a+fp16. > + > +The intrinsics are defined by the ACLE specification. > + > > > ARC > @@ -250,6 +271,15 @@ > (which have no known implementations) has been removed. > Note that Armv5T, Armv5TE and Armv5TEJ architectures remain supported. > > + > +The Armv8.3-A complex number instructions are now supported via intrinsics > +when the option -march=armv8.3-a or equivalent is specified. > +For the half-precision floating-point variants of these instructions use the > +architecture extension flag +fp16, e.g. > +-march=armv8.3-a+fp16. > + > +The intrinsics are defined by the ACLE specification. > + > > > >
Re: [PATCH][wwwdocs][Arm][AArch64] Update changes with new features and flags.
On Wed, Jan 23, 2019 at 04:43:02AM -0600, Tamar Christina wrote: > Hi All, > > This patch adds the documentation for Stack clash protection and Armv8.3-a > support to > changes.html for GCC 9. > I have validated the html using the W3C validator. > > Ok for cvs? Almost OK by me. > > Thanks, > Tamar > > -- > Index: htdocs/gcc-9/changes.html > === > RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v > retrieving revision 1.35 > diff -u -r1.35 changes.html > --- htdocs/gcc-9/changes.html 15 Jan 2019 13:17:49 - 1.35 > +++ htdocs/gcc-9/changes.html 22 Jan 2019 11:16:07 - > @@ -214,6 +214,27 @@ > -mtune=cortex-a76.cortex-a55 or as arguments to the > equivalent target > attributes and pragmas. > > + > +The AArch64 port now has support for stack clash protection using the > +-fstack-clash-protection option. The protection also works > for > +SVE systems. The probing interval/guard size can be set by using I would drop this "also works" part. The option is just available for AArch64, SVE is a part of AArch64. Otherwise OK, though I don't remember if that is for me to OK, or someone else. Thanks, James > +--param stack-clash-protection-guard-size=12|16. > +The value of this parameter must be in bytes represented as a power of > two. > +The only two supported values for this parameter are 12 and 16 being > +4Kb (2^12) and 64Kb (2^16) respectively. > + > +The default value is 16 (64Kb) and can be changed at configure > +time using the flag > --with-stack-clash-protection-guard-size=12|16. > + > + > +The Armv8.3-A complex number instructions are now supported via > intrinsics > +when the option -march=armv8.3-a or equivalent is specified. > +For the half-precision floating-point variants of these instructions use > the > +architecture extension flag +fp16, e.g. > +-march=armv8.3-a+fp16. > + > +The intrinsics are defined by the ACLE specification. > + > > > ARC > @@ -250,6 +271,15 @@ > (which have no known implementations) has been removed. > Note that Armv5T, Armv5TE and Armv5TEJ architectures remain supported. > > + > +The Armv8.3-A complex number instructions are now supported via > intrinsics > +when the option -march=armv8.3-a or equivalent is specified. > +For the half-precision floating-point variants of these instructions use > the > +architecture extension flag +fp16, e.g. > +-march=armv8.3-a+fp16. > + > +The intrinsics are defined by the ACLE specification. > + > > > >
Re: testsuite dg-directives glitches
> Le 28 janv. 2019 à 14:54, Manfred Schwarb a écrit :
>
> Am 26.01.2019 um 16:14 schrieb Dominique d'Humières:
>> I have committed the following patch to the gcc-7-branch as r268294 after a
>> regtest.
>> Manfred, could you please check with your script that I did not miss
>> some test in the gcc-7 and gcc-8 branches?
>
> In the GCC-7 branch, there is
> ./pr68318_1.f90:2:! { dg-options "-O0 »
Committed as r268393
>
> and in the GCC-8 branch I found
> ./newunit_5.f90.f90:1:! { dg-do run )
Fixed and renamed to newunit_5.f90 at r268389.
Thanks, Dominique
>
> Thanks,
> Manfred
Re: Default compute dimensions
Hi!
On Thu, 28 Jan 2016 10:38:51 -0500, Nathan Sidwell wrote:
> This patch adds default compute dimension handling. [...]
> --- gcc/doc/invoke.texi (revision 232881)
> +++ gcc/doc/invoke.texi (working copy)
> @@ -1963,9 +1963,13 @@ Programming Interface v2.0 @w{@uref{http
> implies @option{-pthread}, and thus is only supported on targets that
> have support for @option{-pthread}.
>
> -[...]
> +@item -fopenacc-dim=@var{geom}
> +@opindex fopenacc-dim
> +@cindex OpenACC accelerator programming
> +Specify default compute dimensions [...]
Committed the attached to trunk in r268390, and backported to
openacc-gcc-8-branch in commit de9b72da74a00ab72268f6d99e5ef09693383291.
Grüße
Thomas
>From 915cfb823edbaf3203c2b9348f359cb3a4e004ea Mon Sep 17 00:00:00 2001
From: tschwinge
Date: Wed, 30 Jan 2019 14:40:10 +
Subject: [PATCH] Default compute dimensions: list "-fopenacc-dim" in
documentation
gcc/
* doc/invoke.texi (C Language Options): List "-fopenacc-dim".
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@268390 138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/ChangeLog | 4
gcc/doc/invoke.texi | 4 +++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 4962f473501..3b59dad778d 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,7 @@
+2019-01-30 Thomas Schwinge
+
+ * doc/invoke.texi (C Language Options): List "-fopenacc-dim".
+
2019-01-30 Richard Biener
PR tree-optimization/89111
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 580b48e1eb8..c625350d04d 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -197,7 +197,9 @@ in the following sections.
-fpermitted-flt-eval-methods=@var{standard} @gol
-aux-info @var{filename} -fallow-parameterless-variadic-functions @gol
-fno-asm -fno-builtin -fno-builtin-@var{function} -fgimple@gol
--fhosted -ffreestanding -fopenacc -fopenmp -fopenmp-simd @gol
+-fhosted -ffreestanding @gol
+-fopenacc -fopenacc-dim=@var{geom} @gol
+-fopenmp -fopenmp-simd @gol
-fms-extensions -fplan9-extensions -fsso-struct=@var{endianness} @gol
-fallow-single-precision -fcond-mismatch -flax-vector-conversions @gol
-fsigned-bitfields -fsigned-char @gol
--
2.17.1
From de9b72da74a00ab72268f6d99e5ef09693383291 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Wed, 30 Jan 2019 15:42:27 +0100
Subject: [PATCH] Default compute dimensions: list "-fopenacc-dim" in
documentation
gcc/
* doc/invoke.texi (C Language Options): List "-fopenacc-dim".
trunk r268390
---
gcc/ChangeLog.openacc | 4
gcc/doc/invoke.texi | 4 +++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/gcc/ChangeLog.openacc b/gcc/ChangeLog.openacc
index db4f4f0b8e8..744cf02e51a 100644
--- a/gcc/ChangeLog.openacc
+++ b/gcc/ChangeLog.openacc
@@ -1,3 +1,7 @@
+2019-01-30 Thomas Schwinge
+
+ * doc/invoke.texi (C Language Options): List "-fopenacc-dim".
+
2019-01-29 Gergö Barany
* omp-low.c (check_oacc_kernel_gwv): Remove spurious error message.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 085a87122a3..59421b84bac 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -182,7 +182,9 @@ in the following sections.
-fpermitted-flt-eval-methods=@var{standard} @gol
-aux-info @var{filename} -fallow-parameterless-variadic-functions @gol
-fno-asm -fno-builtin -fno-builtin-@var{function} -fgimple@gol
--fhosted -ffreestanding -fopenacc -fopenmp -fopenmp-simd @gol
+-fhosted -ffreestanding @gol
+-fopenacc -fopenacc-dim=@var{geom} @gol
+-fopenmp -fopenmp-simd @gol
-fms-extensions -fplan9-extensions -fsso-struct=@var{endianness} @gol
-fallow-single-precision -fcond-mismatch -flax-vector-conversions @gol
-fsigned-bitfields -fsigned-char @gol
--
2.17.1
Re: [PATCH][GCC][AArch64] Have empty HWCAPs string ignored during native feature detection
Hi Jakub, On Wed, Jan 30, 2019 at 02:06:01PM +, Tamar Christina wrote: > > Thanks for the feedback, but I think those are changes for another patch. > > At least the memory leak is something that should be fixed even in stage4 > IMNSHO. I'll provide a separate patch for this then. > Anyway, will defer to aarch64 maintainers here. > Just one question, for the *feat_string == '\0' case, is continue what you > want, rather than just enabled = false; and doing the > extension_flags &= ~(aarch64_extensions[i].flag); > later on? Yeah, because the feature may be on by default due to another extension, in which case you would erroneously turn it off. The absence of an HWCAPS shouldn't pro-actively disable an extension. Regards, Tamar
Re: [PATCH] doc: showcase a "union of vectors" pattern (PR 88698)
On Mon, 21 Jan 2019, Alexander Monakov wrote:
> Ah, I see now. I agree transparent_union ought to work, but today both GCC
> and Clang will reject such attempt; I've filed PR 88955 for the GCC issue.
>
> So unfortunately such code would still need a cast or an unnamed temporary,
> which may be relatively obvious to the reader.
In the end it may be preferable to have it anyway, so here's a revised version
with an extra line in the example for passing arguments via compound literals.
Checked with 'make html', OK to apply?
PR c/88698
* doc/extend.texi (Vector Extensions): Add an example of using vector
types together with x86 intrinsics.
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 95d22ac1e3c..34a76927b12 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -10632,6 +10632,47 @@ v4si g = __builtin_convertvector (f, v4si); /* g is
@{1,-2,3,7@} */
v4si h = __builtin_convertvector (c, v4si); /* h is @{1,5,0,10@} */
@end smallexample
+@cindex vector types, using with x86 intrinsics
+Sometimes it is desirable to write code using a mix of generic vector
+operations (for clarity) and machine-specific vector intrinsics (to
+access vector instructions that are not exposed via generic built-ins).
+On x86, intrinsic functions for integer vectors typically use the same
+vector type @code{__m128i} irrespective of how they interpret the vector,
+making it necessary to cast their arguments and return values from/to
+other vector types. In C, you can make use of a @code{union} type:
+@c In C++ such type punning via a union is not allowed by the language
+@smallexample
+#include
+
+typedef unsigned char u8x16 __attribute__ ((vector_size (16)));
+typedef unsigned int u32x4 __attribute__ ((vector_size (16)));
+
+typedef union @{
+__m128i mm;
+u8x16 u8;
+u32x4 u32;
+@} v128;
+@end smallexample
+
+@noindent
+for variables that can be used with both built-in operators and x86
+intrinsics:
+
+@smallexample
+v128 x, y = @{ 0 @};
+memcpy (, ptr, sizeof x);
+y.u8 += 0x80;
+x.mm = _mm_adds_epu8 (x.mm, y.mm);
+x.u32 &= 0xff;
+
+/* Instead of a variable, a compound literal may be used to pass the
+ return value of an intrinsic call to a function expecting the union: */
+v128 foo (v128);
+x = foo ((v128) @{_mm_adds_epu8 (x.mm, y.mm)@});
+@c This could be done implicitly with __attribute__((transparent_union)),
+@c but GCC does not accept it for unions of vector types (PR 88955).
+@end smallexample
+
@node Offsetof
@section Support for @code{offsetof}
@findex __builtin_offsetof
Re: [gomp4] backport firstprivate subarray changes
Hi!
On Fri, 27 May 2016 08:19:56 -0700, Cesar Philippidis
wrote:
> This patch backports the recent firstprivate subarray changes I've made
> [...]
> Thomas, I decided to xfail a bunch of kernels tests in gomp4 instead of
> removing them so that we can have a better record on what changed. [...]
The version of this patch as it is still present on openacc-gcc-8-branch
(commit 629dfb8f365caa5e8a7437459954988c60213ba0 "[OpenACC] firstprivate
subarray changes"), still does "XFAIL" the following two test cases:
> --- a/libgomp/testsuite/libgomp.oacc-c-c++-common/kernels-loop-and-seq-3.c
> +++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/kernels-loop-and-seq-3.c
> @@ -1,3 +1,7 @@
> +/* FIXME: OpenACC kernels stopped working with the firstprivate subarray
> + changes. */
> +/* { dg-prune-output "OpenACC kernels construct will be executed
> sequentially" } */
> --- a/libgomp/testsuite/libgomp.oacc-c-c++-common/kernels-loop-and-seq-4.c
> +++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/kernels-loop-and-seq-4.c
> @@ -1,3 +1,7 @@
> +/* FIXME: OpenACC kernels stopped working with the firstprivate subarray
> + changes. */
> +/* { dg-prune-output "OpenACC kernels construct will be executed
> sequentially" } */
I wrote "XFAIL" in quotes, because a "dg-prune-output" is not an "XFAIL",
because this can't ever turn into an "XPASS" -- which apparently would've
happened at some point: I've now pushed the attached to
openacc-gcc-8-branch.
Grüße
Thomas
From 1175533405fb2c08b2930288c30f58522ce449a6 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Tue, 29 Jan 2019 20:34:35 +0100
Subject: [PATCH] [OpenACC] firstprivate subarray changes: remove "XFAIL"s
Don't know, though, which change restored the expected "parloops" processing.
libgomp/
* testsuite/libgomp.oacc-c-c++-common/kernels-loop-and-seq-3.c:
Remove "dg-prune-output".
* testsuite/libgomp.oacc-c-c++-common/kernels-loop-and-seq-4.c:
Likewise.
---
libgomp/ChangeLog.openacc | 7 +++
.../libgomp.oacc-c-c++-common/kernels-loop-and-seq-3.c | 4
.../libgomp.oacc-c-c++-common/kernels-loop-and-seq-4.c | 4
3 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/libgomp/ChangeLog.openacc b/libgomp/ChangeLog.openacc
index cfccb835591..0387013d232 100644
--- a/libgomp/ChangeLog.openacc
+++ b/libgomp/ChangeLog.openacc
@@ -1,3 +1,10 @@
+2019-01-30 Thomas Schwinge
+
+ * testsuite/libgomp.oacc-c-c++-common/kernels-loop-and-seq-3.c:
+ Remove "dg-prune-output".
+ * testsuite/libgomp.oacc-c-c++-common/kernels-loop-and-seq-4.c:
+ Likewise.
+
2019-01-29 Gergö Barany
* testsuite/libgomp.oacc-fortran/initialize_kernels_loops.f90: New test.
diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/kernels-loop-and-seq-3.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/kernels-loop-and-seq-3.c
index d0ea230a805..e62297129fd 100644
--- a/libgomp/testsuite/libgomp.oacc-c-c++-common/kernels-loop-and-seq-3.c
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/kernels-loop-and-seq-3.c
@@ -1,7 +1,3 @@
-/* FIXME: OpenACC kernels stopped working with the firstprivate subarray
- changes. */
-/* { dg-prune-output "OpenACC kernels construct will be executed sequentially" } */
-
#include
#define N 32
diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/kernels-loop-and-seq-4.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/kernels-loop-and-seq-4.c
index 4017560d0a1..c73127897a9 100644
--- a/libgomp/testsuite/libgomp.oacc-c-c++-common/kernels-loop-and-seq-4.c
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/kernels-loop-and-seq-4.c
@@ -1,7 +1,3 @@
-/* FIXME: OpenACC kernels stopped working with the firstprivate subarray
- changes. */
-/* { dg-prune-output "OpenACC kernels construct will be executed sequentially" } */
-
#include
#define N 32
--
2.17.1
Re: [PATCH] Fix compile-time of PR89115
On 01/30/2019 07:45 AM, Richard Biener wrote: The PR89115 spends ~66% of its compile-time in LRA reload inheritance because of a weak hash and a lot of collisions in the invaraints hash. This can be fixed by the following, bringing down inheritance time to the noise. Bootstrap / regtest running on x86_64-unknown-linux-gnu, OK for trunk (and branches?)? Yes, sure. Thank you, Richard. The hash function is still weak but w/o a testcase I don't think it's worth slowing it down further. Thanks, Richard. 2019-01-30 Richard Biener PR rtl-optimization/89115 * lra.c (lra_rtx_hash): Properly hash CONST_INT values. Index: gcc/lra.c === --- gcc/lra.c (revision 268383) +++ gcc/lra.c (working copy) @@ -1719,10 +1719,12 @@ lra_rtx_hash (rtx x) case SCRATCH: case CONST_DOUBLE: -case CONST_INT: case CONST_VECTOR: return val; +case CONST_INT: + return val + UINTVAL (x); + default: break; }
Re: [PATCH][GCC][AArch64] Have empty HWCAPs string ignored during native feature detection
On Wed, Jan 30, 2019 at 02:06:01PM +, Tamar Christina wrote: > Thanks for the feedback, but I think those are changes for another patch. At least the memory leak is something that should be fixed even in stage4 IMNSHO. Anyway, will defer to aarch64 maintainers here. Just one question, for the *feat_string == '\0' case, is continue what you want, rather than just enabled = false; and doing the extension_flags &= ~(aarch64_extensions[i].flag); later on? Jakub
[PATCH] Add simplification rule tanh (x) * cosh (x) -> sinh (x)
This patch simplifies the function tanh (x) * cosh (x) -> sinh (x).
This rule is derived from the relationship between hyperbolic
functions.
I ran the tests and gfortran.dg/pr79966.f90 failed, but this failure
is unrelated to the patch (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88711 for more
information). My architecture is x86_64.
gcc/ChangeLog:
2019-01-30 Bárbara Fernandes
* match.pd (tanh (x) * cosh (x)): New simplification rule.
gcc/testsuite/ChangeLog:
2019-01-30 Bárbara Fernandes
* tanhtimescosh.c: New test.
Index: gcc/match.pd
===
--- gcc/match.pd (revision 268384)
+++ gcc/match.pd (working copy)
@@ -4545,6 +4545,11 @@
&& ! HONOR_INFINITIES (@0))
(rdiv { build_one_cst (type); } (COS @0
+ /* Simplify tanh (x) * cosh (x) -> sinh (x). */
+ (simplify
+ (mult:c (TANH:s @0) (COSH:s @0))
+ (SINH @0))
+
/* Simplify pow(x,y) * pow(x,z) -> pow(x,y+z). */
(simplify
(mult (POW:s @0 @1) (POW:s @0 @2))
Index: gcc/testsuite/gcc.dg/tanhtimescosh.c
===
--- gcc/testsuite/gcc.dg/tanhtimescosh.c (nonexistent)
+++ gcc/testsuite/gcc.dg/tanhtimescosh.c (working copy)
@@ -0,0 +1,38 @@
+/* { dg-do compile } */
+/* { dg-options "-Ofast -fdump-tree-optimized" } */
+
+extern float coshf (float);
+extern float tanhf (float);
+extern double cosh (double);
+extern double tanh (double);
+extern long double coshl (long double);
+extern long double tanhl (long double);
+
+double __attribute__ ((noinline))
+sinh_ (double x)
+{
+return tanh (x) * cosh (x);
+}
+
+float __attribute__ ((noinline))
+sinhf_(float x)
+{
+return tanhf (x) * coshf (x);
+}
+
+long double __attribute__ ((noinline))
+sinhl_ (long double x)
+{
+return tanhl (x) * coshl (x);
+}
+
+/* There must be no calls to cosh, or tanh */
+/* {dg-final { scan-tree-dump-not "cosh " "optimized" } } */
+/* {dg-final { scan-tree-dump-not "tanh " "optimized" }} */
+/* {dg-final { scan-tree-dump-not "coshf " "optimized" } } */
+/* {dg-final { scan-tree-dump-not "tanhf " "optimized" }} */
+/* {dg-final { scan-tree-dump-not "coshl " "optimized" } } */
+/* {dg-final { scan-tree-dump-not "tanhl " "optimized" }} */
+/* {dg-final { scan-tree-dump-times "sinh " "1" "optimized" }} */
+/* {dg-final { scan-tree-dump-times "sinhf " "1" "optimized" }} */
+/* {dg-final { scan-tree-dump-times "sinhl " "1" "optimized" }} */
Re: [PATCH][GCC][AArch64] Have empty HWCAPs string ignored during native feature detection
Hi Jakub,
Thanks for the feedback, but I think those are changes for another patch.
The patch here does not introduce the problems you highlighted and I don't feel
these changes are appropriate for stage4 or that they should block this patch.
Kind regards,
Tamar
From: Jakub Jelinek
Sent: Wednesday, January 23, 2019 4:27:40 PM
To: Kyrill Tkachov
Cc: Tamar Christina; gcc-patches@gcc.gnu.org; nd; James Greenhalgh; Richard
Earnshaw; Marcus Shawcroft
Subject: Re: [PATCH][GCC][AArch64] Have empty HWCAPs string ignored during
native feature detection
On Thu, Jan 10, 2019 at 04:57:47PM +, Kyrill Tkachov wrote:
> --- a/gcc/config/aarch64/driver-aarch64.c
> +++ b/gcc/config/aarch64/driver-aarch64.c
> @@ -253,6 +253,12 @@ host_detect_local_cpu (int argc, const char **argv)
> char *p = NULL;
> char *feat_string
> = concat (aarch64_extensions[i].feat_string, NULL);
> +
> + /* If the feature contains no HWCAPS string then ignore it for the
> + auto detection. */
> + if (strlen (feat_string) == 0)
> + continue;
>
> I think this can avoid a strlen call by checking (*feat_string == '\0')
> though I believe most compilers will optimise it that way anyway.
> It might be more immediately readable your way.
> I wouldn't let it hold off this patch.
Well, that isn't the only problem of this code.
Another one is that concat (str, NULL) is much better written as xstrdup (str);
Another one is that the if (*feat_string == '\0') check
should be probably if (aarch64_extensions[i].feat_string[0] == '\0')
before the xstrdup, because there is no point to allocate the memory
in that case.
Another one is that it leaks the feat_string (right now always, otherwise
if it isn't empty).
Another one, I wonder if the xstrdup + strtok isn't a too heavy hammer for
something so simple, especially when you have complete control over those
feature strings. They use exactly one space to separate.
So just do
const char *p = aarch64_extensions[i].feat_string;
bool enabled = true;
/* If the feature contains no HWCAPS string then ignore it for the
auto detection. */
if (*p == '\0')
continue;
size_t len = strlen (buf);
do
{
const char *end = strchr (p, ' ');
if (end == NULL)
end = strchr (p, '\0');
if (memmem (buf, len, p, end - p) == NULL)
{
/* Failed to match this token. Turn off the
features we'd otherwise enable. */
enabled = false;
break;
}
if (*end == '\0')
break;
p = end + 1;
}
while (1);
if (enabled)
extension_flags |= aarch64_extensions[i].flag;
else
extension_flags &= ~(aarch64_extensions[i].flag);
?
Last thing, for not_found, there is:
return "";, why not return NULL; ? That is what other detect cpu routines
do, returning "" means a confusion between when a heap allocated string is
returned that needs freeing and when a .rodata string is returned which
doesn't.
Jakub
Re: [PATCH][GCC][AArch64] Fix command line options canonicalization. (PR target/88530)
Ping. From: gcc-patches-ow...@gcc.gnu.org on behalf of Tamar Christina Sent: Tuesday, January 15, 2019 5:12:46 PM To: Kyrill Tkachov Cc: gcc-patches@gcc.gnu.org; nd; James Greenhalgh; Richard Earnshaw; Marcus Shawcroft Subject: Re: [PATCH][GCC][AArch64] Fix command line options canonicalization. (PR target/88530) Hi Kyrill, Thanks for the review, I have respun the patch on top of trunk and here is the new changelog to account for the updates of the new extensions. Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. Ok for trunk? Thanks, Tamar gcc/ChangeLog: 2019-01-15 Tamar Christina PR target/88530 * common/config/aarch64/aarch64-common.c (struct aarch64_option_extension): Add is_synthetic. (all_extensions): Use it. (TARGET_OPTION_INIT_STRUCT): Define hook. (struct gcc_targetm_common): Moved to end. (all_extensions_by_on): New. (opt_ext_cmp, typedef opt_ext): New. (aarch64_option_init_struct): New. (aarch64_contains_opt): New. (aarch64_get_extension_string_for_isa_flags): Output smallest set. * config/aarch64/aarch64-option-extensions.def (AARCH64_OPT_EXTENSION): Explicitly include AES and SHA2 in crypto. (fp, simd, crc, lse, fp16, rcpc, rdma, dotprod, aes, sha2, sha3, sm4, fp16fml, sve, profile, rng, memtag, sb, ssbs, predres): Set is_synthetic to false. (crypto): Set is_synthetic to true. gcc/testsuite/ChangeLog: 2019-01-15 Tamar Christina PR target/88530 * gcc.target/aarch64/options_set_1.c: New test. * gcc.target/aarch64/options_set_2.c: New test. * gcc.target/aarch64/options_set_3.c: New test. * gcc.target/aarch64/options_set_4.c: New test. * gcc.target/aarch64/options_set_5.c: New test. * gcc.target/aarch64/options_set_6.c: New test. * gcc.target/aarch64/options_set_7.c: New test. * gcc.target/aarch64/options_set_8.c: New test. * gcc.target/aarch64/options_set_9.c: New test. The 01/10/2019 17:15, Kyrill Tkachov wrote: > Hi Tamar, > > On 17/12/18 19:18, Tamar Christina wrote: > > Hi All, > > > > The options don't seem to get canonicalized into the smallest possible set > > before output to the assembler. This means that overlapping feature sets are > > emitted with superfluous parts. > > > > Normally this isn't an issue, but in the case of crypto we have > > retro-actively > > split it into aes and sha2. We need to emit only +crypto to the assembler > > so old assemblers continue to work. > > > > Because of how -mcpu=native and -march=native work they end up enabling all > > feature > > bits, so we need to get the smallest possible set, which would also fix the > > problem with older the assemblers and the retro-active split. > > > > Admittedly this should be done earlier in options processing, but the > > problem > > with the way AArch64 currently processes options is that where the isa_bits > > are > > determined we don't know which options are part of the default set yet. > > > > Which is why we instead do it late in processing when we have all the > > information. This however requires us to make a duplicate of the extensions > > list. > > > > The Option handling structures have been extended to have a boolean to > > indicate > > whether the option is synthetic, with that I mean if the option flag itself > > has a bit. > > > > e.g. +crypto isn't an actual bit, it just enables other bits, but other > > features flags > > like +rdma also enable multiple options but are themselves also a feature. > > > > There are two ways to solve this. > > > > 1) Either have the options that are feature bits also turn themselves on, > > e.g. change > >rdma to turn on FP, SIMD and RDMA as dependency bits. > > 2) Make a distinction between these two different type of features and have > > the framework > >handle it correctly. > > > > Even though it's more code I went for the second approach, as it's the one > > that'll be less > > fragile and give the least surprises. > > > > This is a stop-gap measure that's has the lowest impact and is > > back-portable. > > > > Effectively this patch changes the following: > > > > The values before the => are the old compiler and after the => the new code. > > > > -march=armv8.2-a+crypto+sha2 => -march=armv8.2-a+crypto > > -march=armv8.2-a+sha2+aes => -march=armv8.2-a+crypto > > > > The remaining behaviors stay the same. > > > > > > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > > > > Ok for trunk? > > > > This will need rebasing over the Armv8.5-A patches as there are new entries > in config/aarch64/aarch64-option-extensions.def. > Since this has to be done anyway, I've also pointed out a few comment typos > inline. > > Apart from that, the patch looks good to me (this is a subtle area of GCC). > > Thanks, > Kyrill > > > > Thanks, > > Tamar > > >
Re: [PATCH][wwwdocs][Arm][AArch64] Update changes with new features and flags.
Ping. From: gcc-patches-ow...@gcc.gnu.org on behalf of Tamar Christina Sent: Wednesday, January 23, 2019 10:43:02 AM To: gcc-patches@gcc.gnu.org Cc: nd; James Greenhalgh; Richard Earnshaw; Marcus Shawcroft; Ramana Radhakrishnan; ni...@redhat.com; Kyrylo Tkachov; ger...@pfeifer.com Subject: [PATCH][wwwdocs][Arm][AArch64] Update changes with new features and flags. Hi All, This patch adds the documentation for Stack clash protection and Armv8.3-a support to changes.html for GCC 9. I have validated the html using the W3C validator. Ok for cvs? Thanks, Tamar --
[PATCH] Fix PR89115
The following works around the DSE part of PR89115, consuming huge amounts of memory and compile-time. To make "bad" testcases behave more reasonably the following cuts down --param max-dse-active-local-stores from 5000 to 500, reducing compile-time by a factor of 2.5 and memory use by a factor of 5.3. I'm making both existing scalings relative to the default (but keep the actual scaled down value). Bootstrap & regtest running on x86_64-unknown-linux-gnu. Richard. 2019-01-30 Richard Biener PR rtl-optimization/89115 * opts.c (default_options_optimization): Reduce PARAM_MAX_DSE_ACTIVE_LOCAL_STORES by a factor of 10 at -O1. Make PARAM_LOOP_INVARIANT_MAX_BBS_IN_LOOP reduction relative to the default. Index: gcc/opts.c === --- gcc/opts.c (revision 268383) +++ gcc/opts.c (working copy) @@ -670,7 +670,16 @@ default_options_optimization (struct gcc /* For -O1 only do loop invariant motion for very small loops. */ maybe_set_param_value (PARAM_LOOP_INVARIANT_MAX_BBS_IN_LOOP, - opt2 ? default_param_value (PARAM_LOOP_INVARIANT_MAX_BBS_IN_LOOP) : 1000, + opt2 ? default_param_value (PARAM_LOOP_INVARIANT_MAX_BBS_IN_LOOP) + : default_param_value (PARAM_LOOP_INVARIANT_MAX_BBS_IN_LOOP) / 10, + opts->x_param_values, opts_set->x_param_values); + + /* For -O1 reduce the maximum number of active local stores for RTL DSE + since this can consume huge amounts of memory (PR89115). */ + maybe_set_param_value +(PARAM_MAX_DSE_ACTIVE_LOCAL_STORES, + opt2 ? default_param_value (PARAM_MAX_DSE_ACTIVE_LOCAL_STORES) + : default_param_value (PARAM_MAX_DSE_ACTIVE_LOCAL_STORES) / 10, opts->x_param_values, opts_set->x_param_values); /* At -Ofast, allow store motion to introduce potential race conditions. */
Re: [Patch][Aarch64]PR rtl-optimization/87763 - Fix lsl_asr_sbfiz.c test by checking for subregs
Hi, Segher wrote: >On Tue, Jan 29, 2019 at 02:51:30PM -0800, Andrew Pinski wrote: > >> Seems to me rather this should have been simplified to just: >> (set (reg:SI 93) >> (ashift:SI (sign_extract:SI (reg:SI 95) >> (const_int 3 [0x3]) >> (const_int 0 [0])) >> (const_int 19 [0x13]))) > > Yes. > Because the two subreg cancel each other out. > Well, why did it ever think of using DI at all? I looked at this last week - the underlying issue is due to using extv optab without a mode. This then defaults to DI mode only. There is a newer extv optab, and using that to enable zero/sign_extract for SImode fixes this particular issue. However this triggers a bug in expmed using SI->HF lvalue-subregs which isn't legal. Unfortunately generated code after the change ends up worse overall, so it's not clear how to fix this. >> This would be a thing to add to simplify-rtx.c. > > This is probably specific to combine actually. Simplifying the subreg still won't allow the pattern to match since we don't enable sign_extract for SImode. Cheers, Wilco
[PATCH] Fix compile-time of PR89115
The PR89115 spends ~66% of its compile-time in LRA reload inheritance because of a weak hash and a lot of collisions in the invaraints hash. This can be fixed by the following, bringing down inheritance time to the noise. Bootstrap / regtest running on x86_64-unknown-linux-gnu, OK for trunk (and branches?)? The hash function is still weak but w/o a testcase I don't think it's worth slowing it down further. Thanks, Richard. 2019-01-30 Richard Biener PR rtl-optimization/89115 * lra.c (lra_rtx_hash): Properly hash CONST_INT values. Index: gcc/lra.c === --- gcc/lra.c (revision 268383) +++ gcc/lra.c (working copy) @@ -1719,10 +1719,12 @@ lra_rtx_hash (rtx x) case SCRATCH: case CONST_DOUBLE: -case CONST_INT: case CONST_VECTOR: return val; +case CONST_INT: + return val + UINTVAL (x); + default: break; }
Re: [patch][pr88920] Fix noisy check_effective_target_offload_gcn
On 29/01/2019 11:31, Richard Biener wrote: OK. Thanks. Patch committed. Andrew
Re: [PATCH, fortran ieee]: Clear stalled interrupt flags in glibc set_fpu_trap_exceptions
On Tue, Jan 29, 2019 at 9:20 PM Steve Kargl wrote: > > On Tue, Jan 29, 2019 at 08:46:40PM +0100, Uros Bizjak wrote: > > > > When changing trap masks, it is necessary to clear pending traps to > > prevent firing spurious interrupts. Attached patch also optimizes > > set_fpu_trap_exceptions function considerably to only call > > feenableexcept and fedisableexcept functions each once. > > > > 2019-01-29 Uroš Bizjak > > s/Uro/Uros ? No, the original is correct. It is probably your mailer skipping non-ascii characters. > > * config/fpu-glibc.h (set_fpu_trap_exceptions): Clear stalled > > exception flags before changing trap mode. Optimize to call > > feenableexcept and fedisableexcept only once. > > > > Patch was bootstrapped and regression tested on alphaev68-linux-gnu, > > where it fixes gfortran.dg/ieee/ieee_10.f90 failures. > > > > OK for mainline? > > > > Uros, > > Your decription suggests that this fixes PR fortran/88678. > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88678 Actually, additional patch is needed to fully fix PR88678. support_fpu_trap enables and disables exceptions and this may fire spurious exceptions. Just assume that all supported flags can generate exceptions, as is done in the additional patch, posted to PR88678. Uros. > I managed to identify that the issue was traceable to fpu-glibc.h, > but I got stuck going any further. > > In any event, the patch looks good to me. > > Thanks. > > -- > steve
[PATCH] Fix PR89111
I am testing the following patch to restrict MEM canonicalization
in LIM further.
Bootstrap and regtest running on x86_64-unkown-linux-gnu.
Richard.
2019-01-30 Richard Biener
PR tree-optimization/89111
* tree-ssa-loop-im.c (gather_mem_refs_stmt): Restrict
canonicalization to appropriately sized access types.
* gcc.dg/torture/pr89111.c: New testcase.
Index: gcc/tree-ssa-loop-im.c
===
--- gcc/tree-ssa-loop-im.c (revision 268383)
+++ gcc/tree-ssa-loop-im.c (working copy)
@@ -1472,6 +1472,11 @@ gather_mem_refs_stmt (struct loop *loop,
&& aor.max_size.is_constant (_size)
&& size == max_size
&& (size % BITS_PER_UNIT) == 0
+ /* We're canonicalizing to a MEM where TYPE_SIZE specifies the
+size. Make sure this is consistent with the extraction. */
+ && poly_int_tree_p (TYPE_SIZE (TREE_TYPE (*mem)))
+ && known_eq (wi::to_poly_offset (TYPE_SIZE (TREE_TYPE (*mem))),
+ aor.size)
&& (mem_base = get_addr_base_and_unit_offset (aor.ref, _off)))
{
hash = iterative_hash_expr (ao_ref_base (), 0);
Index: gcc/testsuite/gcc.dg/torture/pr89111.c
===
--- gcc/testsuite/gcc.dg/torture/pr89111.c (nonexistent)
+++ gcc/testsuite/gcc.dg/torture/pr89111.c (working copy)
@@ -0,0 +1,30 @@
+/* { dg-do run } */
+/* { dg-require-effective-target int32plus } */
+
+struct __attribute__((packed)) A { int b : 24; } c[243], f;
+
+int d, e, g, j;
+
+__attribute__((noipa)) int
+foo (int x)
+{
+ if (x != 0)
+__builtin_abort ();
+ return 2;
+}
+
+int
+main ()
+{
+ struct A h = f;
+ h.b = 0;
+ while (e++ < 3)
+{
+ while (d++ < 3)
+ c[46].b ^= 9890739;
+ f = c[46] = h;
+}
+ while (g++ < 9)
+j = foo (c[g * 9 + j].b);
+ return 0;
+}
