Fix ipa-icf.c segfault

[Jan Hubicka]

Hi,
this patch fixes segfault that crept into my prevoius patch.

Bootstrapped/regtested x86_64-linux, comitted.

Honza

* ipa-icf.c (sem_function::merge): Check that local_original exists.
Index: ipa-icf.c
===
--- ipa-icf.c   (revision 231319)
+++ ipa-icf.c   (working copy)
@@ -1359,7 +1359,9 @@ sem_function::merge (sem_item *alias_ite
 {
   if (dump_file)
fprintf (dump_file, "Dropping merged_comdat flag.\n\n");
-  local_original->merged_comdat = original->merged_comdat = false;
+  if (local_original)
+local_original->merged_comdat = false;
+  original->merged_comdat = false;
 }
 
   if (remove)

Re: RFC: Merge the GUPC branch into the GCC 6.0 trunk

[Richard Biener]

On December 5, 2015 11:57:27 PM GMT+01:00, Gary Funck  wrote:
>On 12/02/15 10:40:50, Richard Biener wrote:
>> On Tue, 1 Dec 2015, Gary Funck wrote:
>> > The main change recommended to reduce tree space was moving the
>> > "layout factor" (blocking factor) out of the tree node, and using
>> > only two bits there, one bit for a relatively common case of 0,
>> > and the other for > 1.  It was suggested that we use a hash
>> > table to map tree nodes to layout qualifiers for the case they
>> > are > 1.  This necessitated using a garbage collected tree map,
>> > which unfortunately meant that tree nodes needed special garbage
>> > collection logic.
>> 
>> I still don't see why it needs special garbage collection logic.
>> We have many tree -> X maps that just get away without.
>> [...]
>> As said, I don't see why you need a special GC collection logic
>> at all.  Please explain.
>
>The problem we ran into is that we had a tree map which
>mapped a tree node to its UPC layout qualifier, which
>is an integral constant (CST).  Tree nodes for CST's
>are made unique by hashing them into an integer->tree map.
>What happened is that the GC would free up entries in the
>CST table that were being used by the layout qualifier map.
>
>It seems that the new tree map logic fixes this problem
>(as you've noted).  I backed out the custom GC logic and
>re-ran a large test that extensively exercises the use case
>that triggers the issue -- works like a charm.

That's good news!

Richard.

>thanks,
>- Gary

[PATCH 3/6] [DJGPP] libbacktrace/configure.ac: specify that DJGPP do not have mmap()

[Andris Pavenis]

Patch specifies that DJGPP do not have mmap() even when sys/mman.h is available.
libbacktrace is perhaps currently unusable for DJGPP but otherwise mmap() 
usability
misdetection breaks cross-compiler build for DJGPP target (for example Linux 
hosted
cross-compiler)

Andris

2015-12-05 Andris Pavenis 

* configure.ac: Specify that DJGPP do not have mmap even when sys/mman.h exists
* configure: Regenerate
>From 5fb05d0ae112ae1c938c2edf94b8dff8cd5dd1d6 Mon Sep 17 00:00:00 2001
From: Andris Pavenis 
Date: Tue, 24 Nov 2015 20:22:52 +0200
Subject: [PATCH 3/6] [DJGPP] libbacktrace/configure.ac: specify that DJGPP do not have mmap()

---
 libbacktrace/configure| 3 ++-
 libbacktrace/configure.ac | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/libbacktrace/configure b/libbacktrace/configure
index f8adc83..015c944 100755
--- a/libbacktrace/configure
+++ b/libbacktrace/configure
@@ -12301,9 +12301,10 @@ else
 # simply assume that if we have mman.h, we have mmap.
 have_mmap=yes
 case "${host}" in
-spu-*-*)
+spu-*-*|*-*-msdosdjgpp)
 # The SPU does not have mmap, but it has a sys/mman.h header file
 # containing "mmap_eaddr" and the mmap flags, confusing the test.
+# DJGPP also has sys/man.h, but no mmap
 	have_mmap=no ;;
 esac
   else
diff --git a/libbacktrace/configure.ac b/libbacktrace/configure.ac
index 33866e9..7a0a157 100644
--- a/libbacktrace/configure.ac
+++ b/libbacktrace/configure.ac
@@ -267,9 +267,10 @@ else
 # simply assume that if we have mman.h, we have mmap.
 have_mmap=yes
 case "${host}" in
-spu-*-*)
+spu-*-*|*-*-msdosdjgpp)
 # The SPU does not have mmap, but it has a sys/mman.h header file
 # containing "mmap_eaddr" and the mmap flags, confusing the test.
+# DJGPP also has sys/man.h, but no mmap
 	have_mmap=no ;;
 esac
   else
-- 
2.4.3

[PATCH 6/6] [DJGPP] configure.ac: enable LTO

[Andris Pavenis]

Patch enables LTO support for DJGPP in top level configure.ac

Andris

2015-12-05 Andris Pavenis 

* configure.ac: enable LTO for *-*-msdosdjgpp
>From 9df385353dd1f6c275e0ce9266ab4bbb3a80cd44 Mon Sep 17 00:00:00 2001
From: Andris Pavenis 
Date: Sat, 14 Nov 2015 20:38:32 +0200
Subject: [PATCH 6/6] [DJGPP] configure.ac: enable LTO

---
 configure.ac | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index a6998ff..ee4fd23 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1817,7 +1817,7 @@ ACX_ELF_TARGET_IFELSE([# ELF platforms build the lto-plugin always.
   build_lto_plugin=yes
 ],[if test x"$default_enable_lto" = x"yes" ; then
 case $target in
-  *-apple-darwin9* | *-cygwin* | *-mingw*) ;;
+  *-apple-darwin9* | *-cygwin* | *-mingw* | *djgpp*) ;;
   # On other non-ELF platforms, LTO has yet to be validated.
   *) enable_lto=no ;;
 esac
@@ -1828,7 +1828,7 @@ ACX_ELF_TARGET_IFELSE([# ELF platforms build the lto-plugin always.
   # warn during gcc/ subconfigure; unless you're bootstrapping with
   # -flto it won't be needed until after installation anyway.
 case $target in
-  *-cygwin* | *-mingw* | *-apple-darwin*) ;;
+  *-cygwin* | *-mingw* | *-apple-darwin* | *djgpp*) ;;
   *) if test x"$enable_lto" = x"yes"; then
 	AC_MSG_ERROR([LTO support is not enabled for this target.])
 fi
-- 
2.4.3

[PATCH 4/6] [DJGPP] config/i386/djgpp: Update definitions of signed types

[Andris Pavenis]

Included patch updates typedefs of integer types in config/i386/djgpp-stdint.h.
Patch is similar but not identical as attached to

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41557

Andris

2015-12-05 Andris Pavenis 

* config/i386/djgpp-stdint.h: update typedefs for integer types

>From 3533f7a8ac0a16b17e27ab772cfdeae6309005a3 Mon Sep 17 00:00:00 2001
From: Andris Pavenis 
Date: Sat, 14 Nov 2015 14:20:14 +0200
Subject: [PATCH 4/6] [DJGPP] config/i386/djgpp: Update definitions of signed types

* config/i386/djgpp-stdint.h: update definitions of integer types
---
 gcc/config/i386/djgpp-stdint.h | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/gcc/config/i386/djgpp-stdint.h b/gcc/config/i386/djgpp-stdint.h
index 84f2b50..36642e3 100644
--- a/gcc/config/i386/djgpp-stdint.h
+++ b/gcc/config/i386/djgpp-stdint.h
@@ -22,21 +22,21 @@ along with GCC; see the file COPYING3.  If not see
 /* Exact-width integer types */
 
 #define INT8_TYPE "signed char"
-#define INT16_TYPE "signed short int"
-#define INT32_TYPE "signed long int"
-#define INT64_TYPE "signed long long int"
+#define INT16_TYPE "short int"
+#define INT32_TYPE "int"
+#define INT64_TYPE "long long int"
 
 #define UINT8_TYPE "unsigned char"
 #define UINT16_TYPE "short unsigned int"
-#define UINT32_TYPE "long unsigned int"
+#define UINT32_TYPE "unsigned int"
 #define UINT64_TYPE "long long unsigned int"
 
 /* Minimum-width integer types */
 
 #define INT_LEAST8_TYPE "signed char"
-#define INT_LEAST16_TYPE "signed short int"
-#define INT_LEAST32_TYPE "signed int"
-#define INT_LEAST64_TYPE "signed long long int"
+#define INT_LEAST16_TYPE "short int"
+#define INT_LEAST32_TYPE "int"
+#define INT_LEAST64_TYPE "long long int"
 
 #define UINT_LEAST8_TYPE "unsigned char"
 #define UINT_LEAST16_TYPE "short unsigned int"
@@ -46,12 +46,12 @@ along with GCC; see the file COPYING3.  If not see
 /* Fastest minimum-width integer types */
 
 #define INT_FAST8_TYPE "signed char"
-#define INT_FAST16_TYPE "signed int"
-#define INT_FAST32_TYPE "signed int"
-#define INT_FAST64_TYPE "long long signed int"
+#define INT_FAST16_TYPE "short int"
+#define INT_FAST32_TYPE "int"
+#define INT_FAST64_TYPE "long long int"
 
 #define UINT_FAST8_TYPE "unsigned char"
-#define UINT_FAST16_TYPE "unsigned int"
+#define UINT_FAST16_TYPE "short unsigned int"
 #define UINT_FAST32_TYPE "unsigned int"
 #define UINT_FAST64_TYPE "long long unsigned int"
 
-- 
2.4.3

Re: [Patch, fortran] PR68534 - No error on mismatch in number of arguments between submodule and module interface

[Paul Richard Thomas]

Committed revision as 231319.

Thanks for testing the patch.

Paul

On 5 December 2015 at 17:41, Steve Kargl
 wrote:
> On Sat, Dec 05, 2015 at 04:20:54PM +0100, Paul Richard Thomas wrote:
>>
>> The cause of the segfault, I believe, was an error: 'sym' being used
>> instead of 'progname': Could you please try the attached patch when
>> you have a moment.
>
> Patch fixes the issue of i386-*-freebsd.  Thanks for the
> prompt fix.  OK to commit (with ChangeLog, of course).
>
> --
> Steve



-- 
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.

Groucho Marx

[PATCH 5/6] [DJGPP] gcc/config/i386: update DJGPP configuration related files

[Andris Pavenis]

Patch include updates to DJGPP related files in gcc/config/i386.

There are too many changes to gcc/config/i386/djgpp.h and
gcc/config/i386/xm-djgpp.h to list them completely in changelog
entry.

Andris

2015-11-25 Andris Pavenis 

Subject: [PATCH 6/6] [DJGPP] gcc/config/i386: update DJGPP configuration
 related files

* gcc/config/i386/djgpp.h: update
* gcc/config/i386/xm-djgpp.h: update
* gcc/config/i386/djgpp.c: new file
* gcc/config/i386/djgpp.opt: remove obsolete option -mbnu210
* gcc/config/i386/t-djgpp: new file
* gcc/config.gcc: use i386/t-djgpp for DJGPP target
>From 367432d08b4a00f180c3d0710a0f34cda1b6 Mon Sep 17 00:00:00 2001
From: Andris Pavenis 
Date: Sat, 5 Dec 2015 08:49:12 +0200
Subject: [PATCH 5/6] [DJGPP] gcc/config/i386: update DJGPP configuration related files

* gcc/config/i386/djgpp.h: update
* gcc/config/i386/xm-djgpp.h: update
* gcc/config/i386/djgpp.c: new file
* gcc/config/i386/djgpp.opt: remove obsolete option
* gcc/config/i386/t-djgpp: new file
* gcc/config.gcc: use i386/t-djgpp for DJGPP target
---
 gcc/config.gcc |   3 ++
 gcc/config/i386/djgpp.c|  50 +++
 gcc/config/i386/djgpp.h| 122 ++---
 gcc/config/i386/djgpp.opt  |   6 ---
 gcc/config/i386/t-djgpp|   8 +++
 gcc/config/i386/xm-djgpp.h |  40 +--
 6 files changed, 158 insertions(+), 71 deletions(-)
 create mode 100644 gcc/config/i386/djgpp.c
 create mode 100644 gcc/config/i386/t-djgpp

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 59aee2c..656cbd8 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -4387,6 +4387,9 @@ case ${target} in
 	i[34567]86-*-gnu*)
 		tmake_file="$tmake_file i386/t-gnu"
 		;;
+	i[34567]86-*-msdosdjgpp*)
+		tmake_file="${tmake_file} i386/t-djgpp"
+		;;
 	i[34567]86-*-solaris2* | x86_64-*-solaris2.1[0-9]*)
 		;;
 	i[34567]86-*-cygwin* | x86_64-*-cygwin*)
diff --git a/gcc/config/i386/djgpp.c b/gcc/config/i386/djgpp.c
new file mode 100644
index 000..29dad33
--- /dev/null
+++ b/gcc/config/i386/djgpp.c
@@ -0,0 +1,50 @@
+/* Subroutines for DJGPP.
+   Contributed by Andris Pavenis 
+   Copyright (C) 2013 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "tm.h"
+#include "output.h"
+#include "lto-section-names.h"
+
+void
+i386_djgpp_asm_named_section(const char *name, unsigned int flags,
+			 tree decl)
+{
+  char flagchars[8], *f = flagchars;
+
+(void)decl; /* silence warning. */
+
+  if (flags & SECTION_WRITE)
+*f++ = 'w';
+  if (flags & SECTION_CODE)
+*f++ = 'x';
+
+  /* LTO sections need 1-byte alignment to avoid confusing the
+ zlib decompression algorithm with trailing zero pad bytes.  */
+  if (strncmp (name, LTO_SECTION_NAME_PREFIX,
+			strlen (LTO_SECTION_NAME_PREFIX)) == 0)
+*f++ = '0';
+
+  *f++ = '\0';
+
+  fprintf (asm_out_file, "\t.section\t%s,\"%s\"\n", name, flagchars);
+}
diff --git a/gcc/config/i386/djgpp.h b/gcc/config/i386/djgpp.h
index f8b9031..dd441b3 100644
--- a/gcc/config/i386/djgpp.h
+++ b/gcc/config/i386/djgpp.h
@@ -17,12 +17,27 @@ You should have received a copy of the GNU General Public License
 along with GCC; see the file COPYING3.  If not see
 .  */
 
+#define DBX_DEBUGGING_INFO 1
+#define SDB_DEBUGGING_INFO 1
+
 /* Support generation of DWARF2 debugging info.  */
 #define DWARF2_DEBUGGING_INFO 1
 
+/* Use DWARF2 debugging info by default: comment out following  */
+/* 2 lines to default to COFF debugging info  */
+#undef PREFERRED_DEBUGGING_TYPE
+#define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG
+
 /* Don't assume anything about the header files.  */
 #define NO_IMPLICIT_EXTERN_C
 
+/* If defined, a C expression whose value is a string containing the
+   assembler operation to identify the following data as
+   uninitialized global data.  If not defined, and neither
+   `ASM_OUTPUT_BSS' nor `ASM_OUTPUT_ALIGNED_BSS' are defined,
+   uninitialized global data will be output in the data section if
+   `-fno-common' is passed, otherwise `ASM_OUTPUT_COMMON' will be
+   used.  */
 #undef BSS_SECTION_ASM_OP
 #define BSS_SECTION_ASM_OP "\t.section\t.bss"
 
@@ -30,6 +45,10 @@ along with GCC; see the file COPYING3.  If not see
 #undef DATA_SECTION_ASM_OP
 #define DATA_SECTION_ASM_OP 

[PATCH 2/6] [DJGPP] libgcc: Add djgpp to lists of i[34567]86-*-* and x86_64-*-* soft-fp targets.

[Andris Pavenis]

Included patch adds *-*-msdosdjgpp to lists of i[34567]86-*-* soft-fp targets.

Andris

PS. Sending from different address as posts from other address seems not to go 
through

2015-12-05 Andris Pavenis 

*  config.host: Add *-*-msdosdjgpp to lists of i[34567]86-*-* soft-fp targets
>From 9e5259eabf7ce876c8639500b56ad8213d852417 Mon Sep 17 00:00:00 2001
From: Andris Pavenis 
Date: Tue, 24 Nov 2015 20:16:38 +0200
Subject: [PATCH 2/6] [DJGPP] libgcc/config.host: update

* config.host: Add *-*-msdosdjgpp to lists of i[34567]86-*-* and x86_64-*-* soft-fp targets.
---
 libgcc/config.host | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libgcc/config.host b/libgcc/config.host
index 9a58beb..11a82e6 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -1348,6 +1348,7 @@ case ${host} in
 i[34567]86-*-darwin* | x86_64-*-darwin* | \
   i[34567]86-*-kfreebsd*-gnu | x86_64-*-kfreebsd*-gnu | \
   i[34567]86-*-linux* | x86_64-*-linux* | \
+  i[34567]86-*-msdosdjgpp* | \
   i[34567]86-*-gnu* | \
   i[34567]86-*-solaris2* | x86_64-*-solaris2.1[0-9]* | \
   i[34567]86-*-cygwin* | x86_64-*-cygwin* | \
-- 
2.4.3

[PATCH] Fix libgfortran build on hppa64-hp-hpux11.11

[John David Anglin]

The use of libbacktrace in libgfortran exposed a libgfortran build issue on 
hppa64-hp-hpux11.11.
This target doesn't have any __sync builtins, so we need to set 
libbacktrace_cv_sys_sync to no
when with_target_subdir is set and configure tests are not done.

This exposed a compilation issue in elf.c which  is fixed by a void cast.

Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11 with no observed 
regressions.
Okay for trunk?

Regards,
Dave
--
John David Anglin   dave.ang...@bell.net


2015-12-05  John David Anglin  

PR 68115/libfortran
* configure.ac: Set libbacktrace_cv_sys_sync to no on hppa*-*-hpux*.
* configure: Regenerate.
* elf.c (backtrace_initialize): Cast __sync_bool_compare_and_swap call
to void.

Index: configure.ac
===
--- configure.ac(revision 230990)
+++ configure.ac(working copy)
@@ -172,7 +172,10 @@
 AC_CACHE_CHECK([__sync extensions],
 [libbacktrace_cv_sys_sync],
 [if test -n "${with_target_subdir}"; then
-   libbacktrace_cv_sys_sync=yes
+   case "${host}" in
+   hppa*-*-hpux*) libbacktrace_cv_sys_sync=no ;;
+   *) libbacktrace_cv_sys_sync=yes ;;
+   esac
  else
AC_LINK_IFELSE(
  [AC_LANG_PROGRAM([int i;],
Index: elf.c
===
--- elf.c   (revision 231044)
+++ elf.c   (working copy)
@@ -955,7 +955,8 @@
   if (found_sym)
backtrace_atomic_store_pointer (>syminfo_fn, elf_syminfo);
   else
-   __sync_bool_compare_and_swap (>syminfo_fn, NULL, elf_nosyms);
+   (void) __sync_bool_compare_and_swap (>syminfo_fn, NULL,
+elf_nosyms);
 }
 
   if (!state->threaded)

Re: [PATCH 1/6] [DJGPP] libstdc++-v3/config/os/djgpp/error_constants.h: Update according to errno codes available for DJGPP

[Andris Pavenis]

On 12/05/2015 06:35 PM, Andris Pavenis wrote:

Included patch updates libstdc++-v3/config/os/djgpp/error_constants.h
according to defines available in DJGPP errno.h.

I'm reposting a patch as earlier post (Nov 15, 2015) have bug in changelog entry

Andris

2015-12-05 Andris Pavenis 

* config/os/djgpp/error_constants.h: update according to DJGPP errno macros.

[PATCH,committed] PR fortran/50201 -- quadmath_snprintf isn't weak

[Steve Kargl]

Committed to trunk and 5-bracnh after testing.

2015-12-05  Juoko Orava 

PR fortran/50201
* io/write_float.def: Avoid marking quadmath_snprintf as an untyped
weak reference, which fixing linking with -static.

-- 
Steve
Index: libgfortran/io/write_float.def
===
--- libgfortran/io/write_float.def	(revision 231314)
+++ libgfortran/io/write_float.def	(working copy)
@@ -938,7 +938,7 @@ snprintf (buffer, size, "%+-#.*Le", (pre
 
 #if defined(GFC_REAL_16_IS_FLOAT128)
 #define DTOA2Q(prec,val)			\
-__qmath_(quadmath_snprintf) (buffer, size, "%+-#.*Qe", (prec), (val))
+quadmath_snprintf (buffer, size, "%+-#.*Qe", (prec), (val))
 #endif
 
 #define FDTOA(suff,prec,val) TOKENPASTE(FDTOA2,suff)(prec,val)
@@ -953,7 +953,7 @@ snprintf (buffer, size, "%+-#.*Lf", (pre
 
 #if defined(GFC_REAL_16_IS_FLOAT128)
 #define FDTOA2Q(prec,val)			   \
-__qmath_(quadmath_snprintf) (buffer, size, "%+-#.*Qf", \
+quadmath_snprintf (buffer, size, "%+-#.*Qf", \
 			 (prec), (val))
 #endif
 

[PATCH] c++/68711 - [5 regression] SEGV on an invalid offsetof of a member of a virtual base

[Martin Sebor]

The attached patch restores the "invalid access to non-static
data member" error for invalid offsetof-like expressions
involving members of virtually derived base classes that was
inadvertently made ineffective as a result of the merge of
the C++ delayed folding branch.

Martin
gcc/testsuite/ChangeLog:
2015-12-05  Martin Sebor  

	PR c++/68711
	* g++.dg/other/offsetof8.C: New test.

gcc/cp/ChangeLog:
2015-12-05  Martin Sebor  

	PR c++/68711
	* typeck.c (build_class_member_access_expr): Strip NOPs before
testing a potentially null operand for equality to zero.

Index: gcc/cp/typeck.c
===
--- gcc/cp/typeck.c	(revision 231314)
+++ gcc/cp/typeck.c	(working copy)
@@ -2358,8 +2358,14 @@
   int type_quals;
   tree member_type;
 
-  null_object_p = (INDIRECT_REF_P (object)
-		   && integer_zerop (TREE_OPERAND (object, 0)));
+  if (INDIRECT_REF_P (object))
+	{
+	  tree oper = TREE_OPERAND (object, 0);
+	  STRIP_NOPS (oper);
+	  null_object_p = integer_zerop (oper);
+	}
+  else
+	null_object_p = false;
 
   /* Convert OBJECT to the type of MEMBER.  */
   if (!same_type_p (TYPE_MAIN_VARIANT (object_type),
Index: gcc/testsuite/g++.dg/other/offsetof8.C
===
--- gcc/testsuite/g++.dg/other/offsetof8.C	(revision 0)
+++ gcc/testsuite/g++.dg/other/offsetof8.C	(working copy)
@@ -0,0 +1,12 @@
+// PR c++/68711 - [5 regression] SEGV on an invalid offsetof of a member
+//of a virtual base
+// { dg-do compile }
+
+struct A { int i; };
+
+struct B: virtual A { };
+
+int a[]  = {
+  !&((B*)0)->i,// { dg-error "invalid access to non-static data member" }
+  __builtin_offsetof (B, i)   // { dg-error "invalid access to non-static" }
+};

Re: [UPC 07/22] lowering, pointer-to-shared ops

[Gary Funck]

On 12/01/15 12:42:48, Richard Biener wrote:
> On Mon, 30 Nov 2015, Gary Funck wrote:
> [...]
> > +  get_lc_mode_name (mname, (op_mode));
> > +  sprintf (libfunc_name, "__get%s%s%s%s",
> > +   strict_mode ? "s" : "",
> > +   doprofcall ? "g" : "",
> > +  mname,
> > +  (op_mode == BLKmode)
> > +? (doprofcall ? "5" : "3")
> > +: (doprofcall ? "3" : "2"));
> > +  libfunc = identifier_global_value (get_identifier (libfunc_name));
> > +  if (!libfunc)
> > +internal_error ("UPC runtime function %s not found", libfunc_name);
> 
> I think for all these you should use builtins.  You definitely shouldn't
> ICE here if it is an error to not include upc.h (or whatever is required
> to make above lookup succeed).

For UPC, although a reference via a pointer-to-shared will often
access data on another node, fairly often the reference will be
on node or will be local to the current process.  It is a worthwhile
optimization to inline the runtime call because the number of instructions
to test if a reference is on-node or local and to then load/store
directly to that location is small/short relative to the overhead of
making the call.  On some micro-benchmarks, inlining is 30% faster
for get/put accesses.

Inlining is implemented with a pre-include of "gcc-upc.h", which
in turn includes "gcc-upc-lib.h", which defines the API to
the libgupc runtime library.  At optimization levels greater than 0,
gcc-upc-lib.h will implement many UPC runtime procedures as
inline procedures.  This inlining can be disabled with -fupc-no-inline-lib.
The pre-include can be disabled with -fupc-no-pre-include, but
this is typically only done by certain tests.  The pre-include
will be enabled by default if -fupc is asserted.

Thus,

- We need to bring in the inlined runtime procedures via
  the pre-include.

- If we're compiling UPC, then the runtime header file
  will be pre-included, unless explicitly disabled via
  -fupc-no-pre-include (which is ill-advised for regular users).

It is effectively an internal error, if we can't find
the runtime procedures.

Regarding builtins, if we were to contemplate generating
code that makes this locality check and then issuing
a direct access for local/on-node accesses, it would
likely be impractical because different runtime libraries
will implement this locality check and local reference
differently.

- Gary

Re: [UPC 07/22] lowering, pointer-to-shared ops

[Gary Funck]

On 12/01/15 12:42:48, Richard Biener wrote:
> On Mon, 30 Nov 2015, Gary Funck wrote:
> [...]
> > +  if (bitpos)
> > +{
> > +  t_offset = size_int (bitpos / BITS_PER_UNIT);
> > +  if (offset)
> > +   t_offset = fold (build_binary_op (loc, PLUS_EXPR,
> > + offset, t_offset, 0));
> 
> Don't use fold ().  If you want a simplified tree don't go
> through build_binary_op but use fold_build2.  In this case
> it looks you want to use size_binop anyway.

OK

Regarding size_binop(), I'll need to review the code.
There are places that we need to retain sign and use
signed size types for example.

> > +}
> > +  else
> > +t_offset = offset;
> > +  {
> > +const tree base_addr_type = TREE_TYPE (base_addr);
> > +const enum tree_code cvt_op =
> > +   lang_hooks.types_compatible_p (upc_char_pts_type_node, base_addr_type)
> > +   ? NOP_EXPR : CONVERT_EXPR;
> 
> NOP and CONVERT are the same.

I haven't followed every GCC changes/re-org closely, but my impression
is that there has been a move to make NOP and CONVERT the same.
Is that correct?

We retain CONVERT's between UPC pointer-to-shared that are not
equivalent and that require some special logic to inter-operate
or convert them.  The UPC lowering pass handles those special cases.
Those conversions are not NOP's.  For example, a floating point
to integer conversion isn't a no-op.

Could use some additional guidance here.

Re: [UPC 14/22] constant folding changes

[Gary Funck]

On 12/01/15 12:46:01, Richard Biener wrote:
> On Mon, 30 Nov 2015, Gary Funck wrote:
> > UPC pointers-to-shared (aka shared pointers) are not interchangeable
> > with integers as they are in regular "C".  Therefore, additions
> > and subtraction operations which involve UPC shared pointers
> > should not be further simplified.
> 
> This looks worrysome.  I suppose this applies to simplifications
> done before lowering only?  If so I wonder if not using regular
> plus/minus/convert/nop for operations on UPC shared pointers is
> better than introducing this kind of checks.

I suppose that is a possibility.  We could introduce
UPC_POINTER_PLUS, UPC_POINTER_CONVERT, and so-on as needed.
Just not sure how many places that for example,
UPC_POINTER_PLUS will keep showing up alongside POINTER_PLUS
and similarly UPC_POINTER_CONVERT and CONVERT.

After lowering, All UPC-specific operations have been replaced
with the GENERIC code that implements them.  We still retain
the UPC pointer-to-shared types in the tree, rather than
lowering everything to the internal representation of the
pointer-to-shared type.  I recall trying to replace
pointers-to-shared with their internal representation and
ran into some issues.  I think one of them is that procedures
accepting pointers-to-shared as parameters would have
an apparent type mis-match. It might have impacted debug info.
generation as well.  Just don't recall.

- Gary

Re: [UPC 02/22] tree-related changes

[Gary Funck]

On 12/03/15 12:07:35, Richard Biener wrote:
> On Wed, 2 Dec 2015, Gary Funck wrote:
> > OK. As I mentioned in a previous reply, originally we prefixed
> > all "UPC" specific tree node fields and functions with UPC_ or upc_,
> > but as we transitioned away from UPC as a separate language
> > (ala ObjC) and made compilation conditional upon -fupc, an
> > observation was made off list that since the base tree nodes
> > are generic that naming UPC-related fields with "UPC" prefixes
> > didn't make sense, so we removed those prefixes.  There might
> > be a middle ground, however, whee UPC_SHARED_TYPE_P() is preferred
> > to SHARED_TYPE_P() because as you/others have mentioned,
> > the term "shared" gets used in a lot of contexts.
> 
> Yes, specifically for predicates/functions used in the middle-end.

OK
 
> > > > +  outer_is_pts_p = (POINTER_TYPE_P (outer_type)
> > > > +&& SHARED_TYPE_P (TREE_TYPE (outer_type)));
> > > > +  inner_is_pts_p = (POINTER_TYPE_P (inner_type)
> > > > +&& SHARED_TYPE_P (TREE_TYPE (inner_type)));
> > > > +
> > > > +  /* Pointer-to-shared types have special
> > > > + equivalence rules that must be checked.  */
> > > > +  if (outer_is_pts_p && inner_is_pts_p
> > > > +  && lang_hooks.types_compatible_p)
> > > > +return lang_hooks.types_compatible_p (outer_type, inner_type);
> > > 
> > > Sorry, but that can't fly with LTO.
> > 
> > Can you elaborate?  I'm not familiar with LTO or its requirements.
> 
> With LTO the langhooks from the frontends are no longer available
> so you'd need to implement the same logic in the LTO "frontend"
> which means it wouldn't need a langhook at all because all information
> would be contained in the middle-end representations.

Still not quite understanding this one.  Will need to take
a more detailed look at LTO.

> > We would also still need to make sure that the parts of the
> > compiler that think that pointers are interchangeable with
> > integers doesn't do that with UPC pointers-to-shared.
> 
> I'm not very familiar with address-spaces but at least they
> can be used to distinguish different pointer kinds (and prevent
> conversions).  Not sure if it would allow different behavior
> for a simple plus.
> 
> Note that I belive you should lower your "pointer" representation
> when you lower the rest (I suppose you lower this now only during
> RTL generation?)

We lower all *operations* (plus/minus, get/put, conversions)
in the UPC lowering pass, which runs just before c_genericize().
We retain the pointer-to-shared-qualified type in the tree,
often wrapped by a conversion to the internal representation type.

As I mentioned previously, we ran into some issues try to lower
to just the representation type, but I don't recall the specifics.
I can try and check on that.

The RTL will see the pointer-to-shared types, but won't see
things like indirections through them, addition/subtraction and
so on, because that was handled in the lowering pass.

We could probably lower most all things in the front-end when
the program is being parsed, but it would make the initial
tree difficult to understand and would push the lowering
logic into front-end/parser which makes the implementation
less modular.

> > > Use a function please.  No such unwiedlingly large macros.
> > 
> > OK.  Are static inline's OK here?
> 
> Implementations in non-headers are prefered, but yes.

I doubt that performance will be impacted much by making the call
out-of-line.  Will take a look into whether that is feasible.

> > > > +/* UPC pointer to shared qualified object representation */
> > > > +#define upc_pts_rep_type_node  global_trees[TI_UPC_PTS_REP_TYPE]
> > > > +#define upc_char_pts_type_node global_trees[TI_UPC_CHAR_PTS_TYPE]
> > > > +#define upc_phase_field_node   global_trees[TI_UPC_PHASE_FIELD]
> > > > +#define upc_thread_field_node  global_trees[TI_UPC_THREAD_FIELD]
> > > > +#define upc_vaddr_field_node   global_trees[TI_UPC_VADDR_FIELD]
> > > > +#define upc_null_pts_node  global_trees[TI_UPC_NULL_PTS]
> > > > +
> > > 
> > > Ugh.  Please no further global tree nodes.
> > > Do you really need all of them in middle-end code?
> [...]
> After gimplification.  I realize the global trees are in a messy
> state already and most of them should be moved to frontend specific
> places.  It would be a start if you do that.  And lowering your
> pointer representation earlier will probably make that easier.

I will review the code to see if they can be moved to front-end
specific procedures/files.

RE: [PR68001, CilkPlus] Fix for PR68001

[Zamyatin, Igor]

> 
> >
> > FAIL: obj-c++.dg/property/dotsyntax-11.mm -fgnu-runtime  (test for
> > errors, line 51)
> > FAIL: obj-c++.dg/property/dotsyntax-11.mm -fgnu-runtime  (test for
> > errors, line 56)
> > FAIL: obj-c++.dg/property/dotsyntax-11.mm -fgnu-runtime  (test for
> > errors, line 59)
> >
> > Andreas.
> 
> Here is the patch that properly limits GS_ERROR exit only in case of error in
> cilk spawn detection.
>

Resending with PR68511 mentioned in Changelog 

Bootstrapped and regtested on x86_64, ok for trunk?

Thanks,
Igor


 cp/Changelog

2015-12-04  Igor Zamyatin  

PR objc++/68511
PR c++/68001
* cp-gimplify.c (cp_gimplify_expr): Limit GS_ERROR only in case of
error in cilk spawn detection.

diff --git a/gcc/cp/cp-gimplify.c b/gcc/cp/cp-gimplify.c
index 09ee5ff..3dbbd7f 100644
--- a/gcc/cp/cp-gimplify.c
+++ b/gcc/cp/cp-gimplify.c
@@ -559,6 +559,7 @@ int
 cp_gimplify_expr (tree *expr_p, gimple_seq *pre_p, gimple_seq *post_p)
 {
   int saved_stmts_are_full_exprs_p = 0;
+  bool is_spawn_detected = true;
   enum tree_code code = TREE_CODE (*expr_p);
   enum gimplify_status ret;
 
@@ -614,12 +615,12 @@ cp_gimplify_expr (tree *expr_p, gimple_seq *pre_p, 
gimple_seq *post_p)
 25979.  */
 case INIT_EXPR:
   if (fn_contains_cilk_spawn_p (cfun)
- && cilk_detect_spawn_and_unwrap (expr_p))
+ && (is_spawn_detected = cilk_detect_spawn_and_unwrap (expr_p)))
{
  cilk_cp_gimplify_call_params_in_spawned_fn (expr_p, pre_p, post_p);
  return (enum gimplify_status) gimplify_cilk_spawn (expr_p);
}
-  if (seen_error ())
+  if (!is_spawn_detected && seen_error ())
return GS_ERROR;
 
   cp_gimplify_init_expr (expr_p);

Re: [PATCH, libgomp] Rewire OpenACC async

[Chung-Lin Tang]

On 2015/12/1 08:01 PM, Julian Brown wrote:
> On Tue, 24 Nov 2015 18:27:24 +0800
> Chung-Lin Tang  wrote:
> 
>> Hi, this patch reworks some of the way that asynchronous copyouts are
>> implemented for OpenACC in libgomp.
>>
>> Before this patch, we had a somewhat confusing way of implementing
>> this by having two refcounts for each mapping: refcount and
>> async_refcount, which I never got working again after the last wave
>> of async regressions showed up.
>>
>> So this patch implements what I believe to be a simplification:
>> async_refcount is removed, and instead of trying to queue the async
>> copyouts during unmapping we actually do that during the plugin event
>> handling. This requires a addition of the async stream integer as an
>> argument to the register_async_cleanup plugin hook, but overall I
>> think this should be more elegant than before.
> 
> This looks OK to me I think (I've only looked fairly briefly). I vaguely
> remember trying something along these lines in an earlier iteration of
> the async support -- maybe hitting problems with locking (I see you
> have code to mitigate problems with that, and locking generally has
> probably evolved a bit since I last looked at the code in detail
> anyway).
> 
> Can event_gc ever be called when the *device* lock is held?

It only matters when the memmap_lockable argument is true, and for those
cases, no the device lock is never held.

> I'm slightly concerned that pushing async unmapping into event_gc means
> that program-level semantics are deferred to the backend, which is
> arguably the wrong place. But then I don't understand what went wrong
> with the dual-refcount implementation, so maybe it's unavoidable for
> some reason.

I got the dual-refcounting to work again (after the regressions first showed up)
in some cases briefly, but regressed in other testcases, which I don't recall
the full details now.
Indeed the copyout is now triggered inside the plugin, but it is still wrapped
inside GOMP_PLUGIN_async_unmap_vars(), so it's probably not too ugly.

Per our earlier internal discussion, I'm committing this to the gomp4 branch 
first.
Trunk will need to wait for Jakub's approval.

Thanks,
Chung-Lin

Re: [PATCH, C++] Wrap OpenACC wait in EXPR_STMT

[Chung-Lin Tang]

On 2015/12/3 06:32 PM, Chung-Lin Tang wrote:
> On 2015/12/3 6:11 PM, Jakub Jelinek wrote:
>> On Thu, Dec 03, 2015 at 06:05:36PM +0800, Chung-Lin Tang wrote:
 Oh wait, it looks like the C++ front end is not actually using the
 functions defined in the C/C++-shared gcc/c-family/c-omp.c, but has its
 own implementations in gcc/cp/semantics.c, without "c_" prefixes?  In
 addition to finish_expr_stmt calls, I see it's also using
 finish_call_expr instead of build_call_expr_loc/build_call_expr_loc_vec.
 So I guess we'll want to model this the same way for OpenACC support
 functions, and then (later) we should clean this up, to move the
 C-specific code from gcc/c-family/c-omp.c into the C front end?  (Jakub?)
>>>
>>> I see most OpenACC/OpenMP constructs are represented by special statement 
>>> codes,
>>> so they should be a different case. I so far only see the OpenACC wait 
>>> directive
>>> being represented as a CALL_EXPR (maybe there are others, haven't 
>>> exhaustively searched).
>>
>> No, Thomas is right, just look at
>> finish_omp_{barrier,flush,taskwait,taskyield,cancel,cancellation_point},
>> all those are represented as CALL_EXPRs.
>>
>>  Jakub
>>
> 
> Okay, I guess my impression was only for some OpenACC constructs.
> 
> Overall, OpenACC wait seems one of the few cases of using c_finish_* in 
> cp/parser.c.
> Whether other cases should move towards/away from that kind of style is a 
> larger question,
> I was only trying to fix a libgomp.oacc-c++/template-reduction.C regression 
> (testcase currently still in gomp4 branch)
> 
> Chung-Lin
> 

Per our internal discussion, I will commit this patch first to the gomp4 branch,
while awaiting trunk approval.

Thanks,
Chung-Lin

Re: RFC: Merge the GUPC branch into the GCC 6.0 trunk

[Gary Funck]

On 12/02/15 10:40:50, Richard Biener wrote:
> On Tue, 1 Dec 2015, Gary Funck wrote:
> > The main change recommended to reduce tree space was moving the
> > "layout factor" (blocking factor) out of the tree node, and using
> > only two bits there, one bit for a relatively common case of 0,
> > and the other for > 1.  It was suggested that we use a hash
> > table to map tree nodes to layout qualifiers for the case they
> > are > 1.  This necessitated using a garbage collected tree map,
> > which unfortunately meant that tree nodes needed special garbage
> > collection logic.
> 
> I still don't see why it needs special garbage collection logic.
> We have many tree -> X maps that just get away without.
> [...]
> As said, I don't see why you need a special GC collection logic
> at all.  Please explain.

The problem we ran into is that we had a tree map which
mapped a tree node to its UPC layout qualifier, which
is an integral constant (CST).  Tree nodes for CST's
are made unique by hashing them into an integer->tree map.
What happened is that the GC would free up entries in the
CST table that were being used by the layout qualifier map.

It seems that the new tree map logic fixes this problem
(as you've noted).  I backed out the custom GC logic and
re-ran a large test that extensively exercises the use case
that triggers the issue -- works like a charm.

thanks,
- Gary

Re: [PATCH] RFC: Use Levenshtein spelling suggestions in Fortran FE

[Mikael Morin]

Hello,

to get things moving again, a few comments on top of David Malcolm's:

Le 01/12/2015 13:55, Bernhard Reutner-Fischer a écrit :


David Malcolm nice Levenshtein distance spelling check helpers
were used in some parts of other frontends. This proposed patch adds
some spelling corrections to the fortran frontend.

Suggestions are printed if we can find a suitable name, currently
perusing a very simple cutoff factor:
/* If more than half of the letters were misspelled, the suggestion is
likely to be meaningless.  */
cutoff = MAX (strlen (typo), strlen (best_guess)) / 2;
which effectively skips names with less than 4 characters.
For e.g. structures, one could try to be much smarter in an attempt to
also provide suggestions for single-letter members/components.

This patch covers (at least partly):
- user-defined operators
- structures (types and their components)
- functions
- symbols (variables)

I do not immediately see how to handle subroutines. Ideas?

Not sure what you are looking for; I can get an error generated in 
gfc_procedure_use if using IMPLICIT NONE (EXTERNAL)



If anybody has a testcase where a spelling-suggestion would make sense
then please pass it along so we maybe can add support for GCC-7.





diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 685e3f5..6e1f63c 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -29,6 +29,7 @@ along with GCC; see the file COPYING3.  If not see
  #include "data.h"
  #include "target-memory.h" /* for gfc_simplify_transfer */
  #include "constructor.h"
+#include "spellcheck.h"

  /* Types used in equivalence statements.  */

@@ -2682,6 +2683,61 @@ resolve_specific_f (gfc_expr *expr)
return true;
  }

+/* Recursively append candidate SYM to CANDIDATES.  */
+
+static void
+lookup_function_fuzzy_find_candidates (gfc_symtree *sym,
+   vec *candidates)
+{
+  gfc_symtree *p;
+  for (p = sym->right; p; p = p->right)
+{
+  lookup_function_fuzzy_find_candidates (p, candidates);
+  if (p->n.sym->ts.type != BT_UNKNOWN)
+   candidates->safe_push (p->name);
+}
+  for (p = sym->left; p; p = p->left)
+{
+  lookup_function_fuzzy_find_candidates (p, candidates);
+  if (p->n.sym->ts.type != BT_UNKNOWN)
+   candidates->safe_push (p->name);
+}
+}


It seems you are considering some candidates more than once here.
The first time through the recursive call you will consider say 
sym->right->right, and with the loop, you'll consider it again after 
returning from the recursive call.
The usual way to traverse the whole tree is to handle the current 
pointer and recurse on left and right pointers.  So without loop.
There is gfc_traverse_ns that you might find handy to do that (no 
obligation).


Same goes for the user operators below.


+
+
+/* Lookup function FN fuzzily, taking names in FUN into account.  */
+
+const char*
+gfc_lookup_function_fuzzy (const char *fn, gfc_symtree *fun)
+{
+  auto_vec  candidates;
+  lookup_function_fuzzy_find_candidates (fun, );


You have to start the lookup with the current namespace's sym_root (not 
with fun), otherwise you'll miss some candidates.

You may also want to query parent namespaces for host-associated symbols.


+
+  /* Determine closest match.  */
+  int i;
+  const char *name, *best = NULL;
+  edit_distance_t best_distance = MAX_EDIT_DISTANCE;
+


[...]


diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c
index ff9aff9..212f7d8 100644
--- a/gcc/fortran/symbol.c
+++ b/gcc/fortran/symbol.c
@@ -27,6 +27,7 @@ along with GCC; see the file COPYING3.  If not see
  #include "parse.h"
  #include "match.h"
  #include "constructor.h"
+#include "spellcheck.h"


  /* Strings for all symbol attributes.  We use these for dumping the
@@ -235,6 +236,62 @@ gfc_get_default_type (const char *name, gfc_namespace *ns)
  }


+/* Recursively append candidate SYM to CANDIDATES.  */
+
+static void
+lookup_symbol_fuzzy_find_candidates (gfc_symtree *sym,
+   vec *candidates)
+{
+  gfc_symtree *p;
+  for (p = sym->right; p; p = p->right)
+{
+  lookup_symbol_fuzzy_find_candidates (p, candidates);
+  if (p->n.sym->ts.type != BT_UNKNOWN)
+   candidates->safe_push (p->name);
+}
+  for (p = sym->left; p; p = p->left)
+{
+  lookup_symbol_fuzzy_find_candidates (p, candidates);
+  if (p->n.sym->ts.type != BT_UNKNOWN)
+   candidates->safe_push (p->name);
+}
+}

This looks like the same as lookup_function_fuzzy_find_candidates, isn't it?
Maybe have a general symbol traversal function with a selection callback 
argument to test whether the symbol is what you want, depending on the 
context (is it a function? a subroutine? etc).



+
+
+/* Lookup symbol SYM fuzzily, taking names in SYMBOL into account.  */
+
+static const char*
+lookup_symbol_fuzzy (const char *sym, gfc_symbol *symbol)
+{
+  auto_vec  candidates;
+  lookup_symbol_fuzzy_find_candidates (symbol->ns->sym_root,