Re: [PATCH] Try to use issetugid before falling back to insecure getenv

[Matija Skala]

Dne sreda, 25. april 2018 ob 19:53:08 CEST je Andreas Schwab napisal(a):
> On Apr 25 2018, Matija Skala  wrote:
> > diff --git a/libvtv/configure.ac b/libvtv/configure.ac
> > index ba3009ee3fb..878ba02a2e2 100644
> > --- a/libvtv/configure.ac
> > +++ b/libvtv/configure.ac
> > @@ -115,6 +115,9 @@ AC_CHECK_FUNCS([__secure_getenv])
> > 
> >  AC_GNU_SOURCE
> >  AC_CHECK_FUNCS([secure_getenv])
> > 
> > +AC_GNU_SOURCE
> > +AC_CHECK_FUNCS([issetugid])
> 
> There is no need to repeat AC_GNU_SOURCE.
> 
> Andreas.

Thanks for pointing this out. There was already one repetition which confused 
me.

---
 libvtv/configure.ac | 3 ++-
 libvtv/vtv_utils.cc | 2 ++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/libvtv/configure.ac b/libvtv/configure.ac
index ba3009ee3fb..4d8cda9adaf 100644
--- a/libvtv/configure.ac
+++ b/libvtv/configure.ac
@@ -112,9 +112,10 @@ AC_SUBST(toolexeclibdir)
 AC_GNU_SOURCE
 AC_CHECK_FUNCS([__secure_getenv])
 
-AC_GNU_SOURCE
 AC_CHECK_FUNCS([secure_getenv])
 
+AC_CHECK_FUNCS([issetugid])
+
 AC_CHECK_FUNCS([getexecname __fortify_fail])
 
 # Check for programs.
diff --git a/libvtv/vtv_utils.cc b/libvtv/vtv_utils.cc
index 1e41ced4473..10efee987d4 100644
--- a/libvtv/vtv_utils.cc
+++ b/libvtv/vtv_utils.cc
@@ -46,6 +46,8 @@
 #ifndef HAVE_SECURE_GETENV
 #  ifdef HAVE___SECURE_GETENV
 #define secure_getenv __secure_getenv
+#  elif defined HAVE_ISSETUGID
+#define secure_getenv(name) (issetugid() ? NULL : getenv(name))
 #  else
 #define secure_getenv getenv
 #  endif
-- 
2.16.1

PING: [PATCH] Don't mark IFUNC resolver as only called directly

[H.J. Lu]

On Thu, Apr 12, 2018 at 3:50 PM, H.J. Lu  wrote:
> On Thu, Apr 12, 2018 at 6:39 AM, H.J. Lu  wrote:
>> On Thu, Apr 12, 2018 at 5:17 AM, Jan Hubicka  wrote:
 On Thu, Apr 12, 2018 at 1:29 PM, H.J. Lu  wrote:
 > Since IFUNC resolver is called indirectly, don't mark IFUNC resolver as
 > only called directly.
 >
 > OK for trunk?
 >
 >
 > H.J.
 > ---
 > gcc/
 >
 > PR target/85345
 > * cgraph.h: Include stringpool.h" and "attribs.h".
 > (cgraph_node::only_called_directly_or_aliased_p): Return false
 > for IFUNC resolver.
 >
 > gcc/testsuite/
 >
 > PR target/85345
 > * gcc.target/i386/pr85345.c: New test.
 > ---
 >  gcc/cgraph.h|  5 +++-
 >  gcc/testsuite/gcc.target/i386/pr85345.c | 44 
 > +
 >  2 files changed, 48 insertions(+), 1 deletion(-)
 >  create mode 100644 gcc/testsuite/gcc.target/i386/pr85345.c
 >
 > diff --git a/gcc/cgraph.h b/gcc/cgraph.h
 > index d1ef8408497..9e195824fcc 100644
 > --- a/gcc/cgraph.h
 > +++ b/gcc/cgraph.h
 > @@ -24,6 +24,8 @@ along with GCC; see the file COPYING3.  If not see
 >  #include "profile-count.h"
 >  #include "ipa-ref.h"
 >  #include "plugin-api.h"
 > +#include "stringpool.h"
 > +#include "attribs.h"
 >
 >  class ipa_opt_pass_d;
 >  typedef ipa_opt_pass_d *ipa_opt_pass;
 > @@ -2894,7 +2896,8 @@ cgraph_node::only_called_directly_or_aliased_p 
 > (void)
 >   && !DECL_STATIC_CONSTRUCTOR (decl)
 >   && !DECL_STATIC_DESTRUCTOR (decl)
 >   && !used_from_object_file_p ()
 > - && !externally_visible);
 > + && !externally_visible
 > + && !lookup_attribute ("ifunc", DECL_ATTRIBUTES (decl)));

 How's it handled for our own generated resolver functions?  That is,
 isn't there sth cheaper than doing a lookup_attribute here?  I see
 that make_dispatcher_decl nor ix86_get_function_versions_dispatcher
 adds the 'ifunc' attribute (though they are TREE_PUBLIC there).
>>>
>>> Is there any drawback of setting force_output flag?
>>> Honza
>>
>> Setting force_output may prevent some optimizations.  Can we add a bit
>> for IFUNC resolver?
>>
>
> Here is the patch to add ifunc_resolver to cgraph_node. Tested on x86-64
> and i686.  Any comments?
>

PING:

https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00647.html


-- 
H.J.

[PATCH] C/C++: Add -Waddress-of-packed-member

[H.J. Lu]

When address of packed member of struct or union is taken, it may result
in an unaligned pointer value.  This patch adds -Waddress-of-packed-member
to check alignment at pointer assignment and warn unaligned address as
well as unaligned pointer:

$ cat x.i
struct pair_t
{
  char c;
  int i;
} __attribute__ ((packed));

extern struct pair_t p;
int *addr = 
$ gcc -O2 -S x.i
x.i:8:13:  warning: taking address of packed member of 'struct pair_t' may 
result in an unaligned pointer value [-Waddress-of-packed-member]
 int *addr = 
 ^
$ cat c.i
struct B { int i; };
struct C { struct B b; } __attribute__ ((packed));

long* g8 (struct C *p) { return p; }
$ gcc -O2 -S c.i -Wno-incompatible-pointer-types
c.i: In function ‘g8’:
c.i:4:33: warning: taking value of packed 'struct C *' may result in an 
unaligned pointer value [-Waddress-of-packed-member]
 long* g8 (struct C *p) { return p; }
 ^
$

This warning is enabled by default.  Since read_encoded_value_with_base
in unwind-pe.h has

  union unaligned
{
  void *ptr;
  unsigned u2 __attribute__ ((mode (HI)));
  unsigned u4 __attribute__ ((mode (SI)));
  unsigned u8 __attribute__ ((mode (DI)));
  signed s2 __attribute__ ((mode (HI)));
  signed s4 __attribute__ ((mode (SI)));
  signed s8 __attribute__ ((mode (DI)));
} __attribute__((__packed__));
  _Unwind_Internal_Ptr result;

and GCC warns:

gcc/libgcc/unwind-pe.h:210:37: warning: taking address of packed member of 
'union unaligned' may result in an unaligned pointer value 
[-Waddress-of-packed-member]
result = (_Unwind_Internal_Ptr) u->ptr;
^
we need to add GCC pragma to ignore -Waddress-of-packed-member.

OK for trunk?

H.J.

gcc/c/

PR c/51628
* doc/invoke.texi: Document -Wno-address-of-packed-member.

gcc/c-family/

PR c/51628
* c-common.h (warn_for_address_of_packed_member): New.
* c-warn.c (check_address_of_packed_member): New function.
(warn_for_address_of_packed_member): Likewise.
* c.opt: Add -Wno-address-of-packed-member.

gcc/c/

PR c/51628
* c-typeck.c (warn_for_pointer_of_packed_member): New function.
(convert_for_assignment): Call warn_for_address_of_packed_member
and warn_for_pointer_of_packed_member.

gcc/cp/

PR c/51628
* call.c (convert_for_arg_passing): Call
warn_for_address_of_packed_member.
* typeck.c (convert_for_assignment): Likewise.

gcc/testsuite/

PR c/51628
* c-c++-common/pr51628-1.c: New test.
* c-c++-common/pr51628-2.c: Likewise.
* c-c++-common/pr51628-3.c: Likewise.
* c-c++-common/pr51628-4.c: Likewise.
* c-c++-common/pr51628-5.c: Likewise.
* c-c++-common/pr51628-6.c: Likewise.
* c-c++-common/pr51628-7.c: Likewise.
* c-c++-common/pr51628-8.c: Likewise.
* c-c++-common/pr51628-9.c: Likewise.
* c-c++-common/pr51628-10.c: Likewise.
* c-c++-common/pr51628-11.c: Likewise.
* c-c++-common/pr51628-12.c: Likewise.
* c-c++-common/pr51628-13.c: Likewise.
* c-c++-common/pr51628-14.c: Likewise.
* c-c++-common/pr51628-15.c: Likewise.
* gcc.dg/pr51628-16.c: Likewise.
* gcc.dg/pr51628-17.c: Likewise.
* gcc.dg/pr51628-18.c: Likewise.
* gcc.dg/pr51628-19.c: Likewise.
* gcc.dg/pr51628-20.c: Likewise.
* gcc.dg/pr51628-21.c: Likewise.
* gcc.dg/pr51628-22.c: Likewise.
* gcc.dg/pr51628-23.c: Likewise.
* gcc.dg/pr51628-24.c: Likewise.
* c-c++-common/asan/misalign-1.c: Add
-Wno-address-of-packed-member.
* c-c++-common/asan/misalign-2.c: Likewise.
* c-c++-common/ubsan/align-2.c: Likewise.
* c-c++-common/ubsan/align-4.c: Likewise.
* c-c++-common/ubsan/align-6.c: Likewise.
* c-c++-common/ubsan/align-7.c: Likewise.
* c-c++-common/ubsan/align-8.c: Likewise.
* c-c++-common/ubsan/align-10.c: Likewise.
* g++.dg/ubsan/align-2.C: Likewise.
* gcc.target/i386/avx512bw-vmovdqu16-2.c: Likewise.
* gcc.target/i386/avx512f-vmovdqu32-2.c: Likewise.
* gcc.target/i386/avx512f-vmovdqu64-2.c: Likewise.
* gcc.target/i386/avx512vl-vmovdqu16-2.c: Likewise.
* gcc.target/i386/avx512vl-vmovdqu32-2.c: Likewise.
* gcc.target/i386/avx512vl-vmovdqu64-2.c: Likewise.

libgcc/

* unwind-pe.h (read_encoded_value_with_base): Add GCC pragma
to ignore -Waddress-of-packed-member.
---
 gcc/c-family/c-common.h|   1 +
 gcc/c-family/c-warn.c  | 117 +
 gcc/c-family/c.opt |   4 +
 gcc/c/c-typeck.c   |  60 ++-
 gcc/cp/call.c  |   3 +
 gcc/cp/typeck.c|   2 +
 

GCC 8.1 RC1 Bootstrap comparison failure on AIX

[David Edelsohn]

Jakub and Richi,

GCC 8.1 is experiencing the same bootstrap failure with GCC 8.1 RC1 as
we saw previously.

Bootstrap comparison failure!
gcc/function-tests.o differs

And the same reason: unique, static symbol that includes a random timestamp.

1949c1949

< [1936]m   0x0060 1 10x02 0x
   
_GLOBAL__F__nasfarm_edelsohn_src_gcc_8.0.1_RC_20180425_gcc_function_tests.c_DFF67DD7_0x4eda2a0ca57bf446
---
> [1936]m   0x0060 1 10x02 0x 
> _GLOBAL__F__nasfarm_edelsohn_src_gcc_8.0.1_RC_20180425_gcc_function_tests.c_DFF67DD7_0xbe25963bf76153c

The entire file is protected by CHECKING_P. As DEBUG_FUNCTION
propagates to more and more header files, this triggers when building
without checking.

How do you suggest that we try to fix it this time? I'm not certain
that we can pull out the one function this time.  Should we return to
the -frandom-seed patch for self-test files that you proposed last
time?

Thanks, David

Re: [PATCH 0/4] ASAN for MIPS (o32)

[Hans-Peter Nilsson]

> Date: Fri, 23 Mar 2018 03:49:01 +0100
> From: Hans-Peter Nilsson 

The patches enabling ASAN for MIPS (32-bit) have now been
committed, on trunk for gcc-9.  I didn't persist pinging release
maintainers for gcc-8, but I'd certainly like to backport them,
if so allowed.

brgds, H-P

Re: RFC: bash completion

[David Malcolm]

[moving from gcc to gcc-patches mailing list]

On Wed, 2018-04-25 at 15:12 +0200, Martin Liška wrote:
> On 04/24/2018 06:27 PM, David Malcolm wrote:
> > On Tue, 2018-04-24 at 16:45 +0200, Martin Liška wrote:
> > > Hi.
> > > 
> > > Some time ago, I investigated quite new feature of clang which
> > > is support of --autocomplete argument. That can be run from bash
> > > completion
> > > script and one gets more precise completion hints:
> > > 
> > > http://blog.llvm.org/2017/09/clang-bash-better-auto-completion-is
> > > .htm
> > > l
> > > https://www.youtube.com/watch?v=zLPwPdZBpSY
> > > 
> > > I like the idea and I would describe how is that better to
> > > current
> > > GCC completion
> > > script sitting here:
> > > https://github.com/scop/bash-completion/blob/master/completions/g
> > > cc
> > > 
> > > 1) gcc -fsanitize=^ - no support for option enum values
> > > 2) gcc -fno-sa^ - no support for negative options
> > > 3) gcc --param=^ - no support for param names
> > > 
> > > These are main limitations I see. I'm attaching working
> > > prototype,
> > > which you
> > > can test by installed GCC, setting it on $PATH and doing:
> > > $ source gcc.sh
> > > 
> > > Then bash completion is provided via the newly added option. Some
> > > examples:
> > > 
> > > 1)
> > > $ gcc -fsanitize=
> > > addressbounds enum   
> > > 
> > > integer-divide-by-zero nonnull-
> > > attribute  pointer-
> > > comparereturn shift-
> > > base thread vla-bound
> > > alignment  bounds-strict  float-cast-
> > > overflowkernel-
> > > address null   pointer-
> > > overflow   returns-nonnull-attribute  shift-
> > > exponent undefined  vptr
> > > bool   builtinfloat-
> > > divide-
> > > by-zero   leak   object-
> > > sizepointer-
> > > subtract   shift  signed-integer-
> > > overflowunreachable
> > > 
> > > 2)
> > > $ gcc -fno-ipa-
> > > -fno-ipa-bit-cp -fno-ipa-cp-alignment   -fno-ipa-
> > > icf-fno-ipa-icf-variables  -fno-ipa-profile-
> > > fno-
> > > ipa-pure-const -fno-ipa-reference  -fno-ipa-struct-
> > > reorg   
> > > -fno-ipa-cp -fno-ipa-cp-clone   -fno-ipa-icf-
> > > functions  -fno-ipa-matrix-reorg   -fno-ipa-pta-fno-
> > > ipa-
> > > ra -fno-ipa-sra-fno-ipa-vrp
> > > 
> > > 3)
> > > $ gcc --param=lto-
> > > lto-max-partition  lto-min-partition  lto-partitions
> > > 
> > > 4)
> > > gcc --param lto-
> > > lto-max-partition  lto-min-partition  lto-partitions 
> > > 
> > > The patch is quite lean and if people like, I will prepare a
> > > proper
> > > patch submission. I know about some limitations that can be then
> > > handled incrementally.
> > > 
> > > Thoughts?
> > > Martin
> > 
> > Overall, looks good (albeit with various nits).  I like how you're
> > reusing the m_option_suggestions machinery from the misspelled
> > options
> > code.  There are some awkward issues e.g. arch-specific
> > completions,
> > lang-specific completions, custom option-handling etc, but given
> > that
> > as-is this patch seems to be an improvement over the status quo,
> > I'd
> > prefer to tackle those later.
> 
> I'm sending second version of the patch. I did isolation of
> m_option_suggestions machinery
> to a separate file. Mainly due to selftests that are linked with cc1.
> 
> > 
> > The patch doesn't have tests.  There would need to be some way to
> > achieve test coverage for the completion code (especially as we
> > start
> > to tackle the more interesting cases).  I wonder what the best way
> > to
> > do that is; perhaps a combination of selftest and DejaGnu?  (e.g.
> > what
> > about arch-specific completions? what about the interaction with
> > bash?
> > etc)
> 
> For now I come up with quite some selftests. Integration with
> bash
> would be challenging.
> 
> > 
> > A few nits:
> > * Do we want to hardcode that logging path in gcc.sh?
> 
> Sure, that needs to be purged. Crucial question here is where the
> gcc.sh script
> should live. Note that clang has it in: ./tools/clang/utils/bash-
> autocomplete.sh
> and:
> 
> head -n1 ./tools/clang/utils/bash-autocomplete.sh
> # Please add "source /path/to/bash-autocomplete.sh" to your .bashrc
> to use this.
> 
> Which is not ideal. I would prefer to integrate the script into:
> https://github.com/scop/bash-completion/blob/master/completions/gcc
> 
> Thoughts?

Maybe our goal should be to update that upstream bash-completion script
so that it uses "--completion" if it exists (for newer GCCs), falling
back to their existing implementation if it doesn't?

> > 
> > * Looks like m_option_suggestions isn't needed for handling the "-

[Committed] Remove myself as MIPS maintainer

[Moore, Catherine]

2018-04-25  Catherine Moore 

* MAINTAINERS (mips): Remove myself as MIPS maintainer.

[PATCH][arm][FreeBSD] PR libgcc/84292

[Andreas Tobler]

Hi all,

I'm going to commit this patch to all active branches as soon as the 
branch status permits.

Built and tested on native armv5 FreeBSD12.

Thanks,
Andreas

2018-04-25  Andreas Tobler  
Maryse Levavasseur 

PR libgcc/84292
* config/arm/freebsd-atomic.c (SYNC_OP_AND_FETCH_N): Fix the
op_and_fetch to return the right result.
Index: config/arm/freebsd-atomic.c
===
--- config/arm/freebsd-atomic.c (revision 259656)
+++ config/arm/freebsd-atomic.c (working copy)
@@ -171,9 +171,9 @@
 
 #defineSYNC_OP_AND_FETCH_N(N, TYPE, LDR, STR, NAME, OP)
\
 TYPE HIDDEN\
-__sync_##NAME##_and_fetch_##N (TYPE *mem, TYPE val)\
+__sync_##NAME##_and_fetch_##N (TYPE *mem, TYPE val)\
 {  \
-unsigned int old, temp, ras_start;  \
+unsigned int old, temp, ras_start, res; \
 \
 ras_start = ARM_RAS_START; \
 __asm volatile (   \
@@ -180,23 +180,23 @@
 /* Set up Restartable Atomic Sequence.  */ \
 "1:"   \
 "\tadr   %2, 1b\n" \
-"\tstr   %2, [%5]\n"   \
+"\tstr   %2, [%6]\n"   \
 "\tadr   %2, 2f\n" \
-"\tstr   %2, [%5, #4]\n"   \
+"\tstr   %2, [%6, #4]\n"   \
 \
-"\t"LDR" %0, %4\n" /* Load old value.  */  \
-"\t"OP"  %2, %0, %3\n" /* Calculate new value.  */ \
-"\t"STR" %2, %1\n" /* Store new value.  */ \
+"\t"LDR" %0, %5\n" /* Load old value.  */  \
+"\t"OP"  %3, %0, %4\n" /* Calculate new value.  */ \
+"\t"STR" %3, %1\n" /* Store new value.  */ \
 \
 /* Tear down Restartable Atomic Sequence.  */  \
 "2:"   \
 "\tmov   %2, #0x\n"\
-"\tstr   %2, [%5]\n"   \
+"\tstr   %2, [%6]\n"   \
 "\tmov   %2, #0x\n"\
-"\tstr   %2, [%5, #4]\n"   \
-: "=" (old), "=m" (*mem), "=" (temp)   \
+"\tstr   %2, [%6, #4]\n"   \
+: "=" (old), "=m" (*mem), "=" (temp), "=" (res)  \
 : "r" (val), "m" (*mem), "r" (ras_start)); \
-return (old);  \
+return (res);  \
 }
 
 #defineEMIT_ALL_OPS_N(N, TYPE, LDR, STR, STREQ)
\

[PATCH] Minor documentation correction in aarch64-simd.md

[Indu Bhagat]

In function minmax_replacement in tree-ssa-phiopt.c, MIN_EXPR/MAX_EXPR 
are substituted for when the following condition is false - (HONOR_NANS 
(type) || HONOR_SIGNED_ZEROS (type)). So for FP mode, this is false when 
_both_ of the following conditions are fulfilled : 1. flag_signed_zeros 
is zero and 2. flag_finite_math_only is set. So, the documentation in 
aarch64-simd.md is partially misleading. Here is a patch to correct 
that. Thanks


---

gcc/ChangeLog:

* config/aarch64/aarch64-simd.md: correct flags text for 
MIN_EXPR replacement




diff --git a/gcc/config/aarch64/aarch64-simd.md 
b/gcc/config/aarch64/aarch64-simd.md
index 1154fc3..7fd20fd 100644
--- a/gcc/config/aarch64/aarch64-simd.md
+++ b/gcc/config/aarch64/aarch64-simd.md
@@ -2211,8 +2211,9 @@
 ;; Max/Min are introduced by idiom recognition by GCC's mid-end.  An
 ;; expression like:
 ;;  a = (b < c) ? b : c;
-;; is idiom-matched as MIN_EXPR only if -ffinite-math-only is enabled
-;; either explicitly or indirectly via -ffast-math.
+;; is idiom-matched as MIN_EXPR only if -ffinite-math-only and
+;; -fno-signed-zeros are enabled either explicitly or indirectly via
+;; -ffast-math.
 ;;
 ;; MIN_EXPR and MAX_EXPR eventually map to 'smin' and 'smax' in RTL.
 ;; The 'smax' and 'smin' RTL standard pattern names do not specify which

[PATCH] Document that -Wreturn-type is enabled by default for C++

[Jonathan Wakely]

* doc/invoke.texi (-Wreturn-type): Document default status for C++.

OK for trunk and gcc-8-branch?


commit 20357a8ded851a3376b7e8978c77e7c56b1a273e
Author: Jonathan Wakely 
Date:   Wed Apr 25 19:51:10 2018 +0100

Document that -Wreturn-type is enabled by default for C++

* doc/invoke.texi (-Wreturn-type): Document default status for C++.

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index b6784b75fa2..26c0dff28a0 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -4783,7 +4783,7 @@ For C++, a function without return type always produces a 
diagnostic
 message, even when @option{-Wno-return-type} is specified.  The only
 exceptions are @code{main} and functions defined in system headers.
 
-This warning is enabled by @option{-Wall}.
+This warning is enabled by default for C++ and is enabled by @option{-Wall}.
 
 @item -Wshift-count-negative
 @opindex Wshift-count-negative

Re: [PATCH] Try to use issetugid before falling back to insecure getenv

[Andreas Schwab]

On Apr 25 2018, Matija Skala  wrote:

> diff --git a/libvtv/configure.ac b/libvtv/configure.ac
> index ba3009ee3fb..878ba02a2e2 100644
> --- a/libvtv/configure.ac
> +++ b/libvtv/configure.ac
> @@ -115,6 +115,9 @@ AC_CHECK_FUNCS([__secure_getenv])
>  AC_GNU_SOURCE
>  AC_CHECK_FUNCS([secure_getenv])
>  
> +AC_GNU_SOURCE
> +AC_CHECK_FUNCS([issetugid])

There is no need to repeat AC_GNU_SOURCE.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH] DWARF sort longer dirs before shorter ones in directory table.

[Mark Wielaard]

On Mon, 2018-04-16 at 09:41 +0200, Jakub Jelinek wrote:
> On Mon, Apr 16, 2018 at 09:34:17AM +0200, Mark Wielaard wrote:
> > gcc/ChangeLog:
> > 
> > * dwarf2out.c (file_info_cmp): Sort longer dir prefixes before
> > shorter ones.
> 
> Ok, thanks.

Pushed now that trunk is in stage 1 again.

Cheers,

Mark

Re: [PATCH][arm] PR target/82518: Return false in ARRAY_MODE_SUPPORTED_P for BYTES_BIG_ENDIAN

[Maxim Kuvyrkov]

> On Mar 20, 2018, at 8:11 PM, Kyrill Tkachov  
> wrote:
> 
> Hi all,
> 
> This PR shows that we get the load/store_lanes logic wrong for arm big-endian.
> It is tricky to get right. Aarch64 does it by adding the appropriate 
> lane-swapping
> operations during expansion.
> 
> I'd like to do the same on arm eventually, but we'd need to port and validate 
> the VTBL-generating
> code and add it to all the right places and I'm not comfortable enough doing 
> it for GCC 8, but I am keen
> in getting the wrong-code fixed.
> As I say in the PR, vectorisation on armeb is already severely restricted (we 
> disable many patterns on BYTES_BIG_ENDIAN)
> and the load/store_lanes patterns really were not working properly at all, so 
> disabling them is not
> a radical approach.
> 
> The way to do that is to return false in ARRAY_MODE_SUPPORTED_P for 
> BYTES_BIG_ENDIAN.
> 
> Bootstrapped and tested on arm-none-linux-gnueabihf.
> Also tested on armeb-none-eabi.
> 
> Committing to trunk.
...
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -6609,7 +6609,8 @@ proc check_effective_target_vect_load_lanes { } {
>   verbose "check_effective_target_vect_load_lanes: using cached result" 2
>  } else {
>   set et_vect_load_lanes 0
> - if { ([istarget arm*-*-*] && [check_effective_target_arm_neon_ok])
> + # We don't support load_lanes correctly on big-endian arm.
> + if { ([istarget arm-*-*] && [check_effective_target_arm_neon_ok])
>|| [istarget aarch64*-*-*] } {
>   set et_vect_load_lanes 1
>   }
> 

Hi Kyrill,

This part makes armv8l-linux-gnueabihf target fail a few of slp-perm-* tests.  
Using [check_effective_target_arm_little_endian] should fix this.

Would you please fix this on master and gcc-7-branch?

Thanks!

--
Maxim Kuvyrkov
www.linaro.org

Re: [PATCH] Don't offer suggestions for compiler-generated variables (PR c++/85515)

[Nathan Sidwell]

On 04/25/2018 11:41 AM, David Malcolm wrote:

Jason Turner's video C++ Weekly - Ep 112 - GCC's Leaky Abstractions shows
two issues where g++ offers suggestions about implementation details:



For the lambda capture case, there are multiple members:

$9 = 


These names have a space at the end, so the user cannot name them.  We 
could move the space to the beginning, if that helps?



$21 = 
$23 = 


These two could also have the space treatment.


$22 = 


This is a perfectly serviceable user available function, just as any 
member operator function.


nathan
--
Nathan Sidwell

Re: [PATCH, rs6000] Improve Documentation of Built-In Functions Part 1

[Kelvin Nilsen]

Thank you for the prompt review and careful feedback.  I didn't notice
your message until this morning.  At this point, I'll wait a few days before
committing these changes as I understand we are still in the "RC phase of GCC 
8".


On 4/24/18 4:45 PM, Segher Boessenkool wrote:
> Hi!
> 
> On Tue, Apr 24, 2018 at 02:25:58PM -0500, Kelvin Nilsen wrote:
>>> 4. Remove descriptions of built-in function that do not belong in this
>>> section because the
>>>built-in functions are generic (not specific to PowerPC):
>>> __builtin_fabsq,
>>>__builtin_copysignq, __builtin_infq, __builtin_huge_valq, __builtin_nanq,
>>>__builtin_nansq, __builtin_sqrtf128, __builtin_fmaf128.
> 
> Are these described in a generic place, then?  I don't see it?
> 
>> +@node Low-Level PowerPC Built-in Functions Available on all Targets
>> +@subsubsection Low-Level PowerPC Built-in Functions Available on all Targets

Regarding your question about "q functions", the existing gcc.pdf document
is a bit confusing.  Here's what I can figure out.

The following are mentioned only in "Section 6.59.33: x86 Built-in Functions"

  __float128 __builtin_fabsq (__float128)
  __float128 __builtin_copysignq (__float128, __float128)
  __float128 __builtin_infq (void)
  __float128 __builtin_huge_valq (void)
  __float128 __builtin_nanq (void)
  __float128 __builtin_nansq (void)

As far as I can tell, these should not be documented as specific to x86, but
should be documented as generic across all platforms.  This is an issue outside
the realm of PowerPC maintenance.

If we want to preserve mention of these "q" functions, I would recommend
changing the text that introduces them.  Currently, it says:

  "Previous versions of GCC supported some 'q' builtins for IEEE 128-bit
   floating point.  These functions are now mapped into the equivalent
   'f128' builtin functions."

If the description of these built-ins is not moved to a more generic context,
I would prefer to replace this section with something like:

The following functions, which are also supported on x86 targets, are supported
if the -mfloat128 option is specified:

  __float128 __builtin_fabsq (__float128)
  __float128 __builtin_copysignq (__float128, __float128)
  __float128 __builtin_infq (void)
  __float128 __builtin_huge_valq (void)
  __float128 __builtin_nanq (void)
  __float128 __builtin_nansq (void)

Regarding your question about f128 functions, these are "supposed to be"
documented in "Section 6.58: Other Built-in Functions Provided by GCC".
Search for the phrase "corresponding to the TS 18661-3 functions".  We
should add "__builtin_sqrtf128 and builtin_fmaf128 to the list of functions
described this way.  These may not be the only omissions.  Should we push
for fixing this documentation in Section 6.58 instead of keeping it in
the PowerPC section?

It is difficult to find the official TS 18661-3 document, and
I'm not sure where to look for a list of which of the functions are
currently implemented by gcc.  I found this "diff" document, which provides
some hints.  Given that this standard is not easily accessible, perhaps the
generic built-in documentation should provide a little more information?

See http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1945.pdf

[wwwdocs] Add notes on common C++ problems with GCC 8

[Jonathan Wakely]

Ville is going to prepare something for the new -Wclass-memacess and
-Wcatch-value warnings.  Suggestions for other gotchas to document are
welcome.

Committed to CVS.

Index: htdocs/gcc-8/porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/porting_to.html,v
retrieving revision 1.3
diff -u -r1.3 porting_to.html
--- htdocs/gcc-8/porting_to.html	23 Jan 2018 14:16:49 -	1.3
+++ htdocs/gcc-8/porting_to.html	25 Apr 2018 15:42:29 -
@@ -30,6 +30,131 @@
 
 C++ language issues
 
+-Wreturn-type is enabled by default
+
+
+  G++ now assumes that control never reaches the end of a non-void function
+  (i.e. without reaching a return statement). This means that
+  you should always pay attention to -Wreturn-type warnings,
+  as they indicate code that can misbehave when optimized.
+
+
+
+  To tell the compiler that control can never reach the end of a function
+  (e.g. because all callers enforce its preconditions) you can suppress
+  -Wreturn-type warnings by adding
+  __builtin_unreachable:
+
+  
+  char signchar(int i) // precondition: i != 0
+  {
+if (i  0)
+  return '+';
+else if (i  0)
+  return '-';
+__builtin_unreachable();
+  }
+  
+
+
+  Because -Wreturn-type is now enabled by default, G++ will
+  warn if main is declared with an implicit int
+  return type (which is non-standard but allowed by GCC). To avoid the
+  warning simply add a return type to main, which makes the
+  code more portable anyway.
+
+
+Stricter rules when using templates
+
+
+  G++ now diagnoses even more cases of ill-formed templates which can never 
+  be instantiated (in addition to
+  the stricter
+  rules in GCC 7).
+  The following example will now be diagnosed by G++ because the type of
+  BT::a does not depend on T and so the
+  function BT::f is ill-formed for every possible
+  instantiation of the template:
+
+  
+  class A { };
+  template typename T struct B {
+bool f() const { return a; }
+A a;
+  };
+  
+
+
+In member function 'bool BT::f() const':
+error: cannot convert 'const A' to 'bool' in return
+   bool f() const { return a; }
+   ^
+
+
+
+  Ill-formed template code that has never been tested and can never be
+  instantiated should be fixed or removed.
+
+
+Changes to alignof results
+
+
+  The alignof operator has been changed to return the minimum
+  alignment required by the target ABI, instead of the preferred alignment
+  (consistent with _Alignof in C).
+
+
+
+  Previously the following assertions could fail on 32-bit x86 but will now
+  pass. GCC's preferred alignment for standalone variables of type
+  double or long long is 8 bytes, but the minimum
+  alignment required by the ABI (and so used for non-static data members)
+  is 4 bytes:
+
+
+  
+  struct D { double val; };
+  static_assert(alignof(D) == alignof(double), "...");
+  struct L { long long val; };
+  static_assert(alignof(L) == alignof(long long), "...");
+  
+
+
+  Code which uses alignof to obtain the preferred
+  alignment can use __alignof__ instead.
+
+
+Associative containers check the comparison function
+
+
+  The associative containers (std::map,
+  std::multimap, std::set, and
+  std::multiset) now use static assertions to check that their
+  comparison functions support the necessary operations.
+  In C++17 mode this includes enforcing that the function can be called
+  when const-qualified:
+
+  
+  struct Cmp {
+bool operator()(int l, int r) /* not const */ { return l  r; }
+  };
+  std::setint, Cmp s;
+  
+
+In member function 'bool BT::f() const':
+error: static assertion failed: comparison object must be invocable as const
+   static_assert(is_invocable_vconst _Compare, const _Key, const _Key,
+ ^
+   bool f() const { return a; }
+   ^
+
+
+This can be fixed by adding const to the call operator:
+  
+  struct Cmp {
+bool operator()(int l, int r) const { return l  r; }
+  };
+  
 
 Fortran language issues
 
Index: htdocs/gcc-8/porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/porting_to.html,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- htdocs/gcc-8/porting_to.html	25 Apr 2018 15:44:23 -	1.4
+++ htdocs/gcc-8/porting_to.html	25 Apr 2018 15:46:36 -	1.5
@@ -124,7 +124,7 @@
   alignment can use __alignof__ instead.
 
 
-Associative containers check the comparison function
+Associative containers check the comparison function
 
 
   The associative containers (std::map,

Re: [PATCH] Don't offer suggestions for compiler-generated variables (PR c++/85515)

[Jakub Jelinek]

On Wed, Apr 25, 2018 at 11:41:51AM -0400, David Malcolm wrote:
> @@ -1224,9 +1225,19 @@ lookup_field_fuzzy_info::fuzzy_lookup_field (tree type)
>  
>for (tree field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
>  {
> -  if (!m_want_type_p || DECL_DECLARES_TYPE_P (field))
> - if (DECL_NAME (field))
> -   m_candidates.safe_push (DECL_NAME (field));
> +  if (m_want_type_p && !DECL_DECLARES_TYPE_P (field))
> + continue;
> +
> +  tree name = DECL_NAME (field);
> +  if (name == NULL_TREE)
> + continue;
> +
> +  /* FIXME: do we want to impose the underscore-uppercase rule, or
> +  just two underscores here?  */
> +  if (name_reserved_for_implementation_p (IDENTIFIER_POINTER (name)))
> + continue;

This will not suggest fields that are really named __, there are tons of
such fields in many structures.
I think for lambdas it is better to make the fields DECL_NAMELESS (unless
debuginfo relies on them being emitted) and then check here DECL_NAMELESS.

Jakub

Re: [PATCH][i386] PR target/85473, Fix _movdir64b expansion with -mx32

[Jakub Jelinek]

On Wed, Apr 25, 2018 at 08:31:33AM -0700, H.J. Lu wrote:
> On Wed, Apr 25, 2018 at 5:13 AM, Uros Bizjak  wrote:
> > On Wed, Apr 25, 2018 at 1:03 PM, Peryt, Sebastian
> >  wrote:
> >> Hi,
> >>
> >> Patch has been updated and tested. Now I don't see any new regressions.
> >>
> >> Changelog stays the same.
> >>
> >> Is it ok for trunk?
> >
> > OK for mainline and gcc-8 backport after a couple of days, the latter
> > also needs approval from RM.
> 
> Jakub,  is this OK for backport to GCC 8?

Ok.

Jakub

[PATCH] Don't offer suggestions for compiler-generated variables (PR c++/85515)

[David Malcolm]

Jason Turner's video C++ Weekly - Ep 112 - GCC's Leaky Abstractions shows
two issues where g++ offers suggestions about implementation details:

Example 1:

int main ()
{
  auto lambda = [val = 2](){};

  lambda.val;
}

: In function 'int main()':
:5:10: error: 'struct main()::' has no member named 'val'; 
did you mean '__val'?
   lambda.val;
  ^~~
  __val

Example 2:

void test ()
{
  int arr[] = {1, 2, 3, 4, 5};
  for (const auto v: arr) {
_forbegin
  }
}

: In function 'void test()':
:5:5: error: '_forbegin' was not declared in this scope
 _forbegin
 ^
:5:5: note: suggested alternative: '__for_begin'
 _forbegin
 ^
 __for_begin

In the video, he uses these suggestions to assign to the variables,
breaking through the abstractions.

This patch hides the issue by avoiding offering these names as
suggestions.

For the lambda capture case, there are multiple members:

$9 = 
$10 = 
$11 = 
$12 = 
$13 = 
$14 = 
$15 = 
$16 = 
$17 = 
$18 = 
$19 = 
$20 = 
$21 = 
$22 = 
$23 = 

all of which have a double-underscore prefix, so the patch reuses
name_reserved_for_implementation_p from the fix for PR c/83236 - though
that also rejects underscore-uppercase as a pattern - perhaps we should
merely reject double-underscore here?

For the range-for case, the variables are flagged as DECL_ARTIFICIAL, so
the patch rejects suggesting such variables, in consider_binding_level.

Should the __val also be flagged as DECL_ARTIFICIAL, and would that be
a better approach?

This patch doesn't prevent the user from using the variables, merely
preventing suggestions of using them.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu;
adds 9 PASS results to g++.sum.

Thoughts?

gcc/cp/ChangeLog:
PR c++/85515
* name-lookup.c (consider_binding_level): Skip compiler-generated
variables.
* search.c: Include "c-family/c-spellcheck.h".
(lookup_field_fuzzy_info::fuzzy_lookup_field): Flatten nested if
statements into a series of rejection tests.  Reject names
reserved for implementation.

gcc/testsuite/ChangeLog:
PR c++/85515
* g++.dg/pr85515-1.C: New test.
* g++.dg/pr85515-2.C: New test.
---
 gcc/cp/name-lookup.c |  6 ++
 gcc/cp/search.c  | 17 ++---
 gcc/testsuite/g++.dg/pr85515-1.C | 18 ++
 gcc/testsuite/g++.dg/pr85515-2.C | 22 ++
 4 files changed, 60 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/pr85515-1.C
 create mode 100644 gcc/testsuite/g++.dg/pr85515-2.C

diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index d2e5acb..a51cf1b 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -5860,6 +5860,12 @@ consider_binding_level (tree name, best_match  ,
  && DECL_ANTICIPATED (d))
continue;
 
+  /* Skip compiler-generated variables (e.g. __for_begin/__for_end
+within range for).  */
+  if (TREE_CODE (d) == VAR_DECL
+ && DECL_ARTIFICIAL (d))
+   continue;
+
   tree suggestion = DECL_NAME (d);
   if (!suggestion)
continue;
diff --git a/gcc/cp/search.c b/gcc/cp/search.c
index bfeaf2c..7a02c07 100644
--- a/gcc/cp/search.c
+++ b/gcc/cp/search.c
@@ -30,6 +30,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "spellcheck-tree.h"
 #include "stringpool.h"
 #include "attribs.h"
+#include "c-family/c-spellcheck.h"
 
 static int is_subobject_of_p (tree, tree);
 static tree dfs_lookup_base (tree, void *);
@@ -1224,9 +1225,19 @@ lookup_field_fuzzy_info::fuzzy_lookup_field (tree type)
 
   for (tree field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
 {
-  if (!m_want_type_p || DECL_DECLARES_TYPE_P (field))
-   if (DECL_NAME (field))
- m_candidates.safe_push (DECL_NAME (field));
+  if (m_want_type_p && !DECL_DECLARES_TYPE_P (field))
+   continue;
+
+  tree name = DECL_NAME (field);
+  if (name == NULL_TREE)
+   continue;
+
+  /* FIXME: do we want to impose the underscore-uppercase rule, or
+just two underscores here?  */
+  if (name_reserved_for_implementation_p (IDENTIFIER_POINTER (name)))
+   continue;
+
+  m_candidates.safe_push (DECL_NAME (field));
 }
 }
 
diff --git a/gcc/testsuite/g++.dg/pr85515-1.C b/gcc/testsuite/g++.dg/pr85515-1.C
new file mode 100644
index 000..96f767d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr85515-1.C
@@ -0,0 +1,18 @@
+// { dg-require-effective-target c++14 }
+
+void test_1 ()
+{
+  auto lambda = [val = 2](){}; 
+  lambda.val; // { dg-bogus "did you mean" }
+  // { dg-error "has no member named 'val'" "" { target *-*-* } .-1 }
+}
+
+int test_2 ()
+{
+  auto lambda = [val = 2](){ return val; };
+
+  // TODO: should we issue an error for the following assignment?
+  lambda.__val = 4;
+
+  return lambda();
+}
diff --git a/gcc/testsuite/g++.dg/pr85515-2.C 

Re: [PATCH][i386] PR target/85473, Fix _movdir64b expansion with -mx32

[H.J. Lu]

On Wed, Apr 25, 2018 at 5:13 AM, Uros Bizjak  wrote:
> On Wed, Apr 25, 2018 at 1:03 PM, Peryt, Sebastian
>  wrote:
>> Hi,
>>
>> Patch has been updated and tested. Now I don't see any new regressions.
>>
>> Changelog stays the same.
>>
>> Is it ok for trunk?
>
> OK for mainline and gcc-8 backport after a couple of days, the latter
> also needs approval from RM.

Jakub,  is this OK for backport to GCC 8?

Thanks.

>>> > 2018-04-20  Sebastian Peryt  
>>> >
>>> > gcc/ChangeLog:
>>> >
>>> > PR target/85473
>>> > * config/i386/i386.c (ix86_expand_builtin): Change memory
>>> > operand to XI, op0 extend to Pmode.
>
> ... extend op0 to Pmode.
>
>>> > * config/i386/i386.md: Change unspec volatile and operand 1
>>> > mode to XI, change operand 0 mode to P
>
> Full stop.
>
>>> >
>>> > 2018-04-20  Sebastian Peryt  
>>> >
>>> > gcc/testsuite/ChangeLog:
>>> >
>>> > PR target/85473
>>> > * gcc.target/i386/pr85473-1.c: New test.
>>> > * gcc.target/i386/pr85473-2.c: New test.
>>> >
>>> > Sebastian
>>> >
>>



-- 
H.J.

Re: [PATCH] Improve bootstrap times

[Richard Biener]

On Wed, 25 Apr 2018, Jakub Jelinek wrote:

> On Wed, Apr 25, 2018 at 03:52:28PM +0200, Richard Biener wrote:
> > Forcefully setting STAGE3_[CT]FLAGS doesn't have any effect on
> > a checking enabled build but it will disrupt profiledbootstrap
> > on a release build by training with -fchecking.  Suggestions
> > welcome - not sure whether adjusting STAGE3_[CT]FLAGS after
> > setting STAGEtrain_[CT]FLAGS will have the desired effect of
> > leaving the latter alone.
> 
> You could perhaps replace
> STAGEtrain_CFLAGS = $(STAGE3_CFLAGS)
> STAGEtrain_TFLAGS = $(STAGE3_TFLAGS)
> with
> STAGEtrain_CFLAGS = $(filter-out -fchecking,$(STAGE3_CFLAGS))
> STAGEtrain_TFLAGS = $(filter-out -fchecking,$(STAGE3_TFLAGS))
> ?

Good idea - I'll check if that works.

Richard.

Re: [PATCH] Improve bootstrap times

[Jakub Jelinek]

On Wed, Apr 25, 2018 at 03:52:28PM +0200, Richard Biener wrote:
> Forcefully setting STAGE3_[CT]FLAGS doesn't have any effect on
> a checking enabled build but it will disrupt profiledbootstrap
> on a release build by training with -fchecking.  Suggestions
> welcome - not sure whether adjusting STAGE3_[CT]FLAGS after
> setting STAGEtrain_[CT]FLAGS will have the desired effect of
> leaving the latter alone.

You could perhaps replace
STAGEtrain_CFLAGS = $(STAGE3_CFLAGS)
STAGEtrain_TFLAGS = $(STAGE3_TFLAGS)
with
STAGEtrain_CFLAGS = $(filter-out -fchecking,$(STAGE3_CFLAGS))
STAGEtrain_TFLAGS = $(filter-out -fchecking,$(STAGE3_TFLAGS))
?

Jakub

Re: PR85463 '[nvptx] "exit" in offloaded region doesn't terminate process' (was: [patch, libfortran, committed] Implement stop_numeric for minimal targets)

[Martin Jambor]

Hi,

On Thu, Apr 19 2018, Thomas Schwinge wrote:
>
> Per PR85463 '[nvptx] "exit" in offloaded region doesn't terminate
> process' that I just filed, we currently have to use "abort" instead of
> "exit" for nvptx offloading, so I have applied the following in trunk
> r259491, where I completed this by adding and testing stop_string,
> error_stop_string, and error_stop_numeric functions, too.
>
> commit 6bc09e4fa2e5e59dee18f1c03f2d6529b9b0045b
> Author: tschwinge 
> Date:   Thu Apr 19 08:53:38 2018 +
>
> PR85463 '[nvptx] "exit" in offloaded region doesn't terminate process'
> 
> libgomp/
> PR libfortran/85166
> * testsuite/libgomp.oacc-fortran/abort-1.f90: Switch back to "call
> abort".
> * testsuite/libgomp.oacc-fortran/abort-2.f90: Likewise.
> 
> libgfortran/
> PR libfortran/85166
> PR libgomp/85463
> * runtime/minimal.c (stop_numeric): Reimplement.
> (stop_string, error_stop_string, error_stop_numeric): New
> functions.
> libgomp/
> PR libgomp/85463
> * testsuite/libgomp.oacc-fortran/error_stop-1.f: New file.
> * testsuite/libgomp.oacc-fortran/error_stop-2.f: Likewise.
> * testsuite/libgomp.oacc-fortran/error_stop-3.f: Likewise.
> * testsuite/libgomp.oacc-fortran/stop-1.f: Likewise.
> * testsuite/libgomp.oacc-fortran/stop-2.f: Likewise.
> * testsuite/libgomp.oacc-fortran/stop-3.f: Likewise.
> 

The "output pattern test" part of all of these new testcases fail on my
HSA tester even though no HSAIL is generated for them, only host
fallback is used.  Looking at the first one:

> diff --git libgomp/testsuite/libgomp.oacc-fortran/error_stop-1.f 
> libgomp/testsuite/libgomp.oacc-fortran/error_stop-1.f
> new file mode 100644
> index 000..4965e67
> --- /dev/null
> +++ libgomp/testsuite/libgomp.oacc-fortran/error_stop-1.f
> @@ -0,0 +1,20 @@
> +! { dg-do run }
> +
> +  PROGRAM MAIN
> +  IMPLICIT NONE
> +
> +  PRINT *, "CheCKpOInT"
> +!$ACC PARALLEL
> +  ERROR STOP
> +!$ACC END PARALLEL
> +  PRINT *, "WrONg WAy"
> +
> +  END PROGRAM MAIN
> +
> +! { dg-output "CheCKpOInT(\n|\r\n|\r)+" }
> +! { dg-output "ERROR STOP (\n|\r\n|\r)+" }
> +! PR85463.  The "minimal" libgfortran implementation used with nvptx
> +! offloading is a little bit different.
> +! { dg-output "Error termination.*" { target { ! 
> openacc_nvidia_accel_selected } } }
> +! { dg-output "libgomp: cuStreamSynchronize error.*" { target 
> openacc_nvidia_accel_selected } }
> +! { dg-shouldfail "" }

I can tell that checking for "CheCKpOInT" passes but checking for "ERROR
STOP" and "Error termination" do not.  Running the test manually, they
both appear, but in standard error, not standard output (where
CheCKpOInT is printed).  I am not 100% sure whether that is the reason
why they fail but do we have a way of testing std error of the executed
compiled binary?

Thanks,

Martin

Re: [PATCH] Improve bootstrap times

[Richard Biener]

On Wed, 25 Apr 2018, Richard Biener wrote:

> 
> The following patch improves bootstrap times in general, without
> resorting to file splitting.  The observation that stage2 build
> of gimple-match.c improves by 50% when using -fno-checking
> suggests that we avoid doing redundant checking when bootstrapping
> and simply disable that when using the slow stage1 compiler
> (or building stage2 target libs - maybe that should include stage1
> target libs as well).  Given we in the end compare stage2 and stage3
> this will "only" delay checking failures plus also check whether
> the IL checking affects code generation (hah).  I've resorted to
> leave STAGE4 alone.
> 
> For a release checking build the overall win should be slightly
> lower given the patch ends up enabling -fchecking for all target
> libaries built in the final stage rather than just for those
> built by the stage1 compiler (the stage1 compiler has checking
> enabled for release builds as well unless manually specified).
> 
> Bootstrap with all languages enabled running on x86_64-unknown-linux-gnu.
> 
> I'll provide timings before/after the patch when they are gathered.

On a i7-8700 with --enable-languages=c,c++ and -j12 unpatched trunk
bootstraps in

17196.62user 313.77system 37:40.82elapsed 774%CPU (0avgtext+0avgdata 
734572maxresident)k
152inputs+27472376outputs (0major+161848104minor)pagefaults 0swaps

and with an adjusted patch to also do STAGE1_TFLAGS += -fno-checking
we can get that down to

12683.57user 310.63system 29:35.19elapsed 731%CPU (0avgtext+0avgdata 
734572maxresident)k
176inputs+27461016outputs (0major+161926483minor)pagefaults 0swaps

that's a 25% reduction in user/system time and a 22% reduction
in wall-clock time.  As you can see I'm not lucky and parallellism
is reduced (if I can trust %CPU).

Forcefully setting STAGE3_[CT]FLAGS doesn't have any effect on
a checking enabled build but it will disrupt profiledbootstrap
on a release build by training with -fchecking.  Suggestions
welcome - not sure whether adjusting STAGE3_[CT]FLAGS after
setting STAGEtrain_[CT]FLAGS will have the desired effect of
leaving the latter alone.

Richard.

> Any comments?  Any suggested changes (STAGE1_TFLAGS?)
> 
> Thanks,
> Richard.
> 
> 2018-04-25  Richard Biener  
> 
>   * Makefile.tpl (STAGE2_CFLAGS): Add -fno-checking.
>   (STAGE2_TFLAGS): Likewise.
>   (STAGE3_CFLAGS): Add -fchecking.
>   (STAGE3_TFLAGS): Likewise.
>   * Makefile.in: Re-generate.
> 
> Index: Makefile.tpl
> ===
> --- Makefile.tpl  (revision 259638)
> +++ Makefile.tpl  (working copy)
> @@ -452,6 +452,15 @@ STAGE1_CONFIGURE_FLAGS = --disable-inter
> --disable-coverage --enable-languages="$(STAGE1_LANGUAGES)" \
> --disable-build-format-warnings
>  
> +# When using the slow stage1 compiler disable IL verification and forcefully
> +# enable it when using the stage2 compiler instead.  As we later compare
> +# stage2 and stage3 we are merely avoid doing redundant work, plus we apply
> +# checking when building all target libraries for release builds.
> +STAGE2_CFLAGS += -fno-checking
> +STAGE2_TFLAGS += -fno-checking
> +STAGE3_CFLAGS += -fchecking
> +STAGE3_TFLAGS += -fchecking
> +
>  STAGEprofile_CFLAGS = $(STAGE2_CFLAGS) -fprofile-generate
>  STAGEprofile_TFLAGS = $(STAGE2_TFLAGS)
>  
> Index: Makefile.in
> ===
> --- Makefile.in   (revision 259638)
> +++ Makefile.in   (working copy)
> @@ -529,6 +529,15 @@ STAGE1_CONFIGURE_FLAGS = --disable-inter
> --disable-coverage --enable-languages="$(STAGE1_LANGUAGES)" \
> --disable-build-format-warnings
>  
> +# When using the slow stage1 compiler disable IL verification and forcefully
> +# enable it when using the stage2 compiler instead.  As we later compare
> +# stage2 and stage3 we are merely avoid doing redundant work, plus we apply
> +# checking when building all target libraries for release builds.
> +STAGE2_CFLAGS += -fno-checking
> +STAGE2_TFLAGS += -fno-checking
> +STAGE3_CFLAGS += -fchecking
> +STAGE3_TFLAGS += -fchecking
> +
>  STAGEprofile_CFLAGS = $(STAGE2_CFLAGS) -fprofile-generate
>  STAGEprofile_TFLAGS = $(STAGE2_TFLAGS)
>  
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

Re: GCC 6 backports

[Jan Hubicka]

> Hi.
> 
> Sending GCC 6 branch backports.
> Patches can bootstrap on ppc64le-redhat-linux and survives regression tests.
> I'm going to install the patches.
> 
> Martin

> >From e0d32b1f9e0dd0486e63040e1ab8f5d8e9f0fbd5 Mon Sep 17 00:00:00 2001
> From: marxin 
> Date: Tue, 10 Apr 2018 07:24:59 +
> Subject: [PATCH 1/4] Backport r259265
> 
> gcc/lto/ChangeLog:
> 
> 2018-04-10  Richard Biener  
>   Martin Liska  
> 
>   PR lto/85248
>   * lto-symtab.c (lto_symtab_merge_p): Handle noreturn attribute.

Support for syntactic duplicates was new at that time and several
changes was made later. So enabling more of them may lead to troubles.
Did you test that this works for Firefox build?

Honza

[PATCH] Improve bootstrap times

[Richard Biener]

The following patch improves bootstrap times in general, without
resorting to file splitting.  The observation that stage2 build
of gimple-match.c improves by 50% when using -fno-checking
suggests that we avoid doing redundant checking when bootstrapping
and simply disable that when using the slow stage1 compiler
(or building stage2 target libs - maybe that should include stage1
target libs as well).  Given we in the end compare stage2 and stage3
this will "only" delay checking failures plus also check whether
the IL checking affects code generation (hah).  I've resorted to
leave STAGE4 alone.

For a release checking build the overall win should be slightly
lower given the patch ends up enabling -fchecking for all target
libaries built in the final stage rather than just for those
built by the stage1 compiler (the stage1 compiler has checking
enabled for release builds as well unless manually specified).

Bootstrap with all languages enabled running on x86_64-unknown-linux-gnu.

I'll provide timings before/after the patch when they are gathered.

Any comments?  Any suggested changes (STAGE1_TFLAGS?)

Thanks,
Richard.

2018-04-25  Richard Biener  

* Makefile.tpl (STAGE2_CFLAGS): Add -fno-checking.
(STAGE2_TFLAGS): Likewise.
(STAGE3_CFLAGS): Add -fchecking.
(STAGE3_TFLAGS): Likewise.
* Makefile.in: Re-generate.

Index: Makefile.tpl
===
--- Makefile.tpl(revision 259638)
+++ Makefile.tpl(working copy)
@@ -452,6 +452,15 @@ STAGE1_CONFIGURE_FLAGS = --disable-inter
  --disable-coverage --enable-languages="$(STAGE1_LANGUAGES)" \
  --disable-build-format-warnings
 
+# When using the slow stage1 compiler disable IL verification and forcefully
+# enable it when using the stage2 compiler instead.  As we later compare
+# stage2 and stage3 we are merely avoid doing redundant work, plus we apply
+# checking when building all target libraries for release builds.
+STAGE2_CFLAGS += -fno-checking
+STAGE2_TFLAGS += -fno-checking
+STAGE3_CFLAGS += -fchecking
+STAGE3_TFLAGS += -fchecking
+
 STAGEprofile_CFLAGS = $(STAGE2_CFLAGS) -fprofile-generate
 STAGEprofile_TFLAGS = $(STAGE2_TFLAGS)
 
Index: Makefile.in
===
--- Makefile.in (revision 259638)
+++ Makefile.in (working copy)
@@ -529,6 +529,15 @@ STAGE1_CONFIGURE_FLAGS = --disable-inter
  --disable-coverage --enable-languages="$(STAGE1_LANGUAGES)" \
  --disable-build-format-warnings
 
+# When using the slow stage1 compiler disable IL verification and forcefully
+# enable it when using the stage2 compiler instead.  As we later compare
+# stage2 and stage3 we are merely avoid doing redundant work, plus we apply
+# checking when building all target libraries for release builds.
+STAGE2_CFLAGS += -fno-checking
+STAGE2_TFLAGS += -fno-checking
+STAGE3_CFLAGS += -fchecking
+STAGE3_TFLAGS += -fchecking
+
 STAGEprofile_CFLAGS = $(STAGE2_CFLAGS) -fprofile-generate
 STAGEprofile_TFLAGS = $(STAGE2_TFLAGS)
 

Re: [RFH] split {generic,gimple}-match.c files

[Martin Liška]

On 04/25/2018 01:42 PM, Richard Biener wrote:

Hi.

Thanks for working on that.

> 
> The following patch^Whack splits $subject files into three, one
> for the predicates (due to an implementation detail) and two for
> the rest - for now into similar LOC size files.
> 
> I'd like to get help on the makefile changes to make them less
> verbose, somehow globbing the -[12p] parts.
> 
> Also you can see the split point is manually chosen which means
> it will bitrot.  Timings for the stage2 compiles on a x86_64
> box are
> 
> gimple-match-p.c   5s
> generic-match-p.c  3s
> gimple-match-1.c  85s
> generic-match-1.c 56s
> gimple-match-2.c  82s
> generic-match-2.c 31s
> 
> the required header files are quite big (and of course everything
> needs to be exported without the analysis work becoming too cumbersome),
> it's 3342 LOC for gimple-match-head.h and 1556 LOC for 
> generic-match-head.h
> 
> The machine I tested is quite fast so the 80ish second timings are still
> too slow I guess and thus splitting up into four files for gimple and
> three files for generic looks better.
> 
> Note we lose some inlining/cloning capability in the splitting process
> (I see quite a bit of constprop/isra work being done on the generated 
> files).  I didn't try to measure the runtime impact though.

That's true, but once we'll have working backtraces back in GCC 9 with LTO,
then enabling LTO bootstrap will fix that.

> 
> The patch still needs quite some TLC, it really is a bit hacky but I'd
> like to get feedback on the approach and I didn't want to spend time
> on programatically finding optimal split points (so everything is output
> in the same semi-random order as before).

I'm still thinking about an AWK script that will take original file and
make the separation based on LOC. genmatch.c can generate some placeholders
where split is possible + a common header part. That should be easier
to maintain compared to wired partitioning.

What about doing a param that will drive # of partitions? That would require
more smart Makefile and building on a large machine will benefit from that.

Martin

> 
> Richard.
> 
> 
> 
> Index: gcc/genmatch.c
> ===
> --- gcc/genmatch.c(revision 259638)
> +++ gcc/genmatch.c(working copy)
> @@ -1641,7 +1641,7 @@ struct decision_tree
>dt_node *root;
>  
>void insert (struct simplify *, unsigned);
> -  void gen (FILE *f, bool gimple);
> +  void gen (const char *, FILE *, vec &, bool gimple);
>void print (FILE *f = stderr);
>  
>decision_tree () { root = new dt_node (dt_node::DT_NODE, NULL); }
> @@ -3608,12 +3608,25 @@ sinfo_hashmap_traits::equal_keys (const
>return compare_op (v->s->result, v->s, candidate->s->result, candidate->s);
>  }
>  
> +/* Write the common header for the GIMPLE/GENERIC IL matching routines.  */
> +
> +static void
> +write_header (FILE *f, bool gimple)
> +{
> +  fprintf (f, "/* Generated automatically by the program `genmatch' from\n");
> +  fprintf (f, "   a IL pattern matching and simplification description.  
> */\n");
> +
> +  /* Include the header instead of writing it awkwardly quoted here.  */
> +  fprintf (f, "\n#include \"%s-match-head.c\"\n",
> +gimple ? "gimple" : "generic");
> +}
>  
>  /* Main entry to generate code for matching GIMPLE IL off the decision
> tree.  */
>  
>  void
> -decision_tree::gen (FILE *f, bool gimple)
> +decision_tree::gen (const char *output, FILE *headerf,
> + vec , bool gimple)
>  {
>sinfo_map_t si;
>  
> @@ -3624,6 +3637,34 @@ decision_tree::gen (FILE *f, bool gimple
>  gimple ? "GIMPLE" : "GENERIC", 
>  root->num_leafs, root->max_level, root->total_size);
>  
> +  FILE *f;
> +  char *outputtem = NULL;
> +  if (output)
> +outputtem = XNEWVEC (char, strlen (output) + strlen ("-1.c") + 1);
> +
> +  unsigned do_header = headerf ? 2 : 1;
> +  unsigned n_per_part = -1U;
> +  unsigned file_n = output ? 1 : 2;
> +  do
> +{
> +  unsigned n_fn = 0;
> +  do_header--;
> +
> +  if (do_header)
> + f = headerf;
> +  else if (!output)
> + f = stdout;
> +  else
> + {
> +   sprintf (outputtem, "%s-%d.c", output, file_n++);
> +   f = fopen (outputtem, "w");
> +   if (!f)
> + {
> +   perror ("failed to open output file");
> +   exit(1);
> + }
> +   write_header (f, gimple);
> + }
>/* First split out the transform part of equal leafs.  */
>unsigned rcnt = 0;
>unsigned fcnt = 1;
> @@ -3643,21 +3684,22 @@ decision_tree::gen (FILE *f, bool gimple
>   }
>  
>/* Generate a split out function with the leaf transform code.  */
> +  if (do_header || !output)
>s->fname = xasprintf ("%s_simplify_%u", gimple ? "gimple" : "generic",
>   fcnt++);
>if (gimple)
> - fprintf (f, "\nstatic bool\n"
> + fprintf (f, "\n%sbool\n"
>"%s (code_helper *res_code, 

Re: [RFH] split {generic,gimple}-match.c files

[Richard Biener]

On Wed, 25 Apr 2018, Richard Biener wrote:

> On Wed, 25 Apr 2018, Richard Biener wrote:
> 
> > 
> > The following patch^Whack splits $subject files into three, one
> > for the predicates (due to an implementation detail) and two for
> > the rest - for now into similar LOC size files.
> > 
> > I'd like to get help on the makefile changes to make them less
> > verbose, somehow globbing the -[12p] parts.
> > 
> > Also you can see the split point is manually chosen which means
> > it will bitrot.  Timings for the stage2 compiles on a x86_64
> > box are
> > 
> > gimple-match-p.c   5s
> > generic-match-p.c  3s
> > gimple-match-1.c  85s
> > generic-match-1.c 56s
> > gimple-match-2.c  82s
> > generic-match-2.c 31s
> 
> Original timings as requested:
> 
> gimple-match.c   172s

With -fno-checking this becomes 95s...

Richard.

Re: [RFH] split {generic,gimple}-match.c files

[Richard Biener]

On Wed, 25 Apr 2018, Richard Biener wrote:

> 
> The following patch^Whack splits $subject files into three, one
> for the predicates (due to an implementation detail) and two for
> the rest - for now into similar LOC size files.
> 
> I'd like to get help on the makefile changes to make them less
> verbose, somehow globbing the -[12p] parts.
> 
> Also you can see the split point is manually chosen which means
> it will bitrot.  Timings for the stage2 compiles on a x86_64
> box are
> 
> gimple-match-p.c   5s
> generic-match-p.c  3s
> gimple-match-1.c  85s
> generic-match-1.c 56s
> gimple-match-2.c  82s
> generic-match-2.c 31s

Original timings as requested:

gimple-match.c   172s
generic-match.c  95s

Richard.

Re: [PATCH][i386] PR target/85473, Fix _movdir64b expansion with -mx32

[Uros Bizjak]

On Wed, Apr 25, 2018 at 1:03 PM, Peryt, Sebastian
 wrote:
> Hi,
>
> Patch has been updated and tested. Now I don't see any new regressions.
>
> Changelog stays the same.
>
> Is it ok for trunk?

OK for mainline and gcc-8 backport after a couple of days, the latter
also needs approval from RM.

>> > 2018-04-20  Sebastian Peryt  
>> >
>> > gcc/ChangeLog:
>> >
>> > PR target/85473
>> > * config/i386/i386.c (ix86_expand_builtin): Change memory
>> > operand to XI, op0 extend to Pmode.

... extend op0 to Pmode.

>> > * config/i386/i386.md: Change unspec volatile and operand 1
>> > mode to XI, change operand 0 mode to P

Full stop.

>> >
>> > 2018-04-20  Sebastian Peryt  
>> >
>> > gcc/testsuite/ChangeLog:
>> >
>> > PR target/85473
>> > * gcc.target/i386/pr85473-1.c: New test.
>> > * gcc.target/i386/pr85473-2.c: New test.
>> >
>> > Sebastian
>> >
>

Re: [PATCH 0/2] Require that constraints are used to reference global regs

[Michael Matz]

Hi,

On Tue, 24 Apr 2018, Alexander Monakov wrote:

> On Tue, 24 Apr 2018, Michael Matz wrote:
> > What is lost here (it wasn't explicit before, but is the case and must 
> > continue to work) is that function calls and returns count as needing the 
> > observable value in the specified register (function calls also count as 
> > setters of them).  I think that should be made more explicit.
> 
> It's no different from a normal variable in global scope. If the 
> compiler sees

Yeah, that occured to me as well later :)  Ignore me on that.


Ciao,
Michael.

[wwwdocs] Correct notes about -Wreturn-type change for C++

[Jonathan Wakely]

It's always been ill-formed to say "return;" in a non-void function,
the change in GCC 8 is when control flows of the end of a function.
This corrects the release notes.

Committed to CVS.
Index: htdocs/gcc-8/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/changes.html,v
retrieving revision 1.69
diff -u -r1.69 changes.html
--- htdocs/gcc-8/changes.html	24 Apr 2018 20:36:28 -	1.69
+++ htdocs/gcc-8/changes.html	25 Apr 2018 11:40:26 -
@@ -716,9 +716,10 @@
 
 
   
-  A return statement without an operand in a non-void function
+  Flowing off the end of a non-void function
   is considered unreachable and may be subject to optimization
-  on that basis.
+  on that basis. As a result of this change, -Wreturn-type
+  warnings are enabled by default for C++.
 
 
 Runtime Library (libstdc++)

[RFH] split {generic,gimple}-match.c files

[Richard Biener]

The following patch^Whack splits $subject files into three, one
for the predicates (due to an implementation detail) and two for
the rest - for now into similar LOC size files.

I'd like to get help on the makefile changes to make them less
verbose, somehow globbing the -[12p] parts.

Also you can see the split point is manually chosen which means
it will bitrot.  Timings for the stage2 compiles on a x86_64
box are

gimple-match-p.c   5s
generic-match-p.c  3s
gimple-match-1.c  85s
generic-match-1.c 56s
gimple-match-2.c  82s
generic-match-2.c 31s

the required header files are quite big (and of course everything
needs to be exported without the analysis work becoming too cumbersome),
it's 3342 LOC for gimple-match-head.h and 1556 LOC for 
generic-match-head.h

The machine I tested is quite fast so the 80ish second timings are still
too slow I guess and thus splitting up into four files for gimple and
three files for generic looks better.

Note we lose some inlining/cloning capability in the splitting process
(I see quite a bit of constprop/isra work being done on the generated 
files).  I didn't try to measure the runtime impact though.

The patch still needs quite some TLC, it really is a bit hacky but I'd
like to get feedback on the approach and I didn't want to spend time
on programatically finding optimal split points (so everything is output
in the same semi-random order as before).

Richard.



Index: gcc/genmatch.c
===
--- gcc/genmatch.c  (revision 259638)
+++ gcc/genmatch.c  (working copy)
@@ -1641,7 +1641,7 @@ struct decision_tree
   dt_node *root;
 
   void insert (struct simplify *, unsigned);
-  void gen (FILE *f, bool gimple);
+  void gen (const char *, FILE *, vec &, bool gimple);
   void print (FILE *f = stderr);
 
   decision_tree () { root = new dt_node (dt_node::DT_NODE, NULL); }
@@ -3608,12 +3608,25 @@ sinfo_hashmap_traits::equal_keys (const
   return compare_op (v->s->result, v->s, candidate->s->result, candidate->s);
 }
 
+/* Write the common header for the GIMPLE/GENERIC IL matching routines.  */
+
+static void
+write_header (FILE *f, bool gimple)
+{
+  fprintf (f, "/* Generated automatically by the program `genmatch' from\n");
+  fprintf (f, "   a IL pattern matching and simplification description.  
*/\n");
+
+  /* Include the header instead of writing it awkwardly quoted here.  */
+  fprintf (f, "\n#include \"%s-match-head.c\"\n",
+  gimple ? "gimple" : "generic");
+}
 
 /* Main entry to generate code for matching GIMPLE IL off the decision
tree.  */
 
 void
-decision_tree::gen (FILE *f, bool gimple)
+decision_tree::gen (const char *output, FILE *headerf,
+   vec , bool gimple)
 {
   sinfo_map_t si;
 
@@ -3624,6 +3637,34 @@ decision_tree::gen (FILE *f, bool gimple
   gimple ? "GIMPLE" : "GENERIC", 
   root->num_leafs, root->max_level, root->total_size);
 
+  FILE *f;
+  char *outputtem = NULL;
+  if (output)
+outputtem = XNEWVEC (char, strlen (output) + strlen ("-1.c") + 1);
+
+  unsigned do_header = headerf ? 2 : 1;
+  unsigned n_per_part = -1U;
+  unsigned file_n = output ? 1 : 2;
+  do
+{
+  unsigned n_fn = 0;
+  do_header--;
+
+  if (do_header)
+   f = headerf;
+  else if (!output)
+   f = stdout;
+  else
+   {
+ sprintf (outputtem, "%s-%d.c", output, file_n++);
+ f = fopen (outputtem, "w");
+ if (!f)
+   {
+ perror ("failed to open output file");
+ exit(1);
+   }
+ write_header (f, gimple);
+   }
   /* First split out the transform part of equal leafs.  */
   unsigned rcnt = 0;
   unsigned fcnt = 1;
@@ -3643,21 +3684,22 @@ decision_tree::gen (FILE *f, bool gimple
}
 
   /* Generate a split out function with the leaf transform code.  */
+  if (do_header || !output)
   s->fname = xasprintf ("%s_simplify_%u", gimple ? "gimple" : "generic",
fcnt++);
   if (gimple)
-   fprintf (f, "\nstatic bool\n"
+   fprintf (f, "\n%sbool\n"
 "%s (code_helper *res_code, tree *res_ops,\n"
 " gimple_seq *seq, tree (*valueize)(tree) "
 "ATTRIBUTE_UNUSED,\n"
 " const tree ARG_UNUSED (type), tree 
*ARG_UNUSED "
 "(captures)\n",
-s->fname);
+headerf ? "" : "static ", s->fname);
   else
{
- fprintf (f, "\nstatic tree\n"
+ fprintf (f, "\n%stree\n"
   "%s (location_t ARG_UNUSED (loc), const tree ARG_UNUSED 
(type),\n",
-  (*iter).second->fname);
+  headerf ? "" : "static ", (*iter).second->fname);
  for (unsigned i = 0;
   i < as_a (s->s->s->match)->ops.length (); ++i)
fprintf (f, " tree ARG_UNUSED (op%d),", i);
@@ -3674,7 +3716,12 @@ decision_tree::gen (FILE *f, bool 

Re: [nvptx, libgomp, testsuite, PR85519] Reduce recursion depth in declare_target-{1,2}.f90

[Jakub Jelinek]

On Wed, Apr 25, 2018 at 12:58:47PM +0200, Tom de Vries wrote:
> Concluding, these tests run out thread stack on Nvidia Titan V because the
> recursive functions have a larger frame size than we've seen for the Nvidia
> architecture flavours that we've tested before.
> 
> The patch fixes this by reducing the recursion depth.
> 
> OK for stage4 trunk?

Ok for trunk (i.e. 9.x) and 8.2 after 8.1 is released.

> [nvptx, libgomp, testsuite] Reduce recursion depth in declare_target-{1,2}.f90
> 
> 2018-04-25  Tom de Vries  
> 
>   PR target/85519
>   * testsuite/libgomp.fortran/examples-4/declare_target-1.f90: Reduce
>   recursion depth from 25 to 23.
>   * testsuite/libgomp.fortran/examples-4/declare_target-2.f90: Same.

Jakub

RE: [PATCH][i386] PR target/85473, Fix _movdir64b expansion with -mx32

[Peryt, Sebastian]

Hi,

Patch has been updated and tested. Now I don't see any new regressions.

Changelog stays the same.

Is it ok for trunk?

Thanks,
Sebastian


> -Original Message-
> From: Peryt, Sebastian
> Sent: Saturday, April 21, 2018 5:36 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Uros Bizjak ; Kirill Yukhin ;
> H.J. Lu ; Peryt, Sebastian 
> Subject: RE: [PATCH][i386] PR target/85473, Fix _movdir64b expansion with -
> mx32
> 
> Hi,
> 
> I just realized this patch introduces some new regressions.
> 
> Sorry, I must have mixed up something in testing. Will update this patch 
> shortly.
> 
> Sebastian
> 
> > -Original Message-
> > From: Peryt, Sebastian
> > Sent: Friday, April 20, 2018 6:38 PM
> > To: gcc-patches@gcc.gnu.org
> > Cc: Uros Bizjak ; Kirill Yukhin
> > ; H.J. Lu ; Peryt,
> > Sebastian 
> > Subject: [PATCH][i386] PR target/85473, Fix _movdir64b expansion with
> > -mx32
> >
> > Hi,
> >
> > This fixes PR85473 by fixing _movdir64b expansion for -mx32.
> >
> > Ok for trunk?
> >
> > 2018-04-20  Sebastian Peryt  
> >
> > gcc/ChangeLog:
> >
> > PR target/85473
> > * config/i386/i386.c (ix86_expand_builtin): Change memory
> > operand to XI, op0 extend to Pmode.
> > * config/i386/i386.md: Change unspec volatile and operand 1
> > mode to XI, change operand 0 mode to P
> >
> > 2018-04-20  Sebastian Peryt  
> >
> > gcc/testsuite/ChangeLog:
> >
> > PR target/85473
> > * gcc.target/i386/pr85473-1.c: New test.
> > * gcc.target/i386/pr85473-2.c: New test.
> >
> > Sebastian
> >



0001-PR85473-fix-v2.patch
Description: 0001-PR85473-fix-v2.patch

[nvptx, libgomp, testsuite, PR85519] Reduce recursion depth in declare_target-{1,2}.f90

[Tom de Vries]

Hi,

when running the libgomp tests with nvptx accelerator on an Nvidia Titan 
V, we run into these failures:

...
FAIL: libgomp.fortran/examples-4/declare_target-1.f90   -O1  execution test
FAIL: libgomp.fortran/examples-4/declare_target-1.f90   -O2  execution test
FAIL: libgomp.fortran/examples-4/declare_target-1.f90   -Os  execution test
FAIL: libgomp.fortran/examples-4/declare_target-2.f90   -O1  execution test
FAIL: libgomp.fortran/examples-4/declare_target-2.f90   -O2  execution test
FAIL: libgomp.fortran/examples-4/declare_target-2.f90   -Os  execution test
...

These tests contain recursive functions, and the failures are due to the 
fact that during execution it runs out of thread stack. The symptom is:

...
libgomp: cuCtxSynchronize error: an illegal memory access was encountered
...
which we can turn into this symptom:
...
libgomp: cuStreamSynchronize error: an illegal instruction was encountered
...
by using GOMP_NVPTX_JIT=-O0, which inserts a valid thread stack check 
after the thread stack decrement at the start of each function.


The thread stack limit defaults to 1024 on all the boards that I've 
checked, including Titan V. The tests have a recursion depth of ~25, so 
when the frame size of the recursive function exceeds ~40, we can be 
sure to run out off thread stack. [ It also may happen at a smaller 
frame size, given that some thread stack space may have already been 
consumed before calling the recursive function. ]


[ The nvptx libgomp port uses a 128k per-warp stack in the global 
memory, avoiding the use of the .local directive in offloading 
functions, which would be mapped onto thread stack. But doing so does 
not eliminate the thread stack usage. F.i., device routine parameters 
can be stored on thread stack. ]



Concluding, these tests run out thread stack on Nvidia Titan V because 
the recursive functions have a larger frame size than we've seen for the 
Nvidia architecture flavours that we've tested before.


The patch fixes this by reducing the recursion depth.

OK for stage4 trunk?

Thanks,
- Tom
[nvptx, libgomp, testsuite] Reduce recursion depth in declare_target-{1,2}.f90

2018-04-25  Tom de Vries  

	PR target/85519
	* testsuite/libgomp.fortran/examples-4/declare_target-1.f90: Reduce
	recursion depth from 25 to 23.
	* testsuite/libgomp.fortran/examples-4/declare_target-2.f90: Same.

---
 libgomp/testsuite/libgomp.fortran/examples-4/declare_target-1.f90 | 4 +++-
 libgomp/testsuite/libgomp.fortran/examples-4/declare_target-2.f90 | 6 --
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/libgomp/testsuite/libgomp.fortran/examples-4/declare_target-1.f90 b/libgomp/testsuite/libgomp.fortran/examples-4/declare_target-1.f90
index df941ee..51de6b2 100644
--- a/libgomp/testsuite/libgomp.fortran/examples-4/declare_target-1.f90
+++ b/libgomp/testsuite/libgomp.fortran/examples-4/declare_target-1.f90
@@ -27,5 +27,7 @@ end module
 program e_53_1
   use e_53_1_mod, only : fib, fib_wrapper
   if (fib (15) /= fib_wrapper (15)) STOP 1
-  if (fib (25) /= fib_wrapper (25)) STOP 2
+  ! Reduced from 25 to 23, otherwise execution runs out of thread stack on
+  ! Nvidia Titan V.
+  if (fib (23) /= fib_wrapper (23)) STOP 2
 end program
diff --git a/libgomp/testsuite/libgomp.fortran/examples-4/declare_target-2.f90 b/libgomp/testsuite/libgomp.fortran/examples-4/declare_target-2.f90
index 9c31569..76cce01 100644
--- a/libgomp/testsuite/libgomp.fortran/examples-4/declare_target-2.f90
+++ b/libgomp/testsuite/libgomp.fortran/examples-4/declare_target-2.f90
@@ -4,9 +4,11 @@ program e_53_2
   !$omp declare target (fib)
   integer :: x, fib
   !$omp target map(from: x)
-x = fib (25)
+! Reduced from 25 to 23, otherwise execution runs out of thread stack on
+! Nvidia Titan V.
+x = fib (23)
   !$omp end target
-  if (x /= fib (25)) STOP 1
+  if (x /= fib (23)) STOP 1
 end program
 
 integer recursive function fib (n) result (f)

[PATCH] Try to use issetugid before falling back to insecure getenv

[Matija Skala]

---
 libvtv/configure.ac | 3 +++
 libvtv/vtv_utils.cc | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/libvtv/configure.ac b/libvtv/configure.ac
index ba3009ee3fb..878ba02a2e2 100644
--- a/libvtv/configure.ac
+++ b/libvtv/configure.ac
@@ -115,6 +115,9 @@ AC_CHECK_FUNCS([__secure_getenv])
 AC_GNU_SOURCE
 AC_CHECK_FUNCS([secure_getenv])
 
+AC_GNU_SOURCE
+AC_CHECK_FUNCS([issetugid])
+
 AC_CHECK_FUNCS([getexecname __fortify_fail])
 
 # Check for programs.
diff --git a/libvtv/vtv_utils.cc b/libvtv/vtv_utils.cc
index 1e41ced4473..10efee987d4 100644
--- a/libvtv/vtv_utils.cc
+++ b/libvtv/vtv_utils.cc
@@ -46,6 +46,8 @@
 #ifndef HAVE_SECURE_GETENV
 #  ifdef HAVE___SECURE_GETENV
 #define secure_getenv __secure_getenv
+#  elif defined HAVE_ISSETUGID
+#define secure_getenv(name) (issetugid() ? NULL : getenv(name))
 #  else
 #define secure_getenv getenv
 #  endif
-- 
2.16.1

Re: [PATCH] PR gcc/84923 - gcc.dg/attr-weakref-1.c failed on aarch64

[Ramana Radhakrishnan]

On Fri, Apr 13, 2018 at 7:08 AM,   wrote:
> From: Vladimir Mezentsev 
>
> When weakref_targets is not empty a target cannot be removed from weak_decls.
> A small example is below when 'wv12' is removed from the weak list on aarch64:
>   static vtype Wv12 __attribute__((weakref ("wv12")));
>   extern vtype wv12 __attribute__((weak));
>
> Bootstrapped on aarch64-unknown-linux-gnu including (c,c++ and go).
> Tested on aarch64-linux-gnu.
> No regression. The attr-weakref-1.c test passed.


It appears that this patch hasn't been reviewed at all. Just a ping
here and bringing honza on copy as discussed on IRC.

regards
Ramana


>
> ChangeLog:
> 2018-04-12  Vladimir Mezentsev  
>
> PR gcc/84923
> * varasm.c (weak_finish): clean up weak_decls
> ---
>  gcc/varasm.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/gcc/varasm.c b/gcc/varasm.c
> index d24bac4..2a70234 100644
> --- a/gcc/varasm.c
> +++ b/gcc/varasm.c
> @@ -5683,8 +5683,7 @@ weak_finish (void)
>nor multiple .weak directives for the latter.  */
> for (p = _decls; (t2 = *p) ; )
>   {
> -   if (TREE_VALUE (t2) == alias_decl
> -   || target == DECL_ASSEMBLER_NAME (TREE_VALUE (t2)))
> +   if (TREE_VALUE (t2) == alias_decl)
>   *p = TREE_CHAIN (t2);
> else
>   p = _CHAIN (t2);
> --
> 1.8.3.1
>

Re: [Ada] Regenerate gnat_ugn.texi

[Richard Biener]

On Wed, Apr 25, 2018 at 10:52 AM, Eric Botcazou  wrote:
> Pierre-Marie just pointed out that I forgot to regenerate gnat_ugn.texi in my
> fix for PR ada/85007.  Can I put this on the 8 branch too?

Yes.

Richard.

>
> 2018-04-25  Eric Botcazou  
>
> PR ada/85007
> * gnat_ugn.texi: Regenerate.
>
> --
> Eric Botcazou

[Ada] Regenerate gnat_ugn.texi

[Eric Botcazou]

Pierre-Marie just pointed out that I forgot to regenerate gnat_ugn.texi in my 
fix for PR ada/85007.  Can I put this on the 8 branch too?


2018-04-25  Eric Botcazou  

PR ada/85007
* gnat_ugn.texi: Regenerate.

-- 
Eric BotcazouIndex: gnat_ugn.texi
===
--- gnat_ugn.texi	(revision 259515)
+++ gnat_ugn.texi	(working copy)
@@ -3,7 +3,7 @@
 @setfilename gnat_ugn.info
 @documentencoding UTF-8
 @ifinfo
-@*Generated by Sphinx 1.4.6.@*
+@*Generated by Sphinx 1.3.6.@*
 @end ifinfo
 @settitle GNAT User's Guide for Native Platforms
 @defindex ge
@@ -21,7 +21,7 @@
 
 @copying
 @quotation
-GNAT User's Guide for Native Platforms , Dec 15, 2017
+GNAT User's Guide for Native Platforms , April 25, 2018
 
 AdaCore
 
@@ -16770,18 +16770,6 @@ name as the main unit. For example, @cod
 an executable called @code{try}.
 @end table
 
-@geindex -b (gnatlink)
-
-
-@table @asis
-
-@item @code{-b @emph{target}}
-
-Compile your program to run on @code{target}, which is the name of a
-system configuration. You must have a GNAT cross-compiler built if
-@code{target} is not the same as your host system.
-@end table
-
 @geindex -B (gnatlink)
 
 

[PATCH] Bump LTO_major_version on trunk

[Richard Biener]

This bumps the bytecode version.

Committed to trunk.

Richard.

2018-04-25  Richard Biener  

* lto-streamer.h (LTO_major_version): Bump to 8.

Index: gcc/lto-streamer.h
===
--- gcc/lto-streamer.h  (revision 259637)
+++ gcc/lto-streamer.h  (working copy)
@@ -120,7 +120,7 @@ along with GCC; see the file COPYING3.
  String are represented in the table as pairs, a length in ULEB128
  form followed by the data for the string.  */
 
-#define LTO_major_version 7
+#define LTO_major_version 8
 #define LTO_minor_version 0
 
 typedef unsigned char  lto_decl_flags_t;

Re: [PATCH] Update nvptx newlib installation requirements

[Richard Biener]

On Tue, Apr 24, 2018 at 6:00 PM, Cesar Philippidis
 wrote:
> On 04/24/2018 12:10 AM, Richard Biener wrote:
>
>> That's great news!  Note that we usually keep copies of build dependences at
>> ftp://gcc.gnu.org/pub/gcc/infrastructure/ and there's currently no nvptx 
>> newlib
>> variant there.  Maybe you can prepare a tarball that's ready to plug into gcc
>> sources with the nvptx support included?
>
> How do I go about uploading tarball to that ftp server?

Anybody with privileges (like me...) can put it there.

> I could be mistaken, but I think that GCC's build system would need to
> be taught how to build nvptx-tools automatically like newlib. And that's
> likely a stage 1 task. But in the meantime, having tarballs for the
> build dependencies would be nice.

Yes.  Note that dependences that need to be installed are fine as well,
it is after all the usual mode of operation.

>> Otherwise OK.
>>
>> Btw, can you also update the GCC wiki with regarding to this change?
>
> Done. I added a new 'Build Dependencies' section to the nvptx wiki:
>
> https://gcc.gnu.org/wiki/nvptx
>
> Cesar

Re: GCC 6 backports

[Martin Liška]

Hi.

Sending GCC 6 branch backports.
Patches can bootstrap on ppc64le-redhat-linux and survives regression tests.
I'm going to install the patches.

Martin
>From e0d32b1f9e0dd0486e63040e1ab8f5d8e9f0fbd5 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Tue, 10 Apr 2018 07:24:59 +
Subject: [PATCH 1/4] Backport r259265

gcc/lto/ChangeLog:

2018-04-10  Richard Biener  
	Martin Liska  

	PR lto/85248
	* lto-symtab.c (lto_symtab_merge_p): Handle noreturn attribute.

gcc/testsuite/ChangeLog:

2018-04-10  Jakub Jelinek  

	PR lto/85248
	* gcc.dg/lto/pr85248_0.c: New test.
	* gcc.dg/lto/pr85248_1.c: New test.
---
 gcc/lto/lto-symtab.c | 16 +
 gcc/testsuite/gcc.dg/lto/pr85248_0.c | 45 
 gcc/testsuite/gcc.dg/lto/pr85248_1.c |  9 
 3 files changed, 70 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/lto/pr85248_0.c
 create mode 100644 gcc/testsuite/gcc.dg/lto/pr85248_1.c

diff --git a/gcc/lto/lto-symtab.c b/gcc/lto/lto-symtab.c
index 6b3b785b674..b01288d7587 100644
--- a/gcc/lto/lto-symtab.c
+++ b/gcc/lto/lto-symtab.c
@@ -568,6 +568,9 @@ lto_symtab_merge_p (tree prevailing, tree decl)
 	  return false;
 	}
 }
+
+  /* FIXME: after MPX is removed, use flags_from_decl_or_type
+ function instead.  PR lto/85248.  */
   if (DECL_ATTRIBUTES (prevailing) != DECL_ATTRIBUTES (decl))
 {
   tree prev_attr = lookup_attribute ("error", DECL_ATTRIBUTES (prevailing));
@@ -595,6 +598,19 @@ lto_symtab_merge_p (tree prevailing, tree decl)
 		 "warning attribute mismatch\n");
 	  return false;
 	}
+
+  prev_attr = lookup_attribute ("noreturn", DECL_ATTRIBUTES (prevailing));
+  attr = lookup_attribute ("noreturn", DECL_ATTRIBUTES (decl));
+  if ((prev_attr == NULL) != (attr == NULL)
+	  || (prev_attr
+	  && TREE_VALUE (TREE_VALUE (prev_attr))
+		 != TREE_VALUE (TREE_VALUE (attr
+	{
+  if (symtab->dump_file)
+	fprintf (symtab->dump_file, "Not merging decls; "
+		 "noreturn attribute mismatch\n");
+	  return false;
+	}
 }
   return true;
 }
diff --git a/gcc/testsuite/gcc.dg/lto/pr85248_0.c b/gcc/testsuite/gcc.dg/lto/pr85248_0.c
new file mode 100644
index 000..df61ac976a5
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/lto/pr85248_0.c
@@ -0,0 +1,45 @@
+/* PR lto/85248 */
+/* { dg-lto-do run } */
+/* { dg-lto-options { { -flto -O2 } } } */
+
+extern void test_alias (int s, int e) __asm__ (__USER_LABEL_PREFIX__ "test");
+extern void test_noreturn (int s, int e) __asm__ (__USER_LABEL_PREFIX__ "test")
+  __attribute__ ((__noreturn__));
+
+extern inline __attribute__ ((__always_inline__, __gnu_inline__)) void
+test (int s, int e)
+{
+  if (__builtin_constant_p (s) && s != 0)
+test_noreturn (s, e);
+  else
+test_alias (s, e);
+}
+
+int
+foo (void)
+{
+  static volatile int a;
+  return a;
+}
+
+static void
+bar (void)
+{
+  test (0, 1);
+  __builtin_exit (0);
+}
+
+static void
+baz ()
+{
+  test (1, 0);
+}
+
+int
+main ()
+{
+  if (foo ())
+baz ();
+  bar ();
+  __builtin_abort ();
+}
diff --git a/gcc/testsuite/gcc.dg/lto/pr85248_1.c b/gcc/testsuite/gcc.dg/lto/pr85248_1.c
new file mode 100644
index 000..5ce257181fb
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/lto/pr85248_1.c
@@ -0,0 +1,9 @@
+/* { dg-options "-fno-lto" } */
+
+void
+test (int s, int e)
+{
+  asm volatile ("" : "+g" (s), "+g" (e) : : "memory");
+  if (s)
+__builtin_abort ();
+}
-- 
2.16.3

>From 81ee9e20be3804e2c77974d79fd6229e2be355d9 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Tue, 10 Apr 2018 13:52:23 +
Subject: [PATCH 2/4] Backport r259274

gcc/lto/ChangeLog:

2018-04-10  Martin Liska  

	PR lto/85248
	* lto-symtab.c (lto_symtab_merge_p): Do not check for
	TREE_VALUES of error attributes.
---
 gcc/lto/lto-symtab.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/gcc/lto/lto-symtab.c b/gcc/lto/lto-symtab.c
index b01288d7587..32a53b3348f 100644
--- a/gcc/lto/lto-symtab.c
+++ b/gcc/lto/lto-symtab.c
@@ -601,10 +601,7 @@ lto_symtab_merge_p (tree prevailing, tree decl)
 
   prev_attr = lookup_attribute ("noreturn", DECL_ATTRIBUTES (prevailing));
   attr = lookup_attribute ("noreturn", DECL_ATTRIBUTES (decl));
-  if ((prev_attr == NULL) != (attr == NULL)
-	  || (prev_attr
-	  && TREE_VALUE (TREE_VALUE (prev_attr))
-		 != TREE_VALUE (TREE_VALUE (attr
+  if ((prev_attr == NULL) != (attr == NULL))
 	{
   if (symtab->dump_file)
 	fprintf (symtab->dump_file, "Not merging decls; "
-- 
2.16.3

>From eed3101fc80e261a3da029f0633087abcab06bf3 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Tue, 17 Apr 2018 05:41:40 +
Subject: [PATCH 3/4] Backport r259429

gcc/ChangeLog:

2018-04-17  Jan Hubicka  

	PR lto/85405
	* ipa-devirt.c (odr_types_equivalent_p):