[Committed] Fix testsuite/92998: dupq_1.c and simd-abi-8.c fail on big-endian

2019-12-21 Thread Andrew Pinski
Hi,
  These two testcases fail on big-endian aarch64 Linux targets as they
include arm_neon.h or arm_sve.h which in turns includes stdint.h; this
fails as stdint.h includes stubs.h but the stubs for little-endian
does not exist for big-endian.

This fixes the problem by restricting these tests to little-endian only.

Committed as obvious after a test on aarch64_be-linux-gnu.

Thanks,
Andrew Pinski

testsuite/ChangeLog:
PR testsuite/92998
* gcc.target/aarch64/sve/acle/general/dupq_1.c:
Restrict to aarch64_little_endian only.
* gcc.target/aarch64/torture/simd-abi-8.c:
Likewise.
Index: ChangeLog
===
--- ChangeLog   (revision 279708)
+++ ChangeLog   (working copy)
@@ -1,3 +1,11 @@
+2019-12-21  Andrew Pinski  
+
+   PR testsuite/92998
+   * gcc.target/aarch64/sve/acle/general/dupq_1.c:
+   Restrict to aarch64_little_endian only.
+   * gcc.target/aarch64/torture/simd-abi-8.c:
+   Likewise.
+
 2019-12-22  Maciej W. Rozycki  
 
* lib/gcc-defs.exp (gcc-set-multilib-library-path): Use
Index: gcc.target/aarch64/sve/acle/general/dupq_1.c
===
--- gcc.target/aarch64/sve/acle/general/dupq_1.c(revision 279708)
+++ gcc.target/aarch64/sve/acle/general/dupq_1.c(working copy)
@@ -1,5 +1,6 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -mlittle-endian" } */
+/* { dg-options "-O2" } */
+/* { dg-require-effective-target aarch64_little_endian } */
 
 #include 
 
Index: gcc.target/aarch64/torture/simd-abi-8.c
===
--- gcc.target/aarch64/torture/simd-abi-8.c (revision 279708)
+++ gcc.target/aarch64/torture/simd-abi-8.c (working copy)
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
-/* { dg-options "-std=gnu99 -mlittle-endian" } */
+/* { dg-options "-std=gnu99" } */
 /* { dg-skip-if "" { *-*-* } { "-O0" } { "" } } */
+/* { dg-require-effective-target aarch64_little_endian } */
 
 #include 
 


Re: [PING^4][PATCH 0/4] Fix library testsuite compilation for build sysroot

2019-12-21 Thread Maciej W. Rozycki
On Fri, 20 Dec 2019, Mike Stump wrote:

> >> This patch series addresses a problem with the testsuite compiler being 
> >> set up across libatomic, libffi, libgo, libgomp with no correlation 
> >> whatsoever to the target compiler being used in GCC compilation.  
> >> Consequently there in no arrangement made to set up the compilation 
> >> sysroot according to the build sysroot specified for GCC compilation, 
> >> causing a catastrophic failure across the testsuites affected from the 
> >> inability to link executables.
> > 
> > Ping for:
> > 
> > 
> > 
> > 
> 
> Hum...  I'm wondering who should review this...  Feels like I should, 
> the problem is it intertwines with the build system as well.  So, let me 
> approve the testsuite parts so that can clear the way for someone else 
> to approve the remaining bits (if not obvious).

 Thanks for your review; I have applied 4/4 as it doesn't contain any 
non-testsuite parts and will continue pinging 1/4 and 2/4 for the build 
system bits then (3/4 has been already committed by the Go maintainer).

> Please do watch out for breakages as it goes in.  Thanks.

 Sure!

  Maciej


Re: [PATCH] Make LTO link pick up compile-time -g

2019-12-21 Thread Gerald Pfeifer
On Mon, 9 Sep 2019, Richard Biener wrote:
> Like the following?
> 
> Richard.
> 
> 2019-09-09  Richard Biener  
> 
>   * lto-opts.c (lto_write_options): Stream -g when debug is enabled.
>   * lto-wrapper.c (merge_and_complain): Pick up -g.
>   (append_compiler_options): Likewise.
>   (run_gcc): Re-instantiate handling -g0 at link-time.
>   * doc/invoke.texi (flto): Document debug info generation.

Thank you!  I committed the minor editorial update below on top.

Gerald


2019-12-22  Gerald Pfeifer  

* doc/invoke.texi (-flto): Use "compile time" as a noun.

Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 278735)
+++ doc/invoke.texi (working copy)
@@ -10447,7 +10447,7 @@ precedence; and for example @option{-ffp-contract=
 over @option{-ffp-contract=fast}.  You can override them at link time.
 
 To enable debug info generation you need to supply @option{-g} at
-compile-time.  If any of the input files at link time were built
+compile time.  If any of the input files at link time were built
 with debug info generation enabled the link will enable debug info
 generation as well.  Any elaborate debug info settings
 like the dwarf level @option{-gdwarf-5} need to be explicitly repeated


Re: [PING][PATCH v2 2/2] testsuite: Fix run-time tracking down of `libgcc_s'

2019-12-21 Thread Maciej W. Rozycki
On Fri, 20 Dec 2019, Mike Stump wrote:

> >> Fix a catastrophic libgo testsuite failure in cross-compilation where 
> >> the shared `libgcc_s' library cannot be found by the loader at run time 
> >> in build-tree testing and consequently all test cases fail the execution 
> >> stage, giving output (here with the `x86_64-linux-gnu' host and the 
> >> `riscv64-linux-gnu' target, with RISC-V QEMU in the Linux user emulation 
> >> mode as the target board) like:
> >> 
> >> spawn qemu-riscv64 -E 
> >> LD_LIBRARY_PATH=.:.../riscv64-linux-gnu/lib64/lp64d/libgo/.libs ./a.exe
> >> ./a.exe: error while loading shared libraries: libgcc_s.so.1: cannot open 
> >> shared object file: No such file or directory
> >> FAIL: archive/tar
> > 
> > Ping for:
> > 
> > 
> 
> Ok.

 Applied now, thanks for your review.

> Watch for any breakage.

 Will do.

  Maciej


Re: [PATCH] libada: Fix shared library installation with `--disable-libada'

2019-12-21 Thread Maciej W. Rozycki
On Sat, 21 Dec 2019, Eric Botcazou wrote:

> >  Fixed thus, and verified with and without `--disable-libada', ensuring
> > that shared libgnat and libgnarl libraries arrive at their intended places
> > upon `make install'.
> > 
> >  OK to apply?
> 
> Yes (modulo s/overriden/overridden), thanks for the quick turn around.

 Thanks for catching the typo and the review.  Change applied now.

  Maciej


Re: [PATCH] libstdcxx: Update ctype_base.h from NetBSD upstream

2019-12-21 Thread Gerald Pfeifer
Hi Matthew,

On Mon, 4 Feb 2019, Matthew Bauer wrote:
> The ctype_base.h file in libstdc++-v3 is out of date for NetBSD. They
> have changed their ctype.h definition. It was updated in their intree
> libstdc++-v3 but not in the GCC one. My understanding is this is a
> straightforward rewrite. I've attached my own patch, but the file can
> be obtained directly here:
> 
> http://cvsweb.netbsd.org/bsdweb.cgi/src/external/gpl3/gcc/dist/libstdc%2b%2b-v3/config/os/bsd/netbsd/ctype_base.h
> 
> With the attached patch, libstdc++-v3 can succesfully be built with
> NetBSD headers (along with --disable-libcilkrts).

I noticed this has not been applied yet, nor seen a follow-up?, and also 
noticed it went to the gcc-patches list, but not libstd...@gcc.gnu.org.

Let me re-address this to libstd...@gcc.gnu.org in the hope the 
maintainers there will have a look.

Geralddiff --git a/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h b/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
index ff3ec893974..21eccf9fde1 100644
--- a/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
+++ b/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
@@ -38,40 +38,46 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   /// @brief  Base class for ctype.
   struct ctype_base
   {
-// Non-standard typedefs.
-typedef const unsigned char*	__to_type;
 
 // NB: Offsets into ctype::_M_table force a particular size
 // on the mask type. Because of this, we don't use an enum.
-typedef unsigned char  	mask;
 
 #ifndef _CTYPE_U
-static const mask upper	= _U;
-static const mask lower 	= _L;
-static const mask alpha 	= _U | _L;
-static const mask digit 	= _N;
-static const mask xdigit 	= _N | _X;
-static const mask space 	= _S;
-static const mask print 	= _P | _U | _L | _N | _B;
-static const mask graph 	= _P | _U | _L | _N;
-static const mask cntrl 	= _C;
-static const mask punct 	= _P;
-static const mask alnum 	= _U | _L | _N;
+// Non-standard typedefs.
+typedef const unsigned char*	__to_type;
+
+typedef unsigned char	mask;
+
+static const mask upper	= _U;
+static const mask lower	= _L;
+static const mask alpha	= _U | _L;
+static const mask digit	= _N;
+static const mask xdigit	= _N | _X;
+static const mask space	= _S;
+static const mask print	= _P | _U | _L | _N | _B;
+static const mask graph	= _P | _U | _L | _N;
+static const mask cntrl	= _C;
+static const mask punct	= _P;
+static const mask alnum	= _U | _L | _N;
 #else
-static const mask upper	= _CTYPE_U;
-static const mask lower 	= _CTYPE_L;
-static const mask alpha 	= _CTYPE_U | _CTYPE_L;
-static const mask digit 	= _CTYPE_N;
-static const mask xdigit 	= _CTYPE_N | _CTYPE_X;
-static const mask space 	= _CTYPE_S;
-static const mask print 	= _CTYPE_P | _CTYPE_U | _CTYPE_L | _CTYPE_N | _CTYPE_B;
-static const mask graph 	= _CTYPE_P | _CTYPE_U | _CTYPE_L | _CTYPE_N;
-static const mask cntrl 	= _CTYPE_C;
-static const mask punct 	= _CTYPE_P;
-static const mask alnum 	= _CTYPE_U | _CTYPE_L | _CTYPE_N;
+typedef const unsigned short*	__to_type;
+
+typedef unsigned short	mask;
+
+static const mask upper	= _CTYPE_U;
+static const mask lower	= _CTYPE_L;
+static const mask alpha	= _CTYPE_A;
+static const mask digit	= _CTYPE_D;
+static const mask xdigit	= _CTYPE_X;
+static const mask space	= _CTYPE_S;
+static const mask print	= _CTYPE_R;
+static const mask graph	= _CTYPE_G;
+static const mask cntrl	= _CTYPE_C;
+static const mask punct	= _CTYPE_P;
+static const mask alnum	= _CTYPE_A | _CTYPE_D;
 #endif
 #if __cplusplus >= 201103L
-static const mask blank 	= space;
+static const mask blank	= space;
 #endif
   };
 
diff --git a/libstdc++-v3/config/os/bsd/netbsd/ctype_configure_char.cc b/libstdc++-v3/config/os/bsd/netbsd/ctype_configure_char.cc
index ed3b7cd0d6a..33358e8f5d8 100644
--- a/libstdc++-v3/config/os/bsd/netbsd/ctype_configure_char.cc
+++ b/libstdc++-v3/config/os/bsd/netbsd/ctype_configure_char.cc
@@ -38,11 +38,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
 // Information as gleaned from /usr/include/ctype.h
 
-  extern "C" const u_int8_t _C_ctype_[];
-
   const ctype_base::mask*
   ctype::classic_table() throw()
-  { return _C_ctype_ + 1; }
+  { return _C_ctype_tab_ + 1; }
 
   ctype::ctype(__c_locale, const mask* __table, bool __del,
 		 size_t __refs)
@@ -69,14 +67,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   char
   ctype::do_toupper(char __c) const
-  { return ::toupper((int) __c); }
+  { return ::toupper((int)(unsigned char) __c); }
 
   const char*
   ctype::do_toupper(char* __low, const char* __high) const
   {
 while (__low < __high)
   {
-	*__low = ::toupper((int) *__low);
+	*__low = ::toupper((int)(unsigned char) *__low);
 	++__low;
   }
 return __high;
@@ -84,14 +82,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   char
   ctype::do_tolower(char __c) const
-  { return 

Re: [PATCH 07/13] OpenACC 2.6 deep copy: libgomp parts

2019-12-21 Thread Thomas Schwinge
Hi!

On 2019-12-17T22:03:47-0800, Julian Brown  wrote:
> This part contains the libgomp runtime support for the GOMP_MAP_ATTACH and
> GOMP_MAP_DETACH mapping kinds (etc.), as introduced by the front-end
> patches following in this series.

This (r279625) regressed the same OpenMP 'omp declare target link'
functionality/test case that I previously discussed in
,
and/or
:

PASS: libgomp.c/target-link-1.c (test for excess errors)
[-PASS:-]{+FAIL:+} libgomp.c/target-link-1.c execution test

(With nvptx offloading configured, as mentioned before, this test case
doesn't even build --  -- so, yes, this is
clearly insufficient test coverage of the 'omp declare target link'
functionality, but still we shouldn't regress it.)

What's causing the regression is:

> --- a/libgomp/target.c
> +++ b/libgomp/target.c
> @@ -1247,10 +1281,12 @@ gomp_map_vars_internal (struct gomp_device_descr 
> *devicep,

|   k->aux = NULL;
|   if (n && n->refcount == REFCOUNT_LINK)
| {
|   /* Replace target address of the pointer with target address
|  of mapped object in the splay tree.  */
|   splay_tree_remove (mem_map, n);
|   k->aux
| = gomp_malloc_cleared (sizeof (struct splay_tree_aux));
|   k->aux->link_key = n;
| }
|   size_t align = (size_t) 1 << (kind >> rshift);
|   tgt->list[i].key = k;
|   k->tgt = tgt;
|   if (field_tgt_clear != FIELD_TGT_EMPTY)
| {
|   k->tgt_offset = k->host_start - field_tgt_base
|   + field_tgt_offset;
|   if (i == field_tgt_clear)
| field_tgt_clear = FIELD_TGT_EMPTY;
| }
|   else
| {
|   tgt_size = (tgt_size + align - 1) & ~(align - 1);
|   k->tgt_offset = tgt_size;
|   tgt_size += k->host_end - k->host_start;
| }
>   tgt->list[i].copy_from = GOMP_MAP_COPY_FROM_P (kind & typemask);
>   tgt->list[i].always_copy_from
> = GOMP_MAP_ALWAYS_FROM_P (kind & typemask);
> + tgt->list[i].do_detach = false;
>   tgt->list[i].offset = 0;
>   tgt->list[i].length = k->host_end - k->host_start;
>   k->refcount = 1;
>   k->virtual_refcount = 0;
> + k->aux = NULL;
>   tgt->refcount++;
>   array->left = NULL;
>   array->right = NULL;

... that latter 'k->aux = NULL' assignment, which invalidates what the
'REFCOUNT_LINK' handling earlier set up.

I had intentionally left out this assignment in my "In
'libgomp/target.c', 'struct splay_tree_key_s', use 'struct
splay_tree_aux' for infrequently-used or API-specific data" patch,
<87k16uykb7.fsf@euler.schwinge.homeip.net">http://mid.mail-archive.com/87k16uykb7.fsf@euler.schwinge.homeip.net>,
and you also don't have that assignment in your r279620 "Use aux struct
in libgomp for infrequently-used/API-specific data" commit,
<80e0dba326a4414fd2dbe8401dbd8d8f08445129.1576648001.git.julian@codesourcery.com">http://mid.mail-archive.com/80e0dba326a4414fd2dbe8401dbd8d8f08445129.1576648001.git.julian@codesourcery.com>,
so curious why it now appears here -- hopefully just an oversight.

See attached "[OMP] Restore 'omp declare target link' handling";
committed to trunk in r279701.


Grüße
 Thomas


From dc669e8f45a5b1e61e746b6d2c6a23480fdd904f Mon Sep 17 00:00:00 2001
From: tschwinge 
Date: Sat, 21 Dec 2019 22:58:43 +
Subject: [PATCH] [OMP] Restore 'omp declare target link' handling

PASS: libgomp.c/target-link-1.c (test for excess errors)
[-PASS:-]{+FAIL:+} libgomp.c/target-link-1.c execution test

We need to revert one line of code change from r279625.

	libgomp/
	* target.c (gomp_map_vars_internal): Restore 'omp declare target
	link' handling.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@279701 138bc75d-0d04-0410-961f-82ee72b054a4
---
 libgomp/ChangeLog | 5 +
 libgomp/target.c  | 1 -
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/libgomp/ChangeLog b/libgomp/ChangeLog
index 81b9d6788a1..7bc7d41da42 100644
--- a/libgomp/ChangeLog
+++ b/libgomp/ChangeLog
@@ -1,3 +1,8 @@
+2019-12-21  Thomas Schwinge  
+
+	* target.c (gomp_map_vars_internal): Restore 'omp declare target
+	link' handling.
+
 2019-12-19  Julian Brown  
 
 	* testsuite/libgomp.oacc-fortran/class-ptr-param.f95: New test.
diff --git a/libgomp/target.c b/libgomp/target.c
index 50a9c2b1df3..bf30716cd85 100644
--- a/libgomp/target.c
+++ b/libgomp/target.c
@@ -1129,7 +1129,6 @@ gomp_map_vars_internal (struct gomp_device_descr *devicep,
 		tgt->list[i].length = k->host_end 

Re: [PATCH] Add OpenACC 2.6 `acc_get_property' support

2019-12-21 Thread Thomas Schwinge
Hi Frederik!

On 2019-12-20T17:46:57+0100, "Harwath, Frederik"  
wrote:
>> | Before Frederik starts working on integrating this into GCC trunk, do you
>> | (Jakub) agree with the libgomp plugin interface changes as implemented by
>> | Maciej?  For example, top-level 'GOMP_OFFLOAD_get_property' function in
>> | 'struct gomp_device_descr' instead of stuffing this into its
>> | 'acc_dispatch_t openacc'.  (I never understood why the OpenACC functions
>> | need to be segregated like they are.)
>>
>> Jakub didn't answer, but I now myself decided that we should group this
>> with the other OpenACC libgomp-plugin functions, as this interface is
>> defined in terms of OpenACC-specific stuff such as 'acc_device_t'.
>> Frederik, please work on that, also try to move function definitions etc.
>> into appropriate places in case they aren't; ask if you need help.
>> That needs to be updated.
>
> Is it ok to do this in a separate follow-up patch?

Yes.  This doesn't affect anything but the libgomp-plugin interface.


>> > --- a/include/gomp-constants.h
>> > +++ b/include/gomp-constants.h
>> > @@ -178,6 +178,20 @@ enum gomp_map_kind
>> >=20=20
>> >  #define GOMP_DEVICE_ICV   -1
>> >  #define GOMP_DEVICE_HOST_FALLBACK -2
>> > +#define GOMP_DEVICE_CURRENT   -3
>> [...]
>>
>> Not should if this should be grouped with 'GOMP_DEVICE_ICV',
>> 'GOMP_DEVICE_HOST_FALLBACK', for it is not related to there.
>>
>> [...]
>>
>> Should this actually get value '-1' instead of '-3'?  Or, is the OpenACC
>> 'acc_device_t' code already paying special attention to negative values
>> '-1', '-2'?  (I don't think so.)
>> | Also, 'acc_device_current' is a libgomp-internal thing (doesn't interface
>> | with the compiler proper), so strictly speaking 'GOMP_DEVICE_CURRENT'
>> | isn't needed in 'include/gomp-constants.h'.  But probably still a good
>> | idea to list it there, in this canonical place, to keep the several lists
>> | of device types coherent.
>> still wonder about that...  ;-)

> Changing the value of GOMP_DEVICE_ICV violates the following static asserts 
> in oacc-parallel.c: [...]

Hmm, I didn't intend to suggest changing the 'GOMP_DEVICE_ICV' value,
which indeed can't/shouldn't be done.

I still think that 'GOMP_DEVICE_CURENT' should get value '-1' (and
probably be rename 'GOACC_DEVICE_CURRENT' to make more obvious that it's
not related to the 'GOMP_DEVICE_*' ones), but we shall have a look at
that later (before GCC 10 release); that's libgomp/OpenACC-internal,
doesn't affect anything else.

>> Maybe this stuff should move from 'include/gomp-constants.h' to
>> 'libgomp/oacc-int.h'.  I'll think about that again, when I'm awake again
>> tomorrow.  ;-)
>
> Have you made up your mind yet? :-)

Still sleepy.  ;-)


> Is it ok to commit the patch to trunk?

OK, thanks.  And then some follow-up/clean-up next year, also including
some of the open questions that I've snipped off here.


Grüße
 Thomas


signature.asc
Description: PGP signature


Re: C++ PATCH for c++/88337 - Implement P1327R1: Allow dynamic_cast in constexpr

2019-12-21 Thread Jason Merrill

On 12/17/19 5:34 PM, Marek Polacek wrote:

On Mon, Dec 16, 2019 at 04:00:14PM -0500, Jason Merrill wrote:

On 12/16/19 3:55 PM, Jason Merrill wrote:

On 12/14/19 4:25 PM, Marek Polacek wrote:

On Fri, Dec 13, 2019 at 05:56:57PM -0500, Jason Merrill wrote:

On 12/13/19 3:20 PM, Marek Polacek wrote:

+  /* Given dynamic_cast(v),
+
+ [expr.dynamic.cast] If C is the class type to which T
points or refers,
+ the runtime check logically executes as follows:
+
+ If, in the most derived object pointed (referred) to
by v, v points
+ (refers) to a public base class subobject of a C
object, and if only
+ one object of type C is derived from the subobject
pointed (referred)
+ to by v the result points (refers) to that C object.
+
+ In this case, HINT >= 0.  */
+  if (hint >= 0)


Won't this code work for hint == -3 as well?


Yes, it does.  In fact, none of the tests was testing the hint == -3
case, so
I've fixed the code up and added constexpr-dynamic15.C to test it.


+    {
+  /* Look for a component with type TYPE.  */
+  obj = get_component_with_type (obj, type);


You don't seem to use mdtype at all in this case.  Shouldn't
get_component_with_type stop at mdtype if it hasn't found type yet?


It was used for diagnostics but not in get_component_with_type.  It makes
sense to stop at MDTYPE; I've adjusted the code to do so.  E.g., if
we have OBJ in the form of g.D.2121.D.2122.D.2123.D.2124, usually the
component with the most derived type is "g", but in a 'tor, it can be
a different component too.


+  /* If not found or not accessible, give an error.  */
+  if (obj == NULL_TREE || obj == error_mark_node)
+    {
+  if (reference_p)
+    {
+  if (!ctx->quiet)
+    {
+  error_at (loc, "reference % failed");
+  if (obj == NULL_TREE)
+    inform (loc, "dynamic type %qT of its operand does not "
+    "have an unambiguous public base class %qT",
+    mdtype, type);
+  else
+    inform (loc, "static type %qT of its operand is a "
+    "non-public base class of dynamic type %qT",
+    objtype, type);
+
+    }
+  *non_constant_p = true;
+    }
+  return integer_zero_node;
+    }
+  else
+    /* The result points to the TYPE object.  */
+    return cp_build_addr_expr (obj, complain);
+    }
+  /* Otherwise, if v points (refers) to a public base class
subobject of the
+ most derived object, and the type of the most derived
object has a base
+ class, of type C, that is unambiguous and public, the
result points
+ (refers) to the C subobject of the most derived object.
+
+ But it can also be an invalid case.  */


And I think we need to fall through to this code if the hint
turns out to be
wrong, i.e. V is a public base of C, but v is not that
subobject, but rather
a sibling base of C, like


True.  HINT is really just an optimization hint, nothing more.  I've
adjusted
the code to fall through to the normal processing if the HINT >= 0
or -3 case
doesn't succeed.


struct A { virtual void f(); };
struct B1: A { };
struct B2: A { };
struct C: B1, B2 { };
int main()
{
    C c;
    A* ap = (B1*)c;
    constexpr auto p = dynamic_cast(ap); // should succeed
}


Whew, there's always One More Case. :/  New constexpr-dynamic16.c
covers it.


--- /dev/null
+++ gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic11.C
@@ -0,0 +1,34 @@
+// PR c++/88337 - Implement P1327R1: Allow
dynamic_cast/typeid in constexpr.
+// { dg-do compile { target c++2a } }
+
+// dynamic_cast in a constructor.
+
+struct V {
+  virtual void f();
+};
+
+struct A : V { };
+
+struct B : V {
+  constexpr B(V*, A*);
+};
+
+struct D : A, B {
+  constexpr D() : B((A*)this, this) { } // { dg-message "in
'constexpr' expansion of" }
+};
+
+constexpr B::B(V* v, A* a)
+{
+  // well-defined: v of type V*, V base of B results in B*
+  B* b = dynamic_cast(v);
+  if (b != nullptr)
+    __builtin_abort ();
+
+  B& br = dynamic_cast(*v); // { dg-error "reference
.dynamic_cast. failed" }
+// { dg-message "dynamic type .A. of its operand does not
have an unambiguous public base class .B." "" { target *-*-*
} .-1 }
+
+  // FIXME: UB in constexpr should be detected.
+  dynamic_cast(a);  // undefined behavior, a
has type A*, A not a base of B


What undefined behavior?  Seems to me the dynamic_cast should
just fail and
return a null pointer.


This is :
"If the operand of the dynamic_cast refers to the object under
construction
or destruction and the static type of the operand is not a pointer to or
object of the constructor or destructor's own class or one of its
bases, the
dynamic_cast results in undefined behavior."

Clang++ doesn't detect this either.


Ah, interesting.  That text goes back to C++98.  I guess the reason for
that was that the vtable pointer might give problematic answers in that
situation.  It should be straightforward to detect 

Re: [PATCH 08/13] OpenACC 2.6 deep copy: middle-end parts

2019-12-21 Thread Thomas Schwinge
Hi!

On 2019-12-17T22:03:48-0800, Julian Brown  wrote:
> This part contains the middle-end support for OpenACC 2.6 attach and
> detach operations, either as standalone clauses or as "attach/detach"
> actions triggered by other (data movement) clauses, as detailed in the
> specification.

As mentioned in , "that commit [r279626] is
doing more than just the OpenACC 2.6 manual deep copy changes; see the
'gcc/gimplify.c' changes related to the PR92929 discussion" etc. (see
).  See attached "[PR93026, PR92929] Adjust
'gfortran.dg/goacc/finalize-1.f' for r279626 changes"; committed to trunk
in r279700.


Grüße
 Thomas


> ChangeLog
>
>   gcc/
>   * gimplify.c (gimplify_omp_var_data): Add GOVD_MAP_HAS_ATTACHMENTS.
>   (insert_struct_comp_map): Support derived-type member mappings
>   for arrays with descriptors which use GOMP_MAP_TO_PSET.  Support
>   GOMP_MAP_ATTACH_DETACH.
>   (gimplify_scan_omp_clauses): Tidy up OACC_ENTER_DATA/OACC_EXIT_DATA
>   mappings.  Handle attach/detach clauses and component references.
>   (gimplify_adjust_omp_clauses_1): Skip adjustments for explicit
>   attach/detach clauses.
>   (gimplify_omp_target_update): Handle finalize for detach.
>   * omp-low.c (lower_omp_target): Support GOMP_MAP_ATTACH,
>   GOMP_MAP_DETACH, GOMP_MAP_FORCE_DETACH.
>   * tree-pretty-print.c (dump_omp_clause): Likewise, plus
>   GOMP_MAP_ATTACH_DETACH.
>
>   include/
>   * gomp-constants.h (gomp_map_kind): Add GOMP_MAP_ATTACH_DETACH.
> ---
>  gcc/gimplify.c   | 232 ++-
>  gcc/omp-low.c|   3 +
>  gcc/tree-pretty-print.c  |  18 +++
>  include/gomp-constants.h |   6 +-
>  4 files changed, 229 insertions(+), 30 deletions(-)
>
> diff --git a/gcc/gimplify.c b/gcc/gimplify.c
> index e3088dcbe05..e3d5bc83c4f 100644
> --- a/gcc/gimplify.c
> +++ b/gcc/gimplify.c
> @@ -123,6 +123,10 @@ enum gimplify_omp_var_data
>/* Flag for GOVD_REDUCTION: inscan seen in {in,ex}clusive clause.  */
>GOVD_REDUCTION_INSCAN = 0x200,
>  
> +  /* Flag for GOVD_MAP: (struct) vars that have pointer attachments for
> + fields.  */
> +  GOVD_MAP_HAS_ATTACHMENTS = 8388608,
> +
>GOVD_DATA_SHARE_CLASS = (GOVD_SHARED | GOVD_PRIVATE | GOVD_FIRSTPRIVATE
>  | GOVD_LASTPRIVATE | GOVD_REDUCTION | GOVD_LINEAR
>  | GOVD_LOCAL)
> @@ -8209,20 +8213,33 @@ insert_struct_comp_map (enum tree_code code, tree c, 
> tree struct_node,
>   tree prev_node, tree *scp)
>  {
>enum gomp_map_kind mkind
> -= code == OMP_TARGET_EXIT_DATA ? GOMP_MAP_RELEASE : GOMP_MAP_ALLOC;
> += (code == OMP_TARGET_EXIT_DATA || code == OACC_EXIT_DATA)
> +  ? GOMP_MAP_RELEASE : GOMP_MAP_ALLOC;
>  
>tree c2 = build_omp_clause (OMP_CLAUSE_LOCATION (c), OMP_CLAUSE_MAP);
>tree cl = scp ? prev_node : c2;
>OMP_CLAUSE_SET_MAP_KIND (c2, mkind);
>OMP_CLAUSE_DECL (c2) = unshare_expr (OMP_CLAUSE_DECL (c));
>OMP_CLAUSE_CHAIN (c2) = scp ? *scp : prev_node;
> -  OMP_CLAUSE_SIZE (c2) = TYPE_SIZE_UNIT (ptr_type_node);
> +  if (OMP_CLAUSE_CHAIN (prev_node) != c
> +  && OMP_CLAUSE_CODE (OMP_CLAUSE_CHAIN (prev_node)) == OMP_CLAUSE_MAP
> +  && (OMP_CLAUSE_MAP_KIND (OMP_CLAUSE_CHAIN (prev_node))
> +   == GOMP_MAP_TO_PSET))
> +OMP_CLAUSE_SIZE (c2) = OMP_CLAUSE_SIZE (OMP_CLAUSE_CHAIN (prev_node));
> +  else
> +OMP_CLAUSE_SIZE (c2) = TYPE_SIZE_UNIT (ptr_type_node);
>if (struct_node)
>  OMP_CLAUSE_CHAIN (struct_node) = c2;
>  
>/* We might need to create an additional mapping if we have a reference to 
> a
> - pointer (in C++).  */
> -  if (OMP_CLAUSE_CHAIN (prev_node) != c)
> + pointer (in C++).  Don't do this if we have something other than a
> + GOMP_MAP_ALWAYS_POINTER though, i.e. a GOMP_MAP_TO_PSET.  */
> +  if (OMP_CLAUSE_CHAIN (prev_node) != c
> +  && OMP_CLAUSE_CODE (OMP_CLAUSE_CHAIN (prev_node)) == OMP_CLAUSE_MAP
> +  && ((OMP_CLAUSE_MAP_KIND (OMP_CLAUSE_CHAIN (prev_node))
> +== GOMP_MAP_ALWAYS_POINTER)
> +   || (OMP_CLAUSE_MAP_KIND (OMP_CLAUSE_CHAIN (prev_node))
> +   == GOMP_MAP_ATTACH_DETACH)))
>  {
>tree c4 = OMP_CLAUSE_CHAIN (prev_node);
>tree c3 = build_omp_clause (OMP_CLAUSE_LOCATION (c), OMP_CLAUSE_MAP);
> @@ -8329,6 +8346,7 @@ gimplify_scan_omp_clauses (tree *list_p, gimple_seq 
> *pre_p,
>struct gimplify_omp_ctx *ctx, *outer_ctx;
>tree c;
>hash_map *struct_map_to_clause = NULL;
> +  hash_set *struct_deref_set = NULL;
>tree *prev_list_p = NULL, *orig_list_p = list_p;
>int handled_depend_iterators = -1;
>int nowait = -1;
> @@ -8731,8 +8749,6 @@ gimplify_scan_omp_clauses (tree *list_p, gimple_seq 
> *pre_p,
>   case OMP_TARGET_DATA:
>   case OMP_TARGET_ENTER_DATA:
>   case OMP_TARGET_EXIT_DATA:
> - case OACC_ENTER_DATA:
> - case OACC_EXIT_DATA:
>  

[Patch, commited] PR91661 - ICE in gfc_conv_intrinsic_dot_product, at fortran/trans-intrinsic.c:4804

2019-12-21 Thread Harald Anlauf
A "side-effect" of Tobias Burnus' fix for PR92996, which addressed 
simplification
of some array-valued constant expression, is that it fixes the ICE in the 
subject.

To make sure that we do not regress I committed the testcase below as 
rev.279699.
This was OKed in the PR by Thomas König.

Thanks,
Harald


2019-12-21  Harald Anlauf  

PR fortran/91661
* gfortran.dg/pr91661.f90: New test.


Index: gcc/testsuite/gfortran.dg/pr91661.f90
===
--- gcc/testsuite/gfortran.dg/pr91661.f90   (nicht existent)
+++ gcc/testsuite/gfortran.dg/pr91661.f90   (Arbeitskopie)
@@ -0,0 +1,13 @@
+! { dg-do run }
+! PR fortran/91661
+! Contributed by Gerhard Steinmetz
+! Verify that fix for PR92996 also fixes this one
+program p
+  integer, parameter :: a(2)= 2
+  integer, parameter :: b(a(1)) = 3
+  integer, parameter :: c   = dot_product(b, b)
+  integer, parameter :: d(a(1)+a(2)) = 3
+  integer, parameter :: e = size (d,dim=1)
+  if (c /= 18) stop 1   ! This used to ICE
+  if (e /= 4)  stop 2   ! This used to ICE
+end



Re: [Patch] PR92990 - fix error message for invalid argument of NULLIFY

2019-12-21 Thread Harald Anlauf
> Gesendet: Samstag, 21. Dezember 2019 um 17:16 Uhr
> Von: "Thomas Koenig" 
> An: "Harald Anlauf" , fortran , 
> gcc-patches 
> Betreff: Re: [Patch] PR92990 - fix error message for invalid argument of 
> NULLIFY
>
> Am 20.12.19 um 22:33 schrieb Harald Anlauf:
> > The fix for PR70853 changed an ICE-on-invalid for NULLIFY into a
> > misleading error message.  The patch below rectifies that.
> >
> > OK for trunk?
>
> OK.
>
> Thanks for the patch!
>
> Regards
>
>   Thomas
>

Committed as rev.279698.

Thanks for the review!

Harald



Re: [Patch] PR92990 - fix error message for invalid argument of NULLIFY

2019-12-21 Thread Thomas Koenig

Am 20.12.19 um 22:33 schrieb Harald Anlauf:

The fix for PR70853 changed an ICE-on-invalid for NULLIFY into a
misleading error message.  The patch below rectifies that.

OK for trunk?


OK.

Thanks for the patch!

Regards

Thomas


Re: *Ping* Introduce -finline-arg-packing

2019-12-21 Thread Thomas Koenig

Hi Jakub,


This patch broke:
+FAIL: compiler driver --help=fortran option(s): "^ +-.*[^:.]\$" absent from output: 
"  -finline-arg-packingPerform argument packing inline"
That test verifies that the help texts of all options are terminated
with dot or semicolon.


Thanks, and sorry for the breakage.

Note to self: Try not to forget that dot.

This was not caught with "make check-fortran" from the gcc
build directory. Maybe it would be a good idea to add that
test to check-fortran too.  Does anybody have an idea
how to do that?

Regards

Thomas


Re: [PATCH] libada: Fix shared library installation with `--disable-libada'

2019-12-21 Thread Eric Botcazou
>  Fixed thus, and verified with and without `--disable-libada', ensuring
> that shared libgnat and libgnarl libraries arrive at their intended places
> upon `make install'.
> 
>  OK to apply?

Yes (modulo s/overriden/overridden), thanks for the quick turn around.

-- 
Eric Botcazou


Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS env var

2019-12-21 Thread Bernd Edlinger
Hi David,

thanks for fixing this issue.

Just one comment:

> +[DIAGNOSTICS_URLS_DEFAULT=DIAGNOSTICS_URL_AUTO])
> +AC_DEFINE_UNQUOTED(DIAGNOSTICS_URLS_DEFAULT, $DIAGNOSTICS_URLS_DEFAULT,
> +[The default for -fdiagnostics-urls option])

I think for a feature as disruptive as this, when a
terminal implements that it ought to advertise this feature via
an environment variable.  So I would prefer the default
to be auto-if-env.

Ideally there should be some neutral variable similar to TERM,
maybe TERM_URL=yes if that convention does not exist yet,
maybe we should invent it?


Thanks
Bernd.


Re: [PATCH] Avoid segfault when doing IPA-VRP but not IPA-CP (PR 93015)

2019-12-21 Thread Jan Hubicka
> Hi,
> 
> PR 93015 testcase - an empty main function compiled with -O0 -fipa-vrp
> -flto - shows that IPA-VRA can segfault when trying to access results of
> an analysis that has not been performed because of zero optimization
> level, -fno-ipa-cp etc.
> 
> Rather than adding another chain of opt_for_fn() the patch fixes it by
> what IPA-CP-BITS does, which is simply checking that info of a node is
> not NULL.
> 
> Bootstrapped and tested on x86_64-linux.  OK for trunk?
> 
> Thanks,
> 
> Martin
> 
> 
> 2019-12-20  Martin Jambor  
> 
>   PR ipa/93015
>   * ipa-cp.c (ipcp_store_vr_results): Check that info exists
> 
>   testsuite/
>   * gcc.dg/lto/pr93015_0.c: New test.
OK,
thanks!
Honza