Re: [PATCH] s390: Fix C++14 vs. C++17 ABI incompatibility on s390{, x} [PR94704]

2020-04-26 Thread Andreas Krebbel via Gcc-patches
On 26.04.20 14:20, Jakub Jelinek wrote:
> Hi!
> 
> The following patch fixes the C++14 vs. C++17 ABI passing incompatibility
> on s390x-linux.
> 
> Bootstrapped/regtested on s390x-linux without and with the patch, the
> difference being:
> -FAIL: tmpdir-g++.dg-struct-layout-1/t032 cp_compat_x_alt.o-cp_compat_y_tst.o 
> execute 
>  FAIL: tmpdir-g++.dg-struct-layout-1/t032 cp_compat_x_tst.o-cp_compat_y_alt.o 
> execute 
> -FAIL: tmpdir-g++.dg-struct-layout-1/t032 cp_compat_x_tst.o-cp_compat_y_tst.o 
> execute 
>  FAIL: tmpdir-g++.dg-struct-layout-1/t055 cp_compat_x_alt.o-cp_compat_y_alt.o 
> execute 
>  FAIL: tmpdir-g++.dg-struct-layout-1/t055 cp_compat_x_alt.o-cp_compat_y_tst.o 
> execute 
> -FAIL: tmpdir-g++.dg-struct-layout-1/t055 cp_compat_x_tst.o-cp_compat_y_alt.o 
> execute 
> -FAIL: tmpdir-g++.dg-struct-layout-1/t055 cp_compat_x_tst.o-cp_compat_y_tst.o 
> execute 
>  FAIL: tmpdir-g++.dg-struct-layout-1/t056 cp_compat_x_alt.o-cp_compat_y_alt.o 
> execute 
> -FAIL: tmpdir-g++.dg-struct-layout-1/t056 cp_compat_x_alt.o-cp_compat_y_tst.o 
> execute 
>  FAIL: tmpdir-g++.dg-struct-layout-1/t056 cp_compat_x_tst.o-cp_compat_y_alt.o 
> execute 
> -FAIL: tmpdir-g++.dg-struct-layout-1/t056 cp_compat_x_tst.o-cp_compat_y_tst.o 
> execute 
>  FAIL: tmpdir-g++.dg-struct-layout-1/t057 cp_compat_x_alt.o-cp_compat_y_alt.o 
> execute 
> -FAIL: tmpdir-g++.dg-struct-layout-1/t057 cp_compat_x_alt.o-cp_compat_y_tst.o 
> execute 
>  FAIL: tmpdir-g++.dg-struct-layout-1/t057 cp_compat_x_tst.o-cp_compat_y_alt.o 
> execute 
> -FAIL: tmpdir-g++.dg-struct-layout-1/t057 cp_compat_x_tst.o-cp_compat_y_tst.o 
> execute 
>  FAIL: tmpdir-g++.dg-struct-layout-1/t058 cp_compat_x_alt.o-cp_compat_y_alt.o 
> execute 
>  FAIL: tmpdir-g++.dg-struct-layout-1/t058 cp_compat_x_alt.o-cp_compat_y_tst.o 
> execute 
> -FAIL: tmpdir-g++.dg-struct-layout-1/t058 cp_compat_x_tst.o-cp_compat_y_alt.o 
> execute 
> -FAIL: tmpdir-g++.dg-struct-layout-1/t058 cp_compat_x_tst.o-cp_compat_y_tst.o 
> execute 
>  FAIL: tmpdir-g++.dg-struct-layout-1/t059 cp_compat_x_alt.o-cp_compat_y_alt.o 
> execute 
>  FAIL: tmpdir-g++.dg-struct-layout-1/t059 cp_compat_x_alt.o-cp_compat_y_tst.o 
> execute 
> -FAIL: tmpdir-g++.dg-struct-layout-1/t059 cp_compat_x_tst.o-cp_compat_y_alt.o 
> execute 
> -FAIL: tmpdir-g++.dg-struct-layout-1/t059 cp_compat_x_tst.o-cp_compat_y_tst.o 
> execute 
> when performing ALT_CXX_UNDER_TEST=g++ testing with a system GCC 10 compiler
> from a week ago.  So, the alt vs. alt FAILs are all expected (we know before
> this patch there is an ABI incompatibility) and some alt vs. tst (or tst vs.
> alt) FAILs too - that depends on if the particular x or y test is compiled
> with -std=c++14 or -std=c++17 - if x_tst is compiled with -std=c++14 and
> y_alt is compiled with -std=c++17, then it should FAIL, similarly if x_alt
> is compiled with -std=c++17 and y_tst is compiled with -std=c++14.
> 
> Ok for trunk?  Or do you want -Wpsabi warning too (seems s390 backend
> doesn't have any -Wpsabi warnings or informs yet)?
> 
> 2020-04-22  Jakub Jelinek  
> 
>   PR target/94704
>   * config/s390/s390.c (s390_function_arg_vector,
>   s390_function_arg_float): Ignore cxx17_empty_base_field_p fields.

Ok. Thanks for doing this!

We probably have to look into providing a -Wpsabi warning as well.

Andreas



Re: [PATCH] doc: Document all D-specific configuration options.

2020-04-26 Thread Sandra Loosemore

On 4/21/20 1:26 AM, Iain Buclaw via Gcc-patches wrote:

Hi,

This patch adds documentation for --enable-libphobos-checking and
--with-libphobos-druntime-only options.

Does it read and explain clearly enough?

Regards
Iain.

gcc/ChangeLog:

* doc/install.texi (D-Specific Options): Document
--enable-libphobos-checking and --with-libphobos-druntime-only.


Looks good to me.

-Sandra



Re: [PATCH] c++: Delegating constructor in constexpr init [PR94772]

2020-04-26 Thread Jason Merrill via Gcc-patches

On 4/26/20 6:48 PM, Patrick Palka wrote:

In the testcase below, the call to the target constructor foo{} from foo's
delegating constructor is encoded as the INIT_EXPR

   *(struct foo *) this = AGGR_INIT_EXPR <4, __ct_comp, D.2140, ...>;

During initialization of the variable 'bar', we prematurely set TREE_READONLY on
bar's CONSTRUCTOR in two places before the outer delegating constructor has
returned: first, at the end of cxx_eval_call_expression after evaluating the RHS
of the above INIT_EXPR, and second, at the end of cxx_eval_store_expression
after having finished evaluating the above INIT_EXPR.  This then prevents the
rest of the outer delegating constructor from mutating 'bar'.

This (hopefully minimally risky) patch makes cxx_eval_call_expression refrain
from setting TREE_READONLY when evaluating the target constructor of a
delegating constructor.  It also makes cxx_eval_store_expression refrain from
setting TREE_READONLY when the object being initialized is "*this', on the basis
that it should be the responsibility of the routine that set 'this' in the first
place to set the object's TREE_READONLY appropriately.

Passes 'make check-c++', does this look OK to commit after full
bootstrap/regtest?

gcc/cp/ChangeLog:

PR c++/94772
* constexpr.c (cxx_eval_call_expression): Don't set new_obj if we're
evaluating the target constructor of a delegating constructor.
(cxx_eval_store_expression): Don't set TREE_READONLY if the LHS of the
INIT_EXPR is '*this'.

gcc/testsuite/ChangeLog:

PR c++/94772
* g++.dg/cpp1y/constexpr-tracking-const23.C: New test.
---
  gcc/cp/constexpr.c| 29 +++
  .../g++.dg/cpp1y/constexpr-tracking-const23.C | 21 ++
  2 files changed, 45 insertions(+), 5 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const23.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 6b3e514398b..a9ddd861195 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -2367,10 +2367,20 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, 
tree t,
/* In a constructor, it should be the first `this' argument.
 At this point it has already been evaluated in the call
 to cxx_bind_parameters_in_call.  */
-  new_obj = TREE_VEC_ELT (new_call.bindings, 0);
-  STRIP_NOPS (new_obj);
-  if (TREE_CODE (new_obj) == ADDR_EXPR)
-   new_obj = TREE_OPERAND (new_obj, 0);
+
+  if (ctx->call && ctx->call->fundef
+ && DECL_CONSTRUCTOR_P (ctx->call->fundef->decl)
+ && (TREE_VEC_ELT (ctx->call->bindings, 0)
+ == TREE_VEC_ELT (new_call.bindings, 0)))
+   /* We're calling the target constructor of a delegating constructor, so
+  there is no new object.  */;
+  else
+   {
+ new_obj = TREE_VEC_ELT (new_call.bindings, 0);
+ STRIP_NOPS (new_obj);
+ if (TREE_CODE (new_obj) == ADDR_EXPR)
+   new_obj = TREE_OPERAND (new_obj, 0);
+   }
  }
  
tree result = NULL_TREE;

@@ -4950,7 +4960,16 @@ cxx_eval_store_expression (const constexpr_ctx *ctx, 
tree t,
if (TREE_CODE (t) == INIT_EXPR
&& TREE_CODE (*valp) == CONSTRUCTOR
&& TYPE_READONLY (type))
-TREE_READONLY (*valp) = true;
+{
+  if (INDIRECT_REF_P (target)
+ && (is_this_parameter
+ (tree_strip_nop_conversions (TREE_OPERAND (target, 0)
+   /* We've just initialized '*this' (perhaps via the target constructor of
+  a delegating constructor).  Leave it up to the caller that set 'this'
+  to set TREE_READONLY appropriately.  */;


Let's checking_assert that target and *this are 
same_type_ignoring_top_level_qualifiers_p.



+  else
+   TREE_READONLY (*valp) = true;
+}
  
/* Update TREE_CONSTANT and TREE_SIDE_EFFECTS on enclosing

   CONSTRUCTORs, if any.  */
diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const23.C 
b/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const23.C
new file mode 100644
index 000..266b62b852f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const23.C
@@ -0,0 +1,21 @@
+// PR c++/94772
+// { dg-do compile { target c++14 } }
+
+struct foo
+{
+int x{};
+
+constexpr foo() noexcept = default;
+
+constexpr foo(int a) : foo{}
+{ x = -a; }
+
+constexpr foo(int a, int b) : foo{a}
+{ x += a + b; }
+};
+
+int main()
+{
+constexpr foo bar{1, 2};
+static_assert(bar.x == 2, "");
+}





Re: [PATCH v3] c++: Explicit constructor called in copy-initialization [PR90320]

2020-04-26 Thread Jason Merrill via Gcc-patches

On 4/26/20 2:00 PM, Marek Polacek wrote:

On Fri, Apr 24, 2020 at 04:07:03PM -0400, Jason Merrill via Gcc-patches wrote:

On 4/23/20 7:08 PM, Marek Polacek wrote:

@@ -1252,6 +1252,8 @@ standard_conversion (tree to, tree from, tree expr, bool 
c_cast_p,
  if (flags & LOOKUP_PREFER_RVALUE)
/* Tell convert_like_real to set LOOKUP_PREFER_RVALUE.  */
conv->rvaluedness_matches_p = true;
+  if (flags & LOOKUP_ONLYCONVERTING)
+   conv->need_temporary_p = true;


Presumably we want the same thing for ck_base?


We actually already set need_temporary_p for ck_base in standard_conversion:
1529   conv->need_temporary_p = !(flags & LOOKUP_NO_TEMP_BIND);


Hmm, yes.  So with your patch the flag means different things for ck_base
and ck_rvalue.  This suggests to me that overloading need_temporary_p to
also indicate copy-initialization is problematic, and we should move that
information to a new flag.


OK, done in the following.  I think the new flag might be useful for PR87605
too.


That sounds plausible.  Going forward I think we want to use it for 
ck_ambig and ck_user as well.



Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?


OK, thanks.


-- >8 --
This test is rejected with a bogus "use of deleted function" error
starting with r225705 whereby convert_like_real/ck_base no longer
sets LOOKUP_ONLYCONVERTING for user_conv_p conversions.  This does
not seem to be always correct.  To recap, when we have something like
T t = x where T is a class type and the type of x is not T or derived
from T, we perform copy-initialization, something like:
   1. choose a user-defined conversion to convert x to T, the result is
  a prvalue,
   2. use this prvalue to direct-initialize t.

In the second step, explicit constructors should be considered, since
we're direct-initializing.  This is what r225705 fixed.

In this PR we are dealing with the first step, I think, where explicit
constructors should be skipped.  [over.match.copy] says "The converting
constructors of T are candidate functions" which clearly eliminates
explicit constructors.  But we also have to copy-initialize the argument
we are passing to such a converting constructor, and here we should
disregard explicit constructors too.

In this testcase we have

   V v = m;

and we choose V::V(M) to convert m to V.  But we wrongly choose
the explicit M::M(M&) to copy-initialize the argument; it's
a better match for a non-const lvalue than the implicit M::M(const M&)
but because it's explicit, we shouldn't use it.

When convert_like is processing the ck_user conversion -- the convfn is
V::V(M) -- it can see that cand->flags contains LOOKUP_ONLYCONVERTING,
but then when we're in build_over_call for this convfn, we have no way
to pass the flag to convert_like for the argument 'm', because convert_like
doesn't take flags.  Fixed by creating a new conversion flag, copy_init_p,
set in ck_base/ck_rvalue to signal that explicit constructors should be
skipped.

LOOKUP_COPY_PARM looks relevant, but again, it's a LOOKUP_* flag, so
can't pass it to convert_like.  DR 899 also seemed related, but that
deals with direct-init contexts only.

PR c++/90320
* call.c (struct conversion): Add copy_init_p.
(standard_conversion): Set copy_init_p in ck_base and ck_rvalue
if FLAGS demands LOOKUP_ONLYCONVERTING.
(convert_like_real) : If copy_init_p is set, or
LOOKUP_ONLYCONVERTING into FLAGS.

* g++.dg/cpp0x/explicit13.C: New test.
* g++.dg/cpp0x/explicit14.C: New test.
---
  gcc/cp/call.c   | 26 -
  gcc/testsuite/g++.dg/cpp0x/explicit13.C | 14 +
  gcc/testsuite/g++.dg/cpp0x/explicit14.C | 16 +++
  3 files changed, 51 insertions(+), 5 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/explicit13.C
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/explicit14.C

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index c58231601c9..8345997ccf9 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -92,7 +92,7 @@ struct conversion {
   language standards, e.g. disregarding pointer qualifiers or
   converting integers to pointers.  */
BOOL_BITFIELD bad_p : 1;
-  /* If KIND is ck_ref_bind ck_base_conv, true to indicate that a
+  /* If KIND is ck_ref_bind or ck_base, true to indicate that a
   temporary should be created to hold the result of the
   conversion.  If KIND is ck_ambig or ck_user, true means force
   copy-initialization.  */
@@ -111,6 +111,10 @@ struct conversion {
/* Whether check_narrowing should only check TREE_CONSTANTs; used
   in build_converted_constant_expr.  */
BOOL_BITFIELD check_narrowing_const_only: 1;
+  /* True if this conversion is taking place in a copy-initialization context
+ and we should only consider converting constructors.  Only set in
+ ck_base and ck_rvalue.  */
+  BOOL_BITFIELD copy_init_p : 1;
/* The type of the expression resulting from t

[committed] d: Fix ICE in assign_temp, at function.c:984 (PR94777)

2020-04-26 Thread Iain Buclaw via Gcc-patches
Hi,

This patch fixes an ICE in the D front-end when passing non-trivially
copyable types to variadic functions.

Named arguments were being passed around by invisible reference, just
not variadic arguments.  There is a need to de-duplicate the routines
that handle declaration/parameter promotion and reference checking.
However for now, the parameter helper functions have just been renamed
to parameter_reference_p and parameter_type, to make it more clear that
it is the Parameter equivalent to declaration_reference_p and
declaration_type.

On writing the tests, a forward-reference bug was discovered on x86_64
during va_list type semantic.  This was due to fields not having their
parent set-up correctly.

Bootstrapped and regression tested on x86_64-linux-gnu, with the
--target_board configurations -m64, -m32, -mx32.  Committed to mainline.

Regards
Iain

---
gcc/d/ChangeLog:

PR d/94777
* d-builtins.cc (build_frontend_type): Set parent for generated
fields of built-in types.
* d-codegen.cc (argument_reference_p): Rename to ...
(parameter_reference_p): ... this.
(type_passed_as): Rename to ...
(parameter_type): ... this.  Make TREE_ADDRESSABLE types restrict.
(d_build_call): Move handling of non-POD types here from ...
* d-convert.cc (convert_for_argument): ... here.
* d-tree.h (argument_reference_p): Rename declaration to ...
(parameter_reference_p): ... this.
(type_passed_as): Rename declaration to ...
(parameter_type): ... this.
* types.cc (TypeVisitor::visit (TypeFunction *)): Update caller.

gcc/testsuite/ChangeLog:

PR d/94777
* gdc.dg/pr94777a.d: New test.
* gdc.dg/pr94777b.d: New test.
---
 gcc/d/d-builtins.cc |   1 +
 gcc/d/d-codegen.cc  |  32 +-
 gcc/d/d-convert.cc  |  19 +---
 gcc/d/d-tree.h  |   4 +-
 gcc/d/types.cc  |   2 +-
 gcc/testsuite/gdc.dg/pr94777a.d |  15 +++
 gcc/testsuite/gdc.dg/pr94777b.d | 181 
 7 files changed, 231 insertions(+), 23 deletions(-)
 create mode 100644 gcc/testsuite/gdc.dg/pr94777a.d
 create mode 100644 gcc/testsuite/gdc.dg/pr94777b.d

diff --git a/gcc/d/d-builtins.cc b/gcc/d/d-builtins.cc
index cb8f43a88e5..a5654a66bf5 100644
--- a/gcc/d/d-builtins.cc
+++ b/gcc/d/d-builtins.cc
@@ -253,6 +253,7 @@ build_frontend_type (tree type)
= Identifier::idPool (IDENTIFIER_POINTER (DECL_NAME (field)));
  VarDeclaration *vd = VarDeclaration::create (Loc (), ftype, fident,
   NULL);
+ vd->parent = sdecl;
  vd->offset = tree_to_uhwi (DECL_FIELD_OFFSET (field));
  vd->semanticRun = PASSsemanticdone;
  vd->csym = field;
diff --git a/gcc/d/d-codegen.cc b/gcc/d/d-codegen.cc
index 8dc1ab264f8..12c6f138362 100644
--- a/gcc/d/d-codegen.cc
+++ b/gcc/d/d-codegen.cc
@@ -172,7 +172,7 @@ declaration_type (Declaration *decl)
Return TRUE if parameter ARG is a reference type.  */
 
 bool
-argument_reference_p (Parameter *arg)
+parameter_reference_p (Parameter *arg)
 {
   Type *tb = arg->type->toBasetype ();
 
@@ -186,7 +186,7 @@ argument_reference_p (Parameter *arg)
 /* Returns the real type for parameter ARG.  */
 
 tree
-type_passed_as (Parameter *arg)
+parameter_type (Parameter *arg)
 {
   /* Lazy parameters are converted to delegates.  */
   if (arg->storageClass & STClazy)
@@ -207,9 +207,18 @@ type_passed_as (Parameter *arg)
   tree type = build_ctype (arg->type);
 
   /* Parameter is passed by reference.  */
-  if (TREE_ADDRESSABLE (type) || argument_reference_p (arg))
+  if (parameter_reference_p (arg))
 return build_reference_type (type);
 
+  /* Pass non-POD structs by invisible reference.  */
+  if (TREE_ADDRESSABLE (type))
+{
+  type = build_reference_type (type);
+  /* There are no other pointer to this temporary.  */
+  type = build_qualified_type (type, TYPE_QUAL_RESTRICT);
+}
+
+  /* Front-end has already taken care of type promotions.  */
   return type;
 }
 
@@ -1954,6 +1963,23 @@ d_build_call (TypeFunction *tf, tree callable, tree 
object,
  targ = build2 (COMPOUND_EXPR, TREE_TYPE (t), targ, t);
}
 
+ /* Parameter is a struct passed by invisible reference.  */
+ if (TREE_ADDRESSABLE (TREE_TYPE (targ)))
+   {
+ Type *t = arg->type->toBasetype ();
+ gcc_assert (t->ty == Tstruct);
+ StructDeclaration *sd = ((TypeStruct *) t)->sym;
+
+ /* Nested structs also have ADDRESSABLE set, but if the type has
+neither a copy constructor nor a destructor available, then we
+need to take care of copying its value before passing it.  */
+ if (arg->op == TOKstructliteral || (!sd->postblit && !sd->dtor))
+   targ = force_target_expr (targ);
+
+ targ = convert (build_referen

[committed] libphobos: Add hppa-*-linux* as a supported target

2020-04-26 Thread Iain Buclaw via Gcc-patches
Hi,

This patch add hppa-*-linux* as a supported target for libphobos.

This is has been done based off early testing done back in GCC-9
development by John, and recent testing inside a QEMU container.

The hppa64-*-* target has been left out due to thread local storage
being completely unusable on the target (PR94758).

Testsuite summaries from a native hppa D compiler running inside a
QEMU/Docker container:

---
=== libphobos tests ===
FAIL: libphobos.allocations/tls_gc_integration.d execution test
FAIL: libphobos.thread/tlsgc_sections.d execution test
=== libphobos Summary ===
# of expected passes63
# of unexpected failures2
# of unsupported tests  1

=== gdc tests ===
WARNING: compilable/test15019.d -O2   (test for excess errors) program timed 
out.
FAIL: compilable/test15019.d -O2output-exists test15019.o
WARNING: compilable/test15019.d -O2 -frelease   (test for excess errors) 
program timed out.
FAIL: compilable/test15019.d -O2 -freleaseoutput-exists test15019.o
WARNING: compilable/test15019.d -O2 -g   (test for excess errors) program timed 
out.
FAIL: compilable/test15019.d -O2 -goutput-exists test15019.o
WARNING: compilable/test15019.d -O2 -frelease -g   (test for excess errors) 
program timed out.
FAIL: compilable/test15019.d -O2 -frelease -goutput-exists test15019.o
=== gdc Summary ===
# of expected passes21210
# of unexpected failures4
# of unsupported tests  120
/build/gcc/gdc  version 10.0.1 20200426 (experimental) (GCC) 
---

Tested on an emulated hppa-linux-gnu target, committed to mainline.

Regards
Iain.

---
libphobos/ChangeLog:

2020-04-27  Iain Buclaw  

* configure.tgt: Add hppa-*-linux* as a supported target.
---
 libphobos/configure.tgt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libphobos/configure.tgt b/libphobos/configure.tgt
index ce4cc1f7527..94e42bf5509 100644
--- a/libphobos/configure.tgt
+++ b/libphobos/configure.tgt
@@ -30,6 +30,9 @@ case "${target}" in
   arm*-*-linux*)
LIBPHOBOS_SUPPORTED=yes
;;
+  hppa-*-linux*)
+   LIBPHOBOS_SUPPORTED=yes
+   ;;
   mips*-*-linux*)
LIBPHOBOS_SUPPORTED=yes
;;
-- 
2.20.1



[committed] d: Merge upstream dmd f8a1a5153, druntime 2b5c0b27 (PR89418)

2020-04-26 Thread Iain Buclaw via Gcc-patches
Hi,

This patch merges the D front-end impleentation with upstream dmd
f8a1a5153, and the D runtime library with upstream druntime 2b5c0b27.

Adds a new test directive COMPILABLE_MATH_TEST, and support has been
added for it in gdc-convert-test so that they are skipped if phobos is
not present on the target.

Only change in D runtime is a small documentation fix.

Bootstrapped and regression tested on x86_64-linux-gnu, committed to
mainline.

Regards
Iain.

---
gcc/testsuite/ChangeLog:

PR d/89418
* lib/gdc-utils.exp (gdc-convert-test): Add dg-skip-if for compilable
tests that depend on the phobos standard library.
---
 gcc/d/dmd/MERGE   | 2 +-
 gcc/testsuite/gdc.test/compilable/ctfe_math.d | 1 +
 gcc/testsuite/gdc.test/compilable/test5227.d  | 1 +
 gcc/testsuite/lib/gdc-utils.exp   | 9 +
 libphobos/libdruntime/MERGE   | 2 +-
 libphobos/libdruntime/core/internal/convert.d | 4 ++--
 6 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/gcc/d/dmd/MERGE b/gcc/d/dmd/MERGE
index a878cb9f42e..f933cf1c992 100644
--- a/gcc/d/dmd/MERGE
+++ b/gcc/d/dmd/MERGE
@@ -1,4 +1,4 @@
-09db0c41ee922502fa0966bde24c1cb9b15ad436
+f8a1a515346b16ebbd9da56a908540cbef1ee582
 
 The first line of this file holds the git revision number of the last
 merge done from the dlang/dmd repository.
diff --git a/gcc/testsuite/gdc.test/compilable/ctfe_math.d 
b/gcc/testsuite/gdc.test/compilable/ctfe_math.d
index 78de869d090..334b75ac941 100644
--- a/gcc/testsuite/gdc.test/compilable/ctfe_math.d
+++ b/gcc/testsuite/gdc.test/compilable/ctfe_math.d
@@ -1,3 +1,4 @@
+// COMPILABLE_MATH_TEST
 // Test CTFE builtins for std.math functions.
 
 import std.math;
diff --git a/gcc/testsuite/gdc.test/compilable/test5227.d 
b/gcc/testsuite/gdc.test/compilable/test5227.d
index c270b79245b..63ca752f4fb 100644
--- a/gcc/testsuite/gdc.test/compilable/test5227.d
+++ b/gcc/testsuite/gdc.test/compilable/test5227.d
@@ -1,4 +1,5 @@
 /*
+COMPILABLE_MATH_TEST
 REQUIRED_ARGS:
 PERMUTE_ARGS:
 TEST_OUTPUT:
diff --git a/gcc/testsuite/lib/gdc-utils.exp b/gcc/testsuite/lib/gdc-utils.exp
index 87d1105a9db..5c17346dbf5 100644
--- a/gcc/testsuite/lib/gdc-utils.exp
+++ b/gcc/testsuite/lib/gdc-utils.exp
@@ -302,6 +302,12 @@ proc gdc-convert-test { base test } {
# It will need skipping if phobos is not available on the target.
regsub -- {RUNNABLE_PHOBOS_TEST.*$} $copy_line "" out_line
set needs_phobos 1
+
+   } elseif [regexp -- {COMPILABLE_MATH_TEST} $copy_line match sources] {
+   # COMPILABLE_MATH_TEST annotates tests that import the std.math
+   # module.  Which will need skipping if not available on the target.
+   regsub -- {RUNNABLE_PHOBOS_TEST.*$} $copy_line "" out_line
+   set needs_phobos 1
}
 
puts $fdout $out_line
@@ -358,6 +364,9 @@ proc gdc-convert-test { base test } {
# Cleanup extra generated files.
puts $fdout "// { dg-final { file delete $genfile } }"
}
+   if $needs_phobos {
+   puts $fdout "// { dg-skip-if \"imports phobos\" { ! 
d_runtime_has_std_library } }"
+   }
}
 
fail_compilation {
diff --git a/libphobos/libdruntime/MERGE b/libphobos/libdruntime/MERGE
index 8b461f76ad0..e3763485adf 100644
--- a/libphobos/libdruntime/MERGE
+++ b/libphobos/libdruntime/MERGE
@@ -1,4 +1,4 @@
-e68a5ae36790fa9dc5bab6155bc450eb6bf8c12c
+2b5c0b2766949e788e4929c5fb0e2ba698ff79a3
 
 The first line of this file holds the git revision number of the last
 merge done from the dlang/druntime repository.
diff --git a/libphobos/libdruntime/core/internal/convert.d 
b/libphobos/libdruntime/core/internal/convert.d
index 3d2cb59a64a..0f540f83d42 100644
--- a/libphobos/libdruntime/core/internal/convert.d
+++ b/libphobos/libdruntime/core/internal/convert.d
@@ -73,8 +73,8 @@ const(ubyte)[] toUbyte(T)(const ref T val) if (is(Unqual!T == 
float) || is(Unqua
 // Parse DoubleDoubles as a pair of doubles.
 // The layout of the type is:
 //
-//   [1|  7  |   56  ][   8|   56   ]
-//   [S| Exp | Fraction (hi) ][ Unused | Fraction (low) ]
+//   [1|11|   52  ][1|11|   52   ]
+//   [S| Exponent | Fraction (hi) ][S| Exponent | Fraction (low) ]
 //
 // We can get the least significant bits by subtracting the IEEE
 // double precision portion from the real value.
-- 
2.20.1



[committed] libphobos: Remove AC_CACHE_CHECK from network library tests.

2020-04-26 Thread Iain Buclaw via Gcc-patches
Hi,

This patch simplifies the socket library checks, as LIBS is the target
variable ultimately being assigned to.  The original comments from the
deleted libjava directories have been restored as well.

Regression tested on x86_64-linux-gnu, committed to mainline.

Regards
Iain.

---
libphobos/ChangeLog:

* configure: Regenerate.
* m4/druntime/libraries.m4 (DRUNTIME_LIBRARIES_NET): Remove
AC_CACHE_CHECK, simplify by setting LIBS directly.
---
 libphobos/configure| 103 ++---
 libphobos/m4/druntime/libraries.m4 |  51 +++---
 2 files changed, 72 insertions(+), 82 deletions(-)

diff --git a/libphobos/configure b/libphobos/configure
index c923417532f..98d8dc255c1 100755
--- a/libphobos/configure
+++ b/libphobos/configure
@@ -14932,25 +14932,14 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
 fi
 
 
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for socket libraries" >&5
-$as_echo_n "checking for socket libraries... " >&6; }
-if ${druntime_cv_lib_sockets+:} false; then :
-  $as_echo_n "(cached) " >&6
-else
-  druntime_cv_lib_sockets=
- druntime_check_both=no
- ac_fn_c_check_func "$LINENO" "connect" "ac_cv_func_connect"
+druntime_check_both=no
+  ac_fn_c_check_func "$LINENO" "connect" "ac_cv_func_connect"
 if test "x$ac_cv_func_connect" = xyes; then :
-  druntime_check_socket=no
-else
-  druntime_check_socket=yes
-fi
 
- if test "$druntime_check_socket" = "yes"; then
-   unset ac_cv_func_connect
-   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for main in -lsocket" 
>&5
-$as_echo_n "checking for main in -lsocket... " >&6; }
-if ${ac_cv_lib_socket_main+:} false; then :
+else
+  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for connect in -lsocket" 
>&5
+$as_echo_n "checking for connect in -lsocket... " >&6; }
+if ${ac_cv_lib_socket_connect+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -14958,55 +14947,58 @@ LIBS="-lsocket  $LIBS"
 cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 
-
+/* Override any GCC internal prototype to avoid an error.
+   Use char because int might match the return type of a GCC
+   builtin and then its argument prototype would still apply.  */
+#ifdef __cplusplus
+extern "C"
+#endif
+char connect ();
 int
 main ()
 {
-return main ();
+return connect ();
   ;
   return 0;
 }
 _ACEOF
 if ac_fn_c_try_link "$LINENO"; then :
-  ac_cv_lib_socket_main=yes
+  ac_cv_lib_socket_connect=yes
 else
-  ac_cv_lib_socket_main=no
+  ac_cv_lib_socket_connect=no
 fi
 rm -f core conftest.err conftest.$ac_objext \
 conftest$ac_exeext conftest.$ac_ext
 LIBS=$ac_check_lib_save_LIBS
 fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_socket_main" >&5
-$as_echo "$ac_cv_lib_socket_main" >&6; }
-if test "x$ac_cv_lib_socket_main" = xyes; then :
-  druntime_cv_lib_sockets="-lsocket"
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_socket_connect" >&5
+$as_echo "$ac_cv_lib_socket_connect" >&6; }
+if test "x$ac_cv_lib_socket_connect" = xyes; then :
+  LIBS="$LIBS -lsocket"
 else
   druntime_check_both=yes
 fi
 
- fi
- if test "$druntime_check_both" = "yes"; then
-   druntime_old_libs=$LIBS
-   LIBS="$LIBS -lsocket -lnsl"
-   unset ac_cv_func_accept
-   ac_fn_c_check_func "$LINENO" "accept" "ac_cv_func_accept"
+fi
+
+  if test "$druntime_check_both" = "yes"; then
+druntime_old_libs=$LIBS
+LIBS="$LIBS -lsocket -lnsl"
+ac_fn_c_check_func "$LINENO" "accept" "ac_cv_func_accept"
 if test "x$ac_cv_func_accept" = xyes; then :
-  druntime_check_nsl=no
- druntime_cv_lib_sockets="-lsocket -lnsl"
+
+else
+  LIBS=$druntime_old_libs
 fi
 
-   unset ac_cv_func_accept
-   LIBS=$druntime_old_libs
- fi
- unset ac_cv_func_gethostbyname
- druntime_old_libs="$LIBS"
- ac_fn_c_check_func "$LINENO" "gethostbyname" "ac_cv_func_gethostbyname"
+  fi
+  ac_fn_c_check_func "$LINENO" "gethostbyname" "ac_cv_func_gethostbyname"
 if test "x$ac_cv_func_gethostbyname" = xyes; then :
 
 else
-  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for main in -lnsl" >&5
-$as_echo_n "checking for main in -lnsl... " >&6; }
-if ${ac_cv_lib_nsl_main+:} false; then :
+  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for gethostbyname in 
-lnsl" >&5
+$as_echo_n "checking for gethostbyname in -lnsl... " >&6; }
+if ${ac_cv_lib_nsl_gethostbyname+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -15014,38 +15006,39 @@ LIBS="-lnsl  $LIBS"
 cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 
-
+/* Override any GCC internal prototype to avoid an error.
+   Use char because int might match the return type of a GCC
+   builtin and then its argument prototype would still apply.  */
+#ifdef __cplusplus
+extern "C"
+#endif
+char gethostbyname ();
 int
 main ()
 {
-return main ();
+return gethostbyname ();
   ;
   return 0;
 

[PATCH] c++: Delegating constructor in constexpr init [PR94772]

2020-04-26 Thread Patrick Palka via Gcc-patches
In the testcase below, the call to the target constructor foo{} from foo's
delegating constructor is encoded as the INIT_EXPR

  *(struct foo *) this = AGGR_INIT_EXPR <4, __ct_comp, D.2140, ...>;

During initialization of the variable 'bar', we prematurely set TREE_READONLY on
bar's CONSTRUCTOR in two places before the outer delegating constructor has
returned: first, at the end of cxx_eval_call_expression after evaluating the RHS
of the above INIT_EXPR, and second, at the end of cxx_eval_store_expression
after having finished evaluating the above INIT_EXPR.  This then prevents the
rest of the outer delegating constructor from mutating 'bar'.

This (hopefully minimally risky) patch makes cxx_eval_call_expression refrain
from setting TREE_READONLY when evaluating the target constructor of a
delegating constructor.  It also makes cxx_eval_store_expression refrain from
setting TREE_READONLY when the object being initialized is "*this', on the basis
that it should be the responsibility of the routine that set 'this' in the first
place to set the object's TREE_READONLY appropriately.

Passes 'make check-c++', does this look OK to commit after full
bootstrap/regtest?

gcc/cp/ChangeLog:

PR c++/94772
* constexpr.c (cxx_eval_call_expression): Don't set new_obj if we're
evaluating the target constructor of a delegating constructor.
(cxx_eval_store_expression): Don't set TREE_READONLY if the LHS of the
INIT_EXPR is '*this'.

gcc/testsuite/ChangeLog:

PR c++/94772
* g++.dg/cpp1y/constexpr-tracking-const23.C: New test.
---
 gcc/cp/constexpr.c| 29 +++
 .../g++.dg/cpp1y/constexpr-tracking-const23.C | 21 ++
 2 files changed, 45 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const23.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 6b3e514398b..a9ddd861195 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -2367,10 +2367,20 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, 
tree t,
   /* In a constructor, it should be the first `this' argument.
 At this point it has already been evaluated in the call
 to cxx_bind_parameters_in_call.  */
-  new_obj = TREE_VEC_ELT (new_call.bindings, 0);
-  STRIP_NOPS (new_obj);
-  if (TREE_CODE (new_obj) == ADDR_EXPR)
-   new_obj = TREE_OPERAND (new_obj, 0);
+
+  if (ctx->call && ctx->call->fundef
+ && DECL_CONSTRUCTOR_P (ctx->call->fundef->decl)
+ && (TREE_VEC_ELT (ctx->call->bindings, 0)
+ == TREE_VEC_ELT (new_call.bindings, 0)))
+   /* We're calling the target constructor of a delegating constructor, so
+  there is no new object.  */;
+  else
+   {
+ new_obj = TREE_VEC_ELT (new_call.bindings, 0);
+ STRIP_NOPS (new_obj);
+ if (TREE_CODE (new_obj) == ADDR_EXPR)
+   new_obj = TREE_OPERAND (new_obj, 0);
+   }
 }
 
   tree result = NULL_TREE;
@@ -4950,7 +4960,16 @@ cxx_eval_store_expression (const constexpr_ctx *ctx, 
tree t,
   if (TREE_CODE (t) == INIT_EXPR
   && TREE_CODE (*valp) == CONSTRUCTOR
   && TYPE_READONLY (type))
-TREE_READONLY (*valp) = true;
+{
+  if (INDIRECT_REF_P (target)
+ && (is_this_parameter
+ (tree_strip_nop_conversions (TREE_OPERAND (target, 0)
+   /* We've just initialized '*this' (perhaps via the target constructor of
+  a delegating constructor).  Leave it up to the caller that set 'this'
+  to set TREE_READONLY appropriately.  */;
+  else
+   TREE_READONLY (*valp) = true;
+}
 
   /* Update TREE_CONSTANT and TREE_SIDE_EFFECTS on enclosing
  CONSTRUCTORs, if any.  */
diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const23.C 
b/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const23.C
new file mode 100644
index 000..266b62b852f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const23.C
@@ -0,0 +1,21 @@
+// PR c++/94772
+// { dg-do compile { target c++14 } }
+
+struct foo
+{
+int x{};
+
+constexpr foo() noexcept = default;
+
+constexpr foo(int a) : foo{}
+{ x = -a; }
+
+constexpr foo(int a, int b) : foo{a}
+{ x += a + b; }
+};
+
+int main()
+{
+constexpr foo bar{1, 2};
+static_assert(bar.x == 2, "");
+}
-- 
2.26.2.266.ge870325ee8



Re: [committed] d: Merge upstream dmd 09db0c41e, druntime e68a5ae3.

2020-04-26 Thread Iain Buclaw via Gcc-patches
On 26/04/2020 18:41, Segher Boessenkool wrote:
> On Sun, Apr 26, 2020 at 10:38:57AM +0200, Iain Buclaw wrote:
>> On 25/04/2020 22:50, Segher Boessenkool wrote:
>>> On Sat, Apr 25, 2020 at 02:20:19AM +0200, Iain Buclaw via Gcc-patches wrote:
 +// Parse DoubleDoubles as a pair of doubles.
 +// The layout of the type is:
 +//
 +//   [1|  7  |   56  ][   8|   56   ]
 +//   [S| Exp | Fraction (hi) ][ Unused | Fraction (low) ]
 +//
 +// We can get the least significant bits by subtracting the 
 IEEE
 +// double precision portion from the real value.
>>>
>>> That's not correct.  There is no "Unused" field, and the lower fraction
>>> is not always an immediate extension of the higher fraction.
>>>
>>> (It's not 1,7,56 -- it is 1,11,52).
>>
>> Thanks, I did a quick look-up of where the original might have came
>> from, and I've found another extended floating point format of IBM.
>> I'll send the correction upstream.
>>
>>> A "double double" is really a pair of double precision numbers, both
>>> with sign and exponent fields.  If the first number has maximum
>>> exponent (so, it is infinity or a NaN), the second number is not
>>> significant; otherwise, the sum of the two numbers (taken as exact
>>> numbers, no rounding, no truncation, etc.) is the represented number.
>>> The first number should be that, rounded to double precision.
>>>
>>> So the second double does "add fraction bits" somewhat like this, but
>>> there is an implicit leading 1, for normal numbers, and there can be a
>>> gap between the two halves, too (like in 0x1p0 + 0x1p-100).
>>
>> The job of this routine is to pry out the byte representation of real
>> (long double) values at compile-time for hashing-related purposes.
>>
>> As zero, infinity and NaN are already handled, unless a mismatch between
>> compile and run-time computed hashes is found (I haven't seen any
>> unit-tests trigger failures in the testsuite), I don't think that there
>> is any immediate problem with the current implementation.
>>
>> Thanks for the information though.
> 
> All bits are significant to the value, there are no unused bits, for
> most values.  The sign and exponent of the second number are very much
> relevant, in general.
> 
> I didn't look at your actual implementation, just this comment, but it
> sounds like your tests miss a lot of cases, if no problems were found?
> 

All these tests pass.  That is, the computed compile-time byte layout
(the result of this function) is the same as the layout at run-time.

Don't mind that these are all strings, they are all passed to mixin().

/**Test special values*/
testNumberConvert!("-real.infinity");
testNumberConvert!("real.infinity");
testNumberConvert!("-0.0L");
testNumberConvert!("0.0L");
testNumberConvert!("real.nan");

/**Test min and max values values*/
testNumberConvert!("real.min_normal");
testNumberConvert!("real.max");

/**Test common values*/
testNumberConvert!("-0.17L");
testNumberConvert!("3.14L");

/**Test immutable and const*/
testNumberConvert!("cast(const)3.14L");
testNumberConvert!("cast(immutable)3.14L");

/**Test denormalized values*/
testNumberConvert!("real.min_normal/2");
testNumberConvert!("real.min_normal/2UL^^63");

// check subnormal storage edge case for Quadruple
testNumberConvert!("real.min_normal/2UL^^56");
testNumberConvert!("real.min_normal/19");
testNumberConvert!("real.min_normal/17");

/**Test imaginary values: convert algorithm is same with real values*/
testNumberConvert!("0.0Li");

/**True random values*/
testNumberConvert!("-0x9.0f7ee55df77618fp-13829L");
testNumberConvert!("0x7.36e6e2640120d28p+8797L");
testNumberConvert!("-0x1.05df6ce4702ccf8p+15835L");
testNumberConvert!("0x9.54bb0d88806f714p-7088L");

/**Big overflow or underflow*/
testNumberConvert!("cast(double)-0x9.0f7ee55df77618fp-13829L");
testNumberConvert!("cast(double)0x7.36e6e2640120d28p+8797L");
testNumberConvert!("cast(double)-0x1.05df6ce4702ccf8p+15835L");
testNumberConvert!("cast(double)0x9.54bb0d88806f714p-7088L");
testNumberConvert!("cast(float)-0x9.0f7ee55df77618fp-13829L");
testNumberConvert!("cast(float)0x7.36e6e2640120d28p+8797L");

Iain.


Re: [PATCH v3] c++: Explicit constructor called in copy-initialization [PR90320]

2020-04-26 Thread Marek Polacek via Gcc-patches
On Fri, Apr 24, 2020 at 04:07:03PM -0400, Jason Merrill via Gcc-patches wrote:
> On 4/23/20 7:08 PM, Marek Polacek wrote:
> > > > @@ -1252,6 +1252,8 @@ standard_conversion (tree to, tree from, tree 
> > > > expr, bool c_cast_p,
> > > >  if (flags & LOOKUP_PREFER_RVALUE)
> > > > /* Tell convert_like_real to set LOOKUP_PREFER_RVALUE.  */
> > > > conv->rvaluedness_matches_p = true;
> > > > +  if (flags & LOOKUP_ONLYCONVERTING)
> > > > +   conv->need_temporary_p = true;
> > > 
> > > Presumably we want the same thing for ck_base?
> > 
> > We actually already set need_temporary_p for ck_base in standard_conversion:
> > 1529   conv->need_temporary_p = !(flags & LOOKUP_NO_TEMP_BIND);
> 
> Hmm, yes.  So with your patch the flag means different things for ck_base
> and ck_rvalue.  This suggests to me that overloading need_temporary_p to
> also indicate copy-initialization is problematic, and we should move that
> information to a new flag.

OK, done in the following.  I think the new flag might be useful for PR87605
too.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

-- >8 --
This test is rejected with a bogus "use of deleted function" error
starting with r225705 whereby convert_like_real/ck_base no longer
sets LOOKUP_ONLYCONVERTING for user_conv_p conversions.  This does
not seem to be always correct.  To recap, when we have something like
T t = x where T is a class type and the type of x is not T or derived
from T, we perform copy-initialization, something like:
  1. choose a user-defined conversion to convert x to T, the result is
 a prvalue,
  2. use this prvalue to direct-initialize t.

In the second step, explicit constructors should be considered, since
we're direct-initializing.  This is what r225705 fixed.

In this PR we are dealing with the first step, I think, where explicit
constructors should be skipped.  [over.match.copy] says "The converting
constructors of T are candidate functions" which clearly eliminates
explicit constructors.  But we also have to copy-initialize the argument
we are passing to such a converting constructor, and here we should
disregard explicit constructors too.

In this testcase we have

  V v = m;

and we choose V::V(M) to convert m to V.  But we wrongly choose
the explicit M::M(M&) to copy-initialize the argument; it's
a better match for a non-const lvalue than the implicit M::M(const M&)
but because it's explicit, we shouldn't use it.

When convert_like is processing the ck_user conversion -- the convfn is
V::V(M) -- it can see that cand->flags contains LOOKUP_ONLYCONVERTING,
but then when we're in build_over_call for this convfn, we have no way
to pass the flag to convert_like for the argument 'm', because convert_like
doesn't take flags.  Fixed by creating a new conversion flag, copy_init_p,
set in ck_base/ck_rvalue to signal that explicit constructors should be
skipped.

LOOKUP_COPY_PARM looks relevant, but again, it's a LOOKUP_* flag, so
can't pass it to convert_like.  DR 899 also seemed related, but that
deals with direct-init contexts only.

PR c++/90320
* call.c (struct conversion): Add copy_init_p.
(standard_conversion): Set copy_init_p in ck_base and ck_rvalue
if FLAGS demands LOOKUP_ONLYCONVERTING.
(convert_like_real) : If copy_init_p is set, or
LOOKUP_ONLYCONVERTING into FLAGS.

* g++.dg/cpp0x/explicit13.C: New test.
* g++.dg/cpp0x/explicit14.C: New test.
---
 gcc/cp/call.c   | 26 -
 gcc/testsuite/g++.dg/cpp0x/explicit13.C | 14 +
 gcc/testsuite/g++.dg/cpp0x/explicit14.C | 16 +++
 3 files changed, 51 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/explicit13.C
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/explicit14.C

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index c58231601c9..8345997ccf9 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -92,7 +92,7 @@ struct conversion {
  language standards, e.g. disregarding pointer qualifiers or
  converting integers to pointers.  */
   BOOL_BITFIELD bad_p : 1;
-  /* If KIND is ck_ref_bind ck_base_conv, true to indicate that a
+  /* If KIND is ck_ref_bind or ck_base, true to indicate that a
  temporary should be created to hold the result of the
  conversion.  If KIND is ck_ambig or ck_user, true means force
  copy-initialization.  */
@@ -111,6 +111,10 @@ struct conversion {
   /* Whether check_narrowing should only check TREE_CONSTANTs; used
  in build_converted_constant_expr.  */
   BOOL_BITFIELD check_narrowing_const_only: 1;
+  /* True if this conversion is taking place in a copy-initialization context
+ and we should only consider converting constructors.  Only set in
+ ck_base and ck_rvalue.  */
+  BOOL_BITFIELD copy_init_p : 1;
   /* The type of the expression resulting from the conversion.  */
   tree type;
   union {
@@ -1252,6 +1256,10 @@ standard_conversion (tree to,

Re: [PATCH] match.pd: Move (X & C) eqne (Y & C) -> -> (X ^ Y) & C eqne 0 opt to match.pd [PR94718]

2020-04-26 Thread Richard Biener
On April 26, 2020 2:26:26 PM GMT+02:00, Jakub Jelinek  wrote:
>Hi!
>
>This patch moves this optimization from fold-const.c to match.pd where
>it
>is actually much shorter to do and lets optimize even code not seen
>together
>in a single expression in the source, as the first step towards fixing
>the
>PR.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for stage1?

OK. 

Richard. 

>2020-04-24  Jakub Jelinek  
>
>   PR tree-optimization/94718
>   * fold-const.c (fold_binary_loc): Move (X & C) eqne (Y & C)
>   -> (X ^ Y) & C eqne 0 optimization to ...
>   * match.pd ((X & C) op (Y & C) into (X ^ Y) & C op 0): ... here.
>
>   * gcc.dg/tree-ssa/pr94718-1.c: New test.
>   * gcc.dg/tree-ssa/pr94718-2.c: New test.
>
>--- gcc/fold-const.c.jj2020-04-23 19:50:11.693805797 +0200
>+++ gcc/fold-const.c   2020-04-24 18:34:04.245559495 +0200
>@@ -11631,50 +11631,6 @@ fold_binary_loc (location_t loc, enum tr
> return omit_one_operand_loc (loc, type, res, arg0);
>   }
> 
>-  /* Fold (X & C) op (Y & C) as (X ^ Y) & C op 0", and symmetries.
> */
>-  if (TREE_CODE (arg0) == BIT_AND_EXPR
>-&& TREE_CODE (arg1) == BIT_AND_EXPR)
>-  {
>-tree arg00 = TREE_OPERAND (arg0, 0);
>-tree arg01 = TREE_OPERAND (arg0, 1);
>-tree arg10 = TREE_OPERAND (arg1, 0);
>-tree arg11 = TREE_OPERAND (arg1, 1);
>-tree itype = TREE_TYPE (arg0);
>-
>-if (operand_equal_p (arg01, arg11, 0))
>-  {
>-tem = fold_convert_loc (loc, itype, arg10);
>-tem = fold_build2_loc (loc, BIT_XOR_EXPR, itype, arg00, tem);
>-tem = fold_build2_loc (loc, BIT_AND_EXPR, itype, tem, arg01);
>-return fold_build2_loc (loc, code, type, tem,
>-build_zero_cst (itype));
>-  }
>-if (operand_equal_p (arg01, arg10, 0))
>-  {
>-tem = fold_convert_loc (loc, itype, arg11);
>-tem = fold_build2_loc (loc, BIT_XOR_EXPR, itype, arg00, tem);
>-tem = fold_build2_loc (loc, BIT_AND_EXPR, itype, tem, arg01);
>-return fold_build2_loc (loc, code, type, tem,
>-build_zero_cst (itype));
>-  }
>-if (operand_equal_p (arg00, arg11, 0))
>-  {
>-tem = fold_convert_loc (loc, itype, arg10);
>-tem = fold_build2_loc (loc, BIT_XOR_EXPR, itype, arg01, tem);
>-tem = fold_build2_loc (loc, BIT_AND_EXPR, itype, tem, arg00);
>-return fold_build2_loc (loc, code, type, tem,
>-build_zero_cst (itype));
>-  }
>-if (operand_equal_p (arg00, arg10, 0))
>-  {
>-tem = fold_convert_loc (loc, itype, arg11);
>-tem = fold_build2_loc (loc, BIT_XOR_EXPR, itype, arg01, tem);
>-tem = fold_build2_loc (loc, BIT_AND_EXPR, itype, tem, arg00);
>-return fold_build2_loc (loc, code, type, tem,
>-build_zero_cst (itype));
>-  }
>-  }
>-
>   if (TREE_CODE (arg0) == BIT_XOR_EXPR
> && TREE_CODE (arg1) == BIT_XOR_EXPR)
>   {
>--- gcc/match.pd.jj2020-04-23 19:50:11.710805542 +0200
>+++ gcc/match.pd   2020-04-24 18:34:04.247559465 +0200
>@@ -4335,7 +4335,12 @@ (define_operator_list COND_TERNARY
>  (simplify
>   (cmp (convert? addr@0) integer_zerop)
>   (if (tree_single_nonzero_warnv_p (@0, NULL))
>-   { constant_boolean_node (cmp == NE_EXPR, type); })))
>+   { constant_boolean_node (cmp == NE_EXPR, type); }))
>+
>+ /* (X & C) op (Y & C) into (X ^ Y) & C op 0.  */
>+ (simplify
>+  (cmp (bit_and:cs @0 @2) (bit_and:cs @1 @2))
>+  (cmp (bit_and (bit_xor @0 @1) @2) { build_zero_cst (TREE_TYPE (@2));
>})))
> 
> /* If we have (A & C) == C where C is a power of 2, convert this into
>(A & C) != 0.  Similarly for NE_EXPR.  */
>--- gcc/testsuite/gcc.dg/tree-ssa/pr94718-1.c.jj   2020-04-24
>17:31:10.392472875 +0200
>+++ gcc/testsuite/gcc.dg/tree-ssa/pr94718-1.c  2020-04-24
>18:43:35.829119496 +0200
>@@ -0,0 +1,49 @@
>+/* PR tree-optimization/94718 */
>+/* { dg-do compile } */
>+/* { dg-options "-O2 -fno-ipa-icf -fdump-tree-optimized" } */
>+/* { dg-final { scan-tree-dump-times "= \[xy]_\[0-9]+\\\(D\\\) \\^
>\[xy]_\[0-9]+\\\(D\\\);" 6 "optimized" } } */
>+/* { dg-final { scan-tree-dump-times "\[0-9]+ < 0;" 6 "optimized" } }
>*/
>+
>+#define I (-__INT_MAX__ - 1)
>+
>+int
>+f1 (int x, int y)
>+{
>+  return (x & I) != (y & I);
>+}
>+
>+int
>+f2 (int x, int y)
>+{
>+  return (~x & I) != (~y & I);
>+}
>+
>+int
>+f3 (int x, int y)
>+{
>+  return ((x & I) ^ I) != ((y & I) ^ I);
>+}
>+
>+int
>+f4 (int x, int y)
>+{
>+  int s = (x & I);
>+  int t = (y & I);
>+  return s != t;
>+}
>+
>+int
>+f5 (int x, int y)
>+{
>+  int s = (~x & I);
>+  int t = (~y & I);
>+  return s != t;
>+}
>+
>+int
>+f6 (int x, int y)
>+{
>+  int s = ((x & I) ^ I);
>+  int t = ((y & I) ^ I);
>+  return s != t;
>+}
>--- gcc/testsuite

Re: [committed] d: Merge upstream dmd 09db0c41e, druntime e68a5ae3.

2020-04-26 Thread Segher Boessenkool
On Sun, Apr 26, 2020 at 10:38:57AM +0200, Iain Buclaw wrote:
> On 25/04/2020 22:50, Segher Boessenkool wrote:
> > On Sat, Apr 25, 2020 at 02:20:19AM +0200, Iain Buclaw via Gcc-patches wrote:
> >> +// Parse DoubleDoubles as a pair of doubles.
> >> +// The layout of the type is:
> >> +//
> >> +//   [1|  7  |   56  ][   8|   56   ]
> >> +//   [S| Exp | Fraction (hi) ][ Unused | Fraction (low) ]
> >> +//
> >> +// We can get the least significant bits by subtracting the 
> >> IEEE
> >> +// double precision portion from the real value.
> > 
> > That's not correct.  There is no "Unused" field, and the lower fraction
> > is not always an immediate extension of the higher fraction.
> > 
> > (It's not 1,7,56 -- it is 1,11,52).
> 
> Thanks, I did a quick look-up of where the original might have came
> from, and I've found another extended floating point format of IBM.
> I'll send the correction upstream.
> 
> > A "double double" is really a pair of double precision numbers, both
> > with sign and exponent fields.  If the first number has maximum
> > exponent (so, it is infinity or a NaN), the second number is not
> > significant; otherwise, the sum of the two numbers (taken as exact
> > numbers, no rounding, no truncation, etc.) is the represented number.
> > The first number should be that, rounded to double precision.
> > 
> > So the second double does "add fraction bits" somewhat like this, but
> > there is an implicit leading 1, for normal numbers, and there can be a
> > gap between the two halves, too (like in 0x1p0 + 0x1p-100).
> 
> The job of this routine is to pry out the byte representation of real
> (long double) values at compile-time for hashing-related purposes.
> 
> As zero, infinity and NaN are already handled, unless a mismatch between
> compile and run-time computed hashes is found (I haven't seen any
> unit-tests trigger failures in the testsuite), I don't think that there
> is any immediate problem with the current implementation.
> 
> Thanks for the information though.

All bits are significant to the value, there are no unused bits, for
most values.  The sign and exponent of the second number are very much
relevant, in general.

I didn't look at your actual implementation, just this comment, but it
sounds like your tests miss a lot of cases, if no problems were found?


Segher


Re: [PATCH] c-family: Fix ICE on __builtin_speculation_safe_value () [PR94755]

2020-04-26 Thread Jakub Jelinek via Gcc-patches
On Sun, Apr 26, 2020 at 09:58:16AM -0400, Nathan Sidwell wrote:
> > --- gcc/c-family/c-common.c.jj  2020-03-21 18:29:58.989160193 +0100
> > +++ gcc/c-family/c-common.c 2020-04-25 10:13:14.158722031 +0200
> > @@ -7402,9 +7402,11 @@ resolve_overloaded_builtin (location_t l
> > enum built_in_function fncode
> >   = speculation_safe_value_resolve_call (function, params);;
> > +   if (fncode == BUILT_IN_NONE)
> > + return error_mark_node;
> > +
> > first_param = (*params)[0];
> > -   if (fncode == BUILT_IN_NONE
> > -   || !speculation_safe_value_resolve_params (loc, function, params))
> > +   if (!speculation_safe_value_resolve_params (loc, function, params))
> >   return error_mark_node;
> 
> first_param isn't used in that conditional, can't you just move its
> assinment afterwards?

I think I can't, because speculation_safe_value_resolve_params
can modify the (*params)[0] and if there wasn't a reason to remember
(*params)[0] before the call, why would the patch author add first_param
var at all when it could just use (*params)[0]; it does use (*params)[1]...
So my assumption is that where first_param is used, the code wants the
value before promotions/conversions.

Jakub



Re: [PATCH] coroutines: Do not assume parms are named [PR94752].

2020-04-26 Thread Nathan Sidwell

On 4/25/20 4:45 AM, Iain Sandoe wrote:

Hi

As pointed out in the PR, parameters to user-defined coroutines might be
unnamed.  In that case, we must synthesize a name for the coroutine
frame copy.

tested on x86_64-darwin16 so far,
OK if it passes regtest on x86_64-linux?
thanks
Iain

gcc/cp/ChangeLog:

2020-04-25  Iain Sandoe  

* coroutines.cc (morph_fn_to_coro): Ensure that
unnamed function params have a usable and distinct
frame field name.



ok


--
Nathan Sidwell


Re: [PATCH] c-family: Fix ICE on __builtin_speculation_safe_value () [PR94755]

2020-04-26 Thread Nathan Sidwell

On 4/26/20 8:23 AM, Jakub Jelinek wrote:

Hi!

When this builtin has no parameters, speculation_safe_value_resolve_call
returns BUILT_IN_NONE, but resolve_overloaded_builtin uselessly
dereferences the first param just to return error_mark_node immediately.

The following patch rearranges it so that we only read the first parameter
if fncode is not BUILT_IN_NONE.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2020-04-25  Jakub Jelinek  

PR c/94755
* c-common.c (resolve_overloaded_builtin): Return error_mark_node for
fncode == BUILT_IN_NONE before initialization of first_param.

* c-c++-common/pr94755.c: New test.

--- gcc/c-family/c-common.c.jj  2020-03-21 18:29:58.989160193 +0100
+++ gcc/c-family/c-common.c 2020-04-25 10:13:14.158722031 +0200
@@ -7402,9 +7402,11 @@ resolve_overloaded_builtin (location_t l
enum built_in_function fncode
  = speculation_safe_value_resolve_call (function, params);;
  
+	if (fncode == BUILT_IN_NONE)

+ return error_mark_node;
+
first_param = (*params)[0];
-   if (fncode == BUILT_IN_NONE
-   || !speculation_safe_value_resolve_params (loc, function, params))
+   if (!speculation_safe_value_resolve_params (loc, function, params))
  return error_mark_node;


first_param isn't used in that conditional, can't you just move its assinment 
afterwards?



--
Nathan Sidwell


[PATCH] match.pd: Move (X & C) eqne (Y & C) -> -> (X ^ Y) & C eqne 0 opt to match.pd [PR94718]

2020-04-26 Thread Jakub Jelinek via Gcc-patches
Hi!

This patch moves this optimization from fold-const.c to match.pd where it
is actually much shorter to do and lets optimize even code not seen together
in a single expression in the source, as the first step towards fixing the
PR.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for stage1?

2020-04-24  Jakub Jelinek  

PR tree-optimization/94718
* fold-const.c (fold_binary_loc): Move (X & C) eqne (Y & C)
-> (X ^ Y) & C eqne 0 optimization to ...
* match.pd ((X & C) op (Y & C) into (X ^ Y) & C op 0): ... here.

* gcc.dg/tree-ssa/pr94718-1.c: New test.
* gcc.dg/tree-ssa/pr94718-2.c: New test.

--- gcc/fold-const.c.jj 2020-04-23 19:50:11.693805797 +0200
+++ gcc/fold-const.c2020-04-24 18:34:04.245559495 +0200
@@ -11631,50 +11631,6 @@ fold_binary_loc (location_t loc, enum tr
  return omit_one_operand_loc (loc, type, res, arg0);
}
 
-  /* Fold (X & C) op (Y & C) as (X ^ Y) & C op 0", and symmetries.  */
-  if (TREE_CODE (arg0) == BIT_AND_EXPR
- && TREE_CODE (arg1) == BIT_AND_EXPR)
-   {
- tree arg00 = TREE_OPERAND (arg0, 0);
- tree arg01 = TREE_OPERAND (arg0, 1);
- tree arg10 = TREE_OPERAND (arg1, 0);
- tree arg11 = TREE_OPERAND (arg1, 1);
- tree itype = TREE_TYPE (arg0);
-
- if (operand_equal_p (arg01, arg11, 0))
-   {
- tem = fold_convert_loc (loc, itype, arg10);
- tem = fold_build2_loc (loc, BIT_XOR_EXPR, itype, arg00, tem);
- tem = fold_build2_loc (loc, BIT_AND_EXPR, itype, tem, arg01);
- return fold_build2_loc (loc, code, type, tem,
- build_zero_cst (itype));
-   }
- if (operand_equal_p (arg01, arg10, 0))
-   {
- tem = fold_convert_loc (loc, itype, arg11);
- tem = fold_build2_loc (loc, BIT_XOR_EXPR, itype, arg00, tem);
- tem = fold_build2_loc (loc, BIT_AND_EXPR, itype, tem, arg01);
- return fold_build2_loc (loc, code, type, tem,
- build_zero_cst (itype));
-   }
- if (operand_equal_p (arg00, arg11, 0))
-   {
- tem = fold_convert_loc (loc, itype, arg10);
- tem = fold_build2_loc (loc, BIT_XOR_EXPR, itype, arg01, tem);
- tem = fold_build2_loc (loc, BIT_AND_EXPR, itype, tem, arg00);
- return fold_build2_loc (loc, code, type, tem,
- build_zero_cst (itype));
-   }
- if (operand_equal_p (arg00, arg10, 0))
-   {
- tem = fold_convert_loc (loc, itype, arg11);
- tem = fold_build2_loc (loc, BIT_XOR_EXPR, itype, arg01, tem);
- tem = fold_build2_loc (loc, BIT_AND_EXPR, itype, tem, arg00);
- return fold_build2_loc (loc, code, type, tem,
- build_zero_cst (itype));
-   }
-   }
-
   if (TREE_CODE (arg0) == BIT_XOR_EXPR
  && TREE_CODE (arg1) == BIT_XOR_EXPR)
{
--- gcc/match.pd.jj 2020-04-23 19:50:11.710805542 +0200
+++ gcc/match.pd2020-04-24 18:34:04.247559465 +0200
@@ -4335,7 +4335,12 @@ (define_operator_list COND_TERNARY
  (simplify
   (cmp (convert? addr@0) integer_zerop)
   (if (tree_single_nonzero_warnv_p (@0, NULL))
-   { constant_boolean_node (cmp == NE_EXPR, type); })))
+   { constant_boolean_node (cmp == NE_EXPR, type); }))
+
+ /* (X & C) op (Y & C) into (X ^ Y) & C op 0.  */
+ (simplify
+  (cmp (bit_and:cs @0 @2) (bit_and:cs @1 @2))
+  (cmp (bit_and (bit_xor @0 @1) @2) { build_zero_cst (TREE_TYPE (@2)); })))
 
 /* If we have (A & C) == C where C is a power of 2, convert this into
(A & C) != 0.  Similarly for NE_EXPR.  */
--- gcc/testsuite/gcc.dg/tree-ssa/pr94718-1.c.jj2020-04-24 
17:31:10.392472875 +0200
+++ gcc/testsuite/gcc.dg/tree-ssa/pr94718-1.c   2020-04-24 18:43:35.829119496 
+0200
@@ -0,0 +1,49 @@
+/* PR tree-optimization/94718 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fno-ipa-icf -fdump-tree-optimized" } */
+/* { dg-final { scan-tree-dump-times "= \[xy]_\[0-9]+\\\(D\\\) \\^ 
\[xy]_\[0-9]+\\\(D\\\);" 6 "optimized" } } */
+/* { dg-final { scan-tree-dump-times "\[0-9]+ < 0;" 6 "optimized" } } */
+
+#define I (-__INT_MAX__ - 1)
+
+int
+f1 (int x, int y)
+{
+  return (x & I) != (y & I);
+}
+
+int
+f2 (int x, int y)
+{
+  return (~x & I) != (~y & I);
+}
+
+int
+f3 (int x, int y)
+{
+  return ((x & I) ^ I) != ((y & I) ^ I);
+}
+
+int
+f4 (int x, int y)
+{
+  int s = (x & I);
+  int t = (y & I);
+  return s != t;
+}
+
+int
+f5 (int x, int y)
+{
+  int s = (~x & I);
+  int t = (~y & I);
+  return s != t;
+}
+
+int
+f6 (int x, int y)
+{
+  int s = ((x & I) ^ I);
+  int t = ((y & I) ^ I);
+  return s != t;
+}
--- gcc/testsuite/gcc.dg/tree-ssa/pr94718-2.c.jj2020-04-24 
17:31:13.673424244 +0200
+++ gcc/testsuite/gcc.dg/tree-ssa/pr94718-2.c   2020-04-24 18:43:44.669988955 
+0200
@@ -0,0 +1,49 @@

[PATCH] c-family: Fix ICE on __builtin_speculation_safe_value () [PR94755]

2020-04-26 Thread Jakub Jelinek via Gcc-patches
Hi!

When this builtin has no parameters, speculation_safe_value_resolve_call
returns BUILT_IN_NONE, but resolve_overloaded_builtin uselessly
dereferences the first param just to return error_mark_node immediately.

The following patch rearranges it so that we only read the first parameter
if fncode is not BUILT_IN_NONE.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2020-04-25  Jakub Jelinek  

PR c/94755
* c-common.c (resolve_overloaded_builtin): Return error_mark_node for
fncode == BUILT_IN_NONE before initialization of first_param.

* c-c++-common/pr94755.c: New test.

--- gcc/c-family/c-common.c.jj  2020-03-21 18:29:58.989160193 +0100
+++ gcc/c-family/c-common.c 2020-04-25 10:13:14.158722031 +0200
@@ -7402,9 +7402,11 @@ resolve_overloaded_builtin (location_t l
enum built_in_function fncode
  = speculation_safe_value_resolve_call (function, params);;
 
+   if (fncode == BUILT_IN_NONE)
+ return error_mark_node;
+
first_param = (*params)[0];
-   if (fncode == BUILT_IN_NONE
-   || !speculation_safe_value_resolve_params (loc, function, params))
+   if (!speculation_safe_value_resolve_params (loc, function, params))
  return error_mark_node;
 
if (targetm.have_speculation_safe_value (true))
--- gcc/testsuite/c-c++-common/pr94755.c.jj 2020-04-25 10:17:53.297502562 
+0200
+++ gcc/testsuite/c-c++-common/pr94755.c2020-04-25 10:18:32.261916902 
+0200
@@ -0,0 +1,11 @@
+/* PR c/94755 */
+/* { dg-do compile } */
+
+extern void foo (void);
+
+void
+bar (double x)
+{
+  if (x == __builtin_speculation_safe_value ())/* { dg-error "too few 
arguments to function" } */
+foo ();
+}

Jakub



[PATCH] s390: Fix C++14 vs. C++17 ABI incompatibility on s390{,x} [PR94704]

2020-04-26 Thread Jakub Jelinek via Gcc-patches
Hi!

The following patch fixes the C++14 vs. C++17 ABI passing incompatibility
on s390x-linux.

Bootstrapped/regtested on s390x-linux without and with the patch, the
difference being:
-FAIL: tmpdir-g++.dg-struct-layout-1/t032 cp_compat_x_alt.o-cp_compat_y_tst.o 
execute 
 FAIL: tmpdir-g++.dg-struct-layout-1/t032 cp_compat_x_tst.o-cp_compat_y_alt.o 
execute 
-FAIL: tmpdir-g++.dg-struct-layout-1/t032 cp_compat_x_tst.o-cp_compat_y_tst.o 
execute 
 FAIL: tmpdir-g++.dg-struct-layout-1/t055 cp_compat_x_alt.o-cp_compat_y_alt.o 
execute 
 FAIL: tmpdir-g++.dg-struct-layout-1/t055 cp_compat_x_alt.o-cp_compat_y_tst.o 
execute 
-FAIL: tmpdir-g++.dg-struct-layout-1/t055 cp_compat_x_tst.o-cp_compat_y_alt.o 
execute 
-FAIL: tmpdir-g++.dg-struct-layout-1/t055 cp_compat_x_tst.o-cp_compat_y_tst.o 
execute 
 FAIL: tmpdir-g++.dg-struct-layout-1/t056 cp_compat_x_alt.o-cp_compat_y_alt.o 
execute 
-FAIL: tmpdir-g++.dg-struct-layout-1/t056 cp_compat_x_alt.o-cp_compat_y_tst.o 
execute 
 FAIL: tmpdir-g++.dg-struct-layout-1/t056 cp_compat_x_tst.o-cp_compat_y_alt.o 
execute 
-FAIL: tmpdir-g++.dg-struct-layout-1/t056 cp_compat_x_tst.o-cp_compat_y_tst.o 
execute 
 FAIL: tmpdir-g++.dg-struct-layout-1/t057 cp_compat_x_alt.o-cp_compat_y_alt.o 
execute 
-FAIL: tmpdir-g++.dg-struct-layout-1/t057 cp_compat_x_alt.o-cp_compat_y_tst.o 
execute 
 FAIL: tmpdir-g++.dg-struct-layout-1/t057 cp_compat_x_tst.o-cp_compat_y_alt.o 
execute 
-FAIL: tmpdir-g++.dg-struct-layout-1/t057 cp_compat_x_tst.o-cp_compat_y_tst.o 
execute 
 FAIL: tmpdir-g++.dg-struct-layout-1/t058 cp_compat_x_alt.o-cp_compat_y_alt.o 
execute 
 FAIL: tmpdir-g++.dg-struct-layout-1/t058 cp_compat_x_alt.o-cp_compat_y_tst.o 
execute 
-FAIL: tmpdir-g++.dg-struct-layout-1/t058 cp_compat_x_tst.o-cp_compat_y_alt.o 
execute 
-FAIL: tmpdir-g++.dg-struct-layout-1/t058 cp_compat_x_tst.o-cp_compat_y_tst.o 
execute 
 FAIL: tmpdir-g++.dg-struct-layout-1/t059 cp_compat_x_alt.o-cp_compat_y_alt.o 
execute 
 FAIL: tmpdir-g++.dg-struct-layout-1/t059 cp_compat_x_alt.o-cp_compat_y_tst.o 
execute 
-FAIL: tmpdir-g++.dg-struct-layout-1/t059 cp_compat_x_tst.o-cp_compat_y_alt.o 
execute 
-FAIL: tmpdir-g++.dg-struct-layout-1/t059 cp_compat_x_tst.o-cp_compat_y_tst.o 
execute 
when performing ALT_CXX_UNDER_TEST=g++ testing with a system GCC 10 compiler
from a week ago.  So, the alt vs. alt FAILs are all expected (we know before
this patch there is an ABI incompatibility) and some alt vs. tst (or tst vs.
alt) FAILs too - that depends on if the particular x or y test is compiled
with -std=c++14 or -std=c++17 - if x_tst is compiled with -std=c++14 and
y_alt is compiled with -std=c++17, then it should FAIL, similarly if x_alt
is compiled with -std=c++17 and y_tst is compiled with -std=c++14.

Ok for trunk?  Or do you want -Wpsabi warning too (seems s390 backend
doesn't have any -Wpsabi warnings or informs yet)?

2020-04-22  Jakub Jelinek  

PR target/94704
* config/s390/s390.c (s390_function_arg_vector,
s390_function_arg_float): Ignore cxx17_empty_base_field_p fields.

--- gcc/config/s390/s390.c.jj   2020-03-14 08:14:47.097741411 +0100
+++ gcc/config/s390/s390.c  2020-04-22 14:24:17.980091105 +0200
@@ -11917,7 +11917,8 @@ s390_function_arg_vector (machine_mode m
 
   for (field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
{
- if (TREE_CODE (field) != FIELD_DECL)
+ if (TREE_CODE (field) != FIELD_DECL
+ || cxx17_empty_base_field_p (field))
continue;
 
  if (single == NULL_TREE)
@@ -11967,7 +11968,8 @@ s390_function_arg_float (machine_mode mo
 
   for (field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
{
- if (TREE_CODE (field) != FIELD_DECL)
+ if (TREE_CODE (field) != FIELD_DECL
+ || cxx17_empty_base_field_p (field))
continue;
 
  if (single == NULL_TREE)

Jakub



New Swedish PO file for 'gcc' (version 10.1-b20200322)

2020-04-26 Thread Translation Project Robot
Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators.  The file is available at:

https://translationproject.org/latest/gcc/sv.po

(This file, 'gcc-10.1-b20200322.sv.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.




MANPOWER (Employee) Solutions for GCC GNU ORG

2020-04-26 Thread Farrukh | S.A.Z Universal Links via Gcc-patches
Attn: HR Dept. (GCC GNU ORG)

 

Dear Sir/Ma'am,

 

We (S.A.Z Universal Links) are a dedicated ‘Recruitment and Staffing’ Company 
in the sense that we can staff for a range of different industries. We work in 
a strategically processed manner to help industries attain potential 
candidates. We have been serving many reputable clients such as Almarai 
Company, Al Dossary Construction, Isam Kabbani Group, Al-Latifia Trading & 
Contracting Co, Jaddarah workforce services, Eastern Trading & Const. Est., 
Al-Osais Intenational Holding Co, Jeddah Cables Company, Nesma & Partners, 
Abdullah A.Al-Barrak & Sons Co., Johnson Controls, Saeed R Al-Zahrani 
Corporation (SRACO), Al-Watania Industries, Aecom Arabia Ltd. Co. and many more.

 

We have potential candidates that come from different backgrounds like 
Construction, Maintenance, Oil & Gas, IT, Hospitality/Healthcare, Retail, EPC, 
Civil, Mechanical, Logistics, Banking, Finance, Sales, Marketing, facility 
management etc.

 

We are here to offer you MANPOWER SOLUTIONS from unskilled, semi-skilled & 
skilled professionals, mid to top-level management with the following package:

-- Candidates within and from Pakistan

-- Qualified candidates daily pouring in

-- Candidates for every field and Industry

-- 24/7 support from our headquarter in Pakistan and from our offices in Dubai, 
Riyadh & Doha.




If this is something that piques your interest, let’s set up a time to chat or 
call!

 

I look forward to speaking with you soon to discuss more!

 

Regards,





Farrukh A. Shaikh

+92300-8228363


(WhatsApp/IMO/BotIM)

 

For Inquiries, please email to farr...@sazunilinks.com 


 

Please click on below given PDF link and download our detailed company profile 
with some of our work history for your kind reference: 

http://sazunilinks.com/profile.pdf 


[committed] libphobos: Add power*-*-linux* as a supported target

2020-04-26 Thread Iain Buclaw via Gcc-patches
Hi,

This patch adds power*-*-linux* as a supported target for libphobos.

As there is no support for IBM real (long double) types in the std.math
module, full phobos support has been switched off.  This is not needed
currently anyway in order to be able to bootstrap a self-hosted
front-end written in D.

Testsuite summaries from a native powerpc64le D compiler running inside
a QEMU/Docker container:

---
=== libphobos tests ===
WARNING: libphobos.allocations/tls_gc_integration.d execution test program 
timed out.
FAIL: libphobos.allocations/tls_gc_integration.d execution test
FAIL: libphobos.hash/test_hash.d execution test
FAIL: libphobos.thread/tlsgc_sections.d execution test
=== libphobos Summary ===
# of expected passes62
# of unexpected failures3
# of unsupported tests  1
 
=== gdc tests ===
FAIL: compilable/ctfe_math.d   output-exists ctfe_math.o
FAIL: compilable/ctfe_math.d -O2output-exists ctfe_math.o
FAIL: compilable/ctfe_math.d -freleaseoutput-exists ctfe_math.o
FAIL: compilable/ctfe_math.d -O2 -freleaseoutput-exists ctfe_math.o
FAIL: compilable/ctfe_math.d -goutput-exists ctfe_math.o
FAIL: compilable/ctfe_math.d -O2 -goutput-exists ctfe_math.o
FAIL: compilable/ctfe_math.d -frelease -goutput-exists ctfe_math.o
FAIL: compilable/ctfe_math.d -O2 -frelease -goutput-exists ctfe_math.o
WARNING: compilable/test15019.d -O2 -frelease   (test for excess errors) 
program timed out.
FAIL: compilable/test15019.d -O2 -freleaseoutput-exists test15019.o
WARNING: compilable/test15019.d -O2 -g   (test for excess errors) program timed 
out.
FAIL: compilable/test15019.d -O2 -goutput-exists test15019.o
WARNING: compilable/test15019.d -O2 -frelease -g   (test for excess errors) 
program timed out.
FAIL: compilable/test15019.d -O2 -frelease -goutput-exists test15019.o
WARNING: compilable/test15019.d -O2   (test for excess errors) program timed 
out.
FAIL: compilable/test15019.d -O2output-exists test15019.o
FAIL: compilable/test5227.d   output-exists test5227.o
=== gdc Summary ===
# of expected passes21181
# of unexpected failures13
# of unsupported tests  100
/build/gcc/gdc  version 10.0.1 20200425 (experimental) (GCC)
---

Of those that flagged up:

 * I have no immediate cause for concern on the timed out tests, as the
   QEMU interpreter can take a long time to run expensive tests.

 * I can only attribute the test_hash.d failure to QEMU, as it doesn't
   strike me as being anything else.

float f = 2.71;
ubyte* p = cast(ubyte*)&f;
// 2.71 = 0
printf("%f = %d\n", *cast(float*)p, *cast(uint*)p);
uint p0 = cast(uint)p[0];
uint p1 = cast(uint)p[1] << 8;
uint p2 = cast(uint)p[2] << 16;
uint p3 = cast(uint)p[3] << 24;
// 1076719780
printf("%d\n", (p0|p1|p2|p3));
uint i = (p0|p1|p2|p3);
// 0
printf("%d\n", i);

* ctfe_math.d and test5227.d are already reported in PR d/89418.


Tested non-bootstrapped targets powerpc-linux-gnu, powerpc64-linux-gnu,
and powerpc64le-linux-gnu.  Committed to mainline.

Regards
Iain.

---
libphobos/ChangeLog:

* configure: Regenerate.
* configure.tgt: Add power*-*-linux* as a supported target, only
building libdruntime.
* m4/druntime/cpu.m4 (DRUNTIME_CPU_SOURCES): Add cases for powerpcle
and powerpc64le target cpus.
---
 libphobos/configure  | 5 +++--
 libphobos/configure.tgt  | 4 
 libphobos/m4/druntime/cpu.m4 | 5 +++--
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/libphobos/configure b/libphobos/configure
index c2b49132fda..c923417532f 100755
--- a/libphobos/configure
+++ b/libphobos/configure
@@ -13991,9 +13991,10 @@ fi
;;
   mips*)   druntime_target_cpu_parsed="mips"
;;
-  powerpc) druntime_target_cpu_parsed="powerpc"
+  powerpc|powerpcle)
+   druntime_target_cpu_parsed="powerpc"
;;
-  powerpc64)
+  powerpc64|powerpc64le)
druntime_target_cpu_parsed="powerpc64"
;;
   i[34567]86|x86_64)
diff --git a/libphobos/configure.tgt b/libphobos/configure.tgt
index 66082e36fad..ce4cc1f7527 100644
--- a/libphobos/configure.tgt
+++ b/libphobos/configure.tgt
@@ -33,6 +33,10 @@ case "${target}" in
   mips*-*-linux*)
LIBPHOBOS_SUPPORTED=yes
;;
+  power*-*-linux*)
+   LIBPHOBOS_SUPPORTED=yes
+   LIBDRUNTIME_ONLY=yes
+   ;;
   riscv*-*-linux*)
LIBPHOBOS_SUPPORTED=yes
;;
diff --git a/libphobos/m4/druntime/cpu.m4 b/libphobos/m4/druntime/cpu.m4
index 4887248fd09..6e88896ca66 100644
--- a/libphobos/m4/druntime/cpu.m4
+++ b/libphobos/m4/druntime/cpu.m4
@@ -17,9 +17,10 @@ AC_DEFUN([DRUNTIME_CPU_SOURCES],
;;
   mips*)   druntime_target_cpu_parsed="mips"
;;
-  powerpc) druntime_target_cpu_parsed="powerpc"
+  powerpc|powerpcle)
+   druntime_target_cpu_pars

[committed] d: Recognize pragma(inline) in the code generator.

2020-04-26 Thread Iain Buclaw via Gcc-patches
Hi,

This patch adds recognition of pragma(inline) in the code generator.

Pragma inline affects whether functions are inlined or not.  If at the
declaration level, it affects the functions declared in the block it
controls.  If inside a function, it affects the function it is enclosed
by.  Support has been in the front-end for some time, but the
information was not leveraged by the code generation pass.

Bootstrapped and regression tested on x86_64-linux-gnu, and committed to
mainline.

Regards
Iain.

---
gcc/d/ChangeLog:

* decl.cc (get_symbol_decl): Set DECL_DECLARED_INLINE_P or
DECL_UNINLINABLE for declarations with pragma(inline).
* toir.cc (IRVisitor::visit (GccAsmStatement *)): Set ASM_INLINE_P if
in function decorated with pragma(inline).
---
 gcc/d/decl.cc | 7 +++
 gcc/d/toir.cc | 8 +++-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/gcc/d/decl.cc b/gcc/d/decl.cc
index 042c10c2943..845fc5cf877 100644
--- a/gcc/d/decl.cc
+++ b/gcc/d/decl.cc
@@ -1277,6 +1277,13 @@ get_symbol_decl (Declaration *decl)
  DECL_NO_INLINE_WARNING_P (decl->csym) = 1;
}
 
+  /* In [pragma/inline], functions decorated with 'pragma(inline)' affects
+whether they are inlined or not.  */
+  if (fd->inlining == PINLINEalways)
+   DECL_DECLARED_INLINE_P (decl->csym) = 1;
+  else if (fd->inlining == PINLINEnever)
+   DECL_UNINLINABLE (decl->csym) = 1;
+
   /* Function was declared 'naked'.  */
   if (fd->naked)
{
diff --git a/gcc/d/toir.cc b/gcc/d/toir.cc
index 6aaf10bf4e4..074cde0e0da 100644
--- a/gcc/d/toir.cc
+++ b/gcc/d/toir.cc
@@ -1423,7 +1423,8 @@ public:
   outputs, inputs, clobbers, labels);
 SET_EXPR_LOCATION (exp, make_location_t (s->loc));
 
-/* If the extended syntax was not used, mark the ASM_EXPR.  */
+/* If the extended syntax was not used, mark the ASM_EXPR as being an
+   ASM_INPUT expression instead of an ASM_OPERAND with no operands.  */
 if (s->args == NULL && s->clobbers == NULL)
   ASM_INPUT_P (exp) = 1;
 
@@ -1431,6 +1432,11 @@ public:
optimization, this could be unset when building in release mode.  */
 ASM_VOLATILE_P (exp) = 1;
 
+/* If the function has been annotated with 'pragma(inline)', then mark
+   the asm expression as being inline as well.  */
+if (this->func_->inlining == PINLINEalways)
+  ASM_INLINE_P (exp) = 1;
+
 add_stmt (exp);
   }
 
-- 
2.20.1



Re: [committed] d: Merge upstream dmd 09db0c41e, druntime e68a5ae3.

2020-04-26 Thread Iain Buclaw via Gcc-patches
On 25/04/2020 22:50, Segher Boessenkool wrote:
> Hi!
> 
> On Sat, Apr 25, 2020 at 02:20:19AM +0200, Iain Buclaw via Gcc-patches wrote:
>> +// Parse DoubleDoubles as a pair of doubles.
>> +// The layout of the type is:
>> +//
>> +//   [1|  7  |   56  ][   8|   56   ]
>> +//   [S| Exp | Fraction (hi) ][ Unused | Fraction (low) ]
>> +//
>> +// We can get the least significant bits by subtracting the IEEE
>> +// double precision portion from the real value.
> 
> That's not correct.  There is no "Unused" field, and the lower fraction
> is not always an immediate extension of the higher fraction.
> 
> (It's not 1,7,56 -- it is 1,11,52).
> 

Thanks, I did a quick look-up of where the original might have came
from, and I've found another extended floating point format of IBM.
I'll send the correction upstream.


> A "double double" is really a pair of double precision numbers, both
> with sign and exponent fields.  If the first number has maximum
> exponent (so, it is infinity or a NaN), the second number is not
> significant; otherwise, the sum of the two numbers (taken as exact
> numbers, no rounding, no truncation, etc.) is the represented number.
> The first number should be that, rounded to double precision.
> 
> So the second double does "add fraction bits" somewhat like this, but
> there is an implicit leading 1, for normal numbers, and there can be a
> gap between the two halves, too (like in 0x1p0 + 0x1p-100).
> 
> 

The job of this routine is to pry out the byte representation of real
(long double) values at compile-time for hashing-related purposes.

As zero, infinity and NaN are already handled, unless a mismatch between
compile and run-time computed hashes is found (I haven't seen any
unit-tests trigger failures in the testsuite), I don't think that there
is any immediate problem with the current implementation.

Thanks for the information though.

Iain.




Re: [PATCH] c++, middle-end, rs6000: Fix C++17 ABI incompatibilities during class layout [PR94707]

2020-04-26 Thread Iain Sandoe

David Edelsohn  wrote:


On Sat, Apr 25, 2020 at 6:03 AM Jakub Jelinek  wrote:

Hi!

As reported by Iain and David, powerpc-darwin and powerpc-aix* have C++14
vs. C++17 ABI incompatibilities which are not fixed by mere adding of
cxx17_empty_base_field_p calls.  Unlike the issues that were seen on other
targets where the artificial empty base field affected function argument
passing or returning of values, on these two targets the difference is
during class layout, not afterwards (e.g.
struct empty_base {};
struct S : public empty_base { unsigned long long l[2]; };
will have different __alignof__ (S) between C++14 and C++17 (or possibly
with double instead of unsigned long long too)).

The aim of the calls.c (cxx17_empty_base_field_p) was not to match random
artificial fields with zero size, because they could be created by  
something
else for some other reason, thus the DECL_SIZE is bitsize_zero but  
TYPE_SIZE

is non-zero check.  Unfortunately, during the class layout, the empty base
fields have a different type, one which has zero size, so the predicate  
only

works after the class is laid out completely.

This patch adds a langhook, which will return true for those cases.  It
shouldn't be problematic with LTO, because lto1 should see only
structures/classes that are already laid out, or if it does some structure
layout, it won't be something that has C++17 empty base artificial fields.

Tested with cross to powerpc-darwin12 on a simple testcase given from  
Iain,

but otherwise untested.
Iain/David, could you please test this on your targets?
Ok for trunk?


The patch fixes the AIX failures.


It also fixes them on Darwin.


The rs6000 part is okay.

Thanks for tracking down and fixing all of this fallout.


yes, thanks indeed.
Iain



Thanks, David


2020-04-25  Jakub Jelinek  

   PR target/94707
   * langhooks.h (struct lang_hooks_for_decls): Add
   cxx17_empty_base_field_p member.
   * langhooks-def.h (LANG_HOOKS_CXX17_EMPTY_BASE_FIELD_P): Define.
   (LANG_HOOKS_DECLS): Use it.
   * calls.c (cxx17_empty_base_field_p): Use
   langhooks.decls.cxx17_empty_base_field_p.
   * config/rs6000/rs6000.c (rs6000_special_round_type_align,
   darwin_rs6000_special_round_type_align): Skip cxx17_empty_base_field_p
   fields.
cp/
   * cp-objcp-common.h (cp_cxx17_empty_base_field_p): Declare.
   (LANG_HOOKS_CXX17_EMPTY_BASE_FIELD_P): Redefine.
   * class.c (cp_cxx17_empty_base_field_p): New function.

--- gcc/langhooks.h.jj  2020-03-17 13:50:52.262943386 +0100
+++ gcc/langhooks.h 2020-04-25 11:06:11.921931710 +0200
@@ -226,6 +226,9 @@ struct lang_hooks_for_decls
  /* True if this decl may be called via a sibcall.  */
  bool (*ok_for_sibcall) (const_tree);

+  /* True if this FIELD_DECL is C++17 empty base field.  */
+  bool (*cxx17_empty_base_field_p) (const_tree);
+
  /* Return a tree for the actual data of an array descriptor - or NULL_TREE
 if original tree is not an array descriptor.  If the second argument
 is true, only the TREE_TYPE is returned without generating a new tree.  */
--- gcc/langhooks-def.h.jj  2020-01-12 11:54:36.670409531 +0100
+++ gcc/langhooks-def.h 2020-04-25 11:06:03.300061347 +0200
@@ -241,6 +241,7 @@ extern tree lhd_unit_size_without_reusab
#define LANG_HOOKS_WARN_UNUSED_GLOBAL_DECL lhd_warn_unused_global_decl
#define LANG_HOOKS_POST_COMPILATION_PARSING_CLEANUPS NULL
#define LANG_HOOKS_DECL_OK_FOR_SIBCALL lhd_decl_ok_for_sibcall
+#define LANG_HOOKS_CXX17_EMPTY_BASE_FIELD_Phook_bool_const_tree_false
#define LANG_HOOKS_OMP_ARRAY_DATA  hook_tree_tree_bool_null
#define LANG_HOOKS_OMP_IS_ALLOCATABLE_OR_PTR hook_bool_const_tree_false
#define LANG_HOOKS_OMP_CHECK_OPTIONAL_ARGUMENT hook_tree_tree_bool_null
@@ -269,6 +270,7 @@ extern tree lhd_unit_size_without_reusab
  LANG_HOOKS_WARN_UNUSED_GLOBAL_DECL, \
  LANG_HOOKS_POST_COMPILATION_PARSING_CLEANUPS, \
  LANG_HOOKS_DECL_OK_FOR_SIBCALL, \
+  LANG_HOOKS_CXX17_EMPTY_BASE_FIELD_P, \
  LANG_HOOKS_OMP_ARRAY_DATA, \
  LANG_HOOKS_OMP_IS_ALLOCATABLE_OR_PTR, \
  LANG_HOOKS_OMP_CHECK_OPTIONAL_ARGUMENT, \
--- gcc/calls.c.jj  2020-04-22 16:44:30.765946555 +0200
+++ gcc/calls.c 2020-04-25 11:14:45.038217088 +0200
@@ -6275,8 +6275,9 @@ cxx17_empty_base_field_p (const_tree fie
 && RECORD_OR_UNION_TYPE_P (TREE_TYPE (field))
 && DECL_SIZE (field)
 && integer_zerop (DECL_SIZE (field))
- && TYPE_SIZE (TREE_TYPE (field))
- && !integer_zerop (TYPE_SIZE (TREE_TYPE (field;
+ && ((TYPE_SIZE (TREE_TYPE (field))
+  && !integer_zerop (TYPE_SIZE (TREE_TYPE (field
+ || lang_hooks.decls.cxx17_empty_base_field_p (field)));
}

/* Tell the garbage collector about GTY markers in this source file.  */
--- gcc/config/rs6000/rs6000.c.jj   2020-04-22 16:43:14.913087731  
+0200

+++ gcc/config/rs6000/rs6000.c  2020-04-25 11:16:01.536067016 +0200
@@ -7192,7 +7192,9 @@ rs6000_special_round_type_align (tree ty
  tree field