Re: [C++ PATCH] Fix cxx_eval_store_expression (PR c++/89336)
On Tue, Feb 19, 2019 at 11:03:05PM +0100, Jakub Jelinek wrote:
> > Before P0137 I believe foo and bar were arguably undefined.
>
> I see, before that it was:
> "an lvalue-to-rvalue conversion (4.1) or modification (5.18, 5.2.6, 5.3.2)
> that is applied
> to a glvalue that refers to a non-active member of a union or a subobject
> thereof;"
>
> So, do we want something like this then (or free all vectors immediately
> there and return immediately)?
Bootstrapped/regtested now on x86_64-linux and i686-linux.
> 2019-02-19 Jakub Jelinek
>
> PR c++/89336
> * constexpr.c (cxx_eval_store_expression): Diagnose changing of active
> union member for -std=c++17 and earlier.
>
> * g++.dg/cpp1y/constexpr-89336-3.C: New test.
>
> --- gcc/cp/constexpr.c.jj 2019-02-19 10:26:09.567962395 +0100
> +++ gcc/cp/constexpr.c2019-02-19 22:53:45.702983814 +0100
> @@ -3890,8 +3890,20 @@ cxx_eval_store_expression (const constex
>
> if (code == UNION_TYPE && CONSTRUCTOR_NELTS (*valp)
> && CONSTRUCTOR_ELT (*valp, 0)->index != index)
> - /* Changing active member. */
> - vec_safe_truncate (CONSTRUCTOR_ELTS (*valp), 0);
> + {
> + if (cxx_dialect < cxx2a)
> + {
> + if (!ctx->quiet)
> + error_at (cp_expr_loc_or_loc (t, input_location),
> + "change of the active member of a union "
> + "from %qD to %qD",
> + CONSTRUCTOR_ELT (*valp, 0)->index,
> + index);
> + *non_constant_p = true;
> + }
> + /* Changing active member. */
> + vec_safe_truncate (CONSTRUCTOR_ELTS (*valp), 0);
> + }
>
> for (idx = 0;
> vec_safe_iterate (CONSTRUCTOR_ELTS (*valp), idx, );
> --- gcc/testsuite/g++.dg/cpp1y/constexpr-89336-3.C.jj 2019-02-19
> 14:13:19.990627715 +0100
> +++ gcc/testsuite/g++.dg/cpp1y/constexpr-89336-3.C2019-02-19
> 22:59:02.294799026 +0100
> @@ -0,0 +1,46 @@
> +// PR c++/89336
> +// { dg-do compile { target c++14 } }
> +
> +constexpr int
> +foo ()
> +{
> + union U { int a; long b; };
> + union V { union U u; short v; };
> + V w {};
> + w.u.a = w.v = w.u.b = 5L; // { dg-error "change of the active
> member of a union from" "" { target c++17_down } }
> + return w.u.a;
> +}
> +
> +static_assert (foo () == 5, ""); // { dg-error "non-constant condition
> for static assertion" "" { target c++17_down } }
> + // { dg-message "expansion of" "" {
> target c++17_down } .-1 }
> +
> +constexpr int
> +bar ()
> +{
> + union U { int a[5]; long b; };
> + union V { union U u; short v; };
> + V w {};
> + w.v = 5;
> + w.u.a[3] = w.u.a[1] = w.v; // { dg-error "change of the active
> member of a union from" "" { target c++17_down } }
> + return w.u.a[1] + w.u.a[3];
> +}
> +
> +static_assert (bar () == 10, "");// { dg-error "non-constant condition
> for static assertion" "" { target c++17_down } }
> + // { dg-message "expansion of" "" {
> target c++17_down } .-1 }
> +
> +struct Z { int x, y; };
> +
> +constexpr Z
> +baz ()
> +{
> + union W { Z a; long long w; };
> + W w {};
> + w.a = { 5, 0 };
> + w.a = { (int) (w.w = 17LL + w.a.x), 2 }; // { dg-error "change of the
> active member of a union from" "" { target c++17_down } }
> + return w.a;
> +}
> +
> +static_assert (baz ().x == 22, ""); // { dg-error "non-constant condition
> for static assertion" "" { target c++17_down } }
> + // { dg-message "expansion of" "" {
> target c++17_down } .-1 }
> +static_assert (baz ().y == 2, ""); // { dg-error "non-constant condition
> for static assertion" "" { target c++17_down } }
> + // { dg-message "expansion of" "" {
> target c++17_down } .-1 }
>
Jakub
[C++ PATCH] Ensure constexpr evaluation is done on pre-cp_fold_function bodies (PR c++/89285, take 2)
Hi!
On Tue, Feb 19, 2019 at 05:31:28AM +0100, Jakub Jelinek wrote:
> > > + /* These builtins will fold into
> > > +(cast)
> > > + ((something = __real__ SAVE_EXPR <.???_OVERFLOW (cst1, cst2)>),
> > > + __imag__ SAVE_EXPR <.???_OVERFLOW (cst1, cst2)>)
> > > +which fails is_constant_expression. */
This part is now simplified by builtins.c change, so it is actually just
(something = cst1), cst2
but still the !is_constant_expression issue applies.
> > > @@ -1358,6 +1433,9 @@ cxx_bind_parameters_in_call (const const
> > > x = ctx->object;
> > > x = build_address (x);
> > > }
> > > + if (TREE_ADDRESSABLE (type) && TYPE_REF_P (TREE_TYPE (x)))
> > > + /* Undo convert_for_arg_passing work here. */
> > > + x = build_fold_indirect_ref_loc (EXPR_LOCATION (x), x);
> >
> > Not convert_from_reference?
>
> Will change.
Changed.
> > > @@ -4036,6 +4113,10 @@ label_matches (const constexpr_ctx *ctx,
> > > }
> > > break;
> > > +case BREAK_STMT:
> > > +case CONTINUE_STMT:
> > > + break;
> > > +
> >
> > Let's add a comment that these are handled directly in cxx_eval_loop_expr.
>
> Ok, will do.
Likewise.
Here is an updated version with those changes, bootstrapped/regtested on
x86_64-linux/i686-linux.
2019-02-20 Jakub Jelinek
PR c++/89285
* builtins.c (fold_builtin_arith_overflow): If first two args are
INTEGER_CSTs, set intres and ovfres to constants rather than calls
to ifn.
* constexpr.c (struct constexpr_fundef): Add parms and result members.
(retrieve_constexpr_fundef): Adjust for the above change.
(register_constexpr_fundef): Save constexpr body with copy_fn,
temporarily set DECL_CONTEXT on DECL_RESULT before that.
(get_fundef_copy): Change FUN argument to FUNDEF with
constexpr_fundef * type, grab body and parms/result out of
constexpr_fundef struct and temporarily change it for copy_fn calls
too.
(cxx_eval_builtin_function_call): For __builtin_FUNCTION temporarily
adjust current_function_decl from ctx->call context. For arith
overflow builtins, don't test is_constant_expression on the result,
instead test if arguments are suitable constant expressions.
(cxx_bind_parameters_in_call): Grab parameters from new_call. Undo
convert_for_arg_passing changes for TREE_ADDRESSABLE type passing.
(cxx_eval_call_expression): Adjust get_fundef_copy caller.
(cxx_eval_conditional_expression): For IF_STMT, allow then or else
operands to be NULL.
(label_matches): Handle BREAK_STMT and CONTINUE_STMT.
(cxx_eval_loop_expr): Add support for FOR_STMT, WHILE_STMT and DO_STMT.
(cxx_eval_switch_expr): Add support for SWITCH_STMT.
(cxx_eval_constant_expression): Handle IF_STMT, FOR_STMT, WHILE_STMT,
DO_STMT, CONTINUE_STMT, SWITCH_STMT, BREAK_STMT and CONTINUE_STMT.
For SIZEOF_EXPR, recurse on the result of fold_sizeof_expr. Ignore
DECL_EXPR with USING_DECL operand.
* lambda.c (maybe_add_lambda_conv_op): Build thisarg using
build_int_cst to make it a valid constant expression.
* g++.dg/ubsan/vptr-4.C: Expect reinterpret_cast errors.
* g++.dg/cpp1y/constexpr-84192.C (f2): Adjust expected diagnostics.
* g++.dg/cpp1y/constexpr-70265-2.C (foo): Adjust expected line of
diagnostics.
* g++.dg/cpp1y/constexpr-89285.C: New test.
--- gcc/builtins.c.jj 2019-02-16 12:19:37.599192312 +0100
+++ gcc/builtins.c 2019-02-19 10:20:01.103606684 +0100
@@ -9302,8 +9302,7 @@ fold_builtin_arith_overflow (location_t
tree arg0, tree arg1, tree arg2)
{
enum internal_fn ifn = IFN_LAST;
- /* The code of the expression corresponding to the type-generic
- built-in, or ERROR_MARK for the type-specific ones. */
+ /* The code of the expression corresponding to the built-in. */
enum tree_code opcode = ERROR_MARK;
bool ovf_only = false;
@@ -9313,42 +9312,39 @@ fold_builtin_arith_overflow (location_t
ovf_only = true;
/* FALLTHRU */
case BUILT_IN_ADD_OVERFLOW:
- opcode = PLUS_EXPR;
- /* FALLTHRU */
case BUILT_IN_SADD_OVERFLOW:
case BUILT_IN_SADDL_OVERFLOW:
case BUILT_IN_SADDLL_OVERFLOW:
case BUILT_IN_UADD_OVERFLOW:
case BUILT_IN_UADDL_OVERFLOW:
case BUILT_IN_UADDLL_OVERFLOW:
+ opcode = PLUS_EXPR;
ifn = IFN_ADD_OVERFLOW;
break;
case BUILT_IN_SUB_OVERFLOW_P:
ovf_only = true;
/* FALLTHRU */
case BUILT_IN_SUB_OVERFLOW:
- opcode = MINUS_EXPR;
- /* FALLTHRU */
case BUILT_IN_SSUB_OVERFLOW:
case BUILT_IN_SSUBL_OVERFLOW:
case BUILT_IN_SSUBLL_OVERFLOW:
case BUILT_IN_USUB_OVERFLOW:
case BUILT_IN_USUBL_OVERFLOW:
case BUILT_IN_USUBLL_OVERFLOW:
+ opcode = MINUS_EXPR;
ifn = IFN_SUB_OVERFLOW;
break;
Re: [PATCH] 386: Set ix86_fpmath to FPMATH_387 without SSE
On Tue, Feb 19, 2019 at 9:14 PM H.J. Lu wrote: > > On Tue, Feb 19, 2019 at 6:16 AM Uros Bizjak wrote: > > > > On Tue, Feb 19, 2019 at 2:49 PM H.J. Lu wrote: > > > > > > ix86_fpmath should be set to combination of FPMATH_387 and FPMATH_SSE. > > > When SSE is disabled, it should be set to FPMATH_387 and 387 codegen is > > > also controlled by -msoft-float. > > > > > > gcc/ > > > > > > PR target/89397 > > > * config/i386/i386.c (ix86_option_override_internal): Set > > > opts->x_ix86_fpmath to FPMATH_387 when SSE is disabled. > > > > > > gcc/testsuite/ > > > > > > PR target/89397 > > > * gcc.target/i386/pr89397.c: New test. > > > > OK. > > > > This patch is need to fix: > > FAIL: gcc.target/i386/pr67985-3.c scan-assembler movd[ \t]%xmm[0-7], %eax > FAIL: gcc.target/i386/pr67985-3.c scan-assembler mulss > > OK for trunk? PR 67985 says: --q-- Since -miamcu specifies how parameters are passed to functions, inside function, we can use any instructions -march= allows. -miamcu -march=haswell should allow x87 and AVX instructions --/q-- The command line specifies -mfpmath=sse and target attribute implies SSE. So, SSE instructions should be used here. Please investigate why this is not the case. Uros. Uros.
Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.
On 19 February 2019 19:18:21 CET, Steve Kargl
wrote:
>On Mon, Feb 18, 2019 at 02:23:34PM +0100, Martin Liška wrote:
>>
>> As I installed all needed patches, I'm sending a documentation entry
>> for the new functionality.
>>
>> Thoughts?
>
>See below. Ok to commit with suggested changes.
>
>> Thanks,
>> Martin
>
>> >From 2d304e3b1d734548811f963c5bed1855b5375c43 Mon Sep 17 00:00:00
>2001
>> From: marxin
>> Date: Mon, 18 Feb 2019 14:21:56 +0100
>> Subject: [PATCH] Document Fortran header directive.
>>
>> ---
>> gcc/fortran/gfortran.texi | 19 +++
>> 1 file changed, 19 insertions(+)
>>
>> diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
>> index 02ff32f741f..72771a851f7 100644
>> --- a/gcc/fortran/gfortran.texi
>> +++ b/gcc/fortran/gfortran.texi
>> @@ -3596,6 +3596,25 @@ loop that follows. N is an integer constant
>specifying the unrolling factor.
>> The values of 0 and 1 block any unrolling of the loop.
>>
>>
>> +@node BUILTIN directive
>> +@subsection BUILTIN directive
>> +
>> +The syntax of the directive is
>> +
>> +@code{!GCC$ BUILTIN (B) attributes simd FLAGS IF('target')}
>> +
>> +You can used this directive to define which middle-end built-ins
>have vector
>
>s/used/use
>
>> +implementation. B is name of the middle-end built-in. FLAGS are
>optional
>
>s/B is/@code{B} is the
>S/FLAGS/@code{FLAGS}
>
>> +and must have be either "(inbranch)" or "(notinbranch)". IF
>statement
>
>delete 'have'
>s/IF/The @code{IF}
>
>> +is optional and is used to filter multilib ABIs for that
>> +the built-in should be vectorized. Example usage:
>
>Change "for that the built-in should be vectorized" to
>"for the built-in that should be vectorized"
>
>
>> +
>> +@smallexample
>> +!GCC$ builtin (sinf) attributes simd (notinbranch) if('x86_64')
>> +@end smallexample
>> +
>> +The purpose of the directive is to provide an API among the GCC
>compiler and
>> +the GNU C Library which would define vector implementation of math
>routines.
s/implementation/implementations/
define? Or provide.
Thanks,
>>
>> @node Non-Fortran Main Program
>> @section Non-Fortran Main Program
>> --
>> 2.20.1
>>
Re: [PATCH] rs6000: Fix PR 88100, range check for vec_splat_{su}{8,16,32}
Yes, you are correct. If there is no question with this patch,
I will backport this to GCC 8.
Thanks,
Lijia
On 2019/2/20 12:13 PM, Bill Schmidt wrote:
On 2/19/19 8:11 AM, Segher Boessenkool wrote:
Hi!
On Tue, Feb 19, 2019 at 03:38:56AM -0600, Li Jia He wrote:
GCC revision 259524 implemented range check for the vec_splat_{su}{8,16,32}
builtins. However, as a consequence of the implementation, the range check
is not done correctly for the expected vspltis[bhw] instructions. The result
is that we may not get a valid error message if the valid range of the data
is exceeded.
PR target/88100
* gcc/config/rs6000/rs6000.c (rs6000_gimple_fold_builtin): Remove
sext_hwi in IN_RANGE (sext_hwi (TREE_INT_CST_LOW (arg0), size),
-16, 15).
Please avoid more than a word or two of C in changelogs. Also, in such
cases you should show the case labels:
PR target/88100
* gcc/config/rs6000/rs6000.c (rs6000_gimple_fold_builtin)
: Don't convert the operand before range
checking it.
Okay for trunk with that. Thanks!
I believe you will also want to get permission to backport this to GCC 8.
It looks like the problem was introduced there, correct?
Thanks,
Bill
Segher
Re: [PATCH] rs6000: Fix PR 88100, range check for vec_splat_{su}{8,16,32}
On 2/19/19 8:11 AM, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Feb 19, 2019 at 03:38:56AM -0600, Li Jia He wrote:
>> GCC revision 259524 implemented range check for the vec_splat_{su}{8,16,32}
>> builtins. However, as a consequence of the implementation, the range check
>> is not done correctly for the expected vspltis[bhw] instructions. The result
>> is that we may not get a valid error message if the valid range of the data
>> is exceeded.
>> PR target/88100
>> * gcc/config/rs6000/rs6000.c (rs6000_gimple_fold_builtin): Remove
>> sext_hwi in IN_RANGE (sext_hwi (TREE_INT_CST_LOW (arg0), size),
>> -16, 15).
> Please avoid more than a word or two of C in changelogs. Also, in such
> cases you should show the case labels:
>
> PR target/88100
> * gcc/config/rs6000/rs6000.c (rs6000_gimple_fold_builtin)
> ALTIVEC_BUILTIN_VSPLTISW>: Don't convert the operand before range
> checking it.
>
> Okay for trunk with that. Thanks!
I believe you will also want to get permission to backport this to GCC 8.
It looks like the problem was introduced there, correct?
Thanks,
Bill
>
>
> Segher
>
[C++ PATCH] PR c++/88368 - wrong 'use of deleted function'
Since my patch for 81359 allowed us to signal failure on return from
maybe_instantiate_noexcept, we no longer need to turn an error into
noexcept(false). We also need to handle NSDMI instantiation errors under
synthesized_method_walk. This change caused some instantiation context
notes to be lost in the testsuite, so I added push_tinst_level to
get_defaulted_eh_spec to restore that context.
Tested x86_64-pc-linux-gnu, applying to trunk.
* method.c (walk_field_subobs): Remember errors from get_nsdmi.
(get_defaulted_eh_spec): Call push_tinst_level.
* pt.c (maybe_instantiate_noexcept): Keep error_mark_node.
* typeck2.c (merge_exception_specifiers): Handle error_mark_node.
---
gcc/cp/method.c | 10 +-
gcc/cp/pt.c | 2 --
gcc/cp/typeck2.c | 3 +++
gcc/testsuite/g++.dg/cpp0x/nsdmi3.C | 3 ++-
gcc/testsuite/g++.dg/ext/is_constructible3.C | 17 +
gcc/cp/ChangeLog | 8
6 files changed, 39 insertions(+), 4 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/ext/is_constructible3.C
diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index a5f2304d49c..6e0df68273e 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -1367,7 +1367,10 @@ walk_field_subobs (tree fields, special_function_kind
sfk, tree fnname,
if (spec_p)
{
tree nsdmi = get_nsdmi (field, /*ctor*/false, complain);
- if (!expr_noexcept_p (nsdmi, complain))
+ if (nsdmi == error_mark_node)
+ *spec_p = error_mark_node;
+ else if (*spec_p != error_mark_node
+ && !expr_noexcept_p (nsdmi, complain))
*spec_p = noexcept_false_spec;
}
/* Don't do the normal processing. */
@@ -1753,8 +1756,13 @@ get_defaulted_eh_spec (tree decl, tsubst_flags_t
complain)
if (SFK_DTOR_P (sfk) && DECL_VIRTUAL_P (decl))
/* We have to examine virtual bases even if abstract. */
sfk = sfk_virtual_destructor;
+ bool pushed = false;
+ if (CLASSTYPE_TEMPLATE_INSTANTIATION (ctype))
+pushed = push_tinst_level (decl);
synthesized_method_walk (ctype, sfk, const_p, , NULL, NULL,
NULL, diag, , parms);
+ if (pushed)
+pop_tinst_level ();
return spec;
}
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index d8be92ddca4..a69a17ad3b2 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -24199,8 +24199,6 @@ maybe_instantiate_noexcept (tree fn, tsubst_flags_t
complain)
pop_deferring_access_checks ();
pop_access_scope (fn);
pop_tinst_level ();
- if (spec == error_mark_node)
- spec = noexcept_false_spec;
}
else
spec = noexcept_false_spec;
diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c
index ac2c253196b..4e4b1f03b7c 100644
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -2363,6 +2363,9 @@ merge_exception_specifiers (tree list, tree add)
{
tree noex, orig_list;
+ if (list == error_mark_node || add == error_mark_node)
+return error_mark_node;
+
/* No exception-specifier or noexcept(false) are less strict than
anything else. Prefer the newer variant (LIST). */
if (!list || list == noexcept_false_spec)
diff --git a/gcc/testsuite/g++.dg/cpp0x/nsdmi3.C
b/gcc/testsuite/g++.dg/cpp0x/nsdmi3.C
index d2e74392487..8276eab8f80 100644
--- a/gcc/testsuite/g++.dg/cpp0x/nsdmi3.C
+++ b/gcc/testsuite/g++.dg/cpp0x/nsdmi3.C
@@ -13,6 +13,7 @@ struct B
A a3 = { 3 };// { dg-error "explicit" }
};
-constexpr B b; // { dg-error "B::B" }
+constexpr B b;
+// { dg-prune-output "B::B. is not usable" }
// { dg-prune-output "B::a1" }
diff --git a/gcc/testsuite/g++.dg/ext/is_constructible3.C
b/gcc/testsuite/g++.dg/ext/is_constructible3.C
new file mode 100644
index 000..c7c58746cd0
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/is_constructible3.C
@@ -0,0 +1,17 @@
+// PR c++/88368
+// { dg-do compile { target c++11 } }
+
+struct A {
+
+ struct B {
+int I = 1;
+B() = default;
+ };
+
+ static constexpr bool v = __is_constructible (B);
+
+};
+
+void print() {
+ A::B BB;
+}
diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
index 9c42190f04a..3fe0cedb0e3 100644
--- a/gcc/cp/ChangeLog
+++ b/gcc/cp/ChangeLog
@@ -1,3 +1,11 @@
+2019-02-19 Jason Merrill
+
+ PR c++/88368 - wrong 'use of deleted function'
+ * method.c (walk_field_subobs): Remember errors from get_nsdmi.
+ (get_defaulted_eh_spec): Call push_tinst_level.
+ * pt.c (maybe_instantiate_noexcept): Keep error_mark_node.
+ * typeck2.c (merge_exception_specifiers): Handle error_mark_node.
+
2019-02-19 Chung-Lin Tang
PR c/87924
base-commit: cfa86c5ebc839435491f6ab8f541eb44f02d6849
--
2.20.1
[LTO PATCH RFA] PR c++/88049 - ICE with undefined destructor and anon namespace.
A type in an anonymous namespace can never be merged with one from
another translation unit, so a member of such a type is always its own
prevailing decl.
I don't really understand the LTO concept of prevailing decl, or why we don't
get here if the destructor is defined, but this seems reasonable and fixes the
bug.
Tested x86_64-pc-linux-gnu. OK for trunk?
* lto-symtab.c (lto_symtab_prevailing_virtual_decl): Return early
for a type in an anonymous namespace.
---
gcc/lto/lto-symtab.c | 8 ++--
gcc/testsuite/g++.dg/lto/pr88049_0.C | 16
gcc/lto/ChangeLog| 6 ++
3 files changed, 28 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/lto/pr88049_0.C
diff --git a/gcc/lto/lto-symtab.c b/gcc/lto/lto-symtab.c
index 22da4c78b8c..343915c3cec 100644
--- a/gcc/lto/lto-symtab.c
+++ b/gcc/lto/lto-symtab.c
@@ -1085,8 +1085,12 @@ lto_symtab_prevailing_virtual_decl (tree decl)
{
if (DECL_ABSTRACT_P (decl))
return decl;
- gcc_checking_assert (!type_in_anonymous_namespace_p (DECL_CONTEXT (decl))
- && DECL_ASSEMBLER_NAME_SET_P (decl));
+
+ if (type_in_anonymous_namespace_p (DECL_CONTEXT (decl)))
+/* There can't be any other declarations. */
+return decl;
+
+ gcc_checking_assert (DECL_ASSEMBLER_NAME_SET_P (decl));
symtab_node *n = symtab_node::get_for_asmname
(DECL_ASSEMBLER_NAME (decl));
diff --git a/gcc/testsuite/g++.dg/lto/pr88049_0.C
b/gcc/testsuite/g++.dg/lto/pr88049_0.C
new file mode 100644
index 000..7ac3618c2c8
--- /dev/null
+++ b/gcc/testsuite/g++.dg/lto/pr88049_0.C
@@ -0,0 +1,16 @@
+// PR c++/88049
+// { dg-lto-do link }
+// { dg-lto-options {{ -flto -O2 -w }} }
+// { dg-extra-ld-options -r }
+
+template class a;
+class b {};
+template a d(char);
+template class a : public b {
+public:
+ virtual ~a();
+};
+namespace {
+ class f;
+ b c = d(int());
+} // namespace
diff --git a/gcc/lto/ChangeLog b/gcc/lto/ChangeLog
index 6b183df3b0f..71a2a109e64 100644
--- a/gcc/lto/ChangeLog
+++ b/gcc/lto/ChangeLog
@@ -1,3 +1,9 @@
+2019-02-18 Jason Merrill
+
+ PR c++/88049 - ICE with undefined destructor and anon namespace.
+ * lto-symtab.c (lto_symtab_prevailing_virtual_decl): Return early
+ for a type in an anonymous namespace.
+
2019-01-09 Sandra Loosemore
PR other/16615
base-commit: 79ae32275d4a19a1fc6ffebec9ac15a8c94b0b8f
--
2.20.1
Re: [PATCH] luoxhu - backport from trunk r255555, r257253 and r258137
Hi Segher, On 2019/2/20 AM6:24, Segher Boessenkool wrote: Hi! On Tue, Feb 19, 2019 at 01:23:53AM -0600, luo...@linux.ibm.com wrote: This is a backport of r25, r257253 and r258137 of trunk to gcc-7-branch. The patches were on trunk before GCC 8 forked already. Totally 5 files need mannual resolve due to code changes for r25. r257253 and r258137 are dependent testcases require vsx support need merge to avoid regression. Could you show what changes you needed, please? As patches for example. It's not clear from the log :-( I generate the r25 patch from trunk and use the "git am" to apply it to gcc-7-branch to backport, error happens as below: [gcc-7-branch] $ git am 0001-gcc-ChangeLog.patch Applying: gcc/ChangeLog: error: patch failed: gcc/ChangeLog:1 error: gcc/ChangeLog: patch does not apply error: patch failed: gcc/config/rs6000/altivec.h:458 error: gcc/config/rs6000/altivec.h: patch does not apply error: patch failed: gcc/config/rs6000/rs6000-c.c:3618 error: gcc/config/rs6000/rs6000-c.c: patch does not apply error: patch failed: gcc/doc/extend.texi:17382 error: gcc/doc/extend.texi: patch does not apply error: patch failed: gcc/testsuite/ChangeLog:1 error: gcc/testsuite/ChangeLog: patch does not apply error: patch failed: gcc/testsuite/gcc.target/powerpc/builtins-3-p8.c:16 error: gcc/testsuite/gcc.target/powerpc/builtins-3-p8.c: patch does not apply error: patch failed: gcc/testsuite/gcc.target/powerpc/builtins-3.c:88 error: gcc/testsuite/gcc.target/powerpc/builtins-3.c: patch does not apply error: patch failed: gcc/testsuite/gcc.target/powerpc/vsx-vector-6.c:1 error: gcc/testsuite/gcc.target/powerpc/vsx-vector-6.c: patch does not apply Patch failed at 0001 gcc/ChangeLog: The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". The 5 files (altivec.h, rs6000-c.c, extend.texi, etc.) couldn't apply due to some dependent patches in trunk not backported, should I find all the dependency patches(maybe many patches required) and backport them all to avoid such errors or just resolve these errors in this patch? that's why I use the word "resolve" below, will merge or rebase be better to understand? Then I use command "git apply 0001-gcc-ChangeLog.patch --reject" and manually fix the rejected hunks. Do you have better suggested steps for such kind of backport, please? Thanks. 2019-01-14 Luo Xiong Hu Backport from trunk. Mannually resolve 3 files: Two spaces after a full stop. "Manually", one "n". * config/rs6000/altivec.h (vec_extract_fp32_from_shorth, vec_extract_fp32_from_shortl): Resolve new #defines. I don't know what this means, "resolve"? * config/rs6000/rs6000-c.c (ALTIVEC_BUILTIN_VEC_SLD): Resolve new expensions. Same. (And "expansions"? Or what did you mean?). "expansions" means macro expansion is copied from previous ChangeLog, the original ChangeLog is: 2017-12-11 Carl Love * config/rs6000/altivec.h (vec_extract_fp32_from_shorth, vec_extract_fp32_from_shortl]): Add #defines. * config/rs6000/rs6000-builtin.def (VSLDOI_2DI): Add macro expansion. * config/rs6000/rs6000-c.c (ALTIVEC_BUILTIN_VEC_UNPACKH, ALTIVEC_BUILTIN_VEC_UNPACKL, ALTIVEC_BUILTIN_VEC_AND, ALTIVEC_BUILTIN_VEC_SLD, ALTIVEC_BUILTIN_VEC_SRL, ALTIVEC_BUILTIN_VEC_SRO, ALTIVEC_BUILTIN_VEC_SLD, ALTIVEC_BUILTIN_VEC_SLL): Add expansions. * doc/extend.texi: Add documentation for the added builtins. Xionghu * doc/extend.texi: (vec_sld, vec_sll, vec_srl, vec_sro, vec_unpackh, vec_unpackl, test_vsi_packsu_vssi_vssi, vec_packsu, vec_cmpne): Resolve new documentation. 2017-12-11 Carl Love An empty line before a new changelog please (before date and author). Segher
Re: [PATCH] Teach evrp that main's argc argument is always non-negative for C family (PR tree-optimization/89350)
On 2/19/19 10:18 AM, Joseph Myers wrote: On Tue, 19 Feb 2019, Martin Sebor wrote: Sure, the text is in a section named Program startup, but that doesn't imply that the constraints apply only at program startup. If they did, I think it's clear from the context that the section is describing the interface between the program and its environment, not the interface between a recursive caller of main and the so-called instance of main - that argc and argv there refer to the specific argc and argv objects for the initial call of main, not the different objects involved in any recursive call. Furthermore, the statement that the parameters can be modified does not restrict such modifications to preserving the given properties (normal practice such as ++argv; --argc; would mean that there are sequence points at which those objects do not have the properties given). there would be no constraints on the parameters in any other calls to main, which would make the parameters unusable in general (because there is no way for main to tell if it's the fist invocation). If a program chooses to call main recursively, presumably it has its own way to tell (e.g. some global variable the call to main can check). It's an interesting interpretation but I'm having trouble imagining it's an intended one. It feels like a (big) stretch to me to say that if main is careful not to rely on the parameters' constraints then they need not apply to it. But since there appear to be two possible ways to read the standard on this point I think it's worth clarifying. Not so much to validate the optimization but simply as a matter of principle. Martin
PING [PATCH] avoid 4095/INT_MAX warning for fprintf (PR 88993)
I received feedback on the first patch that it doesn't suppress all
the instances of the warning so I've relaxed the checker even more
to avoid the excess instances seen in Elfutils and beefed up
the tests. The top of trunk compiles cleanly now with just
the three instances of -Wformat-truncation=2 that are not
the subject of the two PRs.
Martin
On 2/11/19 11:24 AM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00224.html
(This patch also handles bug 88835.)
On 2/4/19 8:58 PM, Martin Sebor wrote:
The attached patch relaxes -Wformat-overflow=2 to avoid warning about
individual directives that might (but need not) exceed the 4095 byte
limit, and about the total function output that likewise might (but
need not) exceed the INT_MAX limit.
The bug report actually requests that instead of the standard minimum
of 4095 bytes, GCC consider real libc limits, but trying to figure
out what these real limits might be (they're not documented anywhere,
AFAIK) and hardcoding them into GCC doesn't seem like a good solution.
Instead, the patch only does little more than the bare minimum to
suppress these pedantic warnings, and it only does that for the "may
exceed" cases and not for those where the size of output definitely
exceeds either limit. Using the formatted functions to write such
large amounts of data seems more likely to be a bug than intentional,
and at level 2 issuing the warning seems appropriate unless the return
value of the function is tested. When it is, even tough exceeding
these limits is strictly undefined, it seems reasonable to assume that
a quality libc implementation will detect it and return an error (as
required by POSIX).
So with the patch, the only way to get this warning is for calls to
sprintf or to unchecked snprintf.
Martin
PR tree-optimization/88993 - GCC 9 -Wformat-overflow=2 should reflect real libc limits
PR tree-optimization/88835 - overly aggressive -Werror=format-overflow for printf
gcc/ChangeLog:
PR tree-optimization/88993
PR tree-optimization/88835
* gimple-ssa-sprintf.c (sprintf_dom_walker::call_info::is_file_func):
New helper.
(sprintf_dom_walker::call_info::is_string_func): New helper.
(format_directive): Only issue "may exceed" 4095/INT_MAX warnings
for formatted string functions.
(sprintf_dom_walker::compute_format_length): Return HWI_MAX rather than -1.
(sprintf_dom_walker::handle_gimple_call): Fix a typo in a comment.
gcc/testsuite/ChangeLog:
PR tree-optimization/88993
PR tree-optimization/88835
* gcc.dg/tree-ssa/builtin-fprintf-warn-2.c: New test.
* gcc.dg/tree-ssa/builtin-printf-warn-2.c: New test.
* gcc.dg/tree-ssa/builtin-snprintf-warn-3.c: Adjust.
* gcc.dg/tree-ssa/builtin-sprintf-warn-18.c: Same.
Index: gcc/gimple-ssa-sprintf.c
===
--- gcc/gimple-ssa-sprintf.c (revision 269022)
+++ gcc/gimple-ssa-sprintf.c (working copy)
@@ -943,6 +943,29 @@ struct sprintf_dom_walker::call_info
{
return bounded ? OPT_Wformat_truncation_ : OPT_Wformat_overflow_;
}
+
+ /* Return true for calls to file formatted functions. */
+ bool is_file_func () const
+ {
+return (fncode == BUILT_IN_FPRINTF
+ || fncode == BUILT_IN_FPRINTF_CHK
+ || fncode == BUILT_IN_FPRINTF_UNLOCKED
+ || fncode == BUILT_IN_VFPRINTF
+ || fncode == BUILT_IN_VFPRINTF_CHK);
+ }
+
+ /* Return true for calls to string formatted fncodetions. */
+ bool is_string_func () const
+ {
+return (fncode == BUILT_IN_SPRINTF
+ || fncode == BUILT_IN_SPRINTF_CHK
+ || fncode == BUILT_IN_SNPRINTF
+ || fncode == BUILT_IN_SNPRINTF_CHK
+ || fncode == BUILT_IN_VSPRINTF
+ || fncode == BUILT_IN_VSPRINTF_CHK
+ || fncode == BUILT_IN_VSNPRINTF
+ || fncode == BUILT_IN_VSNPRINTF_CHK);
+ }
};
/* Return the result of formatting a no-op directive (such as '%n'). */
@@ -2839,6 +2862,8 @@ format_directive (const sprintf_dom_walker::call_i
if (!warned
/* Only warn at level 2. */
&& warn_level > 1
+ /* Only warn for string functions. */
+ && info.is_string_func ()
&& (!minunder4k
|| (!maxunder4k && fmtres.range.max < HOST_WIDE_INT_MAX)))
{
@@ -2847,7 +2872,9 @@ format_directive (const sprintf_dom_walker::call_i
of C11. Warn on this only at level 2 but remember this and
prevent folding the return value when done. This allows for
the possibility of the actual libc call failing due to ENOMEM
- (like Glibc does under some conditions). */
+ (like Glibc does with very large precision or width).
+ Issue the "may exceed" warning only for string functions and
+ not for fprintf or printf. */
if (fmtres.range.min == fmtres.range.max)
warned = fmtwarn (dirloc, argloc, NULL, info.warnopt (),
@@ -2855,17 +2882,21 @@ format_directive (const sprintf_dom_walker::call_i
"minimum required size of 4095", dirlen,
target_to_host (hostdir, sizeof hostdir, dir.beg),
fmtres.range.min);
-
Re: [PATCH] document __builtin_is_constant_evaluated
On 2/18/19 11:52 AM, Martin Sebor wrote:
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 268992)
+++ gcc/doc/extend.texi (working copy)
@@ -12890,6 +12890,23 @@ built-in in this case, because it has no opportuni
optimization.
@end deftypefn
+@deftypefn {Built-in Function} bool __builtin_is_constant_evaluated ()
+The @code{__builtin_is_constant_evaluated} function is available only
+in C++. The built-in is intended to be used by implemetations of
s/implemetations/implementations/
+the @code{std::is_constant_evaluated} C++ function. Programs should make
+use of the latter function rather than invoking the built-in directly.
+
+The main use case of the built-in is to determine whether a @code{constexpr}
+function is being called in a @code{constexpr} context. A call to
+the function evaluates to a core constant expression with the value
+@code{true} if and only if it occurs within the evaluation of an expression
+or conversion that is manifestly constant-evaluated as defined in the C++
+standard. Manifestly constant-evaluated contexts include constant-expressions,
+the conditions of @code{constexpr if} statements, constraint-expressions, and
+initializers of variables usable in constant expressions. For more details
+refer to the latest revision of the C++ standard.
+@end deftypefn
+
@deftypefn {Built-in Function} long __builtin_expect (long @var{exp}, long
@var{c})
@opindex fprofile-arcs
You may use @code{__builtin_expect} to provide the compiler with
This is OK with the typo fixed.
-Sandra
[PATCH, libvtv] Fix testsuite issue.
One of the testsuite tests for libvtv is failing due to an incorrect
signature for the function
"main". This patch fixes that.
Testing: The libvtv testsuite failed 4 tests without this fix; it
passes all of them with it.
Ok to commit?
-- Caroline Tice
cmt...@google.com
Index: libvtv/ChangeLog
===
--- libvtv/ChangeLog (revision 269022)
+++ libvtv/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2019-02-19 Caroline Tice
+
+ Fix testsuite
+ * testsuite/libvtv.cc/const_vtable.cc (main): Fix function signature.
+
2019-01-01 Jakub Jelinek
Update copyright years.
Index: libvtv/testsuite/libvtv.cc/const_vtable.cc
===
--- libvtv/testsuite/libvtv.cc/const_vtable.cc (revision 269022)
+++ libvtv/testsuite/libvtv.cc/const_vtable.cc (working copy)
@@ -28,7 +28,7 @@
~D();
};
extern "C" int printf(const char *,...);
-main()
+int main(int argc, char**argv)
{
try {
D *d = new D;
Re: [patch, fortran] Fix PR 87689, wrong decls / ABI violation on POWER
Bob, Some of us still use varargs interfaces (in my case, Fortran calling C stdarg subroutines). The problem for us is that that sometimes using varargs made standard- conforming Fortran code like, in file a.f subroutine foo(a) print *,a end and in file main.f programme main call foo(1.0) end depend ABI details: The call to foo used to be called using the varargs convention, and the subroutine foo was compiled as a non-varargs function. This "worked" until PR 87689 showed that this breaks standard-conforming Fortran code on a primary gcc platform. I don't know if that makes a difference for the platform you work on. For the System V AMD64 ABI, I suspect it actually might not matter (at least from glancing at the corresponding Wikipedia article), but I am _not_ an expert in this field, so please take this with a chunk of rock salt of appropriate size. So, we cannot really keep this as a feature (note that varargs are also not C interoperable). Regards Thomas
[Patch, Aarch64] Implement TARGET_GET_MULTILIB_ABI_NAME for aarch64 (for use in Fortran vector header file)
Here is a patch to use the new TARGET_GET_MULTILIB_ABI_NAME macro that
Martin Liska added with the Aarch64 platform. The main issue to
consider is what abi names to support, I created 8 versions for big-
endian/little-endian, ilp32/lp64, and sve/non-sve. I am not sure if we
need all of those but it seemed better to have them and not use them
than to find out we need them later.
Tested on Aarch64 and x86 with bootstraps and test runs. There were no
regressions.
Ok to checkin?
Steve Ellcey
sell...@marvell.com
2018-02-19 Steve Ellcey
* config/aarch64/aarch64.c (aarch64_get_multilib_abi_name):
New function.
(TARGET_GET_MULTILIB_ABI_NAME): New macro.
2018-02-19 Steve Ellcey
* gfortran.dg/simd-builtins-1.f90: Update for aarch64*-*-*.
* gfortran.dg/simd-builtins-2.f90: Ditto.
* gfortran.dg/simd-builtins-6.f90: Ditto.
* gfortran.dg/simd-builtins-8.f90: New test.
* gfortran.dg/simd-builtins-8.h: New header file.
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 9f52cc9ff3b..d26ff85b683 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -18720,6 +18720,23 @@ aarch64_comp_type_attributes (const_tree type1, const_tree type2)
return 1;
}
+/* Implement TARGET_GET_MULTILIB_ABI_NAME */
+
+static const char *
+aarch64_get_multilib_abi_name (void)
+{
+ if (TARGET_BIG_END)
+{
+ if (AARCH64_ISA_SVE)
+ return TARGET_ILP32 ? "aarch64_be_ilp32_sve" : "aarch64_be_sve";
+ return TARGET_ILP32 ? "aarch64_be_ilp32" : "aarch64_be";
+}
+ if (AARCH64_ISA_SVE)
+return TARGET_ILP32 ? "aarch64_ilp32_sve" : "aarch64_sve";
+ return TARGET_ILP32 ? "aarch64_ilp32" : "aarch64";
+}
+
+
/* Implement TARGET_STACK_PROTECT_GUARD. In case of a
global variable based guard use the default else
return a null tree. */
@@ -19242,6 +19259,9 @@ aarch64_libgcc_floating_mode_supported_p
#undef TARGET_COMP_TYPE_ATTRIBUTES
#define TARGET_COMP_TYPE_ATTRIBUTES aarch64_comp_type_attributes
+#undef TARGET_GET_MULTILIB_ABI_NAME
+#define TARGET_GET_MULTILIB_ABI_NAME aarch64_get_multilib_abi_name
+
#if CHECKING_P
#undef TARGET_RUN_TARGET_SELFTESTS
#define TARGET_RUN_TARGET_SELFTESTS selftest::aarch64_run_selftests
diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-1.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-1.f90
index 6d79ef8dc46..5cb3eb5132a 100644
--- a/gcc/testsuite/gfortran.dg/simd-builtins-1.f90
+++ b/gcc/testsuite/gfortran.dg/simd-builtins-1.f90
@@ -1,5 +1,6 @@
-! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* } } }
-! { dg-additional-options "-msse2 -mno-avx -nostdinc -Ofast -fpre-include=simd-builtins-1.h -fdump-tree-optimized" }
+! { dg-do compile { target i?86-*-linux* x86_64-*-linux* aarch64*-*-linux* } }
+! { dg-additional-options "-nostdinc -Ofast -fpre-include=simd-builtins-1.h -fdump-tree-optimized" }
+! { dg-additional-options "-msse2 -mno-avx" { target i?86-*-linux* x86_64-*-linux* } }
program test_overloaded_intrinsic
real(4) :: x4(3200), y4(3200)
@@ -14,6 +15,7 @@ program test_overloaded_intrinsic
print *, y8
end
-! { dg-final { scan-tree-dump "sinf.simdclone" "optimized" } } */
-! { dg-final { scan-tree-dump "__builtin_sin" "optimized" } } */
-! { dg-final { scan-assembler "call.*_ZGVbN4v_sinf" } }
+! { dg-final { scan-tree-dump "sinf.simdclone" "optimized" } }
+! { dg-final { scan-tree-dump "__builtin_sin" "optimized" } }
+! { dg-final { scan-assembler "call.*_ZGVbN4v_sinf" { target i?86-*-linux* x86_64-*-* } } }
+! { dg-final { scan-assembler "bl.*_ZGVnN4v_sinf" { target aarch64*-*-* } } }
diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-2.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-2.f90
index f0e6bc13862..2e5bc22716b 100644
--- a/gcc/testsuite/gfortran.dg/simd-builtins-2.f90
+++ b/gcc/testsuite/gfortran.dg/simd-builtins-2.f90
@@ -1,11 +1,12 @@
-! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* } } }
-! { dg-additional-options "-msse2 -nostdinc -Ofast -fdump-tree-optimized" }
+! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* aarch64*-*-linux* } } }
+! { dg-additional-options "-nostdinc -Ofast -fdump-tree-optimized" }
+! { dg-additional-options "-msse2" { target i?86-*-linux* x86_64-*-linux* } }
program test_overloaded_intrinsic
real(4) :: x4(3200), y4(3200)
real(8) :: x8(3200), y8(3200)
- ! this should be using simd clone
+ ! this should not be using simd clone
y4 = sin(x4)
print *, y4
@@ -18,3 +19,4 @@ end
! { dg-final { scan-tree-dump "__builtin_sin" "optimized" } } */
! { dg-final { scan-tree-dump-not "simdclone" "optimized" } } */
! { dg-final { scan-assembler-not "call.*_ZGVbN4v_sinf" } }
+! { dg-final { scan-assembler-not "bl.*_ZGVnN4v_sinf" } }
diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-6.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-6.f90
index 2ffa807e6b6..60bcac78f3e 100644
--- a/gcc/testsuite/gfortran.dg/simd-builtins-6.f90
+++
Re: [PATCH] luoxhu - backport from trunk r255555, r257253 and r258137
Hi! On Tue, Feb 19, 2019 at 01:23:53AM -0600, luo...@linux.ibm.com wrote: > This is a backport of r25, r257253 and r258137 of trunk to gcc-7-branch. > The patches were on trunk before GCC 8 forked already. Totally 5 files need > mannual resolve due to code changes for r25. r257253 and r258137 are > dependent testcases require vsx support need merge to avoid regression. Could you show what changes you needed, please? As patches for example. It's not clear from the log :-( > 2019-01-14 Luo Xiong Hu > > Backport from trunk. Mannually resolve 3 files: Two spaces after a full stop. "Manually", one "n". > * config/rs6000/altivec.h (vec_extract_fp32_from_shorth, > vec_extract_fp32_from_shortl): Resolve new #defines. I don't know what this means, "resolve"? > * config/rs6000/rs6000-c.c (ALTIVEC_BUILTIN_VEC_SLD): Resolve > new expensions. Same. (And "expansions"? Or what did you mean?). > * doc/extend.texi: (vec_sld, vec_sll, vec_srl, vec_sro, > vec_unpackh, vec_unpackl, test_vsi_packsu_vssi_vssi, vec_packsu, > vec_cmpne): Resolve new documentation. > 2017-12-11 Carl Love An empty line before a new changelog please (before date and author). Segher
Re: [C++ PATCH] Fix cxx_eval_store_expression (PR c++/89336)
On Tue, Feb 19, 2019 at 11:28:22AM -1000, Jason Merrill wrote:
> On Tue, Feb 19, 2019 at 4:00 AM Jakub Jelinek wrote:
> > On Mon, Feb 18, 2019 at 03:01:14PM -1000, Jason Merrill wrote:
> > > But it's not clear to me that the standard actually allows this. I don't
> > > think changing the active member of a union in the mem-initializer for
> > > another member is reasonable.
> >
> > There is in [expr.const]/2:
> >
> > an lvalue-to-rvalue conversion (7.1) that is applied to a glvalue that
> > refers to a non-active member of a
> > union or a subobject thereof;
> >
> > an assignment expression (8.18) or invocation of an assignment operator
> > (15.8) that would change the
> > active member of a union;
> >
> > in C++17 it seems, so maybe my union testcases are accepts-invalid.
> > This has been introduced in P0137R1 and removed again in P1330R0. Does that
> > mean e.g. following is valid in C++14, invalid in C++17 and valid again in
> > C++20? Or has one of the above papers changed retroactively previous
> > standards?
>
> Before P0137 I believe foo and bar were arguably undefined.
I see, before that it was:
"an lvalue-to-rvalue conversion (4.1) or modification (5.18, 5.2.6, 5.3.2) that
is applied
to a glvalue that refers to a non-active member of a union or a subobject
thereof;"
So, do we want something like this then (or free all vectors immediately
there and return immediately)?
2019-02-19 Jakub Jelinek
PR c++/89336
* constexpr.c (cxx_eval_store_expression): Diagnose changing of active
union member for -std=c++17 and earlier.
* g++.dg/cpp1y/constexpr-89336-3.C: New test.
--- gcc/cp/constexpr.c.jj 2019-02-19 10:26:09.567962395 +0100
+++ gcc/cp/constexpr.c 2019-02-19 22:53:45.702983814 +0100
@@ -3890,8 +3890,20 @@ cxx_eval_store_expression (const constex
if (code == UNION_TYPE && CONSTRUCTOR_NELTS (*valp)
&& CONSTRUCTOR_ELT (*valp, 0)->index != index)
- /* Changing active member. */
- vec_safe_truncate (CONSTRUCTOR_ELTS (*valp), 0);
+ {
+ if (cxx_dialect < cxx2a)
+ {
+ if (!ctx->quiet)
+ error_at (cp_expr_loc_or_loc (t, input_location),
+ "change of the active member of a union "
+ "from %qD to %qD",
+ CONSTRUCTOR_ELT (*valp, 0)->index,
+ index);
+ *non_constant_p = true;
+ }
+ /* Changing active member. */
+ vec_safe_truncate (CONSTRUCTOR_ELTS (*valp), 0);
+ }
for (idx = 0;
vec_safe_iterate (CONSTRUCTOR_ELTS (*valp), idx, );
--- gcc/testsuite/g++.dg/cpp1y/constexpr-89336-3.C.jj 2019-02-19
14:13:19.990627715 +0100
+++ gcc/testsuite/g++.dg/cpp1y/constexpr-89336-3.C 2019-02-19
22:59:02.294799026 +0100
@@ -0,0 +1,46 @@
+// PR c++/89336
+// { dg-do compile { target c++14 } }
+
+constexpr int
+foo ()
+{
+ union U { int a; long b; };
+ union V { union U u; short v; };
+ V w {};
+ w.u.a = w.v = w.u.b = 5L;// { dg-error "change of the active
member of a union from" "" { target c++17_down } }
+ return w.u.a;
+}
+
+static_assert (foo () == 5, ""); // { dg-error "non-constant condition
for static assertion" "" { target c++17_down } }
+ // { dg-message "expansion of" "" {
target c++17_down } .-1 }
+
+constexpr int
+bar ()
+{
+ union U { int a[5]; long b; };
+ union V { union U u; short v; };
+ V w {};
+ w.v = 5;
+ w.u.a[3] = w.u.a[1] = w.v; // { dg-error "change of the active
member of a union from" "" { target c++17_down } }
+ return w.u.a[1] + w.u.a[3];
+}
+
+static_assert (bar () == 10, ""); // { dg-error "non-constant condition
for static assertion" "" { target c++17_down } }
+ // { dg-message "expansion of" "" {
target c++17_down } .-1 }
+
+struct Z { int x, y; };
+
+constexpr Z
+baz ()
+{
+ union W { Z a; long long w; };
+ W w {};
+ w.a = { 5, 0 };
+ w.a = { (int) (w.w = 17LL + w.a.x), 2 }; // { dg-error "change of the
active member of a union from" "" { target c++17_down } }
+ return w.a;
+}
+
+static_assert (baz ().x == 22, "");// { dg-error "non-constant condition
for static assertion" "" { target c++17_down } }
+ // { dg-message "expansion of" "" {
target c++17_down } .-1 }
+static_assert (baz ().y == 2, ""); // { dg-error "non-constant condition
for static assertion" "" { target c++17_down } }
+ // { dg-message "expansion of" "" {
target c++17_down } .-1 }
Jakub
[patch, fortran] Fix PR 86119, spurios warning for len(classtype) with -Wconversion
Hello world,
the attached patch fixes the 8/9 regression by inserting the conversion
at the right place. Regression-tested. OK for trunk, and for 8 when it
re-opens?
Regards
Thomas
2019-02-19 Thomas Koenig
PR fortran/86110
* class.c (gfc_get_len_component): Add argument k for kind.
If the kind of the resulting expression is not equal to k,
convert it.
* gfortran.h (gfc_len_component): Adjust prototype.
* simplify.c (gfc_simplify_len): Pass kind to
gfc_get_len_component.
2019-02-19 Thomas Koenig
PR fortran/86110
* gfortran.dg/warn_conversion_11.f90: New test.
Index: class.c
===
--- class.c (Revision 268968)
+++ class.c (Arbeitskopie)
@@ -565,7 +565,7 @@ gfc_intrinsic_hash_value (gfc_typespec *ts)
ref to the _len component. */
gfc_expr *
-gfc_get_len_component (gfc_expr *e)
+gfc_get_len_component (gfc_expr *e, int k)
{
gfc_expr *ptr;
gfc_ref *ref, **last;
@@ -590,6 +590,14 @@ gfc_expr *
}
/* And replace if with a ref to the _len component. */
gfc_add_len_component (ptr);
+ if (k != ptr->ts.kind)
+{
+ gfc_typespec ts;
+ gfc_clear_ts ();
+ ts.type = BT_INTEGER;
+ ts.kind = k;
+ gfc_convert_type_warn (ptr, , 2, 0);
+}
return ptr;
}
Index: gfortran.h
===
--- gfortran.h (Revision 268968)
+++ gfortran.h (Arbeitskopie)
@@ -3479,7 +3479,7 @@ bool gfc_is_class_scalar_expr (gfc_expr *);
bool gfc_is_class_container_ref (gfc_expr *e);
gfc_expr *gfc_class_initializer (gfc_typespec *, gfc_expr *);
unsigned int gfc_hash_value (gfc_symbol *);
-gfc_expr *gfc_get_len_component (gfc_expr *e);
+gfc_expr *gfc_get_len_component (gfc_expr *e, int);
bool gfc_build_class_symbol (gfc_typespec *, symbol_attribute *,
gfc_array_spec **);
gfc_symbol *gfc_find_derived_vtab (gfc_symbol *);
Index: simplify.c
===
--- simplify.c (Revision 268968)
+++ simplify.c (Arbeitskopie)
@@ -4474,7 +4474,7 @@ gfc_simplify_len (gfc_expr *e, gfc_expr *kind)
/* The expression in assoc->target points to a ref to the _data component
of the unlimited polymorphic entity. To get the _len component the last
_data ref needs to be stripped and a ref to the _len component added. */
-return gfc_get_len_component (e->symtree->n.sym->assoc->target);
+return gfc_get_len_component (e->symtree->n.sym->assoc->target, k);
else
return NULL;
}
! { dg-do compile }
! { dg-options "-Wconversion" }
! PR 86119 - this used to warn.
program proglen
implicit none
class(*), allocatable :: s
integer :: l2
allocate(s, source = '123 ')
select type(s)
type is (character(len=*))
l2 = len(s)
end select
end program proglen
Re: [C++ Patch] PR 84536 ("[7/8/9 Regression] ICE with non-type template parameter")
OK.
On Tue, Feb 19, 2019 at 1:16 AM Paolo Carlini wrote:
>
> Hi,
>
> On 19/02/19 02:39, Jason Merrill wrote:
> > On 2/18/19 3:15 PM, Paolo Carlini wrote:
> >> Hi,
> >>
> >> On 19/02/19 00:52, Jason Merrill wrote:
> >>> On 2/18/19 12:14 PM, Paolo Carlini wrote:
> Hi Jason,
>
> On 18/02/19 19:28, Jason Merrill wrote:
> > On 2/18/19 5:31 AM, Paolo Carlini wrote:
> >> Hi Jason,
> >>
> >> On 18/02/19 10:20, Jason Merrill wrote:
> >>> On 2/17/19 6:58 AM, Paolo Carlini wrote:
> Hi,
>
> here, when we don't see an initializer we believe we are surely
> dealing with a case of C++17 template argument deduction for
> class templates, but, in fact, it's just an ill-formed C++14
> template variable specialization. Conveniently, we can use here
> too the predicate variable_template_specialization_p. Not 100%
> sure about the exact wording of the error message, I added '#'
> to %qD to explicitly print the auto-using type too.
> >>>
> >>> I guess we should change the assert to a test, so that we give
> >>> the error if we aren't dealing with a class template
> >>> placeholder. Variable templates don't seem to be important to
> >>> test for.
> >> Thanks, simpler patch.
> >>> This error is also pretty poor for this testcase, where there is
> >>> an initializer.
> >>
> >> Well, implementation-wise, certainly init == NULL_TREE and only
> >> when we have an empty pack this specific issue occurs.
> >>
> >> In practice, clang simply talks about an empty initializer
> >> (during instantiation, etc, like we do), whereas EDG explicitly
> >> says that pack expansion produces an empty list of expressions. I
> >> don't think that in cp_finish_decl it would be easy for us to do
> >> exactly the same, we simply see a NULL_TREE as second argument.
> >> Or we could just *assume* that we are dealing with the outcome of
> >> a pack expansion, say something like EDG even if we don't have
> >> details beyond the fact that init == NULL_TREE. I believe that
> >> without a variadic template the problem cannot occur, because we
> >> catch the empty initializer much earlier, in grokdeclarator -
> >> indeed using a !CLASS_PLACEHOLDER_TEMPLATE (auto_node) check.
> >> What do you think? Again "instantiated for an empty pack" or
> >> something similar?
> >
> > Perhaps we could complain in the code for empty pack expansion
> > handling in tsubst_init?
>
> Ah, thanks Jason. In fact, however, tsubst_init isn't currently
> involved at all, because, at the end of
> regenerate_decl_from_template we call by hand tsubst_expr and
> assign the result to DECL_INITIAL. Simply changing that avoids the
> ICE. However, the error we issue - likewise for the existing
> cpp0x/auto31.C - is the rather user-unfriendly
> "value-initialization of incomplete type ‘auto’", as produced by
> build_value_init. Thus a simple additional test along the lines
> already discussed, which now becomes much more simple to implement
> in a precise way. Again, wording only tentative. I'm also a little
> puzzled that, otherwise, we could get away with tubst_expr instead
> of tsubst_init...
> >>>
> + if (type_uses_auto (TREE_TYPE (decl)))
> +{
> + if (complain & tf_error)
> +error ("initializer for %q#D expands to an empty list "
> + "of expressions", decl);
> + return error_mark_node;
> +}
> >>>
> >>> This needs to allow the CLASS_PLACEHOLDER_TEMPLATE case.
> >>>
> >>> And yes, we mustn't call build_value_init for a dependent type; if
> >>> the type is dependent, we should just return the NULL_TREE.
> >>
> >> Good. Then I'm finishing testing the below (currently in libstdc++).
> >
> >> + if (tree auto_node = type_uses_auto (type))
> >> +if (!CLASS_PLACEHOLDER_TEMPLATE (auto_node))
> >> + {
> >> +if (complain & tf_error)
> >> + error ("initializer for %q#D expands to an empty list "
> >> + "of expressions", decl);
> >> +return error_mark_node;
> >> + }
> >> +
> >> + if (!dependent_type_p (type))
> >
> > This should probably be 'else if', since we can have auto outside of a
> > template and dependent_type_p will always return false outside of a
> > template.
>
> Ok... Note that the CLASS_PLACEHOLDER_TEMPLATE (auto_node) check in
> tsubst_init doesn't really make a difference for our testsuite and I
> have yet to find a testcase where it does. In cp_finish_decl it did, for
> sure.
>
> That said, if I understand correctly, you mean that in principle when we
> have an 'auto' outside of a template and CLASS_PLACEHOLDER_TEMPLATE is
> true, we don't want to do the build_value_init bits - which we would
> certainly do because dependent_type_p is false. If we are on the same
Re: [C++ PATCH] Fix cxx_eval_store_expression (PR c++/89336)
On Tue, Feb 19, 2019 at 4:00 AM Jakub Jelinek wrote: > On Mon, Feb 18, 2019 at 03:01:14PM -1000, Jason Merrill wrote: > > But it's not clear to me that the standard actually allows this. I don't > > think changing the active member of a union in the mem-initializer for > > another member is reasonable. > > There is in [expr.const]/2: > > an lvalue-to-rvalue conversion (7.1) that is applied to a glvalue that refers > to a non-active member of a > union or a subobject thereof; > > an assignment expression (8.18) or invocation of an assignment operator > (15.8) that would change the > active member of a union; > > in C++17 it seems, so maybe my union testcases are accepts-invalid. > This has been introduced in P0137R1 and removed again in P1330R0. Does that > mean e.g. following is valid in C++14, invalid in C++17 and valid again in > C++20? Or has one of the above papers changed retroactively previous > standards? Before P0137 I believe foo and bar were arguably undefined. Jason
[PATCH, testsuite] Enable vect_usad_char effective target for PowerPC and fix up SAD_EXPR testcases
Power9 added support for V16QImode SAD operations. While making the
check_effective_target change I noticed that the tests will also pass on
Power7/Power8 even though they don't have the optab support. The reason is the
tests are only checking that the source pattern is recognized, not that a
SAD_EXPR was actually generated. So I've updated the tests also.
Ok for trunk?
-Pat
testsuite/ChangeLog:
2019-02-19 Pat Haugen
* lib/target-supports.exp (check_effective_target_vect_usad_char):
Add PowerPC support.
* gcc.dg/vect/slp-reduc-sad.c: Update scan string.
* gcc.dg/vect/vect-reduc-sad.c: Likewise.
Index: gcc/testsuite/lib/target-supports.exp
===
--- gcc/testsuite/lib/target-supports.exp (revision 268784)
+++ gcc/testsuite/lib/target-supports.exp (working copy)
@@ -5982,7 +5982,9 @@ proc check_effective_target_vect_usad_ch
expr { [istarget i?86-*-*]
|| [istarget x86_64-*-*]
|| ([istarget aarch64*-*-*]
- && ![check_effective_target_aarch64_sve])}}]
+ && ![check_effective_target_aarch64_sve])
+ || ([istarget powerpc*-*-*]
+ && [check_p9vector_hw_available])}}]
}
# Return 1 if the target plus current options supports both signed
Index: gcc/testsuite/gcc.dg/vect/slp-reduc-sad.c
===
--- gcc/testsuite/gcc.dg/vect/slp-reduc-sad.c (revision 268784)
+++ gcc/testsuite/gcc.dg/vect/slp-reduc-sad.c (working copy)
@@ -58,6 +58,6 @@ main ()
return 0;
}
-/* { dg-final { scan-tree-dump "vect_recog_sad_pattern: detected" "vect" } } */
+/* { dg-final { scan-tree-dump "sad pattern recognized" "vect" } } */
/* { dg-final { scan-tree-dump "vectorizing stmts using SLP" "vect" } } */
/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */
Index: gcc/testsuite/gcc.dg/vect/vect-reduc-sad.c
===
--- gcc/testsuite/gcc.dg/vect/vect-reduc-sad.c (revision 268784)
+++ gcc/testsuite/gcc.dg/vect/vect-reduc-sad.c (working copy)
@@ -49,6 +49,6 @@ main (void)
return 0;
}
-/* { dg-final { scan-tree-dump-times "vect_recog_sad_pattern: detected" 1
"vect" } } */
+/* { dg-final { scan-tree-dump-times "sad pattern recognized" 1 "vect" } } */
/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */
[PATCH v2][rs6000] PR89338, PR89339: Fix compat vector intrinsics for BE and 32-bit
Test FAILS: sse2-cvtpd2dq-1, sse2-cvtpd2ps, sse2-cvttpd2dq on powerpc64
(big-endian).
_mm_cvtpd_epi32, _mm_cvtpd_ps, _mm_cvttpd_epi32: Type conversion from
vector doubleword type to vector word type leaves the results in even
lanes in big endian mode.
Test FAILS: sse-cvtss2si-1, sse-cvtss2si-2, sse-movmskb-1 on powerpc
(32-bit big-endian).
Incorrect type for interpreting the result from mfvsrd instruction leads
to incorrect results. Also, mfvsrd instruction only works as expected in
64-bit mode or for 32-bit quantities in 32-bit mode. A more general,
if slower, solution is needed for 32-bit mode.
2019-02-19 Paul A. Clarke
[gcc]
* config/rs6000/emmintrin.h (_mm_cvtpd_epi32): Fix big endian.
(_mm_cvtpd_ps): Likewise.
(_mm_cvttpd_epi32): Likewise.
PR89338
* config/rs6000/xmmintrin.h (_mm_cvtss_f32): Fix type mismatch.
(_mm_cvt_ss2si): Fix type mismatch and 32-bit.
PR89339
* config/rs6000/xmmintrin.h (_mm_movemask_pi8): Fix 32-bit.
---
v2: more elegant solution for the 32-bit mode fix in _mm_movemask_pi8,
as suggested by Segher.
Index: gcc/config/rs6000/emmintrin.h
===
diff --git a/trunk/gcc/config/rs6000/emmintrin.h
b/trunk/gcc/config/rs6000/emmintrin.h
--- a/trunk/gcc/config/rs6000/emmintrin.h (revision 268997)
+++ b/trunk/gcc/config/rs6000/emmintrin.h (working copy)
@@ -887,7 +887,11 @@ _mm_cvtpd_epi32 (__m128d __A)
: );
#ifdef _ARCH_PWR8
+#ifdef __LITTLE_ENDIAN__
temp = vec_mergeo (temp, temp);
+#else
+ temp = vec_mergee (temp, temp);
+#endif
result = (__v4si) vec_vpkudum ((__vector long long) temp,
(__vector long long) vzero);
#else
@@ -922,7 +926,11 @@ _mm_cvtpd_ps (__m128d __A)
: );
#ifdef _ARCH_PWR8
+#ifdef __LITTLE_ENDIAN__
temp = vec_mergeo (temp, temp);
+#else
+ temp = vec_mergee (temp, temp);
+#endif
result = (__v4sf) vec_vpkudum ((__vector long long) temp,
(__vector long long) vzero);
#else
@@ -951,7 +959,11 @@ _mm_cvttpd_epi32 (__m128d __A)
: );
#ifdef _ARCH_PWR8
+#ifdef __LITTLE_ENDIAN__
temp = vec_mergeo (temp, temp);
+#else
+ temp = vec_mergee (temp, temp);
+#endif
result = (__v4si) vec_vpkudum ((__vector long long) temp,
(__vector long long) vzero);
#else
Index: gcc/config/rs6000/xmmintrin.h
===
diff --git a/trunk/gcc/config/rs6000/xmmintrin.h
b/trunk/gcc/config/rs6000/xmmintrin.h
--- a/trunk/gcc/config/rs6000/xmmintrin.h (revision 268997)
+++ b/trunk/gcc/config/rs6000/xmmintrin.h (working copy)
@@ -905,7 +905,7 @@ _mm_cvtss_f32 (__m128 __A)
extern __inline int __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_cvtss_si32 (__m128 __A)
{
- __m64 res = 0;
+ int res;
#ifdef _ARCH_PWR8
double dtmp;
__asm__(
@@ -938,8 +938,8 @@ _mm_cvt_ss2si (__m128 __A)
extern __inline long long __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_cvtss_si64 (__m128 __A)
{
- __m64 res = 0;
-#ifdef _ARCH_PWR8
+ long long res;
+#if defined (_ARCH_PWR8) && defined (__powerpc64__)
double dtmp;
__asm__(
#ifdef __LITTLE_ENDIAN__
@@ -1577,6 +1577,7 @@ _m_pminub (__m64 __A, __m64 __B)
extern __inline int __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_movemask_pi8 (__m64 __A)
{
+#ifdef __powerpc64__
unsigned long long p =
#ifdef __LITTLE_ENDIAN__
0x0008101820283038UL; // permute control for sign bits
@@ -1584,6 +1585,12 @@ _mm_movemask_pi8 (__m64 __A)
0x3830282018100800UL; // permute control for sign bits
#endif
return __builtin_bpermd (p, __A);
+#else
+ unsigned int mask = 0x20283038UL;
+ unsigned int r1 = __builtin_bpermd (mask, __A) & 0xf;
+ unsigned int r2 = __builtin_bpermd (mask, __A >> 32) & 0xf;
+ return (r2 << 4) | r1;
+#endif
}
extern __inline int __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
Re: [PATCH] 386: Set ix86_fpmath to FPMATH_387 without SSE
On Tue, Feb 19, 2019 at 6:16 AM Uros Bizjak wrote:
>
> On Tue, Feb 19, 2019 at 2:49 PM H.J. Lu wrote:
> >
> > ix86_fpmath should be set to combination of FPMATH_387 and FPMATH_SSE.
> > When SSE is disabled, it should be set to FPMATH_387 and 387 codegen is
> > also controlled by -msoft-float.
> >
> > gcc/
> >
> > PR target/89397
> > * config/i386/i386.c (ix86_option_override_internal): Set
> > opts->x_ix86_fpmath to FPMATH_387 when SSE is disabled.
> >
> > gcc/testsuite/
> >
> > PR target/89397
> > * gcc.target/i386/pr89397.c: New test.
>
> OK.
>
This patch is need to fix:
FAIL: gcc.target/i386/pr67985-3.c scan-assembler movd[ \t]%xmm[0-7], %eax
FAIL: gcc.target/i386/pr67985-3.c scan-assembler mulss
OK for trunk?
Thanks.
--
H.J.
From 6d7cf57984055c640465450dc9ed74da093b5768 Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Tue, 19 Feb 2019 12:05:12 -0800
Subject: [PATCH] i386: Adjust gcc.target/i386/pr67985-3.c
Since -march=lakemont turns off 80387 and SSE,
-miamcu -mfpmath=sse -march=lakemont
results in -mfpmath=387, __attribute__((target("arch=haswell"))) doesn't
enable SSE FP math. SSE shouldn't be used for FP math in pr67985-3.c.
PR target/89397
* gcc.target/i386/pr67985-3.c: Update.
---
gcc/testsuite/gcc.target/i386/pr67985-3.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.target/i386/pr67985-3.c b/gcc/testsuite/gcc.target/i386/pr67985-3.c
index 10705f5b231..e863d5b3bb4 100644
--- a/gcc/testsuite/gcc.target/i386/pr67985-3.c
+++ b/gcc/testsuite/gcc.target/i386/pr67985-3.c
@@ -8,5 +8,6 @@ foo (float x, float y)
return x * y;
}
-/* { dg-final { scan-assembler "mulss" } } */
-/* { dg-final { scan-assembler "movd\[ \t\]%xmm\[0-7\], %eax" } } */
+/* { dg-final { scan-assembler-not "mulss" } } */
+/* { dg-final { scan-assembler-not "movl\[ \t\].*, %eax" } } */
+/* { dg-final { scan-assembler-not "call\[ \t\]__mulsf3" } } */
--
2.20.1
Re: [rs6000] 64-bit integer loads/stores and FP instructions
On Thu, Feb 14, 2019 at 05:30:52PM +0100, Eric Botcazou wrote: > > Yeah, something like that. It will need some serious testing, to make > > sure we don't regress (including not regressing what that patch that took > > them away was meant to do). I can arrange some testing, will you do the > > patch though? > > I can do the patch and also (correctness) testing for 32-bit Linux. Performance testing is important here, of course. > Another issue is the extent of the patch: practically speaking, putting back > the '*' modifier before all the 'd' constraints would be sufficient, but the > current setting is a bit inconsistent|*] so this could also be adjusted. > > [*] For example, in the *movdi_internal32 pattern, 2 'wi' constraints have it > but not the other 2. Likewise for "wv'. I think we should change as little as possible for 7/8/9 here, because this is pretty fragile :-( But for 10, yes, let's get more sanity. (We'll have the "enabled" attribute for GCC 10, btw). Segher
Re: [PATCH] Capture source location of dtors (PR c++/89390)
On Tue, Feb 19, 2019 at 02:44:55PM -0500, David Malcolm wrote:
> How about something like this? (on top of Jakub's patch)
I had following queued for regtest, so if you want to go for the
make_location ^~, you should change more spots.
> pr89390.C: In function 'void foo()':
> pr89390.C:9:6: error: '~A' is not a member of 'A'
> 9 | A::~A ();// { dg-error "6: '~A' is not a member of 'A'" }
> | ^~
> pr89390.C: In function 'void test_2()':
> pr89390.C:17:10: error: '~ns::P' is not a member of 'ns::P'
>17 | ns::P::~P ();// { dg-error "10: '~ns::P' is not a member of
> 'ns::P'" }
> | ^~
>
> (Presumably gcc 10 material at this point; not yet bootstrapped).
I wouldn't say so, it actually is even a regression:
$ /usr/src/gcc-6/obj/gcc/cc1plus -quiet pr89390.C
pr89390.C: In function ‘void foo()’:
pr89390.C:9:3: error: ‘~A’ is not a member of ‘A’
A::~A (); // { dg-error "'~A' is not a member of 'A'" }
^
$ /usr/src/gcc-7/obj/gcc/cc1plus -quiet pr89390.C
In function ‘void foo()’:
cc1plus: error: ‘~A’ is not a member of ‘A’
Feel free to take this over though.
2019-02-19 Jakub Jelinek
PR c++/89390
* parser.c (cp_parser_unqualified_id): For BIT_NOT_EXPR remember
location of the ~ token and use it to build cp_expr.
* g++.dg/diagnostic/pr89390.C (foo): Expect diagnostics at the right
line.
--- gcc/cp/parser.c.jj 2019-02-18 20:48:37.669649863 +0100
+++ gcc/cp/parser.c 2019-02-19 10:41:14.090972524 +0100
@@ -5976,6 +5976,7 @@ cp_parser_unqualified_id (cp_parser* par
tree object_scope;
tree scope;
bool done;
+ location_t loc = token->location;
/* Consume the `~' token. */
cp_lexer_consume_token (parser->lexer);
@@ -6050,7 +6051,7 @@ cp_parser_unqualified_id (cp_parser* par
&& constructor_name_p (token->u.value, scope
{
cp_lexer_consume_token (parser->lexer);
- return build_nt (BIT_NOT_EXPR, scope);
+ return cp_expr (build_nt (BIT_NOT_EXPR, scope), loc);
}
/* ~auto means the destructor of whatever the object is. */
@@ -6061,7 +6062,7 @@ cp_parser_unqualified_id (cp_parser* par
"%<~auto%> only available with "
"-std=c++14 or -std=gnu++14");
cp_lexer_consume_token (parser->lexer);
- return build_nt (BIT_NOT_EXPR, make_auto ());
+ return cp_expr (build_nt (BIT_NOT_EXPR, make_auto ()), loc);
}
/* If there was an explicit qualification (S::~T), first look
@@ -6152,7 +6153,7 @@ cp_parser_unqualified_id (cp_parser* par
type_decl = cp_parser_identifier (parser);
if (type_decl != error_mark_node)
type_decl = build_nt (BIT_NOT_EXPR, type_decl);
- return type_decl;
+ return cp_expr (type_decl, loc);
}
}
/* If an error occurred, assume that the name of the
@@ -6187,7 +6188,7 @@ cp_parser_unqualified_id (cp_parser* par
"typedef-name %qD used as destructor declarator",
type_decl);
- return build_nt (BIT_NOT_EXPR, TREE_TYPE (type_decl));
+ return cp_expr (build_nt (BIT_NOT_EXPR, TREE_TYPE (type_decl)), loc);
}
case CPP_KEYWORD:
--- gcc/testsuite/g++.dg/diagnostic/pr89390.C.jj2019-02-19
09:38:21.816096390 +0100
+++ gcc/testsuite/g++.dg/diagnostic/pr89390.C 2019-02-19 10:41:58.867234266
+0100
@@ -6,5 +6,5 @@ enum class A { B, C };
void
foo ()
{
- A::~A ();// { dg-error "'~A' is not a member of 'A'" "" { target *-*-* }
0 }
+ A::~A ();// { dg-error "'~A' is not a member of 'A'" }
}
Jakub
Re: [PATCH] rs6000: Add support for the vec_sbox_be, vec_cipher_be etc. builtins.
On Tue, Feb 12, 2019 at 02:00:38PM +0800, Xiong Hu Luo wrote:
> On 2019/1/26 AM1:43, Segher Boessenkool wrote:
> >On Wed, Jan 23, 2019 at 03:57:28AM -0600, luo...@linux.vnet.ibm.com wrote:
> >>The 5 new builtins vec_sbox_be, vec_cipher_be, vec_cipherlast_be,
> >>vec_ncipher_be
> >>and vec_ncipherlast_be only support vector unsigned char type parameters.
> >>Add new instruction crypto_vsbox_ and crypto__ to
> >>handle
> >>them accordingly, where the new mode CR_vqdi can be expanded to vector
> >>unsigned
> >>long long for none _be postfix builtins or vector unsigned char for _be
> >>postfix
> >>builtins.
> >
> >Hrm, can't you use the existing CR_mode iterator here?
> >
> >>2019-01-23 Xiong Hu Luo
> >>
> >>* gcc/testsuite/gcc.target/powerpc/crypto-builtin-1.c
> >>(crpyto1_be, crpyto2_be, crpyto3_be, crpyto4_be, crpyto5_be):
> >> New testcases.
> >
> >Typoes ("crypto"). And that last line is indented incorrectly.
> >
> >With those things fixed, okay for trunk, with the new iterator if CR_mode
> >isn't usable here. Thanks!
>
> Thanks, I will fix the typos and indent.
> CR_mode support all the 4 types(v16qi, v8hi, v4si and v2di), so we
> define the new mode CR_vqdi to represent only 2 types(v16qi and v2di) we
> need, means that these two modes cannot be reused.
> BTW, does this patch need back port to gcc-7 and gcc-8?
[ Sorry, I think I forgot to reply to this. ]
They probably should be backported, yes. Okay to backport after 8.3 has
been released. Thanks!
Segher
[PATCH] Capture source location of dtors (PR c++/89390)
On Mon, 2019-02-18 at 14:07 -1000, Jason Merrill wrote:
> On 2/18/19 12:50 PM, Jakub Jelinek wrote:
> > Hi!
> >
> > On the following testcase we ICE because name is BIT_NOT_EXPR and
> > suggest_alternative_in_scoped_enum assumes it is called on
> > IDENTIFIER_NODE
> > only.
> >
> > Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-
> > linux, ok for
> > trunk?
>
> OK.
>
> > There is another issue, starting with 7.x we don't use sensible
> > location in
> > the diagnostics, 6.x emitted
> > pr89390.C: In function ‘void foo()’:
> > pr89390.C:9:3: error: ‘~A’ is not a member of ‘A’
> > A::~A (); // { dg-error "'~A' is not a member of 'A'" }
> > ^
> > but 7.x and later emits:
> > In function ‘void foo()’:
> > cc1plus: error: ‘~A’ is not a member of ‘A’
> >
> > This patch doesn't deal with that, but would be nice to provide
> > location,
> > dunno if it is enough to just use location of ~, or if we need to
> > spend
> > memory and build ~A as combined range with caret on ~.
It should only cost memory if strlen(A) is > 30, since otherwise the
result will have caret==start and strlen() <= 31 and so hit the
optimized range representation.
>
> I think having a range for a destructor id-expression would be
> appropriate.
>
> Jason
How about something like this? (on top of Jakub's patch)
pr89390.C: In function 'void foo()':
pr89390.C:9:6: error: '~A' is not a member of 'A'
9 | A::~A ();// { dg-error "6: '~A' is not a member of 'A'" }
| ^~
pr89390.C: In function 'void test_2()':
pr89390.C:17:10: error: '~ns::P' is not a member of 'ns::P'
17 | ns::P::~P ();// { dg-error "10: '~ns::P' is not a member of
'ns::P'" }
| ^~
(Presumably gcc 10 material at this point; not yet bootstrapped).
gcc/cp/ChangeLog:
PR c++/89390
* parser.c (cp_parser_unqualified_id): Capture locations for
destructors.
gcc/testsuite/ChangeLog:
PR c++/89390
* g++.dg/diagnostic/pr89390.C: Update expected location of error.
Add testcase within namespace.
---
gcc/cp/parser.c | 9 -
gcc/testsuite/g++.dg/diagnostic/pr89390.C | 10 +-
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index ffecce4..e6fdb34 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -5976,6 +5976,7 @@ cp_parser_unqualified_id (cp_parser* parser,
tree object_scope;
tree scope;
bool done;
+ location_t tilde_loc = token->location;
/* Consume the `~' token. */
cp_lexer_consume_token (parser->lexer);
@@ -6049,8 +6050,14 @@ cp_parser_unqualified_id (cp_parser* parser,
|| (CLASS_TYPE_P (scope)
&& constructor_name_p (token->u.value, scope
{
+ /* Create a location with caret == start at the tilde,
+ finishing at the end of the peeked token, e.g:
+~class_name
+^~~. */
+ location_t loc
+ = make_location (tilde_loc, tilde_loc, token->location);
cp_lexer_consume_token (parser->lexer);
- return build_nt (BIT_NOT_EXPR, scope);
+ return cp_expr (build_nt (BIT_NOT_EXPR, scope), loc);
}
/* ~auto means the destructor of whatever the object is. */
diff --git a/gcc/testsuite/g++.dg/diagnostic/pr89390.C
b/gcc/testsuite/g++.dg/diagnostic/pr89390.C
index df35fcc..91a6422 100644
--- a/gcc/testsuite/g++.dg/diagnostic/pr89390.C
+++ b/gcc/testsuite/g++.dg/diagnostic/pr89390.C
@@ -6,5 +6,13 @@ enum class A { B, C };
void
foo ()
{
- A::~A ();// { dg-error "'~A' is not a member of 'A'" "" { target *-*-* }
0 }
+ A::~A ();// { dg-error "6: '~A' is not a member of 'A'" }
+}
+
+namespace ns { enum class P { Q, R }; }
+
+void
+test_2 ()
+{
+ ns::P::~P ();// { dg-error "10: '~ns::P' is not a member of 'ns::P'" }
}
--
1.8.5.3
[COMMITTED] Fix pr88850 test
Fix pr88850.c testcase which was failing in hardfp environments.
Committed as obvious.
ChangeLog:
2019-02-19 Wilco Dijkstra
* gcc.target/arm/pr88850.c: Block -mfloat-abi override.
--
diff --git a/gcc/testsuite/gcc.target/arm/pr88850.c
b/gcc/testsuite/gcc.target/arm/pr88850.c
index
6edd6bcee54dbc843b539ff67399ee7a30a707e4..67fe942a8b8755c18ce8971c3b48011613988a6a
100644
--- a/gcc/testsuite/gcc.target/arm/pr88850.c
+++ b/gcc/testsuite/gcc.target/arm/pr88850.c
@@ -1,6 +1,7 @@
/* PR target/88850 */
/* { dg-do compile } */
-/* { dg-additional-options "-O2 -march=armv7-a -mfloat-abi=softfp -mfpu=neon
-fdump-rtl-final" } */
+/* { dg-skip-if "do not override -mfloat-abi" { *-*-* } { "-mfloat-abi=*" }
{"-mfloat-abi=soft" } } */
+/* { dg-options "-O2 -march=armv7-a -mfloat-abi=softfp -mfpu=neon
-fdump-rtl-final" } */
/* { dg-require-effective-target arm_neon_ok } */
typedef __builtin_neon_qi int8x8_t __attribute__ ((__vector_size__ (8)));
Go patch committed: Add debugger-callable ASP dump functions
This patch to the Go frontend by Than McIntosh adds some
debugger-callable AST dump functions, similar to function like
debug_tree or debug_rtx. They are all named debug_go_xxx.
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 269019)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-fe0382eabbf1e8b148dc8cb7733348bd9d887e10
+08cd59a502127da776e076a8a37016a668ef27fa
The first line of this file holds the git revision number of the last
merge done from the gofrontend repository.
Index: gcc/go/gofrontend/ast-dump.cc
===
--- gcc/go/gofrontend/ast-dump.cc (revision 268949)
+++ gcc/go/gofrontend/ast-dump.cc (working copy)
@@ -482,7 +482,7 @@ Ast_dump_context::write_string(const std
this->ostream() << s;
}
-// Dump statment to stream.
+// Dump statement to stream.
void
Ast_dump_context::dump_to_stream(const Statement* stm, std::ostream* out)
@@ -499,3 +499,84 @@ Ast_dump_context::dump_to_stream(const E
Ast_dump_context adc(out, false);
expr->dump_expression();
}
+
+// Dump an expression to std::cerr. This is intended to be used
+// from within a debugging session.
+
+void
+debug_go_expression(const Expression* expr)
+{
+ if (expr == NULL)
+std::cerr << "";
+ else
+{
+ Ast_dump_context::dump_to_stream(expr, ::cerr);
+ std::string lstr = Linemap::location_to_string(expr->location());
+ std::cerr << " // loc " << lstr << std::endl;
+}
+}
+
+// Shallow dump of stmt to std::cerr. This is intended to be used
+// from within a debugging session.
+
+void
+debug_go_statement(const Statement* stmt)
+{
+ if (stmt == NULL)
+std::cerr << "\n";
+ else
+{
+ std::string lstr = Linemap::location_to_string(stmt->location());
+ Statement *ncstmt = const_cast(stmt);
+ Block_statement* bs = ncstmt->block_statement();
+ if (bs != NULL)
+std::cerr << "Block " << bs->block()
+ << " // location: " << lstr << std::endl;
+ else
+Ast_dump_context::dump_to_stream(stmt, ::cerr);
+}
+}
+
+// Deep dump of statement to std::cerr. This is intended to be used
+// from within a debugging session.
+
+void
+debug_go_statement_deep(const Statement* statement)
+{
+ Ast_dump_context adc(::cerr, true);
+ statement->dump_statement();
+}
+
+// Shallow dump of a block to std::cerr. This is intended to be used
+// from within a debugging session.
+
+void
+debug_go_block(const Block* block)
+{
+ if (block == NULL)
+std::cerr << "";
+ else
+{
+ std::cerr << "Block " << block
+<< " (enclosing " << block->enclosing() << "):\n";
+ const std::vector* stmts = block->statements();
+ if (stmts != NULL)
+{
+ for (size_t i = 0; i < stmts->size(); ++i)
+{
+ debug_go_statement(stmts->at(i));
+}
+}
+}
+}
+
+// Deep dump of a block to std:cerr. This is intended to be used
+// from within a debugging session.
+
+void
+debug_go_block_deep(const Block* block)
+{
+ Ast_dump_context adc(::cerr, true);
+ Block* ncblock = const_cast(block);
+ adc.dump_block(ncblock);
+}
Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.
On Mon, Feb 18, 2019 at 02:23:34PM +0100, Martin Liška wrote:
>
> As I installed all needed patches, I'm sending a documentation entry
> for the new functionality.
>
> Thoughts?
See below. Ok to commit with suggested changes.
> Thanks,
> Martin
> >From 2d304e3b1d734548811f963c5bed1855b5375c43 Mon Sep 17 00:00:00 2001
> From: marxin
> Date: Mon, 18 Feb 2019 14:21:56 +0100
> Subject: [PATCH] Document Fortran header directive.
>
> ---
> gcc/fortran/gfortran.texi | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
> index 02ff32f741f..72771a851f7 100644
> --- a/gcc/fortran/gfortran.texi
> +++ b/gcc/fortran/gfortran.texi
> @@ -3596,6 +3596,25 @@ loop that follows. N is an integer constant
> specifying the unrolling factor.
> The values of 0 and 1 block any unrolling of the loop.
>
>
> +@node BUILTIN directive
> +@subsection BUILTIN directive
> +
> +The syntax of the directive is
> +
> +@code{!GCC$ BUILTIN (B) attributes simd FLAGS IF('target')}
> +
> +You can used this directive to define which middle-end built-ins have vector
s/used/use
> +implementation. B is name of the middle-end built-in. FLAGS are optional
s/B is/@code{B} is the
S/FLAGS/@code{FLAGS}
> +and must have be either "(inbranch)" or "(notinbranch)". IF statement
delete 'have'
s/IF/The @code{IF}
> +is optional and is used to filter multilib ABIs for that
> +the built-in should be vectorized. Example usage:
Change "for that the built-in should be vectorized" to
"for the built-in that should be vectorized"
> +
> +@smallexample
> +!GCC$ builtin (sinf) attributes simd (notinbranch) if('x86_64')
> +@end smallexample
> +
> +The purpose of the directive is to provide an API among the GCC compiler and
> +the GNU C Library which would define vector implementation of math routines.
>
> @node Non-Fortran Main Program
> @section Non-Fortran Main Program
> --
> 2.20.1
>
--
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow
Re: [patch, fortran] Fix PR 87689, wrong decls / ABI violation on POWER
On 2/18/19 12:48 AM, Janne Blomqvist wrote: On Sun, Feb 17, 2019 at 8:19 PM Thomas Koenig wrote: Hello world, the attached patch fixes a rather bad ABI violation on POWER systems. ... I agree, although we're close to the GCC-9 release, it's better to get this in now. So Ok. I wonder if we shouldn't exorcise all the varargs stuff, it seems to cause more problems than benefits? But not in stage4 if we can avoid it.. Please don't. Some of us still use varargs interfaces (in my case, Fortran calling C stdarg subroutines). Thanks... -Bob Deen @ NASA-JPL Multimission Image Processing Lab bob.d...@jpl.nasa.gov
Re: [PATCH] Teach evrp that main's argc argument is always non-negative for C family (PR tree-optimization/89350)
On Tue, 19 Feb 2019, Martin Sebor wrote: > Sure, the text is in a section named Program startup, but that doesn't > imply that the constraints apply only at program startup. If they did, I think it's clear from the context that the section is describing the interface between the program and its environment, not the interface between a recursive caller of main and the so-called instance of main - that argc and argv there refer to the specific argc and argv objects for the initial call of main, not the different objects involved in any recursive call. Furthermore, the statement that the parameters can be modified does not restrict such modifications to preserving the given properties (normal practice such as ++argv; --argc; would mean that there are sequence points at which those objects do not have the properties given). > there would be no constraints on the parameters in any other calls to > main, which would make the parameters unusable in general (because > there is no way for main to tell if it's the fist invocation). If a program chooses to call main recursively, presumably it has its own way to tell (e.g. some global variable the call to main can check). -- Joseph S. Myers jos...@codesourcery.com
Re: [patch] Fix LRA/reload issue with -fnon-call-exceptions
> Doesn't the frame have to be laid out correctly during the final reload > subpass anyway, in order to get the right elimination choices and > elimination offsets? If so, I'm not sure what the " && > info->reload_completed" check in rs6000_stack_info achieves. It seems like > that's at least partly responsible for the problem. Clearly a comment would be in order. I'm not sure it's responsible for the problem, unless you mean that it's papering over the underlying issue, in which case you're probably right. This underlying issue is probably that: /* Calculate which registers need to be saved & save area size. */ info->first_gp_reg_save = first_reg_to_save (); overlooks the specific status of the frame pointer, i.e. it doesn't test frame_pointer_needed explicitly, which I think is pretty much mandatory. The rest of the code apparently works correctly despite this though. > I realise you've already applied it and that you saw it as a hack too, > but this seems like a bit too much. IMO a cleaner fix would be to define > TARGET_COMPUTE_FRAME_LAYOUT for rs6000. Well, it's a hack on top of a big kludge (the get_initial_register_offset stuff in rtlanal.c) so it can be viewed as a safety net too. :-) > I guess that approach means that TARGET_COMPUTE_FRAME_LAYOUT isn't really > optional though. IMO another workaround for the underlying issue. -- Eric Botcazou
Re: [rs6000] PR89338, PR89339: Fix compat vector intrinsics for BE and 32-bit
Hi Paul,
On Tue, Feb 19, 2019 at 10:10:38AM -0600, Paul Clarke wrote:
> Incorrect type for interpreting the result from mfvsrd instruction leads
> to incorrect results. Also, mfvsrd instruction only works as expected in
> 64-bit mode or for 32-bit quantities in 32-bit mode. A more general,
> if slower, solution is needed for 32-bit mode.
You cannot use 64-bit registers in 32 bit mode on Linux, yes.
> @@ -1577,6 +1577,7 @@ _m_pminub (__m64 __A, __m64 __B)
> extern __inline int __attribute__((__gnu_inline__, __always_inline__,
> __artificial__))
> _mm_movemask_pi8 (__m64 __A)
> {
> +#ifdef __powerpc64__
>unsigned long long p =
> #ifdef __LITTLE_ENDIAN__
> 0x0008101820283038UL; // permute control for sign
> bits
> @@ -1584,6 +1585,18 @@ _mm_movemask_pi8 (__m64 __A)
> 0x3830282018100800UL; // permute control for sign
> bits
> #endif
>return __builtin_bpermd (p, __A);
> +#else
> + vector unsigned char A = (vector unsigned char)
> +(vector unsigned long long) { 0, __A };
> + vector unsigned char mask = {
> +0x38, 0x30, 0x28, 0x20, 0x18, 0x10, 0x08, 0x00,
> +0x78, 0x70, 0x68, 0x60, 0x58, 0x50, 0x48, 0x40
> + };
> + vector unsigned long long r = (vector unsigned long long)
> +vec_bperm (A, mask);
> + return r[0];
> +#endif
Wow, how inelegant. Not that splitting the word into two and doing two
__builtin_bpermd will be much better :-/
Okay for trunk. Thanks!
Segher
Re: [PATCH][C++] Fix ICE with VTV
On Tue, Feb 19, 2019 at 1:57 AM Richard Biener wrote: > > Looks like vtv_generate_init_routine calls symtab->process_new_functions > () which has seriously bad effects on GCCs internal memory state. > > VTV has zero testsuite coverage it seems and besides its initial > commit didn't receive any love. > I am puzzled by these statements, as neither of them is true. VTV does have a testsuite in the libvtv directory. Naturally you can only run them when vtv is enabled and only from the libvtv build tree, as they will all fail if VTV is not enabled. I have fixed various bugs in VTV since the initial commit, and I have also approved several patches, especially for people migrating it to other architectures, suggesting that interest in it is not zero. > > Can we rip it out please? > > Is the patch OK? (Pointless) bootstrap and regtest running on > x86_64-unknown-linux-gnu. > > Has anybody "recently" tried to enable the feature and tested the > result? > I have not tried building it recently, but will do so. I will review your patch to see if it makes sense. I would prefer that VTV not be 'ripped out' of GCC, and will do whatever I can, within reason, to try to fix its issues. > > Thanks, > Richard. > > 2019-02-19 Richard Biener > > PR middle-end/89392 > cp/ > * vtable-class-hierarchy.c (vtv_generate_init_routine): Do not > make symtab process new functions here. > > Index: gcc/cp/vtable-class-hierarchy.c > === > --- gcc/cp/vtable-class-hierarchy.c (revision 269009) > +++ gcc/cp/vtable-class-hierarchy.c (working copy) > @@ -1191,8 +1191,6 @@ vtv_generate_init_routine (void) >gimplify_function_tree (vtv_fndecl); >cgraph_node::add_new_function (vtv_fndecl, false); > > - symtab->process_new_functions (); > - >if (flag_vtable_verify == VTV_PREINIT_PRIORITY && !TARGET_PECOFF) > assemble_vtv_preinit_initializer (vtv_fndecl); > >
Re: [PATCH] Teach evrp that main's argc argument is always non-negative for C family (PR tree-optimization/89350)
On 2/18/19 4:12 PM, Joseph Myers wrote: On Sat, 16 Feb 2019, Jakub Jelinek wrote: Hi! Both the C and C++ standard guarantee that the argc argument to main is non-negative, the following patch sets (or adjusts) the corresponding SSA_NAME_RANGE_INFO. While main is just one, with IPA VRP it can also propagate etc. I had to change one testcase because it started optimizing it better (the test has been folded away), so no sinking was done. In C, unlike in C++, it's valid to call main recursively. I think the requirements on argc and argv must be understood to apply only to their values on entry to the initial call to main, not to any recursive calls. What do you base that interpretation on? The C constraints aren't qualified as applying only to the initial call. The text simply says that If they are declared, the parameters to the main function shall obey the following constraints: -- The value of argc shall be nonnegative. -- argv[argc] shall be a null pointer. Sure, the text is in a section named Program startup, but that doesn't imply that the constraints apply only at program startup. If they did, there would be no constraints on the parameters in any other calls to main, which would make the parameters unusable in general (because there is no way for main to tell if it's the fist invocation). Martin So I don't think this optimization is valid for C (in the absence of whole-program information that can prove the absence of any recursive calls).
[PATCH, libgcc] Fixup _UnwindGetGR for function argument rename
Revision 256615 (SVE unwinding) renamed _UnwindGetGR function argument, but forgot to update part under #ifdef DWARF_ZERO_REG. 2019-02-19 Uroš Bizjak * unwind-dw2.c (_Unwind_GetGR) [DWARF_ZERO_REG]: Compare regno instead of index to DWARF_ZERO_REG. Bootstrapped on alphaev68-linux-gnu and committed to mainline and gcc-8 as obvious. Uros. diff --git a/libgcc/unwind-dw2.c b/libgcc/unwind-dw2.c index bd88df963957..e6130af2fb54 100644 --- a/libgcc/unwind-dw2.c +++ b/libgcc/unwind-dw2.c @@ -225,7 +225,7 @@ _Unwind_GetGR (struct _Unwind_Context *context, int regno) _Unwind_Context_Reg_Val val; #ifdef DWARF_ZERO_REG - if (index == DWARF_ZERO_REG) + if (regno == DWARF_ZERO_REG) return 0; #endif
[rs6000] PR89338, PR89339: Fix compat vector intrinsics for BE and 32-bit
Test FAILS: sse2-cvtpd2dq-1, sse2-cvtpd2ps, sse2-cvttpd2dq on powerpc64
(big-endian).
_mm_cvtpd_epi32, _mm_cvtpd_ps, _mm_cvttpd_epi32: Type conversion from
vector doubleword type to vector word type leaves the results in even
lanes in big endian mode.
Test FAILS: sse-cvtss2si-1, sse-cvtss2si-2, sse-movmskb-1 on powerpc
(32-bit big-endian).
Incorrect type for interpreting the result from mfvsrd instruction leads
to incorrect results. Also, mfvsrd instruction only works as expected in
64-bit mode or for 32-bit quantities in 32-bit mode. A more general,
if slower, solution is needed for 32-bit mode.
2019-02-19 Paul A. Clarke
[gcc]
* config/rs6000/emmintrin.h (_mm_cvtpd_epi32): Fix big endian.
(_mm_cvtpd_ps): Likewise.
(_mm_cvttpd_epi32): Likewise.
PR89338
* config/rs6000/xmmintrin.h (_mm_cvtss_f32): Fix type mismatch.
(_mm_cvt_ss2si): Fix type mismatch and 32-bit.
PR89339
* config/rs6000/xmmintrin.h (_mm_movemask_pi8): Fix 32-bit.
Index: gcc/config/rs6000/emmintrin.h
===
diff --git a/trunk/gcc/config/rs6000/emmintrin.h
b/trunk/gcc/config/rs6000/emmintrin.h
--- a/trunk/gcc/config/rs6000/emmintrin.h (revision 268997)
+++ b/trunk/gcc/config/rs6000/emmintrin.h (working copy)
@@ -887,7 +887,11 @@ _mm_cvtpd_epi32 (__m128d __A)
: );
#ifdef _ARCH_PWR8
+#ifdef __LITTLE_ENDIAN__
temp = vec_mergeo (temp, temp);
+#else
+ temp = vec_mergee (temp, temp);
+#endif
result = (__v4si) vec_vpkudum ((__vector long long) temp,
(__vector long long) vzero);
#else
@@ -922,7 +926,11 @@ _mm_cvtpd_ps (__m128d __A)
: );
#ifdef _ARCH_PWR8
+#ifdef __LITTLE_ENDIAN__
temp = vec_mergeo (temp, temp);
+#else
+ temp = vec_mergee (temp, temp);
+#endif
result = (__v4sf) vec_vpkudum ((__vector long long) temp,
(__vector long long) vzero);
#else
@@ -951,7 +959,11 @@ _mm_cvttpd_epi32 (__m128d __A)
: );
#ifdef _ARCH_PWR8
+#ifdef __LITTLE_ENDIAN__
temp = vec_mergeo (temp, temp);
+#else
+ temp = vec_mergee (temp, temp);
+#endif
result = (__v4si) vec_vpkudum ((__vector long long) temp,
(__vector long long) vzero);
#else
Index: gcc/config/rs6000/xmmintrin.h
===
diff --git a/trunk/gcc/config/rs6000/xmmintrin.h
b/trunk/gcc/config/rs6000/xmmintrin.h
--- a/trunk/gcc/config/rs6000/xmmintrin.h (revision 268997)
+++ b/trunk/gcc/config/rs6000/xmmintrin.h (working copy)
@@ -905,7 +905,7 @@ _mm_cvtss_f32 (__m128 __A)
extern __inline int __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_cvtss_si32 (__m128 __A)
{
- __m64 res = 0;
+ int res;
#ifdef _ARCH_PWR8
double dtmp;
__asm__(
@@ -938,8 +938,8 @@ _mm_cvt_ss2si (__m128 __A)
extern __inline long long __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_cvtss_si64 (__m128 __A)
{
- __m64 res = 0;
-#ifdef _ARCH_PWR8
+ long long res;
+#if defined (_ARCH_PWR8) && defined (__powerpc64__)
double dtmp;
__asm__(
#ifdef __LITTLE_ENDIAN__
@@ -1577,6 +1577,7 @@ _m_pminub (__m64 __A, __m64 __B)
extern __inline int __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_movemask_pi8 (__m64 __A)
{
+#ifdef __powerpc64__
unsigned long long p =
#ifdef __LITTLE_ENDIAN__
0x0008101820283038UL; // permute control for sign bits
@@ -1584,6 +1585,18 @@ _mm_movemask_pi8 (__m64 __A)
0x3830282018100800UL; // permute control for sign bits
#endif
return __builtin_bpermd (p, __A);
+#else
+ vector unsigned char A = (vector unsigned char)
+(vector unsigned long long) { 0, __A };
+ vector unsigned char mask = {
+0x38, 0x30, 0x28, 0x20, 0x18, 0x10, 0x08, 0x00,
+0x78, 0x70, 0x68, 0x60, 0x58, 0x50, 0x48, 0x40
+ };
+ vector unsigned long long r = (vector unsigned long long)
+vec_bperm (A, mask);
+ return r[0];
+#endif
+
}
extern __inline int __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
Re: [PATCH, OpenACC] Properly handle wait clause with no arguments
Hi Chung-Lin!
On Tue, 22 Jan 2019 13:16:37 +0100, I wrote:
> On Mon, 14 Jan 2019 21:56:05 +0800, Chung-Lin Tang
> wrote:
> > this version of the wait-clause-with-no-args patch revises the following:
> Thanks.
>
> > Hope this is now okay for trunk when appropriate.
>
> Given that this is a wrong-code generation bug fix, I do approve this in
> the current GCC development stage (and will later backport to the other
> release branches), but please include the following changes as discussed
> before: mention PR87924 "OpenACC wait clauses without async-arguments" in
> the ChangeLogs and commit log
Thanks for committing this, trunk r269016.
> and remove the XFAILs in
> "c-c++-common/goacc/asyncwait-5.c" and "gfortran.dg/goacc/asyncwait-5.f".
This I now have done myself, in trunk r269020 "[PR87924] OpenACC wait
clauses without async-arguments: remove XFAILs", attached.
Grüße
Thomas
>From 3eedad7ade57021a843447e8b6cba9619ac5b39e Mon Sep 17 00:00:00 2001
From: tschwinge
Date: Tue, 19 Feb 2019 16:04:17 +
Subject: [PATCH] [PR87924] OpenACC wait clauses without async-arguments:
remove XFAILs
... which the recent r269016 didn't do.
gcc/testsuite/
PR c/87924
* c-c++-common/goacc/asyncwait-5.c: Remove XFAILs.
* gfortran.dg/goacc/asyncwait-5.f: Likewise.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@269020 138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/testsuite/ChangeLog| 6 ++
gcc/testsuite/c-c++-common/goacc/asyncwait-5.c | 10 +-
gcc/testsuite/gfortran.dg/goacc/asyncwait-5.f | 10 +-
3 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 5796a150c0d..1c91cec1a81 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,9 @@
+2019-02-19 Thomas Schwinge
+
+ PR c/87924
+ * c-c++-common/goacc/asyncwait-5.c: Remove XFAILs.
+ * gfortran.dg/goacc/asyncwait-5.f: Likewise.
+
2019-02-19 H.J. Lu
PR target/89397
diff --git a/gcc/testsuite/c-c++-common/goacc/asyncwait-5.c b/gcc/testsuite/c-c++-common/goacc/asyncwait-5.c
index 80d4a8477b9..f4ba48a1833 100644
--- a/gcc/testsuite/c-c++-common/goacc/asyncwait-5.c
+++ b/gcc/testsuite/c-c++-common/goacc/asyncwait-5.c
@@ -15,21 +15,21 @@ void f()
#pragma acc parallel async (3) wait
;
- /* { dg-final { scan-tree-dump-times "(?n)#pragma acc parallel wait\\(-1\\) async\\(3\\)$" 1 "original" { xfail *-*-* } } } */
+ /* { dg-final { scan-tree-dump-times "(?n)#pragma acc parallel wait\\(-1\\) async\\(3\\)$" 1 "original" } } */
#pragma acc parallel async (4) wait (100) wait
;
- /* { dg-final { scan-tree-dump-times "(?n)#pragma acc parallel wait\\(-1\\) wait\\(100\\) async\\(4\\)$" 1 "original" { xfail *-*-* } } } */
+ /* { dg-final { scan-tree-dump-times "(?n)#pragma acc parallel wait\\(-1\\) wait\\(100\\) async\\(4\\)$" 1 "original" } } */
#pragma acc parallel async (5) wait wait (101)
;
- /* { dg-final { scan-tree-dump-times "(?n)#pragma acc parallel wait\\(101\\) wait\\(-1\\) async\\(5\\)$" 1 "original" { xfail *-*-* } } } */
+ /* { dg-final { scan-tree-dump-times "(?n)#pragma acc parallel wait\\(101\\) wait\\(-1\\) async\\(5\\)$" 1 "original" } } */
#pragma acc parallel async (6) wait wait (102, 103) wait wait
;
- /* { dg-final { scan-tree-dump-times "(?n)#pragma acc parallel wait\\(-1\\) wait\\(-1\\) wait\\(103\\) wait\\(102\\) wait\\(-1\\) async\\(6\\)$" 1 "original" { xfail *-*-* } } } */
+ /* { dg-final { scan-tree-dump-times "(?n)#pragma acc parallel wait\\(-1\\) wait\\(-1\\) wait\\(103\\) wait\\(102\\) wait\\(-1\\) async\\(6\\)$" 1 "original" } } */
#pragma acc parallel async (7) wait (104) wait wait (105, 106)
;
- /* { dg-final { scan-tree-dump-times "(?n)#pragma acc parallel wait\\(106\\) wait\\(105\\) wait\\(-1\\) wait\\(104\\) async\\(7\\)$" 1 "original" { xfail *-*-* } } } */
+ /* { dg-final { scan-tree-dump-times "(?n)#pragma acc parallel wait\\(106\\) wait\\(105\\) wait\\(-1\\) wait\\(104\\) async\\(7\\)$" 1 "original" } } */
}
diff --git a/gcc/testsuite/gfortran.dg/goacc/asyncwait-5.f b/gcc/testsuite/gfortran.dg/goacc/asyncwait-5.f
index 7ad5813b8a0..89cd7923590 100644
--- a/gcc/testsuite/gfortran.dg/goacc/asyncwait-5.f
+++ b/gcc/testsuite/gfortran.dg/goacc/asyncwait-5.f
@@ -12,22 +12,22 @@
!$ACC PARALLEL ASYNC (3) WAIT
!$ACC END PARALLEL
-! { dg-final { scan-tree-dump-times "(?n)#pragma acc parallel async\\(3\\) wait\\(-1\\)$" 1 "original" { xfail *-*-* } } }
+! { dg-final { scan-tree-dump-times "(?n)#pragma acc parallel async\\(3\\) wait\\(-1\\)$" 1 "original" } }
!$ACC PARALLEL ASYNC (4) WAIT (100) WAIT
!$ACC END PARALLEL
-! { dg-final { scan-tree-dump-times "(?n)#pragma acc parallel async\\(4\\) wait\\(100\\) wait\\(-1\\)$" 1 "original" { xfail *-*-* } } }
+! { dg-final { scan-tree-dump-times "(?n)#pragma acc parallel async\\(4\\) wait\\(100\\) wait\\(-1\\)$" 1 "original" } }
!$ACC PARALLEL ASYNC (5) WAIT WAIT (101)
!$ACC END PARALLEL
-! { dg-final {
Re: [omp] Move NE_EXPR handling to omp_adjust_for_condition
On Fri, Feb 15, 2019 at 12:49:58PM +0100, Martin Jambor wrote: > Ping please, the issue is now PR 89302. Please add the PR line to the ChangeLog entry. > > 2019-02-01 Martin Jambor > > > > * omp-general.c (omp_extract_for_data): Removed a duplicate call > > to omp_adjust_for_condition, moved NE_EXPR code_cond processing... > > (omp_adjust_for_condition): ...here. Added necessary parameters. > > * omp-general.h (omp_adjust_for_condition): Updated declaration. > > * omp-grid.c (grid_attempt_target_gridification): Adjust to pass > > proper values to new parameters of omp_adjust_for_condition. Ok, thanks. Jakub
libgo patch committed: Do not require POWER8
Although the gc toolchain requires POWER8, gccgo does not. This libgo
patch removes a check that POWER8 is required. This fixes GCC PR
89169. Bootstrapped and tested on x86_64-pc-linux-gnu and
ppc64-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 269018)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-672572130ba7a7b277a4c9c8f93576fc42accf63
+fe0382eabbf1e8b148dc8cb7733348bd9d887e10
The first line of this file holds the git revision number of the last
merge done from the gofrontend repository.
Index: libgo/go/internal/cpu/cpu_ppc64x.go
===
--- libgo/go/internal/cpu/cpu_ppc64x.go (revision 268949)
+++ libgo/go/internal/cpu/cpu_ppc64x.go (working copy)
@@ -29,9 +29,7 @@ func doinit() {
{Name: "darn", Feature: },
{Name: "scv", Feature: },
{Name: "power9", Feature: },
-
- // These capabilities should always be enabled on ppc64 and
ppc64le:
- {Name: "power8", Feature: , Required: true},
+ {Name: "power8", Feature: },
}
// HWCAP2 feature bits
libgo patch committed: Stop stack scan when we can't unwind stack
This libgo patch by Cherry Zhang stops the stack scan when the stack
can not be unwound. In a signal-triggered stack scan, if the signal
is delivered at certain bad time (e.g. in vdso, or in the middle of
setcontext?), the unwinder may not be able to unwind the whole stack,
while it still reports _URC_END_OF_STACK. So we cannot rely on
_URC_END_OF_STACK to tell if it successfully scanned the stack.
Instead, we check the last Go frame to see it actually reached the end
of the stack. For Go-created stack, this is runtime.kickoff. For
C-created stack, we need to record the outermost Go frame when it
enters the Go side.
Also we cannot unwind the stack if the signal is delivered in the
middle of runtime.gogo, halfway through a goroutine switch, where the
g and the stack don't match. Give up in this case as well.
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 268952)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-9605c2efd99aa9c744652a9153e208e0653b8596
+672572130ba7a7b277a4c9c8f93576fc42accf63
The first line of this file holds the git revision number of the last
merge done from the gofrontend repository.
Index: libgo/go/runtime/cgo_gccgo.go
===
--- libgo/go/runtime/cgo_gccgo.go (revision 268949)
+++ libgo/go/runtime/cgo_gccgo.go (working copy)
@@ -80,6 +80,10 @@ func CgocallBack() {
gp = getg()
mp := gp.m
mp.dropextram = true
+
+ // This is a C-created stack.
+ // Record the outermost Go frame to help stack scan.
+ gp.entrysp = getcallersp()
}
lockOSThread()
Index: libgo/go/runtime/proc.go
===
--- libgo/go/runtime/proc.go(revision 268949)
+++ libgo/go/runtime/proc.go(working copy)
@@ -1192,6 +1192,9 @@ func kickoff() {
gp.param = nil
}
+ // Record the entry SP to help stack scan.
+ gp.entrysp = getsp()
+
fv(param)
goexit1()
}
Index: libgo/go/runtime/runtime2.go
===
--- libgo/go/runtime/runtime2.go(revision 268949)
+++ libgo/go/runtime/runtime2.go(working copy)
@@ -433,6 +433,7 @@ type g struct {
entryfunc(unsafe.Pointer) // goroutine function to run
entryfn uintptr // function address passed to __go_go
+ entrysp uintptr // the stack pointer of the outermost Go
frame
fromgogo bool // whether entered from gogo function
scanningself bool // whether goroutine is scanning its own stack
Index: libgo/go/runtime/stubs.go
===
--- libgo/go/runtime/stubs.go (revision 268949)
+++ libgo/go/runtime/stubs.go (working copy)
@@ -231,6 +231,10 @@ func getcallerpc() uintptr
//go:noescape
func getcallersp() uintptr // implemented as an intrinsic on all platforms
+// getsp returns the stack pointer (SP) of the caller of getsp.
+//go:noinline
+func getsp() uintptr { return getcallersp() }
+
func asmcgocall(fn, arg unsafe.Pointer) int32 {
throw("asmcgocall")
return 0
Index: libgo/runtime/go-unwind.c
===
--- libgo/runtime/go-unwind.c (revision 268949)
+++ libgo/runtime/go-unwind.c (working copy)
@@ -649,6 +649,19 @@ findstackmaps (struct _Unwind_Context *c
_sleb128_t index;
int size;
+#ifdef HAVE_GETIPINFO
+ ip1 = _Unwind_GetIPInfo (context, _before_insn);
+#else
+ ip1 = _Unwind_GetIP (context);
+#endif
+ if (! ip_before_insn)
+--ip1;
+
+ if (ip != NULL)
+*ip = ip1;
+ if (sp != NULL)
+*sp = _Unwind_GetCFA (context);
+
#ifdef __ARM_EABI_UNWINDER__
{
_Unwind_Control_Block *ucbp;
@@ -672,14 +685,6 @@ findstackmaps (struct _Unwind_Context *c
if (info.TType == NULL)
return NOTFOUND_OK;
-#ifdef HAVE_GETIPINFO
- ip1 = _Unwind_GetIPInfo (context, _before_insn);
-#else
- ip1 = _Unwind_GetIP (context);
-#endif
- if (! ip_before_insn)
---ip1;
-
size = value_size (info.ttype_encoding);
action_record = NULL;
@@ -738,15 +743,16 @@ findstackmaps (struct _Unwind_Context *c
if (stackmap1 == NULL)
return NOTFOUND_BAD;
- if (ip != NULL)
-*ip = ip1;
- if (sp != NULL)
-*sp = _Unwind_GetCFA (context);
if (stackmap != NULL)
*stackmap = stackmap1;
return FOUND;
}
+struct scanstate {
+ void* gcw; // the GC worker, passed into scanstackwithmap_callback
+ uintptr lastsp; // the last (outermost) SP of Go function seen in a
traceback, set by the callback
+};
+
// Callback function to scan a stack frame with stack maps.
// It skips
Re: [PATCH] 386: Set ix86_fpmath to FPMATH_387 without SSE
On Tue, Feb 19, 2019 at 2:49 PM H.J. Lu wrote:
>
> ix86_fpmath should be set to combination of FPMATH_387 and FPMATH_SSE.
> When SSE is disabled, it should be set to FPMATH_387 and 387 codegen is
> also controlled by -msoft-float.
>
> gcc/
>
> PR target/89397
> * config/i386/i386.c (ix86_option_override_internal): Set
> opts->x_ix86_fpmath to FPMATH_387 when SSE is disabled.
>
> gcc/testsuite/
>
> PR target/89397
> * gcc.target/i386/pr89397.c: New test.
OK.
Thanks,
Uros.
> ---
> gcc/config/i386/i386.c | 7 +++
> gcc/testsuite/gcc.target/i386/pr89397.c | 11 +++
> 2 files changed, 14 insertions(+), 4 deletions(-)
> create mode 100644 gcc/testsuite/gcc.target/i386/pr89397.c
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 591a7cdccdc..bed17330fa8 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -4310,10 +4310,9 @@ ix86_option_override_internal (bool main_args_p,
> if (!TARGET_SSE_P (opts->x_ix86_isa_flags))
> {
> if (TARGET_80387_P (opts->x_target_flags))
> - {
> - warning (0, "SSE instruction set disabled, using 387
> arithmetics");
> - opts->x_ix86_fpmath = FPMATH_387;
> - }
> + warning (0, "SSE instruction set disabled, using 387
> arithmetics");
> + /* NB: 387 codegen is guarded by TARGET_80387. */
> + opts->x_ix86_fpmath = FPMATH_387;
> }
> else if ((opts->x_ix86_fpmath & FPMATH_387)
>&& !TARGET_80387_P (opts->x_target_flags))
> diff --git a/gcc/testsuite/gcc.target/i386/pr89397.c
> b/gcc/testsuite/gcc.target/i386/pr89397.c
> new file mode 100644
> index 000..42afa6c5247
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr89397.c
> @@ -0,0 +1,11 @@
> +/* { dg-do compile } */
> +/* { dg-options "-mfpmath=sse,387 -msoft-float -mno-sse" } */
> +
> +_Atomic double a;
> +int b;
> +
> +void
> +foo (void)
> +{
> + a += b; /* { dg-error "SSE register return with SSE disabled" "" { target
> { ! ia32 } } } */
> +}
> --
> 2.20.1
>
Re: [PATCH] rs6000: Fix PR 88100, range check for vec_splat_{su}{8,16,32}
Hi!
On Tue, Feb 19, 2019 at 03:38:56AM -0600, Li Jia He wrote:
> GCC revision 259524 implemented range check for the vec_splat_{su}{8,16,32}
> builtins. However, as a consequence of the implementation, the range check
> is not done correctly for the expected vspltis[bhw] instructions. The result
> is that we may not get a valid error message if the valid range of the data
> is exceeded.
> PR target/88100
> * gcc/config/rs6000/rs6000.c (rs6000_gimple_fold_builtin): Remove
> sext_hwi in IN_RANGE (sext_hwi (TREE_INT_CST_LOW (arg0), size),
> -16, 15).
Please avoid more than a word or two of C in changelogs. Also, in such
cases you should show the case labels:
PR target/88100
* gcc/config/rs6000/rs6000.c (rs6000_gimple_fold_builtin)
: Don't convert the operand before range
checking it.
Okay for trunk with that. Thanks!
Segher
Re: [C++ PATCH] Fix cxx_eval_store_expression (PR c++/89336)
On Mon, Feb 18, 2019 at 03:01:14PM -1000, Jason Merrill wrote:
> But it's not clear to me that the standard actually allows this. I don't
> think changing the active member of a union in the mem-initializer for
> another member is reasonable.
There is in [expr.const]/2:
an lvalue-to-rvalue conversion (7.1) that is applied to a glvalue that refers
to a non-active member of a
union or a subobject thereof;
an assignment expression (8.18) or invocation of an assignment operator (15.8)
that would change the
active member of a union;
in C++17 it seems, so maybe my union testcases are accepts-invalid.
This has been introduced in P0137R1 and removed again in P1330R0. Does that
mean e.g. following is valid in C++14, invalid in C++17 and valid again in
C++20? Or has one of the above papers changed retroactively previous
standards?
// PR c++/89336
// { dg-do compile { target c++14 } }
constexpr int
foo ()
{
union U { int a; long b; };
union V { union U u; short v; };
V w {};
w.u.a = w.v = w.u.b = 5L;
return w.u.a;
}
static_assert (foo () == 5, "");
constexpr int
bar ()
{
union U { int a[5]; long b; };
union V { union U u; short v; };
V w {};
w.v = 5;
w.u.a[3] = w.u.a[1] = w.v;
return w.u.a[1] + w.u.a[3];
}
static_assert (bar () == 10, "");
struct Z { int x, y; };
constexpr Z
baz ()
{
union W { Z a; long long w; };
W w {};
w.a = { 5, 0 };
w.a = { (int) (w.w = 17LL + w.a.x), 2 };
return w.a;
}
static_assert (baz ().x == 22, "");
static_assert (baz ().y == 2, "");
Jakub
[PATCH] 386: Set ix86_fpmath to FPMATH_387 without SSE
ix86_fpmath should be set to combination of FPMATH_387 and FPMATH_SSE.
When SSE is disabled, it should be set to FPMATH_387 and 387 codegen is
also controlled by -msoft-float.
gcc/
PR target/89397
* config/i386/i386.c (ix86_option_override_internal): Set
opts->x_ix86_fpmath to FPMATH_387 when SSE is disabled.
gcc/testsuite/
PR target/89397
* gcc.target/i386/pr89397.c: New test.
---
gcc/config/i386/i386.c | 7 +++
gcc/testsuite/gcc.target/i386/pr89397.c | 11 +++
2 files changed, 14 insertions(+), 4 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/i386/pr89397.c
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 591a7cdccdc..bed17330fa8 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -4310,10 +4310,9 @@ ix86_option_override_internal (bool main_args_p,
if (!TARGET_SSE_P (opts->x_ix86_isa_flags))
{
if (TARGET_80387_P (opts->x_target_flags))
- {
- warning (0, "SSE instruction set disabled, using 387
arithmetics");
- opts->x_ix86_fpmath = FPMATH_387;
- }
+ warning (0, "SSE instruction set disabled, using 387
arithmetics");
+ /* NB: 387 codegen is guarded by TARGET_80387. */
+ opts->x_ix86_fpmath = FPMATH_387;
}
else if ((opts->x_ix86_fpmath & FPMATH_387)
&& !TARGET_80387_P (opts->x_target_flags))
diff --git a/gcc/testsuite/gcc.target/i386/pr89397.c
b/gcc/testsuite/gcc.target/i386/pr89397.c
new file mode 100644
index 000..42afa6c5247
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr89397.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-mfpmath=sse,387 -msoft-float -mno-sse" } */
+
+_Atomic double a;
+int b;
+
+void
+foo (void)
+{
+ a += b; /* { dg-error "SSE register return with SSE disabled" "" { target {
! ia32 } } } */
+}
--
2.20.1
Re: [PATCH, stage1] Construct ipa_reduced_postorder always for overwritable (PR ipa/89009).
Hi,
On Tue, Feb 19 2019, Martin Liška wrote:
> On 2/14/19 11:19 AM, Jan Hubicka wrote:
>>
...
>> Next stage1 we should also teach the callback to ignore edges of calls
>> that are not being optimized.
>
> I'm sending patch for that.
...
> gcc/ChangeLog:
>
> 2019-02-19 Martin Liska
>
> * ipa-cp.c (ignore_edge_p): New function.
> (build_toporder_info): Use it.
> * ipa-inline.c (ignore_edge_p): New function/
> (inline_small_functions): Use it.
> * ipa-pure-const.c (ignore_edge_for_nothrow):
> Verify opt_for_fn for caller and callee.
> (ignore_edge_for_pure_const): Likewise.
> * ipa-reference.c (ignore_edge_p): Extend to check
> for opt_for_fn.
> * ipa-utils.c (searchc): Refactor.
> * ipa-utils.h: Fix coding style.
> ---
> gcc/ipa-cp.c | 18 +-
> gcc/ipa-inline.c | 12 +++-
> gcc/ipa-pure-const.c | 17 -
> gcc/ipa-reference.c | 13 ++---
> gcc/ipa-utils.c | 3 +--
> gcc/ipa-utils.h | 2 --
> 6 files changed, 51 insertions(+), 14 deletions(-)
>
> diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
> index 442d5c63eff..004b3a34b1c 100644
> --- a/gcc/ipa-cp.c
> +++ b/gcc/ipa-cp.c
> @@ -806,6 +806,21 @@ public:
>{}
> };
>
> +/* Skip edges from and to nodes without ipa_cp enabled.
> + Ignore not available symbols. */
> +
> +static bool
> +ignore_edge_p (cgraph_edge *e)
> +{
> + enum availability avail;
> + e->callee->function_or_virtual_thunk_symbol (, e->caller);
Can't the return value of this call be directly fed...
> +
> + return (avail <= AVAIL_INTERPOSABLE
> + || !opt_for_fn (e->caller->decl, flag_ipa_cp)
> + || !opt_for_fn (e->callee->function_symbol ()->decl,
...here instead of calling function_symbol... which does not look
through thunks which IMHO you want, even if only for consistency.
Otherwise, it the IPA-CP bits obviously look good,
Martin
Re: [PATCH][GCC][DOC] Remove obsolete arm and aarch64 CPU names from invoke.texi
On Fri, 15 Feb 2019, Sam Tebbs wrote: > I was looking into this and it seems that the CPU and architecture > removals have already been documented in the Arm-specific section of the > GCC 9 changes, so explicitly mentioning that the documentation has been > removed as well is probably unnecessary. Yes, that's a good point. Sorry for sending you on a false chase. Gerald
Re: Go patch committed: Harmonize types referenced by both C and Go
Hi Ian, > On Mon, Feb 18, 2019 at 2:48 AM Rainer Orth > wrote: >> >> > The code was already calling syscall, it was just doing it in a way >> > that the types didn't necessarily match the C declaration. This is >> > the implementation of Go's syscall.Syscall function, so there isn't >> > really anything else we can do. >> >> I feared as much. Some time ago when debugging another issue I saw >> libgo using syscall() directly, certainly unexpected in that particular >> case. > > Those cases--where libgo calls syscall.Syscall--we can clean up where > appropriate. What we can't clean up is user written Go code that > calls syscall.Syscall directly. I'll keep an eye open for the former when looking into the remaining Go failures. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [libphobos, build] Enable libphobos on Solaris 11/x86
Hi Iain, >> Thanks. This will have to wait for >> >> [libphobos] Use sections_elf_shared.d on Solaris 11.5 (PR d/88150) >> https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01661.html > > I'll make a fork of sections support tonight, as that seems to be the > right way forwards. > > Other parts will need upstreaming, I can do that as well. that would be great, thanks. >> and >> [libphobos] Work around lack of dlpi_tls_modid before Solaris 11.5 >> https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01664.html >> > > Johannes has already commented there, and he is right about needing a > way to get tls data from DSOs. Understood. Maybe I can find a way to generalize the hack derived from sections_ldc.d to TLS segments outside the executable. >> of course. Maybe even >> >> [libphobos] Work around Solaris ld bug linking __tls_get_addr on >> 64-bit x86 >> https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01663.html >> >> will be needed depending on whether a proper ld fix makes it into >> Solaris 11.5 or not. > > I'm not sure about this, but haven't looked at it properly just yet. I don't think you need concern yourself with this very much: it's just a hack around a Solaris ld bug, suggested by the Solaris linker engineers for the moment. Once the dlpi_tls_modid patch lands in Solaris 11.5 (this week or next), I'll ask if they see a chance to have that bug fixed in time for the Solaris 11.5 release. If so, nobody besides myself will ever be exposed to this issue. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[PATCH] Remove unused extern variables from debug (PR debug/86964)
Adding so that the DIEs of unused external variables can be removed from the
output when
using -feliminate-unused-debug-symbols.
Tested on x86_64-elf, aarch64-elf, powerpc-eabi, powerpc64-elf and arm-eabi.
2019-02-18 Johan Karlsson
PR debug/86964
* dwarf2out.c (premark_used_variables): New function.
(prune_unused_types_walk): Do not mark not premarked external
variables.
(prune_unused_types): Call premark_used_variables.
* gcc.dg/debug/dwarf2/pr86964.c: New testcase.
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 268977)
+++ gcc/dwarf2out.c (working copy)
@@ -22658,6 +22658,21 @@ premark_types_used_by_global_vars (void)
->traverse (NULL);
}
+/* Mark all variables used by the symtab as perennial. */
+
+static void
+premark_used_variables (void)
+{
+ /* Mark DIEs in the symtab as used. */
+ varpool_node *var;
+ FOR_EACH_VARIABLE (var)
+{
+ dw_die_ref die = lookup_decl_die (var->decl);
+ if (die)
+ die->die_perennial_p = 1;
+}
+}
+
/* Generate a DW_TAG_call_site DIE in function DECL under SUBR_DIE
for CA_LOC call arg loc node. */
@@ -29264,6 +29279,19 @@ prune_unused_types_walk (dw_die_ref die)
return;
+case DW_TAG_variable:
+ if (flag_debug_only_used_symbols)
+ {
+ if (die->die_perennial_p)
+ break;
+
+ /* premark_used_variables marks external variables --- don't mark
+them here. */
+ if (get_AT (die, DW_AT_external))
+ return;
+ }
+ /* FALLTHROUGH */
+
default:
/* Mark everything else. */
break;
@@ -29390,6 +29418,10 @@ prune_unused_types (void)
/* Mark types that are used in global variables. */
premark_types_used_by_global_vars ();
+ /* Mark variables used in the symtab. */
+ if (flag_debug_only_used_symbols)
+premark_used_variables ();
+
/* Set the mark on nodes that are actually used. */
prune_unused_types_walk (comp_unit_die ());
for (node = limbo_die_list; node; node = node->next)
Index: gcc/testsuite/gcc.dg/debug/dwarf2/pr86964.c
===
--- gcc/testsuite/gcc.dg/debug/dwarf2/pr86964.c (nonexistent)
+++ gcc/testsuite/gcc.dg/debug/dwarf2/pr86964.c (working copy)
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -gdwarf -feliminate-unused-debug-symbols -dA" } */
+
+struct S { int i; };
+extern struct S x;
+int y;
+int main()
+{
+ return y;
+}
+
+/* We should elide the DIEs for x and S but not y. */
+/* { dg-final { scan-assembler-times "DW_TAG_variable" 2 } } */
+/* { dg-final { scan-assembler-not "DW_TAG_structure_type" } } */
Re: [patch] Fix LRA/reload issue with -fnon-call-exceptions
Eric Botcazou writes:
> Hi,
>
> this is a regression present on all active branches since the controversial
> get_initial_register_offset stuff was added to rtlanal.c some time ago, and
> visible in the testsuite on PowerPC/Linux under the form of gnat.dg/opt73.adb
> timing out at run time.
>
> The problem is that the compiler generates code that doesn't save the frame
> pointer before clobbering it, because rs6000_stack_info computes a wrong
> final
> (post-reload) stack layout. The scenario is as follows: LRA decides to use
> the frame pointer, sets reload_completed to 1 at the end and then does:
>
> /* We've possibly turned single trapping insn into multiple ones. */
> if (cfun->can_throw_non_call_exceptions)
> {
> auto_sbitmap blocks (last_basic_block_for_fn (cfun));
> bitmap_ones (blocks);
> find_many_sub_basic_blocks (blocks);
> }
>
> But find_many_sub_basic_blocks calls control_flow_insn_p, which in turn can
> call rtx_addr_can_trap_p_1, which can call get_initial_register_offset, which
> uses INITIAL_ELIMINATION_OFFSET, IOW rs6000_initial_elimination_offset, which
> calls rs6000_stack_info. But at this point the DF information hasn't been
> updated so the frame pointer isn't detected as live by df_regs_ever_live_p.
Doesn't the frame have to be laid out correctly during the final reload
subpass anyway, in order to get the right elimination choices and
elimination offsets? If so, I'm not sure what the " && info->reload_completed"
check in rs6000_stack_info achieves. It seems like that's at least partly
responsible for the problem.
> You may think that the fix is just to set reload_completed to 1 after the
> above code in lra, but that's not sufficient because the same issue can arise
> from the do_reload function:
>
> if (optimize)
> cleanup_cfg (CLEANUP_EXPENSIVE);
>
> when checking is enabled, because cleanup_cfg can calls control_flow_insn_p
> and then eventually rtx_addr_can_trap_p_1. In other words, we would need
> to set reload_completed to 1 only after the above code, which is very late.
> As a matter of fact, that's not possible for old reload itself because of:
>
> /* We must set reload_completed now since the cleanup_subreg_operands call
> below will re-recognize each insn and reload may have generated insns
> which are only valid during and after reload. */
> reload_completed = 1;
>
> So, barring the removal of the get_initial_register_offset stuff, the only
> simple fix is probably to prevent it from calling into the back-end too
> early,
> for example with the attached fixlet. Tested on x86-64 and PowerPC/Linux.
>
> Thoughts? Where do we want to fix this?
>
>
> * rtlanal.c (get_initial_register_offset): Fall back to the raw estimate
> as long as the epilogue isn't completed.
I realise you've already applied it and that you saw it as a hack too,
but this seems like a bit too much. IMO a cleaner fix would be to define
TARGET_COMPUTE_FRAME_LAYOUT for rs6000.
I guess that approach means that TARGET_COMPUTE_FRAME_LAYOUT isn't really
optional though.
Thanks,
Richard
Re: Fix libphobos testsuite failures on Solaris
Hi Iain,
> On Tue, 29 Jan 2019 at 15:44, Rainer Orth
> wrote:
>>
>> Yet another trivial fix for a Solaris libphobos testsuite failure:
>>
>> FAIL: libphobos.shared/load.d -shared-libphobos -ldl (test for excess errors)
>> Excess errors:
>> /vol/gcc/src/hg/trunk/local/libphobos/testsuite/libphobos.shared/load.d:9:
>> error: static assert "unimplemented"
>>
>> I guess this is obvious? Tested on i386-pc-solaris2.11. Ok for
>> mainline?
>>
>
> Looks ok.
>
> As the OS-specific bindings are only imported for RTLD_NOLOAD, this
> could be made explicit in the static assert.
>
> ---
> import core.sys.posix.dlfcn;
>
> version (DragonFlyBSD) import core.sys.dragonflybsd.dlfcn : RTLD_NOLOAD;
> version (FreeBSD) import core.sys.freebsd.dlfcn : RTLD_NOLOAD;
> version (linux) import core.sys.linux.dlfcn : RTLD_NOLOAD;
> version (NetBSD) import core.sys.netbsd.dlfcn : RTLD_NOLOAD;
> version (OSX) import core.sys.darwin.dlfcn : RTLD_NOLOAD;
> version (Solaris) import core.sys.solaris.dlfcn : RTLD_NOLOAD;
>
> static assert(__traits(compiles, RTLD_NOLOAD), "unimplemented");
> ---
indeed, that's certainly clearer. Here's what I've committed after
testing on Linux/x86_64 (all libphobos.shared tests continue to pass)
and Solaris 11.5/x86 with dlpi_tls_modid (load.d compiles, but fails at
runtime as before:
core.exception.AssertError@/vol/gcc/src/hg/trunk/solaris-asan/libphobos/testsuite/libphobos.shared/load.d(147):
Assertion failure
That's the same dlclose issue as discussed in PR d/88150 and the
gcc-patches thread starting at
https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01661.html
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
2019-02-19 Iain Buclaw
* testsuite/libphobos.shared/load.d: Import core.sys.posix.dlfcn.
[DragonFlyBSD, FreeBSD, linux, NetBSD, OSX, Solaris]: Import only
RTLD_NOLOAD from core.sys.*.dlfcn.
Assert RTLD_NOLOAD is available.
# HG changeset patch
# Parent f954e54dcb5f39ad242574b49c3a99645396e20e
Fix libphobos testsuite failures on Solaris
diff --git a/libphobos/testsuite/libphobos.shared/load.d b/libphobos/testsuite/libphobos.shared/load.d
--- a/libphobos/testsuite/libphobos.shared/load.d
+++ b/libphobos/testsuite/libphobos.shared/load.d
@@ -3,10 +3,16 @@ import core.stdc.stdio;
import core.stdc.string;
import core.thread;
-version (linux) import core.sys.linux.dlfcn;
-else version (FreeBSD) import core.sys.freebsd.dlfcn;
-else version (NetBSD) import core.sys.netbsd.dlfcn;
-else static assert(0, "unimplemented");
+import core.sys.posix.dlfcn;
+
+version (DragonFlyBSD) import core.sys.dragonflybsd.dlfcn : RTLD_NOLOAD;
+version (FreeBSD) import core.sys.freebsd.dlfcn : RTLD_NOLOAD;
+version (linux) import core.sys.linux.dlfcn : RTLD_NOLOAD;
+version (NetBSD) import core.sys.netbsd.dlfcn : RTLD_NOLOAD;
+version (OSX) import core.sys.darwin.dlfcn : RTLD_NOLOAD;
+version (Solaris) import core.sys.solaris.dlfcn : RTLD_NOLOAD;
+
+static assert(__traits(compiles, RTLD_NOLOAD), "unimplemented");
void loadSym(T)(void* handle, ref T val, const char* mangle)
{
[PATCH] Fix PR88074
The following limits mpfr operations to the maximum exponent range as
determined by available float modes. This avoids excessive work
for evaluating functions like ctan for large arguments.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2019-02-19 Richard Biener
PR middle-end/88074
* toplev.c (do_compile): Initialize mpfr's exponent range
based on available float modes.
* gcc.dg/pr88074.c: New testcase.
diff --git a/gcc/testsuite/gcc.dg/pr88074.c b/gcc/testsuite/gcc.dg/pr88074.c
new file mode 100644
index 000..9f64cc11424
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr88074.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-O" } */
+
+#include
+
+int main()
+{
+ _Complex double x;
+ __real x = 3.091e+8;
+ __imag x = -4.045e+8;
+ /* This used to spend huge amounts of compile-time inside mpc. */
+ volatile _Complex double y = ctan (x);
+ return 0;
+}
diff --git a/gcc/toplev.c b/gcc/toplev.c
index ab20cd98969..fa8e1b78c99 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -2153,6 +2153,30 @@ do_compile ()
else
int_n_enabled_p[i] = false;
+ /* Initialize mpfrs exponent range. This is important to get
+ underflow/overflow in a reasonable timeframe. */
+ machine_mode mode;
+ int min_exp = -1;
+ int max_exp = 1;
+ FOR_EACH_MODE_IN_CLASS (mode, MODE_FLOAT)
+ if (SCALAR_FLOAT_MODE_P (mode))
+ {
+ const real_format *fmt = REAL_MODE_FORMAT (mode);
+ if (fmt)
+ {
+ /* fmt->emin - fmt->p + 1 should be enough but the
+ back-and-forth dance in real_to_decimal_for_mode we
+ do for checking fails due to rounding effects then. */
+ if ((fmt->emin - fmt->p) < min_exp)
+ min_exp = fmt->emin - fmt->p;
+ if (fmt->emax > max_exp)
+ max_exp = fmt->emax;
+ }
+ }
+ if (mpfr_set_emin (min_exp)
+ || mpfr_set_emax (max_exp))
+ sorry ("mpfr not configured to handle all float modes");
+
/* Set up the back-end if requested. */
if (!no_backend)
backend_init ();
[PATCH, stage1] Construct ipa_reduced_postorder always for overwritable (PR ipa/89009).
On 2/14/19 11:19 AM, Jan Hubicka wrote:
>> Hi.
>>
>> This is patch candidate I created and tested. It's not adding
>> filtering based on opt_for_fn which I would defer to the next
>> stage1.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>> Ready to be installed?
>> Thanks,
>> Martin
>
>> From d036f75a880bc91f67a5473767b35ba2f8a4ffe3 Mon Sep 17 00:00:00 2001
>> From: marxin
>> Date: Mon, 11 Feb 2019 16:47:06 +0100
>> Subject: [PATCH] Reduce SCCs in IPA postorder.
>>
>> gcc/ChangeLog:
>>
>> 2019-02-13 Martin Liska
>>
>> * ipa-cp.c (build_toporder_info): Use
>> ignore_edge_if_not_available as edge filter.
>> * ipa-inline.c (inline_small_functions): Likewise.
>> * ipa-pure-const.c (ignore_edge_for_pure_const):
>> Move to ipa-utils.h and rename to ignore_edge_if_not_available.
>> (propagate_pure_const): Use ignore_edge_if_not_available
>> as edge filter.
>> * ipa-reference.c (ignore_edge_p): Make SCCs more fine
>> based on availability and ECF_LEAF attribute.
>> * ipa-utils.c (searchc): Refactor code.
>> * ipa-utils.h (ignore_edge_if_not_available): New.
>
> OK, I think it is safe to wait for stage1 - it is bit fragile to
> propagate across different graph then postorder is computed (as
> manifested by the bug) but it should be safe if SCCs are simply bigger
> then they should be.
>
> Next stage1 we should also teach the callback to ignore edges of calls
> that are not being optimized.
I'm sending patch for that.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed after we enter stage1?
Thanks,
Martin
>
> Honza
>> ---
>> gcc/ipa-cp.c | 3 ++-
>> gcc/ipa-inline.c | 2 +-
>> gcc/ipa-pure-const.c | 13 +
>> gcc/ipa-reference.c | 13 ++---
>> gcc/ipa-utils.c | 3 +--
>> gcc/ipa-utils.h | 10 ++
>> 6 files changed, 25 insertions(+), 19 deletions(-)
>>
>> diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
>> index 442d5c63eff..2253b0cef63 100644
>> --- a/gcc/ipa-cp.c
>> +++ b/gcc/ipa-cp.c
>> @@ -815,7 +815,8 @@ build_toporder_info (struct ipa_topo_info *topo)
>>topo->stack = XCNEWVEC (struct cgraph_node *, symtab->cgraph_count);
>>
>>gcc_checking_assert (topo->stack_top == 0);
>> - topo->nnodes = ipa_reduced_postorder (topo->order, true, NULL);
>> + topo->nnodes = ipa_reduced_postorder (topo->order, true,
>> +ignore_edge_if_not_available);
>> }
>>
>> /* Free information about strongly connected components and the arrays in
>> diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c
>> index 360c3de3289..c7e68a73706 100644
>> --- a/gcc/ipa-inline.c
>> +++ b/gcc/ipa-inline.c
>> @@ -1778,7 +1778,7 @@ inline_small_functions (void)
>> metrics. */
>>
>>max_count = profile_count::uninitialized ();
>> - ipa_reduced_postorder (order, true, NULL);
>> + ipa_reduced_postorder (order, true, ignore_edge_if_not_available);
>>free (order);
>>
>>FOR_EACH_DEFINED_FUNCTION (node)
>> diff --git a/gcc/ipa-pure-const.c b/gcc/ipa-pure-const.c
>> index a8a3956d2d5..e61d279289e 100644
>> --- a/gcc/ipa-pure-const.c
>> +++ b/gcc/ipa-pure-const.c
>> @@ -1395,17 +1395,6 @@ cdtor_p (cgraph_node *n, void *)
>>return false;
>> }
>>
>> -/* We only propagate across edges with non-interposable callee. */
>> -
>> -static bool
>> -ignore_edge_for_pure_const (struct cgraph_edge *e)
>> -{
>> - enum availability avail;
>> - e->callee->function_or_virtual_thunk_symbol (, e->caller);
>> - return (avail <= AVAIL_INTERPOSABLE);
>> -}
>> -
>> -
>> /* Produce transitive closure over the callgraph and compute pure/const
>> attributes. */
>>
>> @@ -1423,7 +1412,7 @@ propagate_pure_const (void)
>>bool has_cdtor;
>>
>>order_pos = ipa_reduced_postorder (order, true,
>> - ignore_edge_for_pure_const);
>> + ignore_edge_if_not_available);
>>if (dump_file)
>> {
>>cgraph_node::dump_cgraph (dump_file);
>> diff --git a/gcc/ipa-reference.c b/gcc/ipa-reference.c
>> index d1759a374bc..16cc4cf44f9 100644
>> --- a/gcc/ipa-reference.c
>> +++ b/gcc/ipa-reference.c
>> @@ -677,14 +677,21 @@ get_read_write_all_from_node (struct cgraph_node *node,
>>}
>> }
>>
>> -/* Skip edges from and to nodes without ipa_reference enables. This leave
>> - them out of strongy connected coponents and makes them easyto skip in the
>> +/* Skip edges from and to nodes without ipa_reference enabled.
>> + Ignore not available symbols. This leave
>> + them out of strongly connected components and makes them easy to skip in
>> the
>> propagation loop bellow. */
>>
>> static bool
>> ignore_edge_p (cgraph_edge *e)
>> {
>> - return (!opt_for_fn (e->caller->decl, flag_ipa_reference)
>> + enum availability avail;
>> + e->callee->function_or_virtual_thunk_symbol (, e->caller);
>> +
>> + return (avail < AVAIL_INTERPOSABLE
Re: [libphobos, build] Enable libphobos on Solaris 11/x86
On Tue, 19 Feb 2019 at 10:32, Rainer Orth wrote: > > Hi Iain, > > > On Tue, 29 Jan 2019 at 13:35, Rainer Orth > > wrote: > >> > >> With the set of libphobos Solaris patches just posted, it would become > >> possible to enable libphobos on Solaris 11/x86 by default. > >> > >> This is what this patch does. > >> > >> * It uses a LIBPHOBOS_SUPPORTED variable both in toplevel configure and > >> libphobos/configure.tgt, following what libvtv does. > >> > >> * It's necessary to disable libphobos when Solaris as is in use: it has > >> a relatively low line length limit of 10240 which is exceeded in a few > >> libphobos files. > >> > >> Bootstrapped without regressions on i386-pc-solaris2.11 (as and gas, gas > >> and gld, Solaris 11.3/11.4/11.5) on top of the previous set of patches. > >> > >> Also tested manually that explicit > >> --enable-libphobos/--disable-libphobos give the desired results > >> (i.e. override the defaults). > >> > > > > OK. > > Thanks. This will have to wait for > > [libphobos] Use sections_elf_shared.d on Solaris 11.5 (PR d/88150) > https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01661.html I'll make a fork of sections support tonight, as that seems to be the right way forwards. Other parts will need upstreaming, I can do that as well. > and > [libphobos] Work around lack of dlpi_tls_modid before Solaris 11.5 > https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01664.html > Johannes has already commented there, and he is right about needing a way to get tls data from DSOs. > of course. Maybe even > > [libphobos] Work around Solaris ld bug linking __tls_get_addr on > 64-bit x86 > https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01663.html > > will be needed depending on whether a proper ld fix makes it into > Solaris 11.5 or not. > I'm not sure about this, but haven't looked at it properly just yet. -- Iain
[PATCH, OpenACC, og8] Fix incorrect test case
Hi,
This patch fixes a broken test case I added in a recent patch:
https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01504.html
The broken test can segfault due to writing to read-only memory, which
this new version avoids. Will apply to the openacc-gcc-8-branch shortly.
Thanks,
Gergö
libgomp/
* testsuite/libgomp.oacc-fortran/initialize_kernels_loops.f90: Update.
>From 65bf7b1656d4cffa2bd057c2e3a2129d449d04a3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gerg=C3=B6=20Barany?=
Date: Tue, 19 Feb 2019 04:17:26 -0800
Subject: [PATCH] [og8] Fix incorrect test case
OpenACC kernels regions implicitly copy variables to and from the device,
but in this test case a loop bound lives in read-only memory and the test
can segfault.
libgomp/
* testsuite/libgomp.oacc-fortran/initialize_kernels_loops.f90: Update.
---
libgomp/ChangeLog.openacc | 4
libgomp/testsuite/libgomp.oacc-fortran/initialize_kernels_loops.f90 | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/libgomp/ChangeLog.openacc b/libgomp/ChangeLog.openacc
index 96908d1..3485c9d 100644
--- a/libgomp/ChangeLog.openacc
+++ b/libgomp/ChangeLog.openacc
@@ -1,3 +1,7 @@
+2019-02-19 Gergö Barany
+
+ * testsuite/libgomp.oacc-fortran/initialize_kernels_loops.f90: Update.
+
2019-01-31 Thomas Schwinge
* testsuite/libgomp.oacc-c-c++-common/acc_prof-kernels-1.c:
diff --git a/libgomp/testsuite/libgomp.oacc-fortran/initialize_kernels_loops.f90 b/libgomp/testsuite/libgomp.oacc-fortran/initialize_kernels_loops.f90
index e8b4f3a..990a8ef 100644
--- a/libgomp/testsuite/libgomp.oacc-fortran/initialize_kernels_loops.f90
+++ b/libgomp/testsuite/libgomp.oacc-fortran/initialize_kernels_loops.f90
@@ -6,7 +6,7 @@ subroutine kernel(lo, hi, a, b, c)
integer :: lo, hi, i
real, dimension(lo:hi) :: a, b, c
-!$acc kernels
+!$acc kernels copyin(lo, hi)
!$acc loop independent ! { dg-warning "note: parallelized loop nest in OpenACC .kernels. construct" }
do i = lo, hi
b(i) = a(i)
--
2.8.1
Re: [C++ Patch] PR 84536 ("[7/8/9 Regression] ICE with non-type template parameter")
Hi,
On 19/02/19 02:39, Jason Merrill wrote:
On 2/18/19 3:15 PM, Paolo Carlini wrote:
Hi,
On 19/02/19 00:52, Jason Merrill wrote:
On 2/18/19 12:14 PM, Paolo Carlini wrote:
Hi Jason,
On 18/02/19 19:28, Jason Merrill wrote:
On 2/18/19 5:31 AM, Paolo Carlini wrote:
Hi Jason,
On 18/02/19 10:20, Jason Merrill wrote:
On 2/17/19 6:58 AM, Paolo Carlini wrote:
Hi,
here, when we don't see an initializer we believe we are surely
dealing with a case of C++17 template argument deduction for
class templates, but, in fact, it's just an ill-formed C++14
template variable specialization. Conveniently, we can use here
too the predicate variable_template_specialization_p. Not 100%
sure about the exact wording of the error message, I added '#'
to %qD to explicitly print the auto-using type too.
I guess we should change the assert to a test, so that we give
the error if we aren't dealing with a class template
placeholder. Variable templates don't seem to be important to
test for.
Thanks, simpler patch.
This error is also pretty poor for this testcase, where there is
an initializer.
Well, implementation-wise, certainly init == NULL_TREE and only
when we have an empty pack this specific issue occurs.
In practice, clang simply talks about an empty initializer
(during instantiation, etc, like we do), whereas EDG explicitly
says that pack expansion produces an empty list of expressions. I
don't think that in cp_finish_decl it would be easy for us to do
exactly the same, we simply see a NULL_TREE as second argument.
Or we could just *assume* that we are dealing with the outcome of
a pack expansion, say something like EDG even if we don't have
details beyond the fact that init == NULL_TREE. I believe that
without a variadic template the problem cannot occur, because we
catch the empty initializer much earlier, in grokdeclarator -
indeed using a !CLASS_PLACEHOLDER_TEMPLATE (auto_node) check.
What do you think? Again "instantiated for an empty pack" or
something similar?
Perhaps we could complain in the code for empty pack expansion
handling in tsubst_init?
Ah, thanks Jason. In fact, however, tsubst_init isn't currently
involved at all, because, at the end of
regenerate_decl_from_template we call by hand tsubst_expr and
assign the result to DECL_INITIAL. Simply changing that avoids the
ICE. However, the error we issue - likewise for the existing
cpp0x/auto31.C - is the rather user-unfriendly
"value-initialization of incomplete type ‘auto’", as produced by
build_value_init. Thus a simple additional test along the lines
already discussed, which now becomes much more simple to implement
in a precise way. Again, wording only tentative. I'm also a little
puzzled that, otherwise, we could get away with tubst_expr instead
of tsubst_init...
+ if (type_uses_auto (TREE_TYPE (decl)))
+ {
+ if (complain & tf_error)
+ error ("initializer for %q#D expands to an empty list "
+ "of expressions", decl);
+ return error_mark_node;
+ }
This needs to allow the CLASS_PLACEHOLDER_TEMPLATE case.
And yes, we mustn't call build_value_init for a dependent type; if
the type is dependent, we should just return the NULL_TREE.
Good. Then I'm finishing testing the below (currently in libstdc++).
+ if (tree auto_node = type_uses_auto (type))
+ if (!CLASS_PLACEHOLDER_TEMPLATE (auto_node))
+ {
+ if (complain & tf_error)
+ error ("initializer for %q#D expands to an empty list "
+ "of expressions", decl);
+ return error_mark_node;
+ }
+
+ if (!dependent_type_p (type))
This should probably be 'else if', since we can have auto outside of a
template and dependent_type_p will always return false outside of a
template.
Ok... Note that the CLASS_PLACEHOLDER_TEMPLATE (auto_node) check in
tsubst_init doesn't really make a difference for our testsuite and I
have yet to find a testcase where it does. In cp_finish_decl it did, for
sure.
That said, if I understand correctly, you mean that in principle when we
have an 'auto' outside of a template and CLASS_PLACEHOLDER_TEMPLATE is
true, we don't want to do the build_value_init bits - which we would
certainly do because dependent_type_p is false. If we are on the same
page on this, the below regtested successfully.
Thanks! Paolo.
//
Index: cp/pt.c
===
--- cp/pt.c (revision 268997)
+++ cp/pt.c (working copy)
@@ -15422,21 +15422,35 @@ tsubst_init (tree init, tree decl, tree args,
init = tsubst_expr (init, args, complain, in_decl, false);
- if (!init && TREE_TYPE (decl) != error_mark_node)
+ tree type = TREE_TYPE (decl);
+
+ if (!init && type != error_mark_node)
{
- /* If we had an initializer but it
-instantiated to nothing,
-value-initialize the object. This will
-only occur when the initializer was a
-pack
Re: [PATCH] Handle timeout warnings in dg-extract-results
On Tue, 19 Feb 2019 at 10:28, Christophe Lyon
wrote:
>
> On Mon, 18 Feb 2019 at 21:12, Rainer Orth
> wrote:
> >
> > Hi Christophe,
> >
> > > dg-extract-results currently moves lines like
> > > WARNING: program timed out
> > > at the end of each .exp section when it generates .sum files.
> > >
> > > This is because it sorts its output based on the 2nd field, which is
> > > normally the testname as in:
> > > FAIL: gcc.c-torture/execute/20020129-1.c -O2 -flto
> > > -fno-use-linker-plugin -flto-partition=none execution test
> > >
> > > As you can notice 'program' comes after
> > > gcc.c-torture/execute/20020129-1.c alphabetically, and generally after
> > > most (all?) GCC testnames.
> > >
> > > This is a bit of a pain when trying to handle transient test failures
> > > because you can no longer match such a WARNING line to its FAIL
> > > counterpart.
> > >
> > > The attached patch changes this behavior by replacing the line
> > > WARNING: program timed out
> > > with
> > > WARNING: gcc.c-torture/execute/20020129-1.c -O2 -flto
> > > -fno-use-linker-plugin -flto-partition=none execution test program
> > > timed out
> > >
> > > The effect is that this line will now appear immediately above the
> > > FAIL: gcc.c-torture/execute/20020129-1.c -O2 -flto
> > > -fno-use-linker-plugin -flto-partition=none execution test
> > > so that it's easier to match them.
> > >
> > >
> > > I'm not sure how much people depend on the .sum format, I also
> > > considered emitting
> > > WARNING: program timed out gcc.c-torture/execute/20020129-1.c -O2
> > > -flto -fno-use-linker-plugin -flto-partition=none execution test
> > >
> > > I also restricted the patch to handling only 'program timed out'
> > > cases, to avoid breaking other things.
> > >
> > > I considered fixing this in Dejagnu, but it seemed more complicated,
> > > and would delay adoption in GCC anyway.
> > >
> > > What do people think about this?
> >
> > I just had a case where your patch broke the generation of go.sum.
> > This is on Solaris 11.5 with python 2.7.15:
> >
> > ro@colima 68 > /bin/ksh
> > /vol/gcc/src/hg/trunk/local/gcc/../contrib/dg-extract-results.sh
> > testsuite/go*/*.sum.sep > testsuite/go/go.sum
> > Traceback (most recent call last):
> > File "/vol/gcc/src/hg/trunk/local/gcc/../contrib/dg-extract-results.py",
> > line 605, in
> > Prog().main()
> > File "/vol/gcc/src/hg/trunk/local/gcc/../contrib/dg-extract-results.py",
> > line 569, in main
> > self.parse_file (filename, file)
> > File "/vol/gcc/src/hg/trunk/local/gcc/../contrib/dg-extract-results.py",
> > line 427, in parse_file
> > num_variations)
> > File "/vol/gcc/src/hg/trunk/local/gcc/../contrib/dg-extract-results.py",
> > line 311, in parse_run
> > first_key = key
> > UnboundLocalError: local variable 'key' referenced before assignment
> >
> > Before your patch, key cannot have been undefined, now it is. I've
> > verified this by removing the WARNING: lines from the two affected
> > go.sum.sep files and now go.sum creation just works fine.
> >
>
> Sorry for the breakage.
>
> Can you send me the .sum that cause the problem so that I can reproduce it?
>
So the problem happens when a WARNING is the first result of a new harness.
This is fixed by the attached dg-extract-results.patch2.txt.
While looking at it, I noticed that the ordering wasn't right with the
shell version,
though I did test it before sending the previous patch.
The attached dg-extract-results.patch1.txt makes sure the WARNING: line
appears before the following testcase with the shell version too.
Are both OK?
Christophe
> Thanks
>
> Christophe
>
> > Rainer
> >
> > --
> > -
> > Rainer Orth, Center for Biotechnology, Bielefeld University
2019-02-19 Christophe Lyon
contrib/
* dg-extract-results.sh: Fix order of WARNING and following test
result.
diff --git a/contrib/dg-extract-results.sh b/contrib/dg-extract-results.sh
index e9833c1..86c4246 100755
--- a/contrib/dg-extract-results.sh
+++ b/contrib/dg-extract-results.sh
@@ -350,6 +350,7 @@ BEGIN {
if (timeout_cnt != 0) {
printf "%s %08d|%s program timed out.\n", testname, timeout_cnt,
timeout_msg >> curfile
timeout_cnt = 0
+ cnt = cnt + 1
}
printf "%s %08d|", testname, cnt >> curfile
cnt = cnt + 1
2019-02-19 Christophe Lyon
contrib/
* dg-extract-results.py: Handle case where a WARNING happens with
the first test of a harness.
diff --git a/contrib/dg-extract-results.py b/contrib/dg-extract-results.py
index ed62f73..5bf2f87 100644
--- a/contrib/dg-extract-results.py
+++ b/contrib/dg-extract-results.py
@@ -307,8 +307,8 @@ class Prog:
has_warning = 0
key = (name, len (harness.results))
harness.results.append ((key, line))
-if not first_key and sort_logs:
Re: [PATCH 00/41] V9: Emulate MMX intrinsics with SSE
On Mon, Feb 18, 2019 at 7:37 PM H.J. Lu wrote: > > On x86-64, since __m64 is returned and passed in XMM registers, we can > emulate MMX intrinsics with SSE instructions. To support it, we added > > #define TARGET_MMX_WITH_SSE (TARGET_64BIT && TARGET_SSE2) > > ;; Define instruction set of MMX instructions > (define_attr "mmx_isa" "base,native,x64,x64_noavx,x64_avx" > (const_string "base")) > > (eq_attr "mmx_isa" "native") >(symbol_ref "!TARGET_MMX_WITH_SSE") > (eq_attr "mmx_isa" "x64") >(symbol_ref "TARGET_MMX_WITH_SSE") > (eq_attr "mmx_isa" "x64_avx") >(symbol_ref "TARGET_MMX_WITH_SSE && TARGET_AVX") > (eq_attr "mmx_isa" "x64_noavx") >(symbol_ref "TARGET_MMX_WITH_SSE && !TARGET_AVX") > > We added SSE emulation to MMX patterns and disabled MMX alternatives with > TARGET_MMX_WITH_SSE. > > Most of MMX instructions have equivalent SSE versions and results of some > SSE versions need to be reshuffled to the right order for MMX. Thee are > couple tricky cases: > > 1. MMX maskmovq and SSE2 maskmovdqu aren't equivalent. We emulate MMX > maskmovq with SSE2 maskmovdqu by zeroing out the upper 64 bits of the > mask operand and handle unmapped bits 64:127 at memory address by > adjusting source and mask operands together with memory address. > > 2. MMX movntq is emulated with SSE2 DImode movnti, which is available > in 64-bit mode. > > 3. MMX pshufb takes a 3-bit index while SSE pshufb takes a 4-bit index. > SSE emulation must clear the bit 4 in the shuffle control mask. > > 4. To emulate MMX cvtpi2p with SSE2 cvtdq2ps, we must properly preserve > the upper 64 bits of destination XMM register. > > Tests are also added to check each SSE emulation of MMX intrinsics. > > There are no regressions on i686 and x86-64. For x86-64, GCC is also > tested with > > --with-arch=native --with-cpu=native > > on AVX2 and AVX512F machines. > > PS: We may be able to enable partial SSE emulation of MMX intrinsics in > 32-bit mode later. > > H.J. Lu (40): > i386: Allow MMX register modes in SSE registers > i386: Emulate MMX packsswb/packssdw/packuswb with SSE2 > i386: Emulate MMX punpcklXX/punpckhXX with SSE punpcklXX > i386: Emulate MMX plusminus/sat_plusminus with SSE > i386: Emulate MMX mulv4hi3 with SSE > i386: Emulate MMX smulv4hi3_highpart with SSE > i386: Emulate MMX mmx_pmaddwd with SSE > i386: Emulate MMX ashr3/3 with SSE > i386: Emulate MMX 3 with SSE > i386: Emulate MMX mmx_andnot3 with SSE > i386: Emulate MMX mmx_eq/mmx_gt3 with SSE > i386: Emulate MMX vec_dupv2si with SSE > i386: Emulate MMX pshufw with SSE > i386: Emulate MMX sse_cvtps2pi/sse_cvttps2pi with SSE > i386: Emulate MMX sse_cvtpi2ps with SSE > i386: Emulate MMX mmx_pextrw with SSE > i386: Emulate MMX mmx_pinsrw with SSE > i386: Emulate MMX V4HI smaxmin/V8QI umaxmin with SSE > i386: Emulate MMX mmx_pmovmskb with SSE > i386: Emulate MMX mmx_umulv4hi3_highpart with SSE > i386: Emulate MMX maskmovq with SSE2 maskmovdqu > i386: Emulate MMX mmx_uavgv8qi3 with SSE > i386: Emulate MMX mmx_uavgv4hi3 with SSE > i386: Emulate MMX mmx_psadbw with SSE > i386: Emulate MMX movntq with SSE2 movntidi > i386: Emulate MMX umulv1siv1di3 with SSE2 > i386: Make _mm_empty () as NOP without MMX > i386: Emulate MMX ssse3_phwv4hi3 with SSE > i386: Emulate MMX ssse3_phdv2si3 with SSE > i386: Emulate MMX ssse3_pmaddubsw with SSE > i386: Emulate MMX ssse3_pmulhrswv4hi3 with SSE > i386: Emulate MMX pshufb with SSE version > i386: Emulate MMX ssse3_psign3 with SSE > i386: Emulate MMX ssse3_palignrdi with SSE > i386: Emulate MMX abs2 with SSE > i386: Allow MMXMODE moves with TARGET_MMX_WITH_SSE > i386: Allow MMX vector expanders with TARGET_MMX_WITH_SSE > i386: Allow MMX intrinsic emulation with SSE > i386: Enable TM MMX intrinsics with SSE2 > i386: Add tests for MMX intrinsic emulations with SSE > > Uros Bizjak (1): > Prevent allocation of MMX registers with TARGET_MMX_WITH_SSE OK for gcc-10. Thanks, Uros. > gcc/config/i386/constraints.md|6 + > gcc/config/i386/i386-builtin.def | 126 +- > gcc/config/i386/i386-c.c |2 + > gcc/config/i386/i386-protos.h |4 + > gcc/config/i386/i386.c| 181 ++- > gcc/config/i386/i386.h|2 + > gcc/config/i386/i386.md | 17 + > gcc/config/i386/mmintrin.h| 12 +- > gcc/config/i386/mmx.md| 1028 +++-- > gcc/config/i386/predicates.md |7 + > gcc/config/i386/sse.md| 368 -- > gcc/config/i386/xmmintrin.h | 61 + > gcc/testsuite/gcc.target/i386/mmx-vals.h | 77 ++ > gcc/testsuite/gcc.target/i386/pr82483-1.c |2 +- > gcc/testsuite/gcc.target/i386/pr82483-2.c |2 +- >
[PATCH][C++] Fix ICE with VTV
Looks like vtv_generate_init_routine calls symtab->process_new_functions () which has seriously bad effects on GCCs internal memory state. VTV has zero testsuite coverage it seems and besides its initial commit didn't receive any love. Can we rip it out please? Is the patch OK? (Pointless) bootstrap and regtest running on x86_64-unknown-linux-gnu. Has anybody "recently" tried to enable the feature and tested the result? Thanks, Richard. 2019-02-19 Richard Biener PR middle-end/89392 cp/ * vtable-class-hierarchy.c (vtv_generate_init_routine): Do not make symtab process new functions here. Index: gcc/cp/vtable-class-hierarchy.c === --- gcc/cp/vtable-class-hierarchy.c (revision 269009) +++ gcc/cp/vtable-class-hierarchy.c (working copy) @@ -1191,8 +1191,6 @@ vtv_generate_init_routine (void) gimplify_function_tree (vtv_fndecl); cgraph_node::add_new_function (vtv_fndecl, false); - symtab->process_new_functions (); - if (flag_vtable_verify == VTV_PREINIT_PRIORITY && !TARGET_PECOFF) assemble_vtv_preinit_initializer (vtv_fndecl);
Re: RFC (branch prediction): PATCH to implement P0479R5, [[likely]] and [[unlikely]].
On 2/18/19 8:34 PM, Jason Merrill wrote: > Fixed thus: Works for me, thanks! Martin
[PATCH] rs6000: Fix PR 88100, range check for vec_splat_{su}{8,16,32}
Hi,
GCC revision 259524 implemented range check for the vec_splat_{su}{8,16,32}
builtins. However, as a consequence of the implementation, the range check
is not done correctly for the expected vspltis[bhw] instructions. The result
is that we may not get a valid error message if the valid range of the data
is exceeded.
Although the input of the function prototype of vec_splat_{su}{8,16,32} is
const int, the actual data usage range is limited to the data range of 5 bits
signed. We should limit the int_cst.val[0] data to the 5 bit signed data range
without any modification in the input arg0 parameter. However, the sext_hwi
function intercepts the data of TREE_INT_CST_LOW (arg0) as size bits in the
sext_hwi (TREE_INT_CST_LOW (arg0), size) statement. This will cause some of
the excess data to fall within the range of 5 bits signed, so that the correct
diagnostic information cannot be generated, we need to remove the sext_hwi to
ensure that the input data has not been modified.
This patch fix range check for the vec_splat_s[8,16,32] builtins. The argument
must be a 5-bit const int as specified for the vspltis[bhw] instructions.
The regression testing for the patch was done on GCC mainline on
powerpc64le-unknown-linux-gnu (Power 8 LE)
with no regressions. Is it OK for trunk?
Thanks,
Lijia
---
gcc/ChangeLog
2019-02-15 Li Jia He
PR target/88100
* gcc/config/rs6000/rs6000.c (rs6000_gimple_fold_builtin): Remove
sext_hwi in IN_RANGE (sext_hwi (TREE_INT_CST_LOW (arg0), size),
-16, 15).
gcc/testsuite/ChangeLog
2019-02-15 Li Jia He
PR target/88100
* gcc/testsuite/gcc.target/powerpc/pr88100.c: New testcase.
---
gcc/config/rs6000/rs6000.c | 11 +---
gcc/testsuite/gcc.target/powerpc/pr88100.c | 44 ++
2 files changed, 45 insertions(+), 10 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/powerpc/pr88100.c
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index aea7925..b1249bc 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -16105,22 +16105,13 @@ rs6000_gimple_fold_builtin (gimple_stmt_iterator *gsi)
case ALTIVEC_BUILTIN_VSPLTISH:
case ALTIVEC_BUILTIN_VSPLTISW:
{
- int size;
- if (fn_code == ALTIVEC_BUILTIN_VSPLTISB)
- size = 8;
- else if (fn_code == ALTIVEC_BUILTIN_VSPLTISH)
- size = 16;
- else
- size = 32;
-
arg0 = gimple_call_arg (stmt, 0);
lhs = gimple_call_lhs (stmt);
/* Only fold the vec_splat_*() if the lower bits of arg 0 is a
5-bit signed constant in range -16 to +15. */
if (TREE_CODE (arg0) != INTEGER_CST
- || !IN_RANGE (sext_hwi (TREE_INT_CST_LOW (arg0), size),
- -16, 15))
+ || !IN_RANGE (TREE_INT_CST_LOW (arg0), -16, 15))
return false;
gimple_seq stmts = NULL;
location_t loc = gimple_location (stmt);
diff --git a/gcc/testsuite/gcc.target/powerpc/pr88100.c
b/gcc/testsuite/gcc.target/powerpc/pr88100.c
new file mode 100644
index 000..4452145
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr88100.c
@@ -0,0 +1,44 @@
+/* PR88100. Verify that rs6000 gimple-folding code handles the
+ vec_splat_{su}{8,16,32} invalid data properly. */
+
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_altivec_ok } */
+/* { dg-options "-maltivec" } */
+
+#include
+
+vector unsigned char
+splatu1 (void)
+{
+ return vec_splat_u8(0x100);/* { dg-error "argument 1 must be a 5-bit signed
literal" } */
+}
+
+vector unsigned short
+splatu2 (void)
+{
+ return vec_splat_u16(0x1);/* { dg-error "argument 1 must be a 5-bit
signed literal" } */
+}
+
+vector unsigned int
+splatu3 (void)
+{
+ return vec_splat_u32(0x1000);/* { dg-error "argument 1 must be a 5-bit
signed literal" } */
+}
+
+vector signed char
+splats1 (void)
+{
+ return vec_splat_s8(0x100);/* { dg-error "argument 1 must be a 5-bit signed
literal" } */
+}
+
+vector signed short
+splats2 (void)
+{
+ return vec_splat_s16(0x1);/* { dg-error "argument 1 must be a 5-bit
signed literal" } */
+}
+
+vector signed int
+splats3 (void)
+{
+ return vec_splat_s32(0x1000);/* { dg-error "argument 1 must be a 5-bit
signed literal" } */
+}
--
2.7.4
Re: [libphobos, build] Enable libphobos on Solaris 11/x86
Hi Iain, > On Tue, 29 Jan 2019 at 13:35, Rainer Orth > wrote: >> >> With the set of libphobos Solaris patches just posted, it would become >> possible to enable libphobos on Solaris 11/x86 by default. >> >> This is what this patch does. >> >> * It uses a LIBPHOBOS_SUPPORTED variable both in toplevel configure and >> libphobos/configure.tgt, following what libvtv does. >> >> * It's necessary to disable libphobos when Solaris as is in use: it has >> a relatively low line length limit of 10240 which is exceeded in a few >> libphobos files. >> >> Bootstrapped without regressions on i386-pc-solaris2.11 (as and gas, gas >> and gld, Solaris 11.3/11.4/11.5) on top of the previous set of patches. >> >> Also tested manually that explicit >> --enable-libphobos/--disable-libphobos give the desired results >> (i.e. override the defaults). >> > > OK. Thanks. This will have to wait for [libphobos] Use sections_elf_shared.d on Solaris 11.5 (PR d/88150) https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01661.html and [libphobos] Work around lack of dlpi_tls_modid before Solaris 11.5 https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01664.html of course. Maybe even [libphobos] Work around Solaris ld bug linking __tls_get_addr on 64-bit x86 https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01663.html will be needed depending on whether a proper ld fix makes it into Solaris 11.5 or not. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] Handle timeout warnings in dg-extract-results
On Mon, 18 Feb 2019 at 21:12, Rainer Orth wrote: > > Hi Christophe, > > > dg-extract-results currently moves lines like > > WARNING: program timed out > > at the end of each .exp section when it generates .sum files. > > > > This is because it sorts its output based on the 2nd field, which is > > normally the testname as in: > > FAIL: gcc.c-torture/execute/20020129-1.c -O2 -flto > > -fno-use-linker-plugin -flto-partition=none execution test > > > > As you can notice 'program' comes after > > gcc.c-torture/execute/20020129-1.c alphabetically, and generally after > > most (all?) GCC testnames. > > > > This is a bit of a pain when trying to handle transient test failures > > because you can no longer match such a WARNING line to its FAIL > > counterpart. > > > > The attached patch changes this behavior by replacing the line > > WARNING: program timed out > > with > > WARNING: gcc.c-torture/execute/20020129-1.c -O2 -flto > > -fno-use-linker-plugin -flto-partition=none execution test program > > timed out > > > > The effect is that this line will now appear immediately above the > > FAIL: gcc.c-torture/execute/20020129-1.c -O2 -flto > > -fno-use-linker-plugin -flto-partition=none execution test > > so that it's easier to match them. > > > > > > I'm not sure how much people depend on the .sum format, I also > > considered emitting > > WARNING: program timed out gcc.c-torture/execute/20020129-1.c -O2 > > -flto -fno-use-linker-plugin -flto-partition=none execution test > > > > I also restricted the patch to handling only 'program timed out' > > cases, to avoid breaking other things. > > > > I considered fixing this in Dejagnu, but it seemed more complicated, > > and would delay adoption in GCC anyway. > > > > What do people think about this? > > I just had a case where your patch broke the generation of go.sum. > This is on Solaris 11.5 with python 2.7.15: > > ro@colima 68 > /bin/ksh > /vol/gcc/src/hg/trunk/local/gcc/../contrib/dg-extract-results.sh > testsuite/go*/*.sum.sep > testsuite/go/go.sum > Traceback (most recent call last): > File "/vol/gcc/src/hg/trunk/local/gcc/../contrib/dg-extract-results.py", > line 605, in > Prog().main() > File "/vol/gcc/src/hg/trunk/local/gcc/../contrib/dg-extract-results.py", > line 569, in main > self.parse_file (filename, file) > File "/vol/gcc/src/hg/trunk/local/gcc/../contrib/dg-extract-results.py", > line 427, in parse_file > num_variations) > File "/vol/gcc/src/hg/trunk/local/gcc/../contrib/dg-extract-results.py", > line 311, in parse_run > first_key = key > UnboundLocalError: local variable 'key' referenced before assignment > > Before your patch, key cannot have been undefined, now it is. I've > verified this by removing the WARNING: lines from the two affected > go.sum.sep files and now go.sum creation just works fine. > Sorry for the breakage. Can you send me the .sum that cause the problem so that I can reproduce it? Thanks Christophe > Rainer > > -- > - > Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [build] Fix libgphobos linking on Solaris 11
Hi Iain, > On Tue, 27 Nov 2018 at 23:28, Rainer Orth > wrote: >> >> As mentioned in passing in PR d/87864, libgphobos.so currently fails to >> link before Solaris 11.4. Until then, you needed to link with -lsocket >> -lnsl for the networking functions, in S11.4 they were merged into libc. >> >> To fix this, I've adapted the check from libgo/configure.ac, for the >> moment just moving it into an autoconf macro, reindenting it, renaming >> the variables for the new location, and removing the check for sendfile >> which isn't used in libphobos. >> >> With that patch (and the one from PR d/87864 to provide >> __start_minfo/__stop_minfo when ld does not), I could bootstrap with >> --enable-libphobos on i386-pc-solaris2.11 with gas and >> sparc-sun-solaris2.11 with as on both S11.3 and S11.4. On the former, >> libsocket and libnsl were properly detected and linked into >> libgdruntime.so and libgphobos.so, leaving no undefined symbols, while >> on the latter nothing more than libc is needed. >> >> Ok for mainline? >> > > Hi, > > Sorry, somehow I missed this and other libphobos related patches. > > I see no problem with this if still needed, thanks. it is on any Solaris release before 11.4. I still test 11.3 which at least receives occasional updates. Solaris 10 is affected as well, but given that it's already deprecated, support will be removed in GCC 10 and there are a couple of additional problems there (PR d/88238), I think it's a better use of everyone's time to just ignore it. Committed now. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [patch] Fix LRA/reload issue with -fnon-call-exceptions
> So, barring the removal of the get_initial_register_offset stuff, the only > simple fix is probably to prevent it from calling into the back-end too > early, for example with the attached fixlet. Tested on x86-64 and > PowerPC/Linux. > > Thoughts? Where do we want to fix this? > > > * rtlanal.c (get_initial_register_offset): Fall back to the raw estimate > as long as the epilogue isn't completed. I have installed it on mainline only for now. -- Eric Botcazou
Re: [patch, fortran] Fix PR 89384
Hi Thomas, That's just the job. OK for trunk. Thanks for the quick fix. Paul On Mon, 18 Feb 2019 at 22:03, Thomas Koenig wrote: > > Hello world, > > this patch fixes the 9 regression in C interop with contiguous > arguments recently reported by Reinhold Bader. > > ChangeLog and patch say it all. I hope I didn't overlook any > obvious things here (Paul, maybe you can take a look). > > Regression-tested. OK for trunk? > > Regards > > Thomas > > 2019-02-18 Thomas Koenig > > PR fortran/89384 > * trans-expr.c (gfc_conv_gfc_desc_to_cfi_desc): If the dummy > argument is contiguous and the actual argument may not be, > use gfc_conv_subref_array_arg. > > 2019-02-18 Thomas Koenig > > PR fortran/89384 > * gfortran.dg/ISO_Fortran_binding_4.f90 -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [committed] Fix set_uids_in_ptset (PR middle-end/89303)
On Tue, Feb 19, 2019 at 02:52:54AM +, Jonathan Wakely wrote:
> On 18/02/19 21:22 +0100, Jakub Jelinek wrote:
> > On Mon, Feb 18, 2019 at 09:15:39PM +0100, Rainer Orth wrote:
> > > 2019-02-15 Rainer Orth
> > >
> > > * g++.dg/torture/pr89303.C (bad_weak_ptr): Rename to
> > > bad_weak_ptr_.
> >
> > Ok, thanks.
> > If needed, guess we could rename much more (or rename the namespace in which
> > most of it is from std to my_std, though we'd need to check for stuff that
> > needs to be in std namespace).
>
> I think that whole testcase could be in some non-std namespace. I
> don't think there are any magic functions or types that need to be in
> namespace std to work correctly.
Ok, I've tested following (both with the tree-ssa-structalias.c change
reverted and vanilla) and committed to trunk and 8.3 (for 8.3 without
reversion of Rainer's change of course):
2019-02-19 Jakub Jelinek
PR middle-end/89303
* g++.dg/torture/pr89303.C: Move everything from std namespace to my
namespace.
--- gcc/testsuite/g++.dg/torture/pr89303.C.jj 2019-02-19 09:33:15.000193513
+0100
+++ gcc/testsuite/g++.dg/torture/pr89303.C 2019-02-19 09:51:47.197721460
+0100
@@ -2,7 +2,7 @@
// { dg-do run }
// { dg-additional-options "-std=c++14" }
-namespace std
+namespace my
{
typedef __SIZE_TYPE__ size_t;
typedef decltype(nullptr) nullptr_t;
@@ -172,28 +172,28 @@ template using __void_t = t
template
constexpr _Tp&&
-forward(typename std::remove_reference<_Tp>::type& __t) noexcept
+forward(typename my::remove_reference<_Tp>::type& __t) noexcept
{ return static_cast<_Tp&&>(__t); }
template
constexpr _Tp&&
-forward(typename std::remove_reference<_Tp>::type&& __t) noexcept
+forward(typename my::remove_reference<_Tp>::type&& __t) noexcept
{
return static_cast<_Tp&&>(__t);
}
template
-constexpr typename std::remove_reference<_Tp>::type&&
+constexpr typename my::remove_reference<_Tp>::type&&
move(_Tp&& __t) noexcept
-{ return static_cast::type&&>(__t); }
+{ return static_cast::type&&>(__t); }
}
-inline void* operator new(std::size_t, void* p) { return p; }
+inline void* operator new(my::size_t, void* p) { return p; }
-extern "C" void* malloc(std::size_t);
+extern "C" void* malloc(my::size_t);
extern "C" void free(void*);
-namespace std
+namespace my
{
template
class allocator
@@ -254,7 +254,7 @@ namespace std
using value_type = _Tp;
using pointer = _Tp*;
using const_pointer = const _Tp*;
- using size_type = std::size_t;
+ using size_type = my::size_t;
static pointer
allocate(allocator_type& __a, size_type __n)
@@ -267,7 +267,7 @@ namespace std
template
static void
construct(allocator_type& __a, _Up* __p, _Args&&... __args)
-{ __a.construct(__p, std::forward<_Args>(__args)...); }
+{ __a.construct(__p, my::forward<_Args>(__args)...); }
template
static void
@@ -282,13 +282,13 @@ namespace std
using value_type = typename allocator_traits<_Alloc>::value_type;
__allocated_ptr(_Alloc& __a, pointer __ptr) noexcept
- : _M_alloc(std::__addressof(__a)), _M_ptr(__ptr)
+ : _M_alloc(my::__addressof(__a)), _M_ptr(__ptr)
{ }
template>>
__allocated_ptr(_Alloc& __a, _Ptr __ptr)
- : _M_alloc(std::__addressof(__a)),
+ : _M_alloc(my::__addressof(__a)),
_M_ptr(__ptr)
{ }
@@ -299,11 +299,11 @@ namespace std
~__allocated_ptr()
{
if (_M_ptr != nullptr)
- std::allocator_traits<_Alloc>::deallocate(*_M_alloc, _M_ptr, 1);
+ my::allocator_traits<_Alloc>::deallocate(*_M_alloc, _M_ptr, 1);
}
__allocated_ptr&
- operator=(std::nullptr_t) noexcept
+ operator=(my::nullptr_t) noexcept
{
_M_ptr = nullptr;
return *this;
@@ -320,7 +320,7 @@ namespace std
__allocated_ptr<_Alloc>
__allocate_guarded(_Alloc& __a)
{
- return { __a, std::allocator_traits<_Alloc>::allocate(__a, 1) };
+ return { __a, my::allocator_traits<_Alloc>::allocate(__a, 1) };
}
template
@@ -350,11 +350,11 @@ namespace std
{ return static_cast(_M_addr()); }
};
- class bad_weak_ptr_ { };
+ class bad_weak_ptr { };
inline void
__throw_bad_weak_ptr()
- { (throw (bad_weak_ptr_())); }
+ { (throw (bad_weak_ptr())); }
class _Sp_counted_base
{
@@ -461,7 +461,7 @@ namespace std
: _M_impl(__a)
{
allocator_traits<_Alloc>::construct(__a, _M_ptr(),
- std::forward<_Args>(__args)...);
+ my::forward<_Args>(__args)...);
}
~_Sp_counted_ptr_inplace() noexcept { }
@@ -500,10 +500,10 @@ namespace std
{
typedef _Sp_counted_ptr_inplace<_Tp, _Alloc> _Sp_cp_type;
typename _Sp_cp_type::__allocator_type __a2(__a._M_a);
-auto __guard =
