Re: [PATCH] PR c++/80544 strip cv-quals from cast results
../../gcc/ada/gcc-interface/utils2.c: In function 'int compare_elmt_bitpos(const void*, const void*)': ../../gcc/ada/gcc-interface/utils2.c:1937:73: error: type qualifiers ignored on cast result type [-Werror=ignored-qualifiers] const constructor_elt * const elmt1 = (const constructor_elt * const) rt1; ^~~ ../../gcc/ada/gcc-interface/utils2.c:1938:73: error: type qualifiers ignored on cast result type [-Werror=ignored-qualifiers] const constructor_elt * const elmt2 = (const constructor_elt * const) rt2; ^~~ Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: C++ PATCH for testsuite failures with -std=c++17
On Tue, May 09, 2017 at 04:37:16PM -0400, Jason Merrill wrote:
> For C++17 aggregate bases, we have started adding base fields for
> empty bases. The code for calculating whether a class is standard
> layout needs to ignore these.
>
> The C++17 mode diagnostic for direct-enum-init1.C was incorrect.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
> commit 9a612cc30d4b3ef905ce45304545d8b99a3cf5b9
> Author: Jason Merrill
> Date: Tue May 9 14:15:38 2017 -0400
>
> * class.c (check_bases): Ignore empty bases.
This should have referenced PR c++/80605 (and is also a 7 regression).
> diff --git a/gcc/cp/class.c b/gcc/cp/class.c
> index fc71766..085dbc3 100644
> --- a/gcc/cp/class.c
> +++ b/gcc/cp/class.c
> @@ -1860,7 +1860,9 @@ check_bases (tree t,
> members */
> for (basefield = TYPE_FIELDS (basetype); basefield;
>basefield = DECL_CHAIN (basefield))
> - if (TREE_CODE (basefield) == FIELD_DECL)
> + if (TREE_CODE (basefield) == FIELD_DECL
> + && DECL_SIZE (basefield)
> + && !integer_zerop (DECL_SIZE (basefield)))
Is that what we really want? I mean, shouldn't we at least also
check that the basefield we want to ignore is DECL_ARTIFICIAL,
or that it doesn't have DECL_NAME or something similar, to avoid
considering user fields with zero size the same?
I believe your change changes e.g.:
struct S { int a[0]; };
struct T : public S { int b[0]; int c; };
bool q = __is_standard_layout (T);
which previously e.g. with -std=gnu++14 emitted q = false, but
now emits q = true.
Jakub
Re: C++ PATCH for testsuite failures with -std=c++17
On Thu, May 25, 2017 at 10:51:56AM +0200, Jakub Jelinek wrote:
> On Tue, May 09, 2017 at 04:37:16PM -0400, Jason Merrill wrote:
> > For C++17 aggregate bases, we have started adding base fields for
> > empty bases. The code for calculating whether a class is standard
> > layout needs to ignore these.
> >
> > The C++17 mode diagnostic for direct-enum-init1.C was incorrect.
> >
> > Tested x86_64-pc-linux-gnu, applying to trunk.
>
> > commit 9a612cc30d4b3ef905ce45304545d8b99a3cf5b9
> > Author: Jason Merrill
> > Date: Tue May 9 14:15:38 2017 -0400
> >
> > * class.c (check_bases): Ignore empty bases.
>
> This should have referenced PR c++/80605 (and is also a 7 regression).
>
> > diff --git a/gcc/cp/class.c b/gcc/cp/class.c
> > index fc71766..085dbc3 100644
> > --- a/gcc/cp/class.c
> > +++ b/gcc/cp/class.c
> > @@ -1860,7 +1860,9 @@ check_bases (tree t,
> >members */
> > for (basefield = TYPE_FIELDS (basetype); basefield;
> > basefield = DECL_CHAIN (basefield))
> > - if (TREE_CODE (basefield) == FIELD_DECL)
> > + if (TREE_CODE (basefield) == FIELD_DECL
> > + && DECL_SIZE (basefield)
> > + && !integer_zerop (DECL_SIZE (basefield)))
>
> Is that what we really want? I mean, shouldn't we at least also
> check that the basefield we want to ignore is DECL_ARTIFICIAL,
> or that it doesn't have DECL_NAME or something similar, to avoid
> considering user fields with zero size the same?
> I believe your change changes e.g.:
> struct S { int a[0]; };
> struct T : public S { int b[0]; int c; };
> bool q = __is_standard_layout (T);
> which previously e.g. with -std=gnu++14 emitted q = false, but
> now emits q = true.
We even have DECL_FIELD_IS_BASE macro, so can't the above be
if (TREE_CODE (basefield) == FIELD_DECL
&& !DECL_FIELD_IS_BASE (basefield))
or
if (TREE_CODE (basefield) == FIELD_DECL
&& (!DECL_FIELD_IS_BASE (basefield)
|| (DECL_SIZE (basefield)
&& !integer_zerop (DECL_SIZE (basefield)
or something similar?
Jakub
[RFC] [PATCH] Introduce configure flag --with-stage1-cflags.
Hello.
After a discussion with Richi, using adding "-O2" to STAGE1 cflags with a recent
enough compiler can significantly speed up bootstrap. Thus I'm suggesting to
introduce --with-stage1-cflags where one can provide such options.
Apart from that, maybe it would be handy to automatically enable "-O2" when
one has a recent compiler? Do we have an example where we detect host compiler
and it's version?
Martin
>From 5c44f79237125ad2bc29fcd1fb06a249c05b277d Mon Sep 17 00:00:00 2001
From: marxin
Date: Thu, 25 May 2017 11:17:29 +0200
Subject: [PATCH] Introduce configure flag --with-stage1-cflags.
ChangeLog:
2017-05-25 Martin Liska
* configure.ac: Introduce configure flag --with-stage1-cflags.
* configure: Regenerate.
---
configure| 40 +++-
configure.ac | 31 +++
2 files changed, 46 insertions(+), 25 deletions(-)
diff --git a/configure b/configure
index 2c2fe644cfa..442f78d9565 100755
--- a/configure
+++ b/configure
@@ -559,7 +559,6 @@ compare_exclusions
host_shared
stage2_werror_flag
stage1_checking
-stage1_cflags
MAINT
MAINTAINER_MODE_FALSE
MAINTAINER_MODE_TRUE
@@ -652,6 +651,7 @@ isllibs
poststage1_ldflags
poststage1_libs
stage1_ldflags
+stage1_cflags
stage1_libs
extra_isl_gmp_configure_flags
extra_mpc_mpfr_configure_flags
@@ -771,6 +771,7 @@ with_gmp
with_gmp_include
with_gmp_lib
with_stage1_libs
+with_stage1_cflags
with_stage1_ldflags
with_boot_libs
with_boot_ldflags
@@ -1542,6 +1543,8 @@ Optional Packages:
--with-gmp-include=PATH specify directory for installed GMP include files
--with-gmp-lib=PATH specify directory for the installed GMP library
--with-stage1-libs=LIBS libraries for stage1
+ --with-stage1-cflags=FLAGS
+ compiler flags for stage1
--with-stage1-ldflags=FLAGS
linker flags for stage1
--with-boot-libs=LIBS libraries for stage2 and later
@@ -5804,6 +5807,29 @@ fi
+# Compiler flags to use for stage1 or when not bootstrapping.
+
+# Check whether --with-stage1-cflags was given.
+if test "${with_stage1_cflags+set}" = set; then :
+ withval=$with_stage1_cflags; if test "$withval" = "no" -o "$withval" = "yes"; then
+ stage1_cflags=
+ else
+ stage1_cflags=$withval
+ fi
+else
+ stage1_cflags="-g"
+ case $build in
+vax-*-*)
+ case ${GCC} in
+ yes) stage1_cflags="-g -Wa,-J" ;;
+ *) stage1_cflags="-g -J" ;;
+ esac ;;
+ esac
+fi
+
+
+
+
# Linker flags to use for stage1 or when not bootstrapping.
# Check whether --with-stage1-ldflags was given.
@@ -14544,18 +14570,6 @@ MAINT=$MAINTAINER_MODE_TRUE
# GCC bootstrap support
# -
-# Stage specific cflags for build.
-stage1_cflags="-g"
-case $build in
- vax-*-*)
-case ${GCC} in
- yes) stage1_cflags="-g -Wa,-J" ;;
- *) stage1_cflags="-g -J" ;;
-esac ;;
-esac
-
-
-
# Enable --enable-checking in stage1 of the compiler.
# Check whether --enable-stage1-checking was given.
if test "${enable_stage1_checking+set}" = set; then :
diff --git a/configure.ac b/configure.ac
index 865dd543fa3..7b7902240c3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1637,6 +1637,25 @@ AC_ARG_WITH(stage1-libs,
[stage1_libs=])
AC_SUBST(stage1_libs)
+# Compiler flags to use for stage1 or when not bootstrapping.
+AC_ARG_WITH(stage1-cflags,
+[AS_HELP_STRING([--with-stage1-cflags=FLAGS], [compiler flags for stage1])],
+[if test "$withval" = "no" -o "$withval" = "yes"; then
+ stage1_cflags=
+ else
+ stage1_cflags=$withval
+ fi],
+[stage1_cflags="-g"
+ case $build in
+vax-*-*)
+ case ${GCC} in
+ yes) stage1_cflags="-g -Wa,-J" ;;
+ *) stage1_cflags="-g -J" ;;
+ esac ;;
+ esac])
+
+AC_SUBST(stage1_cflags)
+
# Linker flags to use for stage1 or when not bootstrapping.
AC_ARG_WITH(stage1-ldflags,
[AS_HELP_STRING([--with-stage1-ldflags=FLAGS], [linker flags for stage1])],
@@ -3421,18 +3440,6 @@ AC_SUBST(MAINT)dnl
# GCC bootstrap support
# -
-# Stage specific cflags for build.
-stage1_cflags="-g"
-case $build in
- vax-*-*)
-case ${GCC} in
- yes) stage1_cflags="-g -Wa,-J" ;;
- *) stage1_cflags="-g -J" ;;
-esac ;;
-esac
-
-AC_SUBST(stage1_cflags)
-
# Enable --enable-checking in stage1 of the compiler.
AC_ARG_ENABLE(stage1-checking,
[AS_HELP_STRING([[--enable-stage1-checking[=all]]],
--
2.12.2
Re: [PATCH, ARM/AArch64] drop aarch32 support for falkor/qdf24xx
On 24/05/17 17:19, Richard Earnshaw (lists) wrote: > On 24/05/17 17:03, Jim Wilson wrote: >> On Wed, May 24, 2017 at 8:17 AM, Richard Earnshaw (lists) >> wrote: >>> On 24/05/17 15:18, Jim Wilson wrote: On Wed, May 24, 2017 at 6:56 AM, Richard Earnshaw (lists) wrote: > OK. does this need to go in the gcc-8 changes file? Falkor hasn't shipped yet. I'm dropping features that only existed in preproduction NDA hardware, so there isn't anything end user visible, and hence I don't think that it needs to be in the release notes. Jim >>> >>> Fair enough, so what about a minimal back-port to GCC-7 that just >>> disables the CPU name for aarch32? >> >> Not sure how to do that. If I remove the arm-cpus.in entry, then 5 >> files get automatically regenerated. That leaves us with a few minor >> inconsistencies in specs handling and multilibs which are harmless but >> we may as well fix anyways. The only part of the patch that is >> optional if the part which moves the qdf24xx_extra_costs array from >> the arm dir to the aarch64 dir. So the minimal patch ends up being >> half the size of the original patch, changing 9 of the original 11 >> files, which isn't very minimal. >> >> Another option might be to just remove the documentation and leave the >> code in, i.e. only apply the doc/invoke.texi patch. That would be a >> small and safe patch. >> >> Jim >> > > Certainly we should remove it from the documentation. That might be the > best idea. > > I don't really regard the size of the changes to the auto-generated code > as being relevant - if we put the generated code directly in the build > directory and treated it like we do the output from gen*.c, then those > changes would never be even noticed. > > R. > Having pondered this over night, I think the lowest risk thing to do, provided it applies cleanly to the gcc-7 branch, is just commit the entire patch on the branch and be done with it. The risk from removing this code is pretty minimal and removing it all is the best way of avoiding things like unexpected compiler warnings breaking the build. If it doesn't apply cleanly, then just drop the documentation. R.
[C++ PATCH] PR c++/80812
Tested on Linux-x64, running full suite on Linux-ppc64. It seems fitting
to put the test into the library tests, we don't have separate tests
on the front-end side for __is_constructible, so I think adding such
would be a separate job.
2017-05-25 Ville Voutilainen
cp/
PR c++/80812
* method.c (constructible_expr): Strip array types before calling
build_value_init.
libstdc++/
PR c++/80812
* testsuite/20_util/is_constructible/80812.cc: New.
diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index 8aa4f3e..aa607d5 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -1188,7 +1188,7 @@ constructible_expr (tree to, tree from)
else
{
if (from == NULL_TREE)
- return build_value_init (to, tf_none);
+ return build_value_init (strip_array_types (to), tf_none);
else if (TREE_CHAIN (from))
return error_mark_node; // too many initializers
from = build_stub_object (TREE_VALUE (from));
diff --git a/libstdc++-v3/testsuite/20_util/is_constructible/80812.cc
b/libstdc++-v3/testsuite/20_util/is_constructible/80812.cc
new file mode 100644
index 000..17af9ae
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/is_constructible/80812.cc
@@ -0,0 +1,29 @@
+// { dg-do compile { target c++11 } }
+// Copyright (C) 2017 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library 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.
+//
+// This library 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 this library; see the file COPYING3. If not see
+//
Re: [PATCH v2 3/N] Transform TDF_{lang,tree,ipa,rtl} to dump_kind enum.
On 05/25/2017 05:35 AM, Martin Sebor wrote: > On 05/12/2017 07:04 AM, Martin Liška wrote: >> Third part removes TDF_* flags mentioned in the subject. These flags are used >> to enable all passes of specific type and Nathan has recently separated these >> by a new pair of macros. I hope moving these to a separate enum will help >> even more. > > Just as an FYI, the addition of the user-defined constructor makes > the class non-trivial and so unsafe to initialize by calling memset > in C++ 11 and later. In C++ 98 that GCC is compiled with, the class > is not a POD and so not safe to realloc (i.e., new objects must be > brought to life by calling a constructor). I noticed this by testing > my latest patch for the new -Wclass-memassign warning but I thought > it might be worth noting here as well. Hi. Thanks for heads up. I'm not sure why the class is no longer POD as one can define constructors (but not copy-ctors) in order to preserve a type to be POD? I'm also interested what is the new warning -Wclass-memassign about? > > + /* Constructor. */ > + dump_file_info (); > + > + /* Constructor. */ > + dump_file_info (const char *_suffix, const char *_swtch, dump_kind _dkind, > + int _num); > + > > Also, making the ctor constexpr and defining it in the .c file will > trigger Clang -Wundefined-inline and makes the ctor unusable in other > sources. AFAICS, there is no constexpr context where the constexpr > ctor would be needed so I'm not sure I understand its purpose. Is > it constexpr to allow the static initialization of dump_files[0]? > (All the other elements of the array are dynamically initialized > by calling the other, non-constexpr ctor so that doesn't seem like > the answer.) Yep, that was Richi's objection to use constexpr and I know it's used just for the first elements of the array. Richi? Martin > > Martin
[PATCH] Introduce 4-stages profiledbootstrap to get a better profile.
Hi.
As I spoke about the PGO with Honza and Richi, current 3-stage is not ideal for
following
2 reasons:
1) stageprofile compiler is train just on libraries that are built during stage2
2) apart from that, as the compiler is also used to build the final compiler,
profile
is being updated during the build. So the stage2 compiler is making different
decisions.
Both problems can be resolved by adding another step in between current stage2
and stage3
where we train stage2 compiler by building compiler with default options.
I'm going to do some measurements.
Ready for trunk?
Martin
>From 0a9c9a7f7d335e5e053ab37c5649371996e95325 Mon Sep 17 00:00:00 2001
From: marxin
Date: Thu, 25 May 2017 11:35:29 +0200
Subject: [PATCH] Introduce 4-stages profiledbootstrap to get a better profile.
gcc/ChangeLog:
2017-05-25 Martin Liska
* doc/install.texi: Document that PGO runs in 4 stages.
ChangeLog:
2017-05-25 Martin Liska
* Makefile.def: Define 4 stages PGO bootstrap.
* Makefile.tpl: Define FLAGS.
* Makefile.in: Regenerate.
---
Makefile.in | 7 +--
Makefile.tpl | 7 +--
gcc/doc/install.texi | 5 +++--
3 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/Makefile.in b/Makefile.in
index b824e0a0ca1..75e5a1a912b 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -522,8 +522,11 @@ STAGE1_CONFIGURE_FLAGS = --disable-intermodule $(STAGE1_CHECKING) \
STAGEprofile_CFLAGS = $(STAGE2_CFLAGS) -fprofile-generate
STAGEprofile_TFLAGS = $(STAGE2_TFLAGS)
-STAGEfeedback_CFLAGS = $(STAGE3_CFLAGS) -fprofile-use
-STAGEfeedback_TFLAGS = $(STAGE3_TFLAGS)
+STAGEtrain_CFLAGS = $(STAGE3_CFLAGS)
+STAGEtrain_TFLAGS = $(STAGE3_TFLAGS)
+
+STAGEfeedback_CFLAGS = $(STAGE4_CFLAGS) -fprofile-use
+STAGEfeedback_TFLAGS = $(STAGE4_TFLAGS)
STAGEautoprofile_CFLAGS = $(STAGE2_CFLAGS) -g
STAGEautoprofile_TFLAGS = $(STAGE2_TFLAGS)
diff --git a/Makefile.tpl b/Makefile.tpl
index d0fa07005be..5fcd7e358d9 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -455,8 +455,11 @@ STAGE1_CONFIGURE_FLAGS = --disable-intermodule $(STAGE1_CHECKING) \
STAGEprofile_CFLAGS = $(STAGE2_CFLAGS) -fprofile-generate
STAGEprofile_TFLAGS = $(STAGE2_TFLAGS)
-STAGEfeedback_CFLAGS = $(STAGE3_CFLAGS) -fprofile-use
-STAGEfeedback_TFLAGS = $(STAGE3_TFLAGS)
+STAGEtrain_CFLAGS = $(STAGE3_CFLAGS)
+STAGEtrain_TFLAGS = $(STAGE3_TFLAGS)
+
+STAGEfeedback_CFLAGS = $(STAGE4_CFLAGS) -fprofile-use
+STAGEfeedback_TFLAGS = $(STAGE4_TFLAGS)
STAGEautoprofile_CFLAGS = $(STAGE2_CFLAGS) -g
STAGEautoprofile_TFLAGS = $(STAGE2_TFLAGS)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index b13fc1f6f42..386771872ba 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -2611,8 +2611,9 @@ bootstrap the compiler with profile feedback, use @code{make profiledbootstrap}.
When @samp{make profiledbootstrap} is run, it will first build a @code{stage1}
compiler. This compiler is used to build a @code{stageprofile} compiler
instrumented to collect execution counts of instruction and branch
-probabilities. Then runtime libraries are compiled with profile collected.
-Finally a @code{stagefeedback} compiler is built using the information collected.
+probabilities. Training run is done by building @code{stagetrain}
+compiler. Finally a @code{stagefeedback} compiler is built
+using the information collected.
Unlike standard bootstrap, several additional restrictions apply. The
compiler used to build @code{stage1} needs to support a 64-bit integral type.
--
2.12.2
[PATCH] Bound partial-inlining-entry-probability param (PR ipa/80663).
Hello.
Having value of parameter partial-inlining-entry-probability bigger than 100
does not
make sense and can be just used to artificially trigger partial inlining.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Martin
>From 4f849447030daa05f64a095d14d56a4df0583573 Mon Sep 17 00:00:00 2001
From: marxin
Date: Wed, 17 May 2017 13:23:54 +0200
Subject: [PATCH] Bound partial-inlining-entry-probability param (PR
ipa/80663).
gcc/ChangeLog:
2017-05-17 Martin Liska
PR ipa/80663
* params.def: Bound partial-inlining-entry-probability param.
gcc/testsuite/ChangeLog:
2017-05-19 Martin Liska
* g++.dg/ipa/pr80212.C: Remove the test as it does not longer
split at the problematic spot.
* gcc.dg/ipa/pr48195.c: Change 101 to 100 as 101 is no longer
a valid value of the param.
---
gcc/params.def | 2 +-
gcc/testsuite/g++.dg/ipa/pr80212.C | 18 --
gcc/testsuite/gcc.dg/ipa/pr48195.c | 2 +-
3 files changed, 2 insertions(+), 20 deletions(-)
delete mode 100644 gcc/testsuite/g++.dg/ipa/pr80212.C
diff --git a/gcc/params.def b/gcc/params.def
index 1b058e49860..6b07518a34b 100644
--- a/gcc/params.def
+++ b/gcc/params.def
@@ -126,7 +126,7 @@ DEFPARAM (PARAM_COMDAT_SHARING_PROBABILITY,
DEFPARAM (PARAM_PARTIAL_INLINING_ENTRY_PROBABILITY,
"partial-inlining-entry-probability",
"Maximum probability of the entry BB of split region (in percent relative to entry BB of the function) to make partial inlining happen.",
- 70, 0, 0)
+ 70, 0, 100)
/* Limit the number of expansions created by the variable expansion
optimization to avoid register pressure. */
diff --git a/gcc/testsuite/g++.dg/ipa/pr80212.C b/gcc/testsuite/g++.dg/ipa/pr80212.C
deleted file mode 100644
index 60d3b613035..000
--- a/gcc/testsuite/g++.dg/ipa/pr80212.C
+++ /dev/null
@@ -1,18 +0,0 @@
-// PR ipa/80212
-// { dg-options "-O2 --param partial-inlining-entry-probability=403796683 -fno-early-inlining" }
-
-struct b
-{
- virtual b *c () const;
-};
-struct d : virtual b
-{
-};
-struct e : d
-{
- e *
- c () const
- {
- }
-};
-main () { e a; }
diff --git a/gcc/testsuite/gcc.dg/ipa/pr48195.c b/gcc/testsuite/gcc.dg/ipa/pr48195.c
index 2e38452d598..25e80bab8f8 100644
--- a/gcc/testsuite/gcc.dg/ipa/pr48195.c
+++ b/gcc/testsuite/gcc.dg/ipa/pr48195.c
@@ -1,5 +1,5 @@
/* { dg-do link } */
-/* { dg-options "-O2 -flto --param partial-inlining-entry-probability=101" } */
+/* { dg-options "-O2 -flto --param partial-inlining-entry-probability=100" } */
/* { dg-require-effective-target lto } */
extern void abort(void);
--
2.12.2
Re: [PATCH] PR c++/80544 strip cv-quals from cast results
On 24/05/17 20:09 -0700, Andrew Pinski wrote: On Wed, May 24, 2017 at 8:07 PM, Andrew Pinski wrote: This change caused a bootstrap failure on aarch64-linux-gnu and x86_64-linux-gnu: In file included from ../../gcc/gcc/system.h:691:0, from ../../gcc/gcc/read-rtl.c:31: ../../gcc/gcc/read-rtl.c: In member function ‘const char* md_reader::apply_iterator_to_string(const char*)’: ../../gcc/gcc/../include/libiberty.h:722:38: error: type qualifiers ignored on cast result type [-Werror=ignored-qualifiers] # define alloca(x) __builtin_alloca(x) ^ ../../gcc/gcc/../include/libiberty.h:727:47: note: in expansion of macro ‘alloca’ char *const libiberty_nptr = (char *const) alloca (libiberty_len); \ ^~ ../../gcc/gcc/read-rtl.c:380:21: note: in expansion of macro ‘ASTRDUP’ base = p = copy = ASTRDUP (string); ^~~ I know you did not touch libiberty.h but that is emitting an error. Did you test your patch with a full bootstrap? I thought that was recorded as being required now for C++ patches; I know a few years back when the GCC was not compiling as C++, it was not required. Oh it looks like it was already fixed by revision 248442. Just my build automated build was not done for that timeframe. I thought I did, but a --disable-bootstrap slipped in there, copy&pasted from another build, sorry.
[PATCH] Fix multi-versioning issues (PR ipa/80732).
Hello.
Following patch tries to resolve following 2 issues:
a) When one takes address of a function that uses target_clones attribute,
default implementation is always returned.
b) Using dlsym("foo") should work and thus the resolver function should
use the default name. Because of that, default implementation must be
renamed.
Unfortunately, we currently do not support redirection of ipa_refs, thus
walk_tree is needed to resolve that. Hopefully there should not be any
different IPA_REF that needs to be handled.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Martin
>From 198c8464978c21cd68d4743de5648ecfefd2e09c Mon Sep 17 00:00:00 2001
From: marxin
Date: Wed, 17 May 2017 15:56:22 +0200
Subject: [PATCH] Fix multi-versioning issues (PR ipa/80732).
gcc/ChangeLog:
2017-05-19 Martin Liska
PR ipa/80732
* attribs.c (make_dispatcher_decl): Do not append '.ifunc'
to dispatcher function name.
* multiple_target.c (replace_function_decl): New function.
(create_dispatcher_calls): Redirect both edges and references.
gcc/testsuite/ChangeLog:
2017-05-19 Martin Liska
PR ipa/80732
* gcc.target/i386/mvc5.c: Scan indirect_function.
* gcc.target/i386/mvc7.c: Likewise.
* gcc.target/i386/pr80732.c: New test.
---
gcc/attribs.c | 6 +-
gcc/multiple_target.c | 105 ++--
gcc/testsuite/gcc.target/i386/mvc5.c| 2 +-
gcc/testsuite/gcc.target/i386/mvc7.c| 2 +-
gcc/testsuite/gcc.target/i386/pr80732.c | 85 ++
5 files changed, 161 insertions(+), 39 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/i386/pr80732.c
diff --git a/gcc/attribs.c b/gcc/attribs.c
index 4ba0eab8899..5eb19e82795 100644
--- a/gcc/attribs.c
+++ b/gcc/attribs.c
@@ -888,12 +888,8 @@ make_dispatcher_decl (const tree decl)
tree func_decl;
char *func_name;
tree fn_type, func_type;
- bool is_uniq = false;
- if (TREE_PUBLIC (decl) == 0)
-is_uniq = true;
-
- func_name = make_unique_name (decl, "ifunc", is_uniq);
+ func_name = xstrdup (IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl)));
fn_type = TREE_TYPE (decl);
func_type = build_function_type (TREE_TYPE (fn_type),
diff --git a/gcc/multiple_target.c b/gcc/multiple_target.c
index 2ee6a9591ba..fba2636ba16 100644
--- a/gcc/multiple_target.c
+++ b/gcc/multiple_target.c
@@ -34,6 +34,27 @@ along with GCC; see the file COPYING3. If not see
#include "target.h"
#include "attribs.h"
#include "pretty-print.h"
+#include "gimple-iterator.h"
+#include "gimple-walk.h"
+
+/* Walker callback that replaces all FUNCTION_DECL of a function that's
+ going to be versioned. */
+
+static tree
+replace_function_decl (tree *op, int *walk_subtrees, void *data)
+{
+ struct walk_stmt_info *wi = (struct walk_stmt_info *) data;
+ cgraph_function_version_info *info = (cgraph_function_version_info *)wi->info;
+
+ if (TREE_CODE (*op) == FUNCTION_DECL
+ && info->this_node->decl == *op)
+{
+ *op = info->dispatcher_resolver;
+ *walk_subtrees = 0;
+}
+
+ return NULL;
+}
/* If the call in NODE has multiple target attribute with multiple fields,
replace it with dispatcher call and create dispatcher (once). */
@@ -41,51 +62,48 @@ along with GCC; see the file COPYING3. If not see
static void
create_dispatcher_calls (struct cgraph_node *node)
{
- cgraph_edge *e;
- cgraph_edge *e_next = NULL;
+ ipa_ref *ref;
+
+ if (!DECL_FUNCTION_VERSIONED (node->decl))
+return;
+
+ auto_vec edges_to_redirect;
+ auto_vec references_to_redirect;
+
+ for (unsigned i = 0; node->iterate_referring (i, ref); i++)
+references_to_redirect.safe_push (ref);
/* We need to remember NEXT_CALLER as it could be modified in the loop. */
- for (e = node->callers; e ;e = (e == NULL) ? e_next : e->next_caller)
-{
- tree resolver_decl;
- tree idecl;
- tree decl;
- gimple *call = e->call_stmt;
- struct cgraph_node *inode;
-
- /* Checking if call of function is call of versioned function.
- Versioned function are not inlined, so there is no need to
- check for inline. */
- if (!call
- || !(decl = gimple_call_fndecl (call))
- || !DECL_FUNCTION_VERSIONED (decl))
- continue;
+ for (cgraph_edge *e = node->callers; e ; e = e->next_caller)
+edges_to_redirect.safe_push (e);
+ if (!edges_to_redirect.is_empty () || !references_to_redirect.is_empty ())
+{
if (!targetm.has_ifunc_p ())
{
- error_at (gimple_location (call),
+ error_at (DECL_SOURCE_LOCATION (node->decl),
"the call requires ifunc, which is not"
" supported by this target");
- break;
+ return;
}
else if (!targetm.get_function_versions_dispatcher)
{
- error_at (gimple_location (call),
+ error_at (DECL_SOURCE_LOCATION (node->decl),
"target does not support function version dispatcher");
- break;
+ return;
}
- e_next = e->next_caller;
- i
Re: [PATCH] PR c++/80544 strip cv-quals from cast results
On 25/05/17 10:05 +0200, Andreas Schwab wrote:
../../gcc/ada/gcc-interface/utils2.c: In function 'int
compare_elmt_bitpos(const void*, const void*)':
../../gcc/ada/gcc-interface/utils2.c:1937:73: error: type qualifiers ignored on
cast result type [-Werror=ignored-qualifiers]
const constructor_elt * const elmt1 = (const constructor_elt * const) rt1;
^~~
../../gcc/ada/gcc-interface/utils2.c:1938:73: error: type qualifiers ignored on
cast result type [-Werror=ignored-qualifiers]
const constructor_elt * const elmt2 = (const constructor_elt * const) rt2;
I'm testing this obvious fix.
diff --git a/gcc/ada/gcc-interface/utils2.c b/gcc/ada/gcc-interface/utils2.c
index fc6f1b8..cd37791 100644
--- a/gcc/ada/gcc-interface/utils2.c
+++ b/gcc/ada/gcc-interface/utils2.c
@@ -1934,8 +1934,8 @@ build_call_raise_range (int msg, Node_Id gnat_node, char kind,
static int
compare_elmt_bitpos (const PTR rt1, const PTR rt2)
{
- const constructor_elt * const elmt1 = (const constructor_elt * const) rt1;
- const constructor_elt * const elmt2 = (const constructor_elt * const) rt2;
+ const constructor_elt * const elmt1 = (const constructor_elt *) rt1;
+ const constructor_elt * const elmt2 = (const constructor_elt *) rt2;
const_tree const field1 = elmt1->index;
const_tree const field2 = elmt2->index;
const int ret
Re: [libibery PATCH] Fix bootstrap
On 05/25/2017 01:29 AM, Richard Biener wrote: On May 25, 2017 3:22:18 AM GMT+02:00, Nathan Sidwell wrote: On 05/24/2017 09:13 PM, Nathan Sidwell wrote: On 05/24/2017 08:56 PM, Nathan Sidwell wrote: On 05/24/2017 08:34 PM, Nathan Sidwell wrote: We now warn on casts to T const. Applied as obvious to fix bootstrap. And this fixes c-common.c And fix auto-profile.c and lto-streamer-out.c, sigh What's the reason to warn here?! It's a new warning about trying to cast to a const T because the const is ignored. It might be better if the warning only triggered on trying to cast 'T' to 'const T' and not trigger casting 'U' to 'const T'? I dunno. nathan -- Nathan Sidwell
Re: [PATCH v2 3/N] Transform TDF_{lang,tree,ipa,rtl} to dump_kind enum.
On 05/25/2017 05:52 AM, Martin Liška wrote: On 05/25/2017 05:35 AM, Martin Sebor wrote: On 05/12/2017 07:04 AM, Martin Liška wrote: Third part removes TDF_* flags mentioned in the subject. These flags are used to enable all passes of specific type and Nathan has recently separated these by a new pair of macros. I hope moving these to a separate enum will help even more. Just as an FYI, the addition of the user-defined constructor makes the class non-trivial and so unsafe to initialize by calling memset in C++ 11 and later. In C++ 98 that GCC is compiled with, the class is not a POD and so not safe to realloc (i.e., new objects must be brought to life by calling a constructor). I noticed this by testing my latest patch for the new -Wclass-memassign warning but I thought it might be worth noting here as well. Hi. Thanks for heads up. I'm not sure why the class is no longer POD as one can define constructors (but not copy-ctors) in order to preserve a type to be POD? As Martin S says, it's a change from C98 to C11. 98 disallowed any ctor. nathan -- Nathan Sidwell
Fwd: [patch, libfortran] AMD-specific versions of library matmul
Hi, patch is at https://gcc.gnu.org/ml/fortran/2017-05/msg00133.html (didn't to through to gcc-patches due to size limitations). Regards Thomas Weitergeleitete Nachricht Betreff: [patch, libfortran] AMD-specific versions of library matmul Datum: Thu, 25 May 2017 12:45:46 +0200 Von: Thomas Koenig An: fort...@gcc.gnu.org , gcc-patches Hello world, the attached patch speeds up the library version of matmul for AMD chips by selecting AVX128 instructions and, depending on which instructions are supported, either FMA3 (aka FMA) or FMA4. Jerry tested this on his AMD systems, and found a speedup vs. the current code of around 10%. I have been unable to test this on a Ryzen system (the new compile farm machines won't accept my login yet). From the benchmarks I have read, this method should also work fairly well on a Ryzen. So, OK for trunk? Regards Thomas 2017-05-25 Thomas Koenig PR libfortran/78379 * Makefile.am: Add generated/matmulavx128_*.c files. Handle them for compiling and setting the right flags. * acinclude.m4: Add tests for FMA3, FMA4 and AVX128. * configure.ac: Call them. * Makefile.in: Regenerated. * config.h.in: Regenerated. * configure: Regenerated. * m4/matmul.m4: Handle AMD chips by calling 128-bit AVX versions which use FMA3 or FMA4. * m4/matmulavx128.m4: New file. * generated/matmul_c10.c: Regenerated. * generated/matmul_c16.c: Regenerated. * generated/matmul_c4.c: Regenerated. * generated/matmul_c8.c: Regenerated. * generated/matmul_i1.c: Regenerated. * generated/matmul_i16.c: Regenerated. * generated/matmul_i2.c: Regenerated. * generated/matmul_i4.c: Regenerated. * generated/matmul_i8.c: Regenerated. * generated/matmul_r10.c: Regenerated. * generated/matmul_r16.c: Regenerated. * generated/matmul_r4.c: Regenerated. * generated/matmul_r8.c: Regenerated. * generated/matmulavx128_c10.c: New file. * generated/matmulavx128_c16.c: New file. * generated/matmulavx128_c4.c: New file. * generated/matmulavx128_c8.c: New file. * generated/matmulavx128_i1.c: New file. * generated/matmulavx128_i16.c: New file. * generated/matmulavx128_i2.c: New file. * generated/matmulavx128_i4.c: New file. * generated/matmulavx128_i8.c: New file. * generated/matmulavx128_r10.c: New file. * generated/matmulavx128_r16.c: New file. * generated/matmulavx128_r4.c: New file. * generated/matmulavx128_r8.c: New file.
Re: [libibery PATCH] Fix bootstrap
On 25/05/17 06:54 -0400, Nathan Sidwell wrote: On 05/25/2017 01:29 AM, Richard Biener wrote: On May 25, 2017 3:22:18 AM GMT+02:00, Nathan Sidwell wrote: On 05/24/2017 09:13 PM, Nathan Sidwell wrote: On 05/24/2017 08:56 PM, Nathan Sidwell wrote: On 05/24/2017 08:34 PM, Nathan Sidwell wrote: We now warn on casts to T const. Applied as obvious to fix bootstrap. And this fixes c-common.c And fix auto-profile.c and lto-streamer-out.c, sigh What's the reason to warn here?! It's a new warning about trying to cast to a const T because the const is ignored. It might be better if the warning only triggered on trying to cast 'T' to 'const T' and not trigger casting 'U' to 'const T'? I dunno. Maybe, although the language is clear that casting to (const T) means exactly the same as casting to (T) when T is a scalar type. What benefit is there to saying (const T) if the compiler ignores the const? (which the standard says it should, and I implemented in r248432).
Re: [libibery PATCH] Fix bootstrap
On 25/05/17 12:19 +0100, Jonathan Wakely wrote: On 25/05/17 06:54 -0400, Nathan Sidwell wrote: On 05/25/2017 01:29 AM, Richard Biener wrote: On May 25, 2017 3:22:18 AM GMT+02:00, Nathan Sidwell wrote: On 05/24/2017 09:13 PM, Nathan Sidwell wrote: On 05/24/2017 08:56 PM, Nathan Sidwell wrote: On 05/24/2017 08:34 PM, Nathan Sidwell wrote: We now warn on casts to T const. Applied as obvious to fix bootstrap. And this fixes c-common.c And fix auto-profile.c and lto-streamer-out.c, sigh What's the reason to warn here?! It's a new warning about trying to cast to a const T because the const is ignored. It might be better if the warning only triggered on trying to cast 'T' to 'const T' and not trigger casting 'U' to 'const T'? I dunno. Maybe, although the language is clear that casting to (const T) means exactly the same as casting to (T) when T is a scalar type. What benefit is there to saying (const T) if the compiler ignores the const? (which the standard says it should, and I implemented in r248432). I don't mind removing the warning again if preferred. I thought it was useful (as we already warn for ignored const in return types). All I really care about is that the compiler ignores the const, if it does that without warning that's OK.
Re: [PATCH] Introduce 4-stages profiledbootstrap to get a better profile.
On 2017.05.25 at 11:55 +0200, Martin Liška wrote: > Hi. > > As I spoke about the PGO with Honza and Richi, current 3-stage is not ideal > for following > 2 reasons: > > 1) stageprofile compiler is train just on libraries that are built during > stage2 > 2) apart from that, as the compiler is also used to build the final compiler, > profile > is being updated during the build. So the stage2 compiler is making different > decisions. > > Both problems can be resolved by adding another step in between current > stage2 and stage3 > where we train stage2 compiler by building compiler with default options. > > I'm going to do some measurements. I did some measurements on gcc67 (trunk with --enable-checking=release). The apparent speedup is in the noise. Without your patch: Performance counter stats for 'g++ -w -Ofast tramp3d-v4.cpp' (10 runs): 15749.058451 task-clock (msec) #0.997 CPUs utilized ( +- 0.13% ) 1,352 context-switches #0.086 K/sec ( +- 0.16% ) 7 cpu-migrations#0.000 K/sec ( +- 5.73% ) 269,142 page-faults #0.017 M/sec ( +- 0.01% ) 60,676,581,181 cycles#3.853 GHz ( +- 0.09% ) (83.35%) 13,401,784,189 stalled-cycles-frontend # 22.09% frontend cycles idle ( +- 0.20% ) (83.33%) 12,926,843,370 stalled-cycles-backend# 21.30% backend cycles idle ( +- 0.04% ) (83.31%) 73,074,099,356 instructions #1.20 insn per cycle #0.18 stalled cycles per insn ( +- 0.02% ) (83.34%) 16,607,220,814 branches # 1054.490 M/sec ( +- 0.03% ) (83.36%) 616,673,310 branch-misses #3.71% of all branches ( +- 0.08% ) (83.36%) 15.803602619 seconds time elapsed ( +- 0.14% ) With your patch: Performance counter stats for 'g++ -w -Ofast tramp3d-v4.cpp' (10 runs): 15735.220610 task-clock (msec) #0.997 CPUs utilized ( +- 0.11% ) 1,354 context-switches #0.086 K/sec ( +- 0.22% ) 6 cpu-migrations#0.000 K/sec ( +- 6.67% ) 269,164 page-faults #0.017 M/sec ( +- 0.01% ) 60,723,862,242 cycles#3.859 GHz ( +- 0.08% ) (83.35%) 13,382,554,421 stalled-cycles-frontend # 22.04% frontend cycles idle ( +- 0.14% ) (83.31%) 12,912,171,664 stalled-cycles-backend# 21.26% backend cycles idle ( +- 0.03% ) (83.34%) 73,109,081,227 instructions #1.20 insn per cycle #0.18 stalled cycles per insn ( +- 0.03% ) (83.34%) 16,590,421,798 branches # 1054.349 M/sec ( +- 0.02% ) (83.35%) 616,669,135 branch-misses #3.72% of all branches ( +- 0.08% ) (83.36%) 15.788772466 seconds time elapsed ( +- 0.12% ) -- Markus
Re: [libibery PATCH] Fix bootstrap
On 05/25/2017 07:21 AM, Jonathan Wakely wrote: I don't mind removing the warning again if preferred. I thought it was useful (as we already warn for ignored const in return types). Oh yeah, I recall noticing we did that (and noting we didn't warn elsewhere). This new warning seems consistent. I say leave it in unless the grumbling gets too much for you :) nathan -- Nathan Sidwell
Re: [libibery PATCH] Fix bootstrap
On May 25, 2017 1:38:36 PM GMT+02:00, Nathan Sidwell wrote: >On 05/25/2017 07:21 AM, Jonathan Wakely wrote: > >> I don't mind removing the warning again if preferred. I thought it >was >> useful (as we already warn for ignored const in return types). > >Oh yeah, I recall noticing we did that (and noting we didn't warn >elsewhere). This new warning seems consistent. > >I say leave it in unless the grumbling gets too much for you :) I wonder if we can somehow default to -Wno-error=xyz for such kind of 'style' warnings... Adding const can't possibly break anything or result in wrong expectations, can it? Richard. >nathan
Re: [libibery PATCH] Fix bootstrap
On 25/05/17 14:35 +0200, Richard Biener wrote: On May 25, 2017 1:38:36 PM GMT+02:00, Nathan Sidwell wrote: On 05/25/2017 07:21 AM, Jonathan Wakely wrote: I don't mind removing the warning again if preferred. I thought it was useful (as we already warn for ignored const in return types). Oh yeah, I recall noticing we did that (and noting we didn't warn elsewhere). This new warning seems consistent. I say leave it in unless the grumbling gets too much for you :) I wonder if we can somehow default to -Wno-error=xyz for such kind of 'style' warnings... Adding const can't possibly break anything or result in wrong expectations, can it? Now that G++ correctly ignores the const it can't change (or break) anything to add const in the cast. Before I fixed PR 80544, the presence/absence of the const affected the generated code and could result in e.g. different overloaded functions being called (in some fairly obscure cases). The original report I got was http://ideone.com/JSFEZ3 and GCC was giving different behaviour to all other C++ compilers (which ignored the const and so failed the static assertion). The warning is just saying "hey, you know what you wrote is going to be ignored, right?" That's a bit like "statement has no effect" warnings, although those warnings are usually because you mistyped something and so find real bugs.
[C++ PATCH] Reimplement ADL
This patch reimplements ADL.
I replace the existing adl_lookup object with a new name_lookup object,
and move all the workers into it as member fns.
In terms of implementation, ADL requires us to look in a bunch of
places, and we obviously want to look in each place only once. The
current implementation uses a vector, which it scans to see if we've met
the class or namespace before. Not even a hash table!
Anyway, this implementation introduces LOOKUP_SEEN_P and LOOKUP_FOUND_P
to directly mark the DECL node. Hence determination is now O(1) rather
than O(N^2). We still have a vector to recall which decls we need to
unmark at the end of the lookup. We need two markers on a class,
because depending on how we found it we may need to search additional
things about it. (These two maker bits will be used in later changes too.)
One quirk is that ADL can be recursive. ADL can cause template
instantiation, which can in turn cause a different ADL to happen. The
new testcase is an example of this. So, we need to detect this and
undo/redo the outer DECL marking during the inner ADL. Thus
implementing a simple chain of ADLs and using their record of which
decls got marked to undo/redo. The fiddly bit there is recording
whether LOOKUP_FOUND_P was set or not (LOOKUP_SEEN_P will be). To
record that I simply push those DECLS with lookup_found_p set onto the
stack. They'll thus appear twice, and we can infer from the second
sighting that it had FOUND_P set (and pop the stack). The recursion is
a rare event, so we optimize the non-recursive case.
I use a static vec for the scopes of outermost lookup object. That'll
avoid malloc/free for every lookup in the usual case. Inner lookups get
their own stack (but as mentioned are rare).
I still keep the old code's determination of whether a found fn was in
the original lookup or not. That will go away soon. As will the
iteration over inline namespaces.
nathan
--
Nathan Sidwell
2017-05-25 Nathan Sidwell
gcc/cp/
* cp-tree.h (LOOKUP_SEEN_P, LOOKUP_FOUND_P): New.
* name-lookup.h (lookup_arg_dependent): Return plain tree.
* name-lookup.c (arg_lookup, arg_assoc, arg_assoc_args,
arg_assoc_args_vec, arg_assoc_type, add_function,
arg_assoc_namespace, arg_assoc_class_only, arg_assoc_bases,
arg_assoc_class, arg_assoc_template_arg, arg_assoc,
lookup_arg_dependent_1): Delete.
(name_lookup): New lookup object.
(name_lookup::preserve_state, name_lookup::restore_state,
name_lookup::mark_seen, name_lookup::find_and_mark,
name_lookup::add_fns, name_lookup::adl_namespace_only,
name_lookup::adl_namespace, name_lookup::adl_class_only,
name_lookup::adl_bases, name_lookup::adl_class,
name_lookup::adl_expr, name_lookup::adl_type,
name_lookup::adl_template_arg, name_lookup::search_adl): New.
(lookup_arg_dependent): Return a plain tree. Adjust.
(is_associated_namespace): Move later.
gcc/cp/
* g++.dg/lookup/koenig14.C: New.
Index: cp/cp-tree.h
===
--- cp/cp-tree.h (revision 248452)
+++ cp/cp-tree.h (working copy)
@@ -395,6 +395,7 @@ extern GTY(()) tree cp_global_trees[CPTI
DECL_TINFO_P (in VAR_DECL)
FUNCTION_REF_QUALIFIED (in FUNCTION_TYPE, METHOD_TYPE)
OVL_LOOKUP_P (in OVERLOAD)
+ LOOKUP_FOUND_P (in RECORD_TYPE, UNION_TYPE, NAMESPACE_DECL)
5: C_IS_RESERVED_WORD (in IDENTIFIER_NODE)
DECL_VTABLE_OR_VTT_P (in VAR_DECL)
FUNCTION_RVALUE_QUALIFIED (in FUNCTION_TYPE, METHOD_TYPE)
@@ -648,10 +649,17 @@ typedef struct ptrmem_cst * ptrmem_cst_t
&& MAIN_NAME_P (DECL_NAME (NODE)) \
&& flag_hosted)
-/* The overloaded FUNCTION_DECL. */
+/* Lookup walker marking. */
+#define LOOKUP_SEEN_P(NODE) TREE_VISITED(NODE)
+#define LOOKUP_FOUND_P(NODE) \
+ TREE_LANG_FLAG_4 (TREE_CHECK3(NODE,RECORD_TYPE,UNION_TYPE,NAMESPACE_DECL))
+
+/* These two accessors should only be used by OVL manipulators.
+ Other users should use iterators and convenience functions. */
#define OVL_FUNCTION(NODE) \
(((struct tree_overload*)OVERLOAD_CHECK (NODE))->function)
#define OVL_CHAIN(NODE) TREE_CHAIN (NODE)
+
/* Polymorphic access to FUNCTION and CHAIN. */
#define OVL_CURRENT(NODE) \
((TREE_CODE (NODE) == OVERLOAD) ? OVL_FUNCTION (NODE) : (NODE))
Index: cp/name-lookup.c
===
--- cp/name-lookup.c (revision 248452)
+++ cp/name-lookup.c (working copy)
@@ -160,208 +160,274 @@ find_local_binding (cp_binding_level *b,
return NULL;
}
-/* [basic.lookup.koenig] */
-/* A nonzero return value in the functions below indicates an error. */
-
-struct arg_lookup
+struct name_lookup
{
- tree name;
- vec *args;
- vec *namespaces;
- vec *classes;
- tree functions;
+public:
+ tree name; /* The identifier being looked for. */
+ tree value; /* A (possibly ambiguous) set of things found. */
+ tree type; /* A type that has been found. */
+ vec *scopes;
+ name_lookup *previou
[PATCH, GCC/ARM/gcc-7-branch] Backport PR71607
This patch tackles the issue reported in PR71607. This patch takes a different
approach for disabling the creation of literal pools. Instead of disabling the
patterns that would normally transform the rtl into actual literal pools, it
disables the creation of this literal pool rtl by making the target hook
TARGET_CANNOT_FORCE_CONST_MEM return true if arm_disable_literal_pool is true.
I added patterns to split floating point constants for both SF and DFmode. A
pattern to handle the addressing of label_refs had to be included as well since
all "memory_operand" patterns are disabled when TARGET_CANNOT_FORCE_CONST_MEM
returns true. Also the pattern for splitting 32-bit immediates had to be
changed, it was not accepting unsigned 32-bit unsigned integers with the MSB
set. I believe const_int_operand expects the mode of the operand to be set to
VOIDmode and not SImode. I have only changed it in the patterns that were
affecting this code, though I suggest looking into changing it in the rest of
the ARM backend.
Additionally, the use of thread-local storage is disabled if literal pools are
disabled, as there are no relocations for TLS variables and incorrect code is
generated as a result. The patch now emits a diagnostic in TLS-enabled
toolchains if a TLS symbol is found when -mpure-code or -mslow-flash-data are
enabled.
2017-05-25 Prakhar Bahuguna
Backport from mainline
2017-05-05 Andre Vieira
Prakhar Bahuguna
gcc/
PR target/71607
* config/arm/arm.md (use_literal_pool): Remove.
(64-bit immediate split): No longer takes cost into consideration
if arm_disable_literal_pool is enabled.
* config/arm/arm.c (arm_tls_referenced_p): Add diagnostic if TLS is
used when arm_disable_literal_pool is enabled.
(arm_max_const_double_inline_cost): Remove use of
arm_disable_literal_pool.
(push_minipool_fix): Add assert.
(arm_reorg): Add return if arm_disable_literal_pool is enabled.
* config/arm/vfp.md (no_literal_pool_df_immediate): New.
(no_literal_pool_sf_immediate): New.
2017-05-05 Andre Vieira
Thomas Preud'homme
Prakhar Bahuguna
gcc/testsuite/
PR target/71607
* gcc.target/arm/thumb2-slow-flash-data.c: Renamed to ...
* gcc.target/arm/thumb2-slow-flash-data-1.c: ... this.
* gcc.target/arm/thumb2-slow-flash-data-2.c: New.
* gcc.target/arm/thumb2-slow-flash-data-3.c: New.
* gcc.target/arm/thumb2-slow-flash-data-4.c: New.
* gcc.target/arm/thumb2-slow-flash-data-5.c: New.
* gcc.target/arm/tls-disable-literal-pool.c: New.
Testing done: Ran regression tests for arm-eabi-none for ARMv7-M and ARMv8-M
targets. A bootstrap for arm-none-linux-gnueabihf was also successful.
--
Prakhar Bahuguna
>From 93ee5640b11cb7efbbe9aec53ce0d12d377c2be3 Mon Sep 17 00:00:00 2001
From: Prakhar Bahuguna
Date: Tue, 18 Apr 2017 14:16:46 +0100
Subject: [PATCH] PR71607: Fix ICE when loading constant
---
gcc/config/arm/arm.c | 21 +---
gcc/config/arm/arm.md | 9 ++
gcc/config/arm/vfp.md | 37 ++
...low-flash-data.c => thumb2-slow-flash-data-1.c} | 0
.../gcc.target/arm/thumb2-slow-flash-data-2.c | 28
.../gcc.target/arm/thumb2-slow-flash-data-3.c | 25 +++
.../gcc.target/arm/thumb2-slow-flash-data-4.c | 26 +++
.../gcc.target/arm/thumb2-slow-flash-data-5.c | 14
.../gcc.target/arm/tls-disable-literal-pool.c | 14
9 files changed, 163 insertions(+), 11 deletions(-)
rename gcc/testsuite/gcc.target/arm/{thumb2-slow-flash-data.c =>
thumb2-slow-flash-data-1.c} (100%)
create mode 100644 gcc/testsuite/gcc.target/arm/thumb2-slow-flash-data-2.c
create mode 100644 gcc/testsuite/gcc.target/arm/thumb2-slow-flash-data-3.c
create mode 100644 gcc/testsuite/gcc.target/arm/thumb2-slow-flash-data-4.c
create mode 100644 gcc/testsuite/gcc.target/arm/thumb2-slow-flash-data-5.c
create mode 100644 gcc/testsuite/gcc.target/arm/tls-disable-literal-pool.c
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index f3a6b64b168..ea371e27797 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -8633,7 +8633,16 @@ arm_tls_referenced_p (rtx x)
{
const_rtx x = *iter;
if (GET_CODE (x) == SYMBOL_REF && SYMBOL_REF_TLS_MODEL (x) != 0)
- return true;
+ {
+ /* ARM currently does not provide relocations to encode TLS variables
+into AArch32 instructions, only data, so there is no way to
+currently implement these if a literal pool is disabled. */
+ if (arm_disable_literal_pool)
+ sorry ("accessing thread-local storage is not currently supported "
+ "with -mpure-code or -mslow-flash-data");
+
+
Re: [PATCH] PR c++/80544 strip cv-quals from cast results
On 25/05/17 11:07 +0100, Jonathan Wakely wrote:
On 25/05/17 10:05 +0200, Andreas Schwab wrote:
../../gcc/ada/gcc-interface/utils2.c: In function 'int
compare_elmt_bitpos(const void*, const void*)':
../../gcc/ada/gcc-interface/utils2.c:1937:73: error: type qualifiers ignored on
cast result type [-Werror=ignored-qualifiers]
const constructor_elt * const elmt1 = (const constructor_elt * const) rt1;
^~~
../../gcc/ada/gcc-interface/utils2.c:1938:73: error: type qualifiers ignored on
cast result type [-Werror=ignored-qualifiers]
const constructor_elt * const elmt2 = (const constructor_elt * const) rt2;
I'm testing this obvious fix.
Committed as r248458 because it gets bootstrap past the error above,
although now Ada fails for me with:
/home/jwakely/src/gcc/bootstrap/./gcc/xgcc
-B/home/jwakely/src/gcc/bootstrap/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/
-B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem
/usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include-c -g -O2 -m32 -fpic -W -Wall
-gnatpg -nostdinc -m32 s-regpat.adb -o s-regpat.o
raised STORAGE_ERROR : stack overflow or erroneous memory access
../gcc-interface/Makefile:296: recipe for target 's-regpat.o' failed
diff --git a/gcc/ada/gcc-interface/utils2.c b/gcc/ada/gcc-interface/utils2.c
index fc6f1b8..cd37791 100644
--- a/gcc/ada/gcc-interface/utils2.c
+++ b/gcc/ada/gcc-interface/utils2.c
@@ -1934,8 +1934,8 @@ build_call_raise_range (int msg, Node_Id gnat_node, char
kind,
static int
compare_elmt_bitpos (const PTR rt1, const PTR rt2)
{
- const constructor_elt * const elmt1 = (const constructor_elt * const) rt1;
- const constructor_elt * const elmt2 = (const constructor_elt * const) rt2;
+ const constructor_elt * const elmt1 = (const constructor_elt *) rt1;
+ const constructor_elt * const elmt2 = (const constructor_elt *) rt2;
const_tree const field1 = elmt1->index;
const_tree const field2 = elmt2->index;
const int ret
Re: [patch, libfortran] AMD-specific versions of library matmul
On 05/25/2017 03:45 AM, Thomas Koenig wrote: Hello world, the attached patch speeds up the library version of matmul for AMD chips by selecting AVX128 instructions and, depending on which instructions are supported, either FMA3 (aka FMA) or FMA4. Jerry tested this on his AMD systems, and found a speedup vs. the current code of around 10%. I have been unable to test this on a Ryzen system (the new compile farm machines won't accept my login yet). From the benchmarks I have read, this method should also work fairly well on a Ryzen. So, OK for trunk? Yes, OK. Maybe test Ryzen first? I just confirmed access to the Ryzen machines so I plan to get set up and test there. Time to start looking under the hood. cat /proc/cpuinfo gives for flags: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf eagerfpu pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_l2 mwaitx hw_pstate vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic overflow_recov succor smca
Re: [PATCH] PR c++/80544 strip cv-quals from cast results
On Thu, May 25, 2017 at 03:02:42PM +0100, Jonathan Wakely wrote:
> On 25/05/17 11:07 +0100, Jonathan Wakely wrote:
> > On 25/05/17 10:05 +0200, Andreas Schwab wrote:
> > > ../../gcc/ada/gcc-interface/utils2.c: In function 'int
> > > compare_elmt_bitpos(const void*, const void*)':
> > > ../../gcc/ada/gcc-interface/utils2.c:1937:73: error: type qualifiers
> > > ignored on cast result type [-Werror=ignored-qualifiers]
> > > const constructor_elt * const elmt1 = (const constructor_elt * const)
> > > rt1;
> > >^~~
> > > ../../gcc/ada/gcc-interface/utils2.c:1938:73: error: type qualifiers
> > > ignored on cast result type [-Werror=ignored-qualifiers]
> > > const constructor_elt * const elmt2 = (const constructor_elt * const)
> > > rt2;
> >
> > I'm testing this obvious fix.
>
> Committed as r248458 because it gets bootstrap past the error above,
> although now Ada fails for me with:
>
> /home/jwakely/src/gcc/bootstrap/./gcc/xgcc
> -B/home/jwakely/src/gcc/bootstrap/./gcc/
> -B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/
> -isystem /usr/local/x86_64-pc-linux-gnu/include -isystem
> /usr/local/x86_64-pc-linux-gnu/sys-include-c -g -O2 -m32 -fpic -W -Wall
> -gnatpg -nostdinc -m32 s-regpat.adb -o s-regpat.o
>
> raised STORAGE_ERROR : stack overflow or erroneous memory access
> ../gcc-interface/Makefile:296: recipe for target 's-regpat.o' failed
>
>
> > diff --git a/gcc/ada/gcc-interface/utils2.c b/gcc/ada/gcc-interface/utils2.c
> > index fc6f1b8..cd37791 100644
> > --- a/gcc/ada/gcc-interface/utils2.c
> > +++ b/gcc/ada/gcc-interface/utils2.c
> > @@ -1934,8 +1934,8 @@ build_call_raise_range (int msg, Node_Id gnat_node,
> > char kind,
> > static int
> > compare_elmt_bitpos (const PTR rt1, const PTR rt2)
> > {
> > - const constructor_elt * const elmt1 = (const constructor_elt * const)
> > rt1;
> > - const constructor_elt * const elmt2 = (const constructor_elt * const)
> > rt2;
> > + const constructor_elt * const elmt1 = (const constructor_elt *) rt1;
> > + const constructor_elt * const elmt2 = (const constructor_elt *) rt2;
> > const_tree const field1 = elmt1->index;
> > const_tree const field2 = elmt2->index;
> > const int ret
So, what can one do with typeof or similar to avoid the warning?
void
foo (const void *p)
{
const int *const q = (const int *const) p;
typeof (q) r = (typeof (q)) p;
(void) q;
(void) r;
}
AFAIK typeof doesn't strip the toplevel qualifiers and I see current trunk
warns even about the cast in r initialization. Similarly to what has been
noted recently in another (C) PR, it would be nice if we had toplevel cv
stripping variant of typeof or some special builtin that could wrap
typeof or some type and could be used in places where typeof can,
__strip_cv (typeof (q)) = (__strip_cv (typeof (q))) p;
or
typeof (q) = (__strip_cv (typeof (q))) p;
or
__strip_cv (const int *const) z;
where the last one would be effectively
const int *z;
Jakub
Re: [PATCH] PR c++/80544 strip cv-quals from cast results
On Thu, May 25, 2017 at 04:11:19PM +0200, Jakub Jelinek wrote:
> So, what can one do with typeof or similar to avoid the warning?
>
> void
> foo (const void *p)
> {
> const int *const q = (const int *const) p;
> typeof (q) r = (typeof (q)) p;
> (void) q;
> (void) r;
> }
>
> AFAIK typeof doesn't strip the toplevel qualifiers and I see current trunk
> warns even about the cast in r initialization. Similarly to what has been
> noted recently in another (C) PR, it would be nice if we had toplevel cv
> stripping variant of typeof or some special builtin that could wrap
> typeof or some type and could be used in places where typeof can,
> __strip_cv (typeof (q)) = (__strip_cv (typeof (q))) p;
> or
> typeof (q) = (__strip_cv (typeof (q))) p;
> or
> __strip_cv (const int *const) z;
> where the last one would be effectively
> const int *z;
I guess in C++ one can use
typeof (q) r = (remove_cv ::type) p;
or something similar, but in C there is nothing like that.
Jakub
[C++ PATCH] Fix -Wunused with C++17 structured bindings
On Wed, May 24, 2017 at 12:13:40PM -0400, Jason Merrill wrote:
> On Wed, May 24, 2017 at 2:48 AM, Jakub Jelinek wrote:
> > On Tue, May 23, 2017 at 09:45:10PM -0400, Jason Merrill wrote:
> >> Someone on IRC complained that there was no way to suppress -Wunused
> >> on structured bindings. It seemed to me that the way the feature
> >> works, we shouldn't warn about the bindings individually; users need
> >> to give each of the subobjects a name even if they're only interested
> >> in using one of them.
> >>
> >> So this patch switches to tracking whether the underlying aggregate
> >> object as a whole is used; using one of the bindings will avoid any
> >> warning.
> >>
> >> This doesn't apply to tuple structured bindings, since in that case
> >> the bindings are actual variables rather than aliases to subobjects.
> >
> > So, shall we have even for the tuple structured bindings somewhere (in
> > lang_decl, such as adding struct lang_decl_decomp that would include
> > lang_decl_min?) the tree for the underlying artificial var decl?
>
> That would make sense.
So like this (so far lightly tested)? As DECL_DECOMPOSITION_P bit
sits in DECL_LANG_SPECIFIC, it is not possible to set that bit first and
then retrofit_lang_decl, so I had to play some games with that.
There is one issue I've noticed in your earlier patch (fixed in this patch),
we have separate DECL_HAS_VALUE_EXPR_P bit and DECL_VALUE_EXPR, testing
the former is cheap, the latter is an expensive function call.
So
if (DECL_VALUE_EXPR (exp))
mark_exp_read (DECL_VALUE_EXPR (exp));
is something unnecessarily expensive for all vars, while
if (DECL_HAS_VALUE_EXPR_P (exp))
mark_exp_read (DECL_VALUE_EXPR (exp));
or
if (DECL_HAS_VALUE_EXPR_P (exp))
{
tree t = DECL_VALUE_EXPR (exp);
if (t)
mark_exp_read (t);
}
is much cheaper. I believe usually DECL_VALUE_EXPR should be non-NULL
if DECL_HAS_VALUE_EXPR_P, but am not 100% sure if it is always guaranteed
(but pretty sure lots of code would break if it is not).
2017-05-25 Jakub Jelinek
* cp-tree.h (struct lang_decl_decomp): New type.
(struct lang_decl): Add u.decomp.
(LANG_DECL_DECOMP_CHECK): Define.
(DECL_DECOMPOSITION_P): Note it is set also on the vars
for user identifiers.
(DECL_DECOMP_BASE): Define.
(retrofit_lang_decl): Add extra int = 0 argument.
* lex.c (retrofit_lang_decl): Add SEL argument, if non-zero
use it to influence the selector choices and for selector
0 to non-zero transition copy old content.
(cxx_dup_lang_specific_decl): Handle DECL_DECOMPOSITION_P.
* decl.c (poplevel): For DECL_DECOMPOSITION_P, check
!DECL_DECOMP_BASE instead of !DECL_VALUE_EXPR. Adjust warning
wording if decl is a structured binding.
(cp_finish_decomp): Pass 4 as the new argument to retrofit_lang_decl.
Set DECL_DECOMP_BASE. Ignore DECL_READ_P sets from initialization
of individual variables for tuple structured bindings.
(grokdeclarator): Pass 4 as the new argument to retrofit_lang_decl.
Clear DECL_DECOMP_BASE.
* decl2.c (mark_used): Mark DECL_DECOMP_BASE TREE_USED as well.
* pt.c (tsubst_decomp_names): Assert DECL_DECOMP_BASE matches what
is expected.
* expr.c (mark_exp_read): Recurse on DECL_DECOMP_BASE instead of
DECL_VALUE_EXPR.
* g++.dg/cpp1z/decomp29.C (p): New variable.
(main): Add further tests.
--- gcc/cp/cp-tree.h.jj 2017-05-25 10:37:00.0 +0200
+++ gcc/cp/cp-tree.h2017-05-25 12:48:34.828167911 +0200
@@ -2516,6 +2516,15 @@ struct GTY(()) lang_decl_parm {
int index;
};
+/* Additional DECL_LANG_SPECIFIC information for structured bindings. */
+
+struct GTY(()) lang_decl_decomp {
+ struct lang_decl_min min;
+ /* The artificial underlying "e" variable of the structured binding
+ variable. */
+ tree base;
+};
+
/* DECL_LANG_SPECIFIC for all types. It would be nice to just make this a
union rather than a struct containing a union as its only field, but
tree.h declares it as a struct. */
@@ -2527,6 +2536,7 @@ struct GTY(()) lang_decl {
struct lang_decl_fn GTY ((tag ("1"))) fn;
struct lang_decl_ns GTY((tag ("2"))) ns;
struct lang_decl_parm GTY((tag ("3"))) parm;
+struct lang_decl_decomp GTY((tag ("4"))) decomp;
} u;
};
@@ -2563,6 +2573,13 @@ struct GTY(()) lang_decl {
lang_check_failed (__FILE__, __LINE__, __FUNCTION__); \
<->u.parm; })
+#define LANG_DECL_DECOMP_CHECK(NODE) __extension__ \
+({ struct lang_decl *lt = DECL_LANG_SPECIFIC (NODE); \
+ if (!VAR_P (NODE)\
+ || lt->u.base.selector != 4) \
+lang_check_failed (__FILE__, __LINE__, __FUNCTION__); \
+ <->u.decomp; })
+
#define LANG_DECL_U2_CHECK(NODE, TF) __extension__ \
({ st
Re: [PATCH] PR c++/80544 strip cv-quals from cast results
On Thu, May 25, 2017 at 04:11:19PM +0200, Jakub Jelinek wrote:
> On Thu, May 25, 2017 at 03:02:42PM +0100, Jonathan Wakely wrote:
> > On 25/05/17 11:07 +0100, Jonathan Wakely wrote:
> > > On 25/05/17 10:05 +0200, Andreas Schwab wrote:
> > > > ../../gcc/ada/gcc-interface/utils2.c: In function 'int
> > > > compare_elmt_bitpos(const void*, const void*)':
> > > > ../../gcc/ada/gcc-interface/utils2.c:1937:73: error: type qualifiers
> > > > ignored on cast result type [-Werror=ignored-qualifiers]
> > > > const constructor_elt * const elmt1 = (const constructor_elt * const)
> > > > rt1;
> > > >
> > > > ^~~
> > > > ../../gcc/ada/gcc-interface/utils2.c:1938:73: error: type qualifiers
> > > > ignored on cast result type [-Werror=ignored-qualifiers]
> > > > const constructor_elt * const elmt2 = (const constructor_elt * const)
> > > > rt2;
> > >
> > > I'm testing this obvious fix.
> >
> > Committed as r248458 because it gets bootstrap past the error above,
> > although now Ada fails for me with:
> >
> > /home/jwakely/src/gcc/bootstrap/./gcc/xgcc
> > -B/home/jwakely/src/gcc/bootstrap/./gcc/
> > -B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/
> > -isystem /usr/local/x86_64-pc-linux-gnu/include -isystem
> > /usr/local/x86_64-pc-linux-gnu/sys-include-c -g -O2 -m32 -fpic -W
> > -Wall -gnatpg -nostdinc -m32 s-regpat.adb -o s-regpat.o
> >
> > raised STORAGE_ERROR : stack overflow or erroneous memory access
> > ../gcc-interface/Makefile:296: recipe for target 's-regpat.o' failed
> >
> >
> > > diff --git a/gcc/ada/gcc-interface/utils2.c
> > > b/gcc/ada/gcc-interface/utils2.c
> > > index fc6f1b8..cd37791 100644
> > > --- a/gcc/ada/gcc-interface/utils2.c
> > > +++ b/gcc/ada/gcc-interface/utils2.c
> > > @@ -1934,8 +1934,8 @@ build_call_raise_range (int msg, Node_Id gnat_node,
> > > char kind,
> > > static int
> > > compare_elmt_bitpos (const PTR rt1, const PTR rt2)
> > > {
> > > - const constructor_elt * const elmt1 = (const constructor_elt * const)
> > > rt1;
> > > - const constructor_elt * const elmt2 = (const constructor_elt * const)
> > > rt2;
> > > + const constructor_elt * const elmt1 = (const constructor_elt *) rt1;
> > > + const constructor_elt * const elmt2 = (const constructor_elt *) rt2;
> > > const_tree const field1 = elmt1->index;
> > > const_tree const field2 = elmt2->index;
> > > const int ret
>
> So, what can one do with typeof or similar to avoid the warning?
>
> void
> foo (const void *p)
> {
> const int *const q = (const int *const) p;
> typeof (q) r = (typeof (q)) p;
> (void) q;
> (void) r;
> }
>
> AFAIK typeof doesn't strip the toplevel qualifiers and I see current trunk
> warns even about the cast in r initialization. Similarly to what has been
> noted recently in another (C) PR, it would be nice if we had toplevel cv
> stripping variant of typeof or some special builtin that could wrap
> typeof or some type and could be used in places where typeof can,
> __strip_cv (typeof (q)) = (__strip_cv (typeof (q))) p;
> or
> typeof (q) = (__strip_cv (typeof (q))) p;
> or
> __strip_cv (const int *const) z;
> where the last one would be effectively
> const int *z;
I remember trying to implement the stripping version of __typeof; I even had
a prototype patch that I'm of course not finding right now, but I'd be happy to
work on this again.
Ok, I at least found the PR:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39985
Also there's
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00268.html
Let me know if I should get back to it.
Marek
Re: [patch, libfortran] AMD-specific versions of library matmul
Hi Jerry, Yes, OK. Maybe test Ryzen first? Sure, I can wait for a bit :-) I just confirmed access to the Ryzen machines so I plan to get set up and test there. The gcc compile farm machines? My ssh key does not work there... I have based the choice of FMA(3) over FMA4 when both are available on a short remark in a benchmark that FMA3 is faster... it might be interesting to see if that is actually true. Regards Thomas
Re: [PATCH] PR c++/80544 strip cv-quals from cast results
On 25/05/17 16:11 +0200, Jakub Jelinek wrote:
On Thu, May 25, 2017 at 03:02:42PM +0100, Jonathan Wakely wrote:
On 25/05/17 11:07 +0100, Jonathan Wakely wrote:
> On 25/05/17 10:05 +0200, Andreas Schwab wrote:
> > ../../gcc/ada/gcc-interface/utils2.c: In function 'int
compare_elmt_bitpos(const void*, const void*)':
> > ../../gcc/ada/gcc-interface/utils2.c:1937:73: error: type qualifiers
ignored on cast result type [-Werror=ignored-qualifiers]
> > const constructor_elt * const elmt1 = (const constructor_elt * const) rt1;
> >^~~
> > ../../gcc/ada/gcc-interface/utils2.c:1938:73: error: type qualifiers
ignored on cast result type [-Werror=ignored-qualifiers]
> > const constructor_elt * const elmt2 = (const constructor_elt * const) rt2;
>
> I'm testing this obvious fix.
Committed as r248458 because it gets bootstrap past the error above,
although now Ada fails for me with:
/home/jwakely/src/gcc/bootstrap/./gcc/xgcc
-B/home/jwakely/src/gcc/bootstrap/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/
-B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem
/usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include-c -g -O2 -m32 -fpic -W -Wall
-gnatpg -nostdinc -m32 s-regpat.adb -o s-regpat.o
raised STORAGE_ERROR : stack overflow or erroneous memory access
../gcc-interface/Makefile:296: recipe for target 's-regpat.o' failed
> diff --git a/gcc/ada/gcc-interface/utils2.c b/gcc/ada/gcc-interface/utils2.c
> index fc6f1b8..cd37791 100644
> --- a/gcc/ada/gcc-interface/utils2.c
> +++ b/gcc/ada/gcc-interface/utils2.c
> @@ -1934,8 +1934,8 @@ build_call_raise_range (int msg, Node_Id gnat_node,
char kind,
> static int
> compare_elmt_bitpos (const PTR rt1, const PTR rt2)
> {
> - const constructor_elt * const elmt1 = (const constructor_elt * const) rt1;
> - const constructor_elt * const elmt2 = (const constructor_elt * const) rt2;
> + const constructor_elt * const elmt1 = (const constructor_elt *) rt1;
> + const constructor_elt * const elmt2 = (const constructor_elt *) rt2;
> const_tree const field1 = elmt1->index;
> const_tree const field2 = elmt2->index;
> const int ret
So, what can one do with typeof or similar to avoid the warning?
void
foo (const void *p)
{
const int *const q = (const int *const) p;
typeof (q) r = (typeof (q)) p;
(void) q;
(void) r;
}
I'd probably write that like this instead:
void
foo (const void *p)
{
typedef const int* ptr_type;
ptr_type const q = (ptr_type) p;
ptr_type const r = (ptr_type) p;
(void) q;
(void) r;
}
It names the type only once, not twice as in your example, and doesn't
need to use typeof to refer to that type again.
The variables p and q are defined const, which is what's wanted. The
cast is to ptr_type, not ptr_type const.
Re: [PATCH] PR c++/80544 strip cv-quals from cast results
On Thu, May 25, 2017 at 03:52:47PM +0100, Jonathan Wakely wrote:
> I'd probably write that like this instead:
>
> void
> foo (const void *p)
> {
> typedef const int* ptr_type;
> ptr_type const q = (ptr_type) p;
> ptr_type const r = (ptr_type) p;
> (void) q;
> (void) r;
> }
>
> It names the type only once, not twice as in your example, and doesn't
> need to use typeof to refer to that type again.
That was over-simplified, I meant cases where you actually don't know the
exact type, just use typeof to create a variable of such a type and
then want to cast something to that type.
Jakub
Re: SSA range class and removal of VR_ANTI_RANGEs
On May 24, 2017, at 1:25 AM, Richard Biener wrote: > > There's trailing_wide_ints. But having 6 of them is still expensive. > > Something nice would be to make wide_ints not tied to use HOST_WIDE_INT > as basic element type but for example uint32. wide_int was made so that they would be calculation time efficient at the expense of a little space efficiency. The underlying type is fairly arbitrary, and indeed, one could add it as a template parameter, and have all the existing code just use HWI for that parameter. The new space saving version, could pass char, or short, or int, if they wanted to. The only down side should be an extreme slowdown on operations. It would be a lot of work to do this... but thought I would mention it. Earlier on, we used int for testing to ensure that the code was solid, as when using a 64-bit chunk, most code never needs more than 1. With a 32-bit type, the odds of more than 1 being used spike up considerably.
Re: [PATCH GCC][3/6]Fix PR80815 by handling negative DR_STEPs in runtime alias check
On Wed, May 24, 2017 at 11:54 AM, Richard Sandiford
wrote:
> "Bin.Cheng" writes:
>> On Tue, May 23, 2017 at 6:53 PM, Richard Sandiford
>> wrote:
>>> AIUI, the reason the old code mishandled negative steps was that the
>>> associated segment lengths were stored as sizetype and so looked like
>>> big unsigned values. Those values therefore satisfied tree_fits_uhwi_p
>>> even though they were semantically negative. Is that right?
>> Yes, and the undesired wrapping behavior when such large unsigned hwi
>> is involved in computation. But I think there are possible leaks in
>> the code even after this patch, as embedded below.
>>>
>>> Assuming yes, and quoting the change as a context diff...
>>>
diff --git a/gcc/tree-data-ref.c b/gcc/tree-data-ref.c
index a5f8c1c..f0799d9 100644
*** a/gcc/tree-data-ref.c
--- b/gcc/tree-data-ref.c
***
*** 1259,1264
--- 1259,1273
!= tree_int_cst_compare (DR_STEP (dr_a2->dr), size_zero_node))
continue;
+ bool neg_step
+ = (tree_int_cst_compare (DR_STEP (dr_a1->dr), size_zero_node) <
0);
+
+ /* DR_A1 and DR_A2 must have the same step if it's negative. */
+ if (neg_step
+ && tree_int_cst_compare (DR_STEP (dr_a1->dr),
+DR_STEP (dr_a2->dr)) != 0)
+ continue;
+
>>>
>>> [Why do they need to be the same step?]
>> There are two reasons. First is to simplify diff computation between
>> dr_a1 and dr_a2, otherwise we need to adjust diff for negative steps.
>
> What kind of adjustment would be needed? Could you give an example?
I handled negative step in updated patch by adjusting diff according
to access size of references.
>
>> And wrapping behavior needs to be handled when adjusting diff with
>> steps. The second reason is not fully handled in this patch. We now
>> only set merged segment length to MAX only when both dr_a1->seg_len
>> and dr_a2->seg_len are constant, as below:
>> + if (tree_fits_uhwi_p (dr_a1->seg_len)
>> + && tree_fits_uhwi_p (dr_a2->seg_len))
>> +new_seg_len
>> + = size_int (MAX (tree_to_uhwi (dr_a1->seg_len),
>> + diff + tree_to_uhwi (dr_a2->seg_len)));
>> + else
>> +new_seg_len
>> + = size_binop (PLUS_EXPR, dr_a2->seg_len, size_int (diff));
>> In fact, we should do this for else branch too. with different steps,
>> it is still possible that dr_a1-seg_len > dr_a2->seg_len + diff. Here
>> I only restrict it to negative DR_STEP. Patch updated with
>> explanation in comment.
>>>
/* Make sure dr_a1 starts left of dr_a2. */
if (tree_int_cst_lt (DR_INIT (dr_a2->dr), DR_INIT (dr_a1->dr)))
std::swap (*dr_a1, *dr_a2);
***
*** 1266,1325
bool do_remove = false;
unsigned HOST_WIDE_INT diff
= (tree_to_shwi (DR_INIT (dr_a2->dr))
!- tree_to_shwi (DR_INIT (dr_a1->dr)));
! /* If the left segment does not extend beyond the start of the
! right segment the new segment length is that of the right
! plus the segment distance. */
! if (tree_fits_uhwi_p (dr_a1->seg_len)
! && compare_tree_int (dr_a1->seg_len, diff) <= 0)
{
! dr_a1->seg_len = size_binop (PLUS_EXPR, dr_a2->seg_len,
!size_int (diff));
! do_remove = true;
}
! /* Generally the new segment length is the maximum of the
! left segment size and the right segment size plus the distance.
! ??? We can also build tree MAX_EXPR here but it's not clear
this
! is profitable. */
! else if (tree_fits_uhwi_p (dr_a1->seg_len)
!&& tree_fits_uhwi_p (dr_a2->seg_len))
! {
! unsigned HOST_WIDE_INT seg_len_a1 = tree_to_uhwi
(dr_a1->seg_len);
! unsigned HOST_WIDE_INT seg_len_a2 = tree_to_uhwi
(dr_a2->seg_len);
! dr_a1->seg_len = size_int (MAX (seg_len_a1, diff +
seg_len_a2));
! do_remove = true;
! }
! /* Now we check if the following condition is satisfied:
! DIFF - SEGMENT_LENGTH_A < SEGMENT_LENGTH_B
! where DIFF = DR_A2_INIT - DR_A1_INIT. However,
! SEGMENT_LENGTH_A or SEGMENT_LENGTH_B may not be constant so we
! have to make a best estimation. We can get the minimum value
! of SEGMENT_LENGTH_B as a constant, represented by MIN_SEG_LEN_B,
! then either of the following two conditions can guarantee the
! one above:
! 1: DIFF <= MIN_SEG_LEN_B
! 2: DIFF - SEGMENT_LENGTH_A <
Re: [PATCH GCC][4/6]Relax minimal segment length of DR_B for merging alias check
On Tue, May 23, 2017 at 5:23 PM, Bin Cheng wrote:
> Hi,
> As commented in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80815#c1,
> We can relax minimal segment length of DR_B for merging. With this change,
> the new test can be improved to only one alias check. Note the
> condition is still accurate after this patch, it won't introduce false
> alias.
> Bootstrap and test on x86_64 and AArch64, is it OK?
Updated patch wrto change of previous patch.
Bootstrap and test on x86_64 and AArch64.
Thanks,
bin
>
> 2017-05-22 Bin Cheng
>
> * tree-data-ref.c (prune_runtime_alias_test_list): Relax minimal
> segment length for dr_b.
>
> gcc/testsuite/ChangeLog
> 2017-05-22 Bin Cheng
>
> * gcc.dg/vect/pr80815-3.c: New test.
From 654996fde92852a50c49fefeff79489e01d7db97 Mon Sep 17 00:00:00 2001
From: Bin Cheng
Date: Mon, 22 May 2017 11:34:18 +0100
Subject: [PATCH 4/6] minimal-seg-length-for-dr_b-20170519.txt
---
gcc/testsuite/gcc.dg/vect/pr80815-3.c | 45 +++
gcc/tree-data-ref.c | 4 +++-
2 files changed, 48 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.dg/vect/pr80815-3.c
diff --git a/gcc/testsuite/gcc.dg/vect/pr80815-3.c
b/gcc/testsuite/gcc.dg/vect/pr80815-3.c
new file mode 100644
index 000..dae01fa
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr80815-3.c
@@ -0,0 +1,45 @@
+/* { dg-require-effective-target vect_int } */
+
+#include "tree-vect.h"
+int arr[2048];
+int res[100] = { 2148, 2146, 2144, 2142, 2140, 2138, 2136, 2134, 2132, 2130,
+2128, 2126, 2124, 2122, 2120, 2118, 2116, 2114, 2112, 2110,
+2108, 2106, 2104, 2102, 2100, 2098, 2096, 2094, 2092, 2090,
+2088, 2086, 2084, 2082, 2080, 2078, 2076, 2074, 2072, 2070,
+2068, 2066, 2064, 2062, 2060, 2058, 2056, 2054, 3078, 2050};
+
+__attribute__ ((noinline)) int
+foo (int *a, int *b, int len)
+{
+ int i;
+ int *a1 = a;
+ int *a0 = a1 - 4;
+ for (i = 0; i < len; i++)
+{
+ *b = *a0 + *a1;
+ b--;
+ a0++;
+ a1++;
+}
+ return 0;
+}
+
+int main (void)
+{
+ int *a = &arr[1027];
+ int *b = &arr[1024];
+
+ int i;
+ for (i = 0; i < 2048; i++)
+arr[i] = i;
+
+ foo (a, b, 50);
+
+ for (i = 975; i < 1025; i++)
+if (arr[i] != res[i - 975])
+ abort ();
+
+ return 0;
+}
+
+/* { dg-final { scan-tree-dump "improved number of alias checks from \[0-9\]*
to 1" "vect" } } */
diff --git a/gcc/tree-data-ref.c b/gcc/tree-data-ref.c
index 1a28000..0b5fd1b 100644
--- a/gcc/tree-data-ref.c
+++ b/gcc/tree-data-ref.c
@@ -1287,7 +1287,9 @@ prune_runtime_alias_test_list
(vec *alias_pairs,
min_seg_len_b = wi::neg (min_seg_len_b);
}
else
- min_seg_len_b = wi::uhwi (factor, TYPE_PRECISION (sizetype));
+ {
+ min_seg_len_b = wi::mul (factor, wi::abs (DR_STEP (dr_b1->dr)));
+ }
/* Now we try to merge alias check dr_a1 & dr_b and dr_a2 & dr_b.
--
1.9.1
Re: Web page for binaries
On May 23, 2017, at 1:41 AM, FX wrote: > > I’m suggesting we apply the following patch to provide links to macOS package > managers, where users can download binaries for GCC on macOS. I have included > the two major ones, Homebrew and MacPorts. I'm not against it. :-) I'd let the doc people comment on linking, as they keep up on all the rules. I think those links are fine.
[C++ PATCH] Reimplement qualified namespace lookup
This patch reimplements qualified namespace lookup. It extends the
name_lookup object I introduced for ADL.
qualified namespace lookup is essentially a flood-fill algorithm, where
if nothing is found in namespace X you follow the using directives
therein. You stop when you find something (or there's no using
directives to follow). As you can see implementing this requires
knowing if you've met X before -- and if you have, whether searching
from there found something or not.
The current algorithm maintains 5 vectors (count them, 5!) to record
where one's been and where one needs to go. Along with the O(N^2) 'have
I been here' check.
This implementation uses the new LOOKUP_SEEN_P and LOOKUP_FOUND_P
markers to just tag the NAMESPACE_DECL directly. We don't need a work
queue -- recursion does just fine. Using directives can create a loop,
which one will traverse if there is nothing found. That is handled
naturally by this algorithm.
There is still some awkwardness with following using directive, because
of the current implementation of unqualified lookup. And concatenating
lookups is still maintaining 1D overloads.
nathan
--
Nathan Sidwell
2017-05-25 Nathan Sidwell
Reimplement qualified namespace lookup.
* name-lookup.c (name_lookup::flags): New member. Adjust ctor.
(name_lookup::ambiguous, name_lookup::add_value,
name_lookup::add_type, name_lookup::process_binding): New.
(name_lookup::search_namespace_only,
name_lookup::search_namespace, name_lookup::search_usings): New.
(name_lookup::search_qualified): New.
(do_nonmember_using_decl, suggest_alternatives_for,
lookup_qualified_name): Adjust.
(tree_vec_contains): Delete.
(qualified_lookup_using_namespace): Rename to ...
(qualified_namespace_lookup): ... here. Reimplement.
Index: name-lookup.c
===
--- name-lookup.c (revision 248457)
+++ name-lookup.c (working copy)
@@ -48,18 +48,6 @@ struct scope_binding {
};
#define EMPTY_SCOPE_BINDING { NULL_TREE, NULL_TREE }
-static bool lookup_using_namespace (tree, struct scope_binding *, tree,
-tree, int);
-static bool qualified_lookup_using_namespace (tree, tree,
- struct scope_binding *, int);
-static void consider_binding_level (tree name,
-best_match &bm,
-cp_binding_level *lvl,
-bool look_within_fields,
-enum lookup_name_fuzzy_kind kind);
-static tree push_using_directive (tree);
-static void diagnose_name_conflict (tree, tree);
-
/* Create a local binding level for NAME. */
static cxx_binding *
@@ -166,6 +154,7 @@ public:
tree name; /* The identifier being looked for. */
tree value; /* A (possibly ambiguous) set of things found. */
tree type; /* A type that has been found. */
+ int flags; /* Lookup flags. */
vec *scopes;
name_lookup *previous; /* Previously active lookup. */
hash_set *fn_set;
@@ -177,8 +166,8 @@ protected:
static name_lookup *active;
public:
- name_lookup (tree n)
- : name (n), value (NULL_TREE), type (NULL_TREE),
+ name_lookup (tree n, int f = 0)
+ : name (n), value (NULL_TREE), type (NULL_TREE), flags (f),
scopes (NULL), previous (NULL), fn_set (NULL)
{
preserve_state ();
@@ -222,7 +211,22 @@ private:
void preserve_state ();
void restore_state ();
- private:
+private:
+ static tree ambiguous (tree thing, tree current);
+ void add_value (tree new_val);
+ void add_type (tree new_type);
+ bool process_binding (tree val_bind, tree type_bind);
+
+ /* Look in only namespace. */
+ bool search_namespace_only (tree scope);
+ /* Look in namespace and its (recursive) inlines. Ignore using
+ directives. Return true if something found (inc dups). */
+ bool search_namespace (tree scope);
+ /* Look in the using directives of namespace + inlines using
+ qualified lookup rules. */
+ bool search_usings (tree scope);
+
+private:
void add_fns (tree);
void adl_expr (tree);
@@ -235,6 +239,10 @@ private:
void adl_namespace_only (tree);
public:
+ /* Search namespace + inlines + maybe usings as qualified lookup. */
+ bool search_qualified (tree scope, bool usings = true);
+
+ /* ADL lookup of ARGS. */
tree search_adl (tree fns, vec *args);
};
@@ -348,6 +356,207 @@ name_lookup::find_and_mark (tree scope)
return result;
}
+/* THING and CURRENT are ambiguous, concatenate them. */
+
+tree
+name_lookup::ambiguous (tree thing, tree current)
+{
+ if (TREE_CODE (current) != TREE_LIST)
+{
+ current = build_tree_list (NULL_TREE, current);
+ TREE_TYPE (current) = error_mark_node;
+}
+ current = tree_cons (NULL_TREE, thing, current);
+ TREE_TYPE (current) = error_mark_node;
+
+ return current;
+}
+
+/* Add a NEW_VAL, a found value binding into the current value binding. */
+
+void
+name_lookup::add_value (tree new_val)
+{
+ if (!value)
+value = new_val;
+ else if (value == new_val)
+;
+ else if ((TREE_CODE (value) == TYPE_D
Re: [PATCH] add more detail to -Wconversion and -Woverflow (PR 80731)
FAIL: gcc.dg/overflow-warn-9.c (test for warnings, line 59) FAIL: gcc.dg/overflow-warn-9.c (test for warnings, line 60) FAIL: gcc.dg/overflow-warn-9.c (test for warnings, line 62) FAIL: gcc.dg/overflow-warn-9.c (test for excess errors) Excess errors: /daten/aranym/gcc/gcc-20170525/gcc/testsuite/gcc.dg/overflow-warn-9.c:62:9: warning: signed conversion from 'long unsigned int' to 'long int' changes value from '2147483648' to '-2147483648' [-Wsign-conversion] FAIL: gcc.dg/pr59963-2.c (test for warnings, line 16) FAIL: gcc.dg/pr59963-2.c (test for excess errors) Excess errors: /daten/aranym/gcc/gcc-20170525/gcc/testsuite/gcc.dg/pr59963-2.c:16:6: warning: overflow in conversion from 'long unsigned int' to 'short int' changes value from '4294967295' to '-1' [-Woverflow] FAIL: gcc.dg/pr60114.c (test for warnings, line 12) FAIL: gcc.dg/pr60114.c (test for warnings, line 13) FAIL: gcc.dg/pr60114.c (test for warnings, line 14) FAIL: gcc.dg/pr60114.c (test for warnings, line 23) FAIL: gcc.dg/pr60114.c (test for warnings, line 24) FAIL: gcc.dg/pr60114.c (test for excess errors) Excess errors: /daten/aranym/gcc/gcc-20170525/gcc/testsuite/gcc.dg/pr60114.c:12:9: warning: signed conversion from 'unsigned int' to 'int' changes value from '2147483648' to '-2147483648' [-Wsign-conversion] /daten/aranym/gcc/gcc-20170525/gcc/testsuite/gcc.dg/pr60114.c:13:11: warning: signed conversion from 'unsigned int' to 'int' changes value from '2147483648' to '-2147483648' [-Wsign-conversion] /daten/aranym/gcc/gcc-20170525/gcc/testsuite/gcc.dg/pr60114.c:14:16: warning: signed conversion from 'unsigned int' to 'int' changes value from '2147483648' to '-2147483648' [-Wsign-conversion] /daten/aranym/gcc/gcc-20170525/gcc/testsuite/gcc.dg/pr60114.c:23:17: warning: overflow in conversion from 'int' to 'signed char' changes value from '256' to '0' [-Woverflow] /daten/aranym/gcc/gcc-20170525/gcc/testsuite/gcc.dg/pr60114.c:24:20: warning: overflow in conversion from 'int' to 'signed char' changes value from '256' to '0' [-Woverflow] Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [PATCH] PR c++/80544 strip cv-quals from cast results
On 25/05/17 16:56 +0200, Jakub Jelinek wrote:
On Thu, May 25, 2017 at 03:52:47PM +0100, Jonathan Wakely wrote:
I'd probably write that like this instead:
void
foo (const void *p)
{
typedef const int* ptr_type;
ptr_type const q = (ptr_type) p;
ptr_type const r = (ptr_type) p;
(void) q;
(void) r;
}
It names the type only once, not twice as in your example, and doesn't
need to use typeof to refer to that type again.
That was over-simplified, I meant cases where you actually don't know the
exact type, just use typeof to create a variable of such a type and
then want to cast something to that type.
The most obvious case I can think of where you don't know the type
would be the result of some expression (maybe involving overloaded
operators, or a call to an overloaded function). In that case:
typeof (expr) const q = (typeof (expr)) p;
Again, add the const to the variable definition, but not the cast.
or using a typedef again for clarity and to avoid the repetition:
typedef typeof (expr) the_type;
the_type const q = (the_type) p;
If the result of the expression is a scalar type then it won't be
const-qualified, so the_type isn't either, and the cast won't warn.
If the result of the expression is a class-type then it can be
const-qualified, and so the_type is also const-qualified, but the
warning isn't issued in such case.
All the realistic case I can think of expr won't be simply a variable
(because if you have a variable then it was already declared with some
type and you can refer to that type directly) so the original problem
where typeof(q) deduces a const-qualified type won't happen.
template void f (const T& t, const void* p) {
// no need for typeof(t) because we can just use T
T* const q = (T*)p;
T* const r = (T*)p;
}
There's this case, which will warn if the type is a pointer or other
scalar:
auto const q = some_function (p);
typeof (q) r = (typeof (q)) p
But what you really care about is typeof (some_function (p)) not
typeof (q), which is just the 'expr' case above:
typedef typeof (some_function(p)) ptr_type;
ptr_type const q = some_function (p);
ptr_type const r = (ptr_type)p;
The warning is avoidable by using typeof on the expression that
determines the type, not on a variable that has a const-qualified
version of the type.
Re: [PATCH] Introduce 4-stages profiledbootstrap to get a better profile.
On 05/25/2017 01:22 PM, Markus Trippelsdorf wrote: > On 2017.05.25 at 11:55 +0200, Martin Liška wrote: >> Hi. >> >> As I spoke about the PGO with Honza and Richi, current 3-stage is not ideal >> for following >> 2 reasons: >> >> 1) stageprofile compiler is train just on libraries that are built during >> stage2 >> 2) apart from that, as the compiler is also used to build the final >> compiler, profile >> is being updated during the build. So the stage2 compiler is making >> different decisions. >> >> Both problems can be resolved by adding another step in between current >> stage2 and stage3 >> where we train stage2 compiler by building compiler with default options. >> >> I'm going to do some measurements. > > I did some measurements on gcc67 (trunk with --enable-checking=release). > The apparent speedup is in the noise. Hello. Thanks for measurements: I can see difference for GCC 7.1: g++-7 tramp3d-v4.ii -O2 && time for i in `seq 1 10` ; do g++-7 tramp3d-v4.ii -O2 ; done before: 2m25.133s after: real 2m25.133s which is 99.09124426480228%. It's probably within a noise level. And apparently file size of binary is bugger: before (using bloaty): VM SIZE FILE SIZE -- -- 59.0% 15.1Mi .text 15.1Mi 62.3% 21.3% 5.45Mi .rodata5.45Mi 22.5% 6.6% 1.69Mi .eh_frame 1.69Mi 6.9% 5.4% 1.38Mi .bss0 0.0% 3.3% 874Ki .dynstr 874Ki 3.5% 1.8% 480Ki .dynsym 480Ki 1.9% 1.1% 285Ki .eh_frame_hdr 285Ki 1.1% 0.6% 158Ki .gnu.hash 158Ki 0.6% 0.5% 144Ki .hash 144Ki 0.6% 0.2% 44.4Ki .data 44.4Ki 0.2% 0.2% 40.0Ki .gnu.version 40.0Ki 0.2% 0.0% 11.1Ki .rela.plt 11.1Ki 0.0% 0.0% 7.44Ki .plt 7.44Ki 0.0% 0.0% 4.56Ki .data.rel.ro 4.56Ki 0.0% 0.0% 3.73Ki .got.plt 3.73Ki 0.0% 0.0% 38 [Unmapped] 2.75Ki 0.0% 0.0% 624 [ELF Headers] 2.55Ki 0.0% 0.0% 848 [Other]1.13Ki 0.0% 0.0% 917 .gcc_except_table 917 0.0% 0.0% 608 .dynamic 608 0.0% 0.0% 16 [None] 0 0.0% 100.0% 25.7Mi TOTAL 24.3Mi 100.0% after: VM SIZE FILE SIZE -- -- 58.3% 14.6Mi .text 14.6Mi 54.2% 21.6% 5.41Mi .rodata5.41Mi 20.1% 0.0% 0 .strtab2.13Mi 7.9% 6.7% 1.67Mi .eh_frame 1.67Mi 6.2% 5.5% 1.38Mi .bss0 0.0% 0.0% 0 .symtab1.11Mi 4.1% 3.4% 876Ki .dynstr 876Ki 3.2% 1.9% 480Ki .dynsym 480Ki 1.7% 1.1% 280Ki .eh_frame_hdr 280Ki 1.0% 0.6% 158Ki .gnu.hash 158Ki 0.6% 0.6% 144Ki .hash 144Ki 0.5% 0.2% 44.4Ki .data 44.4Ki 0.2% 0.2% 40.1Ki .gnu.version 40.1Ki 0.1% 0.0% 11.1Ki .rela.plt 11.1Ki 0.0% 0.0% 7.44Ki .plt 7.44Ki 0.0% 0.0% 4.56Ki .data.rel.ro 4.56Ki 0.0% 0.0% 3.73Ki .got.plt 3.73Ki 0.0% 0.0% 58 [Unmapped] 3.11Ki 0.0% 0.0% 624 [ELF Headers] 2.61Ki 0.0% 0.0% 2.32Ki [Other]2.60Ki 0.0% 0.0% 16 [None] 0 0.0% 100.0% 25.1Mi TOTAL 26.9Mi 100.0% As I had chat with Honza, we still have problem in GCC that using current working sets, get_hot_bb_threshold () is very close to number of runs, which is effectively 1 for a single run. That's mistake and that should be fixed. Martin > > Without your patch: > > Performance counter stats for 'g++ -w -Ofast tramp3d-v4.cpp' (10 runs): > > 15749.058451 task-clock (msec) #0.997 CPUs utilized > ( +- 0.13% ) > 1,352 context-switches #0.086 K/sec > ( +- 0.16% ) > 7 cpu-migrations#0.000 K/sec > ( +- 5.73% ) >269,142 page-faults #0.017 M/sec > ( +- 0.01% ) > 60,676,581,181 cycles#3.853 GHz > ( +- 0.09% ) (83.35%) > 13,401,784,189 stalled-cycles-frontend # 22.09% frontend cycles > idle ( +- 0.20% ) (83.33%) > 12,926,843,370 stalled-cycles-backend# 21.30% backend cycles > idle ( +- 0.04% ) (83.31%) > 73,074,099,356 instructions #1.20 insn per cycle > #0.18 stalled cycles > per insn ( +- 0.02% ) (83.34%) > 16,607,220,814 branches # 1054.490 M/sec > ( +- 0.03% ) (83.36%) >616,673,310 branch-misses #3.71% of all branches > ( +- 0.08% ) (83.36%) > > 15.8036026
Re: Default std::vector default and move constructor
On 15/05/17 19:57 +0200, François Dumont wrote: Hi Following what I have started on RbTree here is a patch to default implementation of default and move constructors on std::vector. As in _Rb_tree_impl the default allocator is not value initialized anymore. We could add a small helper type arround the allocator to do this value initialization per default. Should I do so ? It's required to be value-initialized, so if your patch changes that then it's a problem. Did we decide it's OK to do that for RB-trees? Did we actually discuss that part of the r243379 changes? N.B. defining these members as defaulted makes diagnostics worse, see PR 80858, but I think we need to fix that in the compiler anyway.
[PATCH] ICE with ~INT_MAX in fold-const.c (PR sanitizer/80875)
We ICE on this testcase in
9812 /* Transform x * -C into -x * C if x is easily negatable. */
9813 if (TREE_CODE (op1) == INTEGER_CST
9814 && tree_int_cst_sgn (op1) == -1
9815 && negate_expr_p (op0)
9816 && (tem = negate_expr (op1)) != op1
9817 && ! TREE_OVERFLOW (tem))
because fold_negate_expr returns NULL_TREE for INT_MIN, so negate_expr just
wrapped in into a NEGATE_EXPR, creating NEGATE_EXPR . TREE_OVERFLOW
crashes on that. I thought it made sense to check whether we can negate OP1
first, as done in the patch below.
Bootstrapped/regtested on x86_64-linux, ok for trunk and 7?
2017-05-25 Marek Polacek
PR sanitizer/80875
* fold-const.c (fold_binary_loc) : Check if OP1
can be negated.
* c-c++-common/ubsan/pr80875.c: New test.
diff --git gcc/fold-const.c gcc/fold-const.c
index efc0b10..911ae36 100644
--- gcc/fold-const.c
+++ gcc/fold-const.c
@@ -9813,6 +9813,7 @@ fold_binary_loc (location_t loc,
if (TREE_CODE (op1) == INTEGER_CST
&& tree_int_cst_sgn (op1) == -1
&& negate_expr_p (op0)
+ && negate_expr_p (op1)
&& (tem = negate_expr (op1)) != op1
&& ! TREE_OVERFLOW (tem))
return fold_build2_loc (loc, MULT_EXPR, type,
diff --git gcc/testsuite/c-c++-common/ubsan/pr80875.c
gcc/testsuite/c-c++-common/ubsan/pr80875.c
index e69de29..e679452 100644
--- gcc/testsuite/c-c++-common/ubsan/pr80875.c
+++ gcc/testsuite/c-c++-common/ubsan/pr80875.c
@@ -0,0 +1,9 @@
+/* PR sanitizer/80875 */
+/* { dg-do compile } */
+/* { dg-options "-fsanitize=undefined" } */
+
+int
+foo (void)
+{
+ return ~__INT_MAX__ * (0 / 0); /* { dg-warning "division by zero" } */
+}
Marek
Re: [PATCH] add more detail to -Wconversion and -Woverflow (PR 80731)
Thank you. The excess failures should be gone with r248464.
Some comments below.
On 05/25/2017 09:34 AM, Andreas Schwab wrote:
FAIL: gcc.dg/overflow-warn-9.c (test for warnings, line 59)
FAIL: gcc.dg/overflow-warn-9.c (test for warnings, line 60)
FAIL: gcc.dg/overflow-warn-9.c (test for warnings, line 62)
FAIL: gcc.dg/overflow-warn-9.c (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20170525/gcc/testsuite/gcc.dg/overflow-warn-9.c:62:9:
warning: signed conversion from 'long unsigned int' to 'long int' changes value
from '2147483648' to '-2147483648' [-Wsign-conversion]
These were ILP32 issues.
FAIL: gcc.dg/pr59963-2.c (test for warnings, line 16)
FAIL: gcc.dg/pr59963-2.c (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20170525/gcc/testsuite/gcc.dg/pr59963-2.c:16:6: warning:
overflow in conversion from 'long unsigned int' to 'short int' changes value
from '4294967295' to '-1' [-Woverflow]
FAIL: gcc.dg/pr60114.c (test for warnings, line 12)
FAIL: gcc.dg/pr60114.c (test for warnings, line 13)
FAIL: gcc.dg/pr60114.c (test for warnings, line 14)
FAIL: gcc.dg/pr60114.c (test for warnings, line 23)
FAIL: gcc.dg/pr60114.c (test for warnings, line 24)
FAIL: gcc.dg/pr60114.c (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20170525/gcc/testsuite/gcc.dg/pr60114.c:12:9: warning:
signed conversion from 'unsigned int' to 'int' changes value from '2147483648'
to '-2147483648' [-Wsign-conversion]
/daten/aranym/gcc/gcc-20170525/gcc/testsuite/gcc.dg/pr60114.c:13:11: warning:
signed conversion from 'unsigned int' to 'int' changes value from '2147483648'
to '-2147483648' [-Wsign-conversion]
/daten/aranym/gcc/gcc-20170525/gcc/testsuite/gcc.dg/pr60114.c:14:16: warning:
signed conversion from 'unsigned int' to 'int' changes value from '2147483648'
to '-2147483648' [-Wsign-conversion]
/daten/aranym/gcc/gcc-20170525/gcc/testsuite/gcc.dg/pr60114.c:23:17: warning:
overflow in conversion from 'int' to 'signed char' changes value from '256' to
'0' [-Woverflow]
/daten/aranym/gcc/gcc-20170525/gcc/testsuite/gcc.dg/pr60114.c:24:20: warning:
overflow in conversion from 'int' to 'signed char' changes value from '256' to
'0' [-Woverflow]
Besides verifying the right warning on each line, these tests
also verify the column number of each expected warning, e.g.,
like so (pr59963-2.c):
return f (0xL, /* { dg-warning "13:-Woverflow" } */
0xL) /* { dg-warning "13:-Woverflow" } */
&& f (0xL, /* { dg-warning "9:-Woverflow" } */
0xL); /* { dg-warning "9:-Woverflow" } */
The 13 is the 1-based column number corresponding to the number
of characters from the beginning of the line to the position
of the caret in the source file. To make things interesting,
the column number hardcoded into the tests is not the same as
what one sees in editors like emacs that use zerop-based column
numbers, or even others like vi that translate tabs into the
appropriate number of spaces. Some lines in some tests have
all spaces, others may have tabs. That's why above, the third
line has a lower column number than the two above it, even though
the caret on the third line is expected to be offset farther to
the right.
The script I use to apply patches after they have been approved
and retested one last time just before the final commit adjusts
whitespace to conform to the GNU coding standard (among other
things). In particular, it replaces blocks of 8 spaces with
tabs as the outdated rule still requires. That breaks these
assertions.
I'll change my script to avoid changing tests but I think the
long term solution is to eliminate the outdated requirement to
replace spaces with tabs. It serves no useful purpose and only
makes things harder for us. Another option is to tweak either
DejaGnu or the GCC part of it to treat a tab the same as a block
of 8 spaces.
Martin
[C++ PATCH] Reimplement unqualified namespace lookup
This patch reimplements unqualified namespace lookup.
Unqualified lookup progresses from namespace X towards ::, stopping once
something is found. However, using directives are searched in parallel
at the common ancestor of the namespace containing the using directive
and the target it nominates.
The current algorithm precalculates the entire graph of using directives
for each namespace (this is O(N^2)), and then during the lookup iterates
over this list for each level of the namespace hierarchy (this is
O(M.N^2)). Thus we have an algorithm that is at least quadratic in both
time and space. Ow!
This reimplementation does away with the precalculation (Actually, I
haven't excised the precalc, we just ignore it for the moment). and
determines the common ancestor during the lookup. Because I introduced
NAMESPACE_DEPTH recently, the common ancestor check is trivial. If it
turns out too expensive (need data), there's a much better
representation that will avoid the O(M.N^2) cost.
We still append found functions one at a time. If you look carefully
I've removed the code that checked for duplicates. We can only get
duplicates if a function is named by both a using declaration and found
via a using directive (either finding another using declaration or the
original). I suspect this is a rare event, and we'll just take the hit
in joust during overload resolution. If I'm wrong (again, need data),
duplicate detection can be cheaper than it is currently because the
instances found be using declaration are all going to be at the front of
an overload list. We can optimize for that.
nathan
--
Nathan Sidwell
2017-05-25 Nathan Sidwell
gcc/cp/
Reimplement unqualified namespace lookup.
* name-lookup.c (name_lookup::using_pair,
name_lookup::using_queue): New typedefs.
(name_lookup::queue_namespace, name_lookup::do_queue_usings,
name_lookup::queue_usings): New.
(name_lookup::search_unqualified): New.
(merge_functions, same_entity_p, ambiguous_decl,
unqualified_namespace_lookup_1, unqualified_namespace_lookup,
lookup_using_namespace): Delete.
(lookup_name_real_1): Adjust.
gcc/testsuite/
* g++.dg/lookup/using17.C: Adjust diagnostics.
Index: cp/name-lookup.c
===
--- cp/name-lookup.c (revision 248462)
+++ cp/name-lookup.c (working copy)
@@ -151,6 +151,10 @@ find_local_binding (cp_binding_level *b,
struct name_lookup
{
public:
+ typedef std::pair using_pair;
+ typedef vec using_queue;
+
+public:
tree name; /* The identifier being looked for. */
tree value; /* A (possibly ambiguous) set of things found. */
tree type; /* A type that has been found. */
@@ -227,6 +231,16 @@ private:
bool search_usings (tree scope);
private:
+ using_queue *queue_namespace (using_queue *queue, int depth, tree scope);
+ using_queue *do_queue_usings (using_queue *queue, int depth, tree usings);
+ using_queue *queue_usings (using_queue *queue, int depth, tree usings)
+ {
+if (usings)
+ queue = do_queue_usings (queue, depth, usings);
+return queue;
+ }
+
+private:
void add_fns (tree);
void adl_expr (tree);
@@ -242,6 +256,9 @@ public:
/* Search namespace + inlines + maybe usings as qualified lookup. */
bool search_qualified (tree scope, bool usings = true);
+ /* Search namespace + inlines + usings as unqualified lookup. */
+ bool search_unqualified (tree scope, cp_binding_level *);
+
/* ADL lookup of ARGS. */
tree search_adl (tree fns, vec *args);
};
@@ -557,6 +574,101 @@ name_lookup::search_qualified (tree scop
return found;
}
+/* Add SCOPE to the unqualified search queue, recursively add its
+ inlines and those via using directives. */
+
+name_lookup::using_queue *
+name_lookup::queue_namespace (using_queue *queue, int depth, tree scope)
+{
+ if (see_and_mark (scope))
+return queue;
+
+ /* Record it. */
+ tree common = scope;
+ while (SCOPE_DEPTH (common) > depth)
+common = CP_DECL_CONTEXT (common);
+ vec_safe_push (queue, using_pair (common, scope));
+
+ /* Queue its inline children. */
+ for (tree inner = NAMESPACE_LEVEL (scope)->namespaces;
+ inner; inner = TREE_CHAIN (inner))
+if (DECL_NAMESPACE_INLINE_P (inner))
+ queue = queue_namespace (queue, depth, inner);
+
+ /* Queue its using targets. */
+ queue = queue_usings (queue, depth, DECL_NAMESPACE_USING (scope));
+
+ return queue;
+}
+
+/* Add the namespaces in USINGS to the unqualified search queue. */
+
+name_lookup::using_queue *
+name_lookup::do_queue_usings (using_queue *queue, int depth, tree usings)
+{
+ for (; usings; usings = TREE_CHAIN (usings))
+if (!TREE_INDIRECT_USING (usings))
+ queue = queue_namespace (queue, depth, TREE_PURPOSE (usings));
+
+ return queue;
+}
+
+/* Unqualified namespace lookup in SCOPE.
+ 1) add scope+inlins to worklist.
+ 2) recursively add target of every using directive
+ 3) for each worklist item where SCOPE is common
Re: [patch, libfortran] AMD-specific versions of library matmul
On Thu, May 25, 2017 at 1:45 PM, Thomas Koenig wrote:
> Hello world,
>
> the attached patch speeds up the library version of matmul for AMD chips
> by selecting AVX128 instructions and, depending on which instructions
> are supported, either FMA3 (aka FMA) or FMA4.
>
> Jerry tested this on his AMD systems, and found a speedup vs. the
> current code of around 10%.
>
> I have been unable to test this on a Ryzen system (the new compile farm
> machines won't accept my login yet). From the benchmarks I have read,
> this method should also work fairly well on a Ryzen.
>
> So, OK for trunk?
In some comments, you have -mprefer=avx128 whereas the option that gcc
understands is -mprefer-avx128. Also, have you verified that e.g.
contemporary Intel processors still use the avx256 codepath and don't
accidentally end up with avx128?
As for FMA4, are there sufficient numbers of processors supporting
FMA4 but not FMA3 around to justify bloating the library to support
them? I understood that this is only a single AMD CPU generation
("bulldozer" in 2011), the next one ("piledriver" in 2012) added FMA3
in addition to FMA4. And in the new Zen core (Ryzen, Epyc, etc.) AMD
has dropped support for FMA4 although there are reports that it will
still execute FMA4 for backward compatibility although it's no longer
advertised in CPUID, but in any case AMD seems to consider it a legacy
instruction that should not be used anymore (Intel never supported
it).
--
Janne Blomqvist
[PATCH TEST]Adapt test case gcc.target/i386/l_fma_double_1.c
Hi,
Test gcc.target/i386/l_fma_double_1.c depends on how many times prolog/epilog
loops are unrolled.
This patch adapts the test strings in line with patch at
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01689.html
Bootstrap and test in series on x86_64. Is it OK?
Thanks,
bin
gcc/testsuite/ChangeLog
2017-05-11 Bin Cheng
* gcc.target/i386/l_fma_double_1.c: Adjust test strings.From 366a250f9fded486523f0ad1dfcc07595e7b5eeb Mon Sep 17 00:00:00 2001
From: Bin Cheng
Date: Wed, 19 Apr 2017 14:45:58 +0100
Subject: [PATCH 9/9] adjust-l_fma_tests.txt
---
gcc/testsuite/gcc.target/i386/l_fma_double_1.c | 8
gcc/testsuite/gcc.target/i386/l_fma_double_2.c | 8
gcc/testsuite/gcc.target/i386/l_fma_double_3.c | 8
gcc/testsuite/gcc.target/i386/l_fma_double_4.c | 8
gcc/testsuite/gcc.target/i386/l_fma_double_5.c | 8
gcc/testsuite/gcc.target/i386/l_fma_double_6.c | 8
gcc/testsuite/gcc.target/i386/l_fma_float_1.c | 8
gcc/testsuite/gcc.target/i386/l_fma_float_2.c | 8
gcc/testsuite/gcc.target/i386/l_fma_float_3.c | 8
gcc/testsuite/gcc.target/i386/l_fma_float_4.c | 8
gcc/testsuite/gcc.target/i386/l_fma_float_5.c | 8
gcc/testsuite/gcc.target/i386/l_fma_float_6.c | 8
12 files changed, 48 insertions(+), 48 deletions(-)
diff --git a/gcc/testsuite/gcc.target/i386/l_fma_double_1.c b/gcc/testsuite/gcc.target/i386/l_fma_double_1.c
index c8ea28a..94e512b 100644
--- a/gcc/testsuite/gcc.target/i386/l_fma_double_1.c
+++ b/gcc/testsuite/gcc.target/i386/l_fma_double_1.c
@@ -13,7 +13,7 @@ typedef double adouble __attribute__((aligned(sizeof (double;
/* { dg-final { scan-assembler-times "vfmsub\[123\]+pd" 8 } } */
/* { dg-final { scan-assembler-times "vfnmadd\[123\]+pd" 8 } } */
/* { dg-final { scan-assembler-times "vfnmsub\[123\]+pd" 8 } } */
-/* { dg-final { scan-assembler-times "vfmadd\[123\]+sd" 80 } } */
-/* { dg-final { scan-assembler-times "vfmsub\[123\]+sd" 80 } } */
-/* { dg-final { scan-assembler-times "vfnmadd\[123\]+sd" 80 } } */
-/* { dg-final { scan-assembler-times "vfnmsub\[123\]+sd" 80 } } */
+/* { dg-final { scan-assembler-times "vfmadd\[123\]+sd" 56 } } */
+/* { dg-final { scan-assembler-times "vfmsub\[123\]+sd" 56 } } */
+/* { dg-final { scan-assembler-times "vfnmadd\[123\]+sd" 56 } } */
+/* { dg-final { scan-assembler-times "vfnmsub\[123\]+sd" 56 } } */
diff --git a/gcc/testsuite/gcc.target/i386/l_fma_double_2.c b/gcc/testsuite/gcc.target/i386/l_fma_double_2.c
index bd873bc..ffceab4 100644
--- a/gcc/testsuite/gcc.target/i386/l_fma_double_2.c
+++ b/gcc/testsuite/gcc.target/i386/l_fma_double_2.c
@@ -13,7 +13,7 @@ typedef double adouble __attribute__((aligned(sizeof (double;
/* { dg-final { scan-assembler-times "vfmsub\[123\]+pd" 8 } } */
/* { dg-final { scan-assembler-times "vfnmadd\[123\]+pd" 8 } } */
/* { dg-final { scan-assembler-times "vfnmsub\[123\]+pd" 8 } } */
-/* { dg-final { scan-assembler-times "vfmadd\[123\]+sd" 80 } } */
-/* { dg-final { scan-assembler-times "vfmsub\[123\]+sd" 80 } } */
-/* { dg-final { scan-assembler-times "vfnmadd\[123\]+sd" 80 } } */
-/* { dg-final { scan-assembler-times "vfnmsub\[123\]+sd" 80 } } */
+/* { dg-final { scan-assembler-times "vfmadd\[123\]+sd" 56 } } */
+/* { dg-final { scan-assembler-times "vfmsub\[123\]+sd" 56 } } */
+/* { dg-final { scan-assembler-times "vfnmadd\[123\]+sd" 56 } } */
+/* { dg-final { scan-assembler-times "vfnmsub\[123\]+sd" 56 } } */
diff --git a/gcc/testsuite/gcc.target/i386/l_fma_double_3.c b/gcc/testsuite/gcc.target/i386/l_fma_double_3.c
index 7677ecb..cdb4d33 100644
--- a/gcc/testsuite/gcc.target/i386/l_fma_double_3.c
+++ b/gcc/testsuite/gcc.target/i386/l_fma_double_3.c
@@ -13,7 +13,7 @@ typedef double adouble __attribute__((aligned(sizeof (double;
/* { dg-final { scan-assembler-times "vfmsub\[123\]+pd" 8 } } */
/* { dg-final { scan-assembler-times "vfnmadd\[123\]+pd" 8 } } */
/* { dg-final { scan-assembler-times "vfnmsub\[123\]+pd" 8 } } */
-/* { dg-final { scan-assembler-times "vfmadd\[123\]+sd" 80 } } */
-/* { dg-final { scan-assembler-times "vfmsub\[123\]+sd" 80 } } */
-/* { dg-final { scan-assembler-times "vfnmadd\[123\]+sd" 80 } } */
-/* { dg-final { scan-assembler-times "vfnmsub\[123\]+sd" 80 } } */
+/* { dg-final { scan-assembler-times "vfmadd\[123\]+sd" 56 } } */
+/* { dg-final { scan-assembler-times "vfmsub\[123\]+sd" 56 } } */
+/* { dg-final { scan-assembler-times "vfnmadd\[123\]+sd" 56 } } */
+/* { dg-final { scan-assembler-times "vfnmsub\[123\]+sd" 56 } } */
diff --git a/gcc/testsuite/gcc.target/i386/l_fma_double_4.c b/gcc/testsuite/gcc.target/i386/l_fma_double_4.c
index e5de796..dda487e 100644
--- a/gcc/testsuite/gcc.target/i386/l_fma_double_4.c
+++ b/gcc/testsuite/gcc.target/i386/l_fma_double_4.c
@@ -13,7 +13,7 @@ typedef double adouble __attribute__((aligned(sizeof (double;
/* { dg-final { scan-assembler-times "vfmsub\[123\]+pd" 8 } } */
/* { dg-final { scan-assembler-times "v
[PATCH TEST]Rectify test case gcc.dg/tree-ssa/ivopt_mult_4.c
Hi,
I believe this tests has been wrongly modified previously. It is to test that
the exit check on
pointer shouldn't be replaced by integer IV. Somehow GCC starts replacing the
check on
integer IV with pointer IV. It's valid, though inefficient. And somehow we
starting checking
this iv replacement. This patch rectifies it by specifically checking the
check on pointer
shouldn't be replaced.
Bootstrap and test in series on x86_64. Is it OK?
Thanks,
bin
gcc/testsuite/ChangeLog
2017-05-11 Bin Cheng
* gcc.dg/tree-ssa/ivopt_mult_4.c: Explicitly check comparison
on pointer should not be replaced.From e011b6952cc70a9582df51b672937934d4b85f29 Mon Sep 17 00:00:00 2001
From: Bin Cheng
Date: Wed, 19 Apr 2017 14:24:30 +0100
Subject: [PATCH 8/9] rectify-ivopt_mult_4.txt
---
gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_4.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_4.c b/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_4.c
index effb052..321c786 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_4.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_4.c
@@ -21,4 +21,4 @@ long foo(long* p, long* p2, int N1, int N2)
return s;
}
-/* { dg-final { scan-tree-dump "Replacing exit test" "ivopts"} } */
+/* { dg-final { scan-tree-dump-not "Replacing exit test: if \\(p" "ivopts"} } */
--
1.9.1
Re: [RFC 1/5] gcc: xtensa: allow XCHAL_* macros to be non-constant
On Mon, May 22, 2017 at 2:09 PM, Max Filippov wrote: > XCHAL_* macros from the xtensa-config.h are used in a number of places > that require them to be preprocessor constants. Rewrite these places so > that non-constant XCHAL_* definitions could be used there. > > 2017-05-22 Max Filippov > gcc/ > * config/xtensa/xtensa.c (xtensa_option_override): Append > MASK_CONST16 to target_flags in the absence of TARGET_L32R. > (hwloop_optimize, hwloop_fail, hwloop_pattern_reg, > xtensa_doloop_hooks): Define unconditionally. > (xtensa_reorg_loops): Only call reorg_loops in the presence of > TARGET_LOOPS. > * config/xtensa/xtensa.h (TARGET_L32R): New definition. > (TARGET_DEFAULT): Remove XCHAL_HAVE_L32R condition and account > for it in xtensa_option_override. > (HARD_FRAME_POINTER_IS_FRAME_POINTER, > HARD_FRAME_POINTER_IS_ARG_POINTER): New definitions. This is OK. Please apply.
Re: [RFC 2/5] gcc: xtensa: make configuration dynamic
On Mon, May 22, 2017 at 2:09 PM, Max Filippov wrote: > Now that XCHAL_* macros don't have to be preprocessor constants add > include/xtensa-dynconfig.h that defines them as fields of a structure > returned from the xtensa_get_config function. > Define that structure and fill it with default parameter values > specified in the include/xtensa-config.h. > Define reusable function xtensa_load_config that tries to load > configuration and return an address of an exported object from it. > Define the function xtensa_get_config that uses xtensa_load_config to > get structure xtensa_config, either dynamically configured or the > default. > > 2017-05-22 Max Filippov > gcc/ > * Makefile.in (PLUGIN_HEADERS): Add include/xtensa-dynconfig.h. > * config.gcc (xtensa*-*-*): Add xtensa-config.o to extra_objs. > * gcc/config/xtensa/t-xtensa (xtensa-config.o): New rule. > * gcc/config/xtensa/xtensa-config.c: New file. > * gcc/config/xtensa/xtensa.h (xtensa-config.h): Replace #include > with xtensa-dynconfig.h > (XCHAL_HAVE_MUL32_HIGH, XCHAL_HAVE_RELEASE_SYNC, > XCHAL_HAVE_S32C1I, XCHAL_HAVE_THREADPTR, > XCHAL_HAVE_FP_POSTINC): Drop definitions. This almost certainly should go through the normal gcc plugin mechanism instead of the hand-rolled one you have here. https://gcc.gnu.org/onlinedocs/gccint/Plugins.html#Plugins If there is a reason it can't (and I'm not sufficiently familiar with the issues here), then you need to ensure that the various protections enforced by the normal plugin mechanism is used--and someone more knowledgeable than me needs to review it. Please note that by using a plugin mechanism, there are licensing issues that come into play, that are different from the usual licensing issues. I would be absolutely sure that you all are OK with how the runtime exception applies to this new situation.
[PATCH] Add attribute((target_clone(...))) to PowerPC
This patch adds the initial attribute((target_clone(...))) support to the PowerPC. It looks at the HWCAP bits for ISA 2.05 (power6), ISA 2.06 (power7), ISA 2.07 (power8) and ISA 3.0 (power9) to determine which clone function to run. The implementation used the existing i386/x86_64 support for target_clone as a template. At the moment, it has the same basic flaw that the i386/x86_64 implementation has, which is outside of the current module, the default version of the function is exported. It is only in the module that the function is defined in that supports calling the different target clones. I hope to add support in the future to make the exported function be the ifunc handler and not the default version. However, I wanted to get the basic framework into the compiler before tackling that issue. I have tested these patches on a little endian power8 system and there were no regressions. Can I install it into the trunk? [gcc] 2017-05-24 Michael Meissner * config/rs6000/rs6000.c (toplevel): Include attribs.h. (enum clone_list): New enumeration to give the target clones processors we generate code for. (rs6000_clone_map): New array to identify which clone processors the current program is running on. (TARGET_COMPARE_VERSION_PRIORITY): Define to enable the target_clone attribute. (TARGET_GENERATE_VERSION_DISPATCHER_BODY): Likewise. (TARGET_GET_FUNCTION_VERSIONS_DISPATCHER): Likewise. (TARGET_OPTION_FUNCTION_VERSIONS): Likewise. (cpu_expand_builtin): Add support for target_clone attribute. (rs6000_valid_attribute_p): Allow "default" attribute. (get_decl_name): New debug function to simplify printing the current function name in debugging statements. (rs6000_clone_priority): New functions to support the target_clone attribute, and be able to generate code to switch between ISA 2.05 through ISA 3.0 (power6 through power9). (rs6000_compare_version_priority): Likewise. (rs6000_get_function_versions_dispatcher): Likewise. (make_resolver_func): Likewise. (add_condition_to_bb): Likewise. (dispatch_function_versions): Likewise. (rs6000_generate_version_dispatcher_body): Likewise. (rs6000_can_inline_p): Call get_decl_name for debugging usage. * doc/extend.texi (Common Function Attributes): Document that the PowerPC supports the target_clone attribute. [gcc/testsuite] 2017-05-24 Michael Meissner * gcc.target/powerpc/clone1.c: New test. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
[C++ PATCH] Kill DECL_NAMESPACE_USERS, DECL_NAMESPACE_ASSOCIATIONS.
With namespace lookup reimplemented we need neither DECL_NAMESPACE_USERS
nor DECL_NAMESPACE_ASSOCIATIONS.
This patch nukes them.
The change in libcp1plugin.cc, which checks before setting will make
more sense when the next change to inline namespace representation lands.
nathan
--
Nathan Sidwell
2017-05-25 Nathan Sidwell
gcc/cp/
Kill DECL_NAMESPACE_USERS, DECL_NAMESPACE_ASSOCIATIONS.
* cp-tree.h (lang_decl_ns): Remove ns_users field.
(DECL_NAMESPACE_USERS, DECL_NAMESPACE_ASSOCIATIONS): Delete.
(TREE_INDIRECT_USING): Delete.
* name-lookup.h (is_associated_namespace): Delete.
* name-lookup.c (name_lookup::search_usings,
name_lookup::do_queue_usings): Usings are always direct.
(is_associated_namespace): Delete.
(handle_namespace_attrs): Use DECL_NAMESPACE_INLINE_P.
(namespace_ancestor_1, namespace_ancestor): Delete.
(push_using_directive_1, push_using_directive): Delete.
(add_using_namespace_1): Delete.
(add_using_namespace): Reimplement.
(emit_debug_info_using_namespace): New.
(finish_namespace_using_directive, finish_local_using_directive,
push_namespace): Adjust.
* tree.c (cp_free_lang_data): Remove DECL_NAMESPACE_USERS handling.
libcc1/
* libcp1plugin.cc (plugin_make_namespace_inline): Check and set
DECL_NAMESPACE_INLINE_P.
gcc/testsuite/
* g++.dg/lookup/using56.C: New.
* g++.dg/lookup/using57.C: New.
* g++.dg/lookup/using58.C: New.
* g++.dg/lookup/using59.C: New.
Index: gcc/cp/cp-tree.h
===
--- gcc/cp/cp-tree.h (revision 248457)
+++ gcc/cp/cp-tree.h (working copy)
@@ -328,7 +328,6 @@ extern GTY(()) tree cp_global_trees[CPTI
BASELINK_QUALIFIED_P (in BASELINK)
TARGET_EXPR_IMPLICIT_P (in TARGET_EXPR)
TEMPLATE_PARM_PARAMETER_PACK (in TEMPLATE_PARM_INDEX)
- TREE_INDIRECT_USING (in a TREE_LIST of using-directives)
ATTR_IS_DEPENDENT (in the TREE_LIST for an attribute)
ABI_TAG_IMPLICIT (in the TREE_LIST for the argument of abi_tag)
CONSTRUCTOR_IS_DIRECT_INIT (in CONSTRUCTOR)
@@ -2513,7 +2512,6 @@ struct GTY(()) lang_decl_ns {
struct lang_decl_base base;
cp_binding_level *level;
tree ns_using;
- tree ns_users;
};
/* DECL_LANG_SPECIFIC for parameters. */
@@ -3085,15 +3083,6 @@ struct GTY(()) lang_decl {
that is the common ancestor. */
#define DECL_NAMESPACE_USING(NODE) (LANG_DECL_NS_CHECK (NODE)->ns_using)
-/* In a NAMESPACE_DECL, the DECL_INITIAL is used to record all users
- of a namespace, to record the transitive closure of using namespace. */
-#define DECL_NAMESPACE_USERS(NODE) (LANG_DECL_NS_CHECK (NODE)->ns_users)
-
-/* In a NAMESPACE_DECL, the list of namespaces which have associated
- themselves with this one. */
-#define DECL_NAMESPACE_ASSOCIATIONS(NODE) \
- DECL_INITIAL (NAMESPACE_DECL_CHECK (NODE))
-
/* In a NAMESPACE_DECL, points to the original namespace if this is
a namespace alias. */
#define DECL_NAMESPACE_ALIAS(NODE) \
@@ -3107,10 +3096,6 @@ struct GTY(()) lang_decl {
&& CP_DECL_CONTEXT (NODE) == global_namespace \
&& DECL_NAME (NODE) == std_identifier)
-/* In a TREE_LIST concatenating using directives, indicate indirect
- directives */
-#define TREE_INDIRECT_USING(NODE) TREE_LANG_FLAG_0 (TREE_LIST_CHECK (NODE))
-
/* In a TREE_LIST in an attribute list, indicates that the attribute
must be applied at instantiation time. */
#define ATTR_IS_DEPENDENT(NODE) TREE_LANG_FLAG_0 (TREE_LIST_CHECK (NODE))
Index: gcc/cp/name-lookup.c
===
--- gcc/cp/name-lookup.c (revision 248465)
+++ gcc/cp/name-lookup.c (working copy)
@@ -533,8 +533,7 @@ name_lookup::search_usings (tree scope)
/* Look in direct usings. */
for (tree usings = DECL_NAMESPACE_USING (scope);
usings; usings = TREE_CHAIN (usings))
-if (!TREE_INDIRECT_USING (usings))
- found |= search_qualified (TREE_PURPOSE (usings), true);
+found |= search_qualified (TREE_PURPOSE (usings), true);
/* Look in its inline children. */
for (tree inner = NAMESPACE_LEVEL (scope)->namespaces;
@@ -607,8 +606,7 @@ name_lookup::using_queue *
name_lookup::do_queue_usings (using_queue *queue, int depth, tree usings)
{
for (; usings; usings = TREE_CHAIN (usings))
-if (!TREE_INDIRECT_USING (usings))
- queue = queue_namespace (queue, depth, TREE_PURPOSE (usings));
+queue = queue_namespace (queue, depth, TREE_PURPOSE (usings));
return queue;
}
@@ -1019,7 +1017,6 @@ static void consider_binding_level (tree
cp_binding_level *lvl,
bool look_within_fields,
enum lookup_name_fuzzy_kind kind);
-static tree push_using_directive (tree);
static void diagnose_name_conflict (tree, tree);
/* ADL lookup of NAME. FNS is the result of regular lookup, and we
@@ -1036,47 +1033,6 @@ lookup_arg_dependent (tree name, tree fn
return fns;
}
-/* Returns true iff CURRENT has declared itself to be an associated
- namespace of SCOPE via a s
Re: [C++ PATCH] Fix -Wunused with C++17 structured bindings
OK, thanks.
On Thu, May 25, 2017 at 10:22 AM, Jakub Jelinek wrote:
> On Wed, May 24, 2017 at 12:13:40PM -0400, Jason Merrill wrote:
>> On Wed, May 24, 2017 at 2:48 AM, Jakub Jelinek wrote:
>> > On Tue, May 23, 2017 at 09:45:10PM -0400, Jason Merrill wrote:
>> >> Someone on IRC complained that there was no way to suppress -Wunused
>> >> on structured bindings. It seemed to me that the way the feature
>> >> works, we shouldn't warn about the bindings individually; users need
>> >> to give each of the subobjects a name even if they're only interested
>> >> in using one of them.
>> >>
>> >> So this patch switches to tracking whether the underlying aggregate
>> >> object as a whole is used; using one of the bindings will avoid any
>> >> warning.
>> >>
>> >> This doesn't apply to tuple structured bindings, since in that case
>> >> the bindings are actual variables rather than aliases to subobjects.
>> >
>> > So, shall we have even for the tuple structured bindings somewhere (in
>> > lang_decl, such as adding struct lang_decl_decomp that would include
>> > lang_decl_min?) the tree for the underlying artificial var decl?
>>
>> That would make sense.
>
> So like this (so far lightly tested)? As DECL_DECOMPOSITION_P bit
> sits in DECL_LANG_SPECIFIC, it is not possible to set that bit first and
> then retrofit_lang_decl, so I had to play some games with that.
>
> There is one issue I've noticed in your earlier patch (fixed in this patch),
> we have separate DECL_HAS_VALUE_EXPR_P bit and DECL_VALUE_EXPR, testing
> the former is cheap, the latter is an expensive function call.
> So
> if (DECL_VALUE_EXPR (exp))
> mark_exp_read (DECL_VALUE_EXPR (exp));
> is something unnecessarily expensive for all vars, while
> if (DECL_HAS_VALUE_EXPR_P (exp))
> mark_exp_read (DECL_VALUE_EXPR (exp));
> or
> if (DECL_HAS_VALUE_EXPR_P (exp))
> {
> tree t = DECL_VALUE_EXPR (exp);
> if (t)
> mark_exp_read (t);
> }
> is much cheaper. I believe usually DECL_VALUE_EXPR should be non-NULL
> if DECL_HAS_VALUE_EXPR_P, but am not 100% sure if it is always guaranteed
> (but pretty sure lots of code would break if it is not).
>
> 2017-05-25 Jakub Jelinek
>
> * cp-tree.h (struct lang_decl_decomp): New type.
> (struct lang_decl): Add u.decomp.
> (LANG_DECL_DECOMP_CHECK): Define.
> (DECL_DECOMPOSITION_P): Note it is set also on the vars
> for user identifiers.
> (DECL_DECOMP_BASE): Define.
> (retrofit_lang_decl): Add extra int = 0 argument.
> * lex.c (retrofit_lang_decl): Add SEL argument, if non-zero
> use it to influence the selector choices and for selector
> 0 to non-zero transition copy old content.
> (cxx_dup_lang_specific_decl): Handle DECL_DECOMPOSITION_P.
> * decl.c (poplevel): For DECL_DECOMPOSITION_P, check
> !DECL_DECOMP_BASE instead of !DECL_VALUE_EXPR. Adjust warning
> wording if decl is a structured binding.
> (cp_finish_decomp): Pass 4 as the new argument to retrofit_lang_decl.
> Set DECL_DECOMP_BASE. Ignore DECL_READ_P sets from initialization
> of individual variables for tuple structured bindings.
> (grokdeclarator): Pass 4 as the new argument to retrofit_lang_decl.
> Clear DECL_DECOMP_BASE.
> * decl2.c (mark_used): Mark DECL_DECOMP_BASE TREE_USED as well.
> * pt.c (tsubst_decomp_names): Assert DECL_DECOMP_BASE matches what
> is expected.
> * expr.c (mark_exp_read): Recurse on DECL_DECOMP_BASE instead of
> DECL_VALUE_EXPR.
>
> * g++.dg/cpp1z/decomp29.C (p): New variable.
> (main): Add further tests.
>
> --- gcc/cp/cp-tree.h.jj 2017-05-25 10:37:00.0 +0200
> +++ gcc/cp/cp-tree.h2017-05-25 12:48:34.828167911 +0200
> @@ -2516,6 +2516,15 @@ struct GTY(()) lang_decl_parm {
>int index;
> };
>
> +/* Additional DECL_LANG_SPECIFIC information for structured bindings. */
> +
> +struct GTY(()) lang_decl_decomp {
> + struct lang_decl_min min;
> + /* The artificial underlying "e" variable of the structured binding
> + variable. */
> + tree base;
> +};
> +
> /* DECL_LANG_SPECIFIC for all types. It would be nice to just make this a
> union rather than a struct containing a union as its only field, but
> tree.h declares it as a struct. */
> @@ -2527,6 +2536,7 @@ struct GTY(()) lang_decl {
> struct lang_decl_fn GTY ((tag ("1"))) fn;
> struct lang_decl_ns GTY((tag ("2"))) ns;
> struct lang_decl_parm GTY((tag ("3"))) parm;
> +struct lang_decl_decomp GTY((tag ("4"))) decomp;
>} u;
> };
>
> @@ -2563,6 +2573,13 @@ struct GTY(()) lang_decl {
> lang_check_failed (__FILE__, __LINE__, __FUNCTION__); \
><->u.parm; })
>
> +#define LANG_DECL_DECOMP_CHECK(NODE) __extension__ \
> +({ struct lang_decl *lt = DECL_LANG_SPECIFIC (NODE); \
> + if (!VAR_P (NODE)
Re: [C++ PATCH] Reimplement ADL
On Thu, May 25, 2017 at 9:03 AM, Nathan Sidwell wrote: > Anyway, this implementation introduces LOOKUP_SEEN_P and LOOKUP_FOUND_P to > directly mark the DECL node. Hence determination is now O(1) rather than > O(N^2). We still have a vector to recall which decls we need to unmark at > the end of the lookup. We need two markers on a class, because depending on > how we found it we may need to search additional things about it. (These two > maker bits will be used in later changes too.) > > One quirk is that ADL can be recursive. ADL can cause template > instantiation, which can in turn cause a different ADL to happen. The new > testcase is an example of this. So, we need to detect this and undo/redo > the outer DECL marking during the inner ADL. Thus implementing a simple > chain of ADLs and using their record of which decls got marked to undo/redo. > The fiddly bit there is recording whether LOOKUP_FOUND_P was set or not > (LOOKUP_SEEN_P will be). To record that I simply push those DECLS with > lookup_found_p set onto the stack. They'll thus appear twice, and we can > infer from the second sighting that it had FOUND_P set (and pop the stack). > The recursion is a rare event, so we optimize the non-recursive case. Sounds like it would make sense to use a hash_set rather than flags on the decls. Jason
Re: [C++ PATCH] Reimplement ADL
On 05/25/2017 03:07 PM, Jason Merrill wrote: The recursion is a rare event, so we optimize the non-recursive case. Sounds like it would make sense to use a hash_set rather than flags on the decls. I don't think that would be a win. Although both are O(1), the constant factor is greater for the hash_set. As I said, it is rare -- I think there was only once instance in building libstdc++ or in its testsuite, I can't recall which. The cost of fixing it up is pretty cheap anyway -- iterate over the vector of seen scopes. nathan -- Nathan Sidwell
Re: [PATCH] Match x86 family machine constraints section with constarints.md
On Thu, May 25, 2017 at 8:22 AM, Peryt, Sebastian wrote: > Hi, > > Thank you very much for the answers. Can someone please commit this patch for > me? Committed as r248468. Uros.
Re: [PATCH] Add attribute((target_clone(...))) to PowerPC
On Thu, May 25, 2017 at 8:25 PM, Michael Meissner wrote: > This patch adds the initial attribute((target_clone(...))) support to the Patch seems to be missing. Florian
Re: [PATCH] Add attribute((target_clone(...))) to PowerPC
On Thu, May 25, 2017 at 09:56:20PM +0200, Florian Weimer wrote:
> On Thu, May 25, 2017 at 8:25 PM, Michael Meissner
> wrote:
> > This patch adds the initial attribute((target_clone(...))) support to the
>
> Patch seems to be missing.
>
> Florian
>
Sorry about that.
This patch adds the initial attribute((target_clone(...))) support to the
PowerPC. It looks at the HWCAP bits for ISA 2.05 (power6), ISA 2.06 (power7),
ISA 2.07 (power8) and ISA 3.0 (power9) to determine which clone function to
run. The implementation used the existing i386/x86_64 support for target_clone
as a template.
At the moment, it has the same basic flaw that the i386/x86_64 implementation
has, which is outside of the current module, the default version of the
function is exported. It is only in the module that the function is defined in
that supports calling the different target clones. I hope to add support in
the future to make the exported function be the ifunc handler and not the
default version. However, I wanted to get the basic framework into the
compiler before tackling that issue.
I have tested these patches on a little endian power8 system and there were no
regressions. Can I install it into the trunk?
[gcc]
2017-05-24 Michael Meissner
* config/rs6000/rs6000.c (toplevel): Include attribs.h.
(enum clone_list): New enumeration to give the target clones
processors we generate code for.
(rs6000_clone_map): New array to identify which clone processors
the current program is running on.
(TARGET_COMPARE_VERSION_PRIORITY): Define to enable the
target_clone attribute.
(TARGET_GENERATE_VERSION_DISPATCHER_BODY): Likewise.
(TARGET_GET_FUNCTION_VERSIONS_DISPATCHER): Likewise.
(TARGET_OPTION_FUNCTION_VERSIONS): Likewise.
(cpu_expand_builtin): Add support for target_clone attribute.
(rs6000_valid_attribute_p): Allow "default" attribute.
(get_decl_name): New debug function to simplify printing the
current function name in debugging statements.
(rs6000_clone_priority): New functions to support the target_clone
attribute, and be able to generate code to switch between ISA 2.05
through ISA 3.0 (power6 through power9).
(rs6000_compare_version_priority): Likewise.
(rs6000_get_function_versions_dispatcher): Likewise.
(make_resolver_func): Likewise.
(add_condition_to_bb): Likewise.
(dispatch_function_versions): Likewise.
(rs6000_generate_version_dispatcher_body): Likewise.
(rs6000_can_inline_p): Call get_decl_name for debugging usage.
* doc/extend.texi (Common Function Attributes): Document that the
PowerPC supports the target_clone attribute.
[gcc/testsuite]
2017-05-24 Michael Meissner
* gcc.target/powerpc/clone1.c: New test.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c
(.../svn+ssh://meiss...@gcc.gnu.org/svn/gcc/trunk/gcc/config/rs6000)
(revision 248378)
+++ gcc/config/rs6000/rs6000.c (.../gcc/config/rs6000) (working copy)
@@ -42,6 +42,7 @@
#include "flags.h"
#include "alias.h"
#include "fold-const.h"
+#include "attribs.h"
#include "stor-layout.h"
#include "calls.h"
#include "print-tree.h"
@@ -384,6 +385,34 @@ static const struct
{ "ieee128", PPC_FEATURE2_HAS_IEEE128, 1 }
};
+/* On PowerPC, we have a limited number of target clones that we care about
+ which means we can use an array to hold the options, rather than having more
+ elaborate data structures to identify each possible variation. Order the
+ clones from the highest ISA to the least. */
+enum clone_list {
+ CLONE_ISA_3_00, /* ISA 3.00 (power9). */
+ CLONE_ISA_2_07, /* ISA 2.07 (power8). */
+ CLONE_ISA_2_06, /* ISA 2.06 (power7). */
+ CLONE_ISA_2_05, /* ISA 2.05 (power6). */
+ CLONE_DEFAULT, /* default clone. */
+ CLONE_MAX
+};
+
+/* Map compiler ISA bits into HWCAP names. */
+struct clone_map {
+ HOST_WIDE_INT isa_mask; /* rs6000_isa mask */
+ const char *name;/* name to use in __builtin_cpu_supports. */
+};
+
+static const struct clone_map rs6000_clone_map[ (int)CLONE_MAX ] = {
+ { OPTION_MASK_P9_VECTOR, "arch_3_00" }, /* ISA 3.00 (power9). */
+ { OPTION_MASK_P8_VECTOR, "arch_2_07" }, /* ISA 2.07 (power8). */
+ { OPTION_MASK_POPCNTD, "arch_2_06" }, /* ISA 2.06 (power7). */
+ { OPTION_MASK_CMPB, "arch_2_05" }, /* ISA 2.05 (power6). */
+ { 0, "" }, /* Default options. */
+};
+
+
/* Newer LIBCs explicitly export this symbol to declare that they provide
the AT_PLATFORM and AT_HWCAP/AT_HWCAP2 values in the TCB.
Re: Web page for binaries
On Thu, 25 May 2017, Mike Stump wrote: >> I’m suggesting we apply the following patch to provide links to macOS >> package managers, where users can download binaries for GCC on macOS. I >> have included the two major ones, Homebrew and MacPorts. > I'm not against it. :-) I'd let the doc people comment on linking, > as they keep up on all the rules. I think those links are fine. This looks fine, thanks. Just omit the slashes at the ends of the two URLs please. (If you paste them into Firefox, say, you'll notice they end up getting stripped. I don't have the RFC handy right now, but for domain names without directories the / hasn't been necessary for fifteen or so years.) Gerald
Re: [patch, libfortran] AMD-specific versions of library matmul
On 05/25/2017 10:20 AM, Janne Blomqvist wrote:
On Thu, May 25, 2017 at 1:45 PM, Thomas Koenig wrote:
Hello world,
the attached patch speeds up the library version of matmul for AMD chips
by selecting AVX128 instructions and, depending on which instructions
are supported, either FMA3 (aka FMA) or FMA4.
Jerry tested this on his AMD systems, and found a speedup vs. the
current code of around 10%.
I have been unable to test this on a Ryzen system (the new compile farm
machines won't accept my login yet). From the benchmarks I have read,
this method should also work fairly well on a Ryzen.
So, OK for trunk?
In some comments, you have -mprefer=avx128 whereas the option that gcc
understands is -mprefer-avx128. Also, have you verified that e.g.
contemporary Intel processors still use the avx256 codepath and don't
accidentally end up with avx128?
As for FMA4, are there sufficient numbers of processors supporting
FMA4 but not FMA3 around to justify bloating the library to support
them? I understood that this is only a single AMD CPU generation
("bulldozer" in 2011), the next one ("piledriver" in 2012) added FMA3
in addition to FMA4. And in the new Zen core (Ryzen, Epyc, etc.) AMD
has dropped support for FMA4 although there are reports that it will
still execute FMA4 for backward compatibility although it's no longer
advertised in CPUID, but in any case AMD seems to consider it a legacy
instruction that should not be used anymore (Intel never supported
it).
Good questions. I am testing this on Ryzen now. It does work as advertised. The
cpu flags only advertise FMA.
So I will be testing the older AMD machine which advertises FMA4 and FMA with
just the FMA flag and likewise the Ryzen with FMA4 and FMA.
I want to see if there is any breakage between the two generations of AMD I can
access.
Also Ryzen with and without -mprefer-avx128 will be tested.
I do not have an Intel box to test.
Regards,
Jerry
Re: [RFC 2/5] gcc: xtensa: make configuration dynamic
On Thu, May 25, 2017 at 11:24 AM, augustine.sterl...@gmail.com wrote: > On Mon, May 22, 2017 at 2:09 PM, Max Filippov wrote: >> Now that XCHAL_* macros don't have to be preprocessor constants add >> include/xtensa-dynconfig.h that defines them as fields of a structure >> returned from the xtensa_get_config function. >> Define that structure and fill it with default parameter values >> specified in the include/xtensa-config.h. >> Define reusable function xtensa_load_config that tries to load >> configuration and return an address of an exported object from it. >> Define the function xtensa_get_config that uses xtensa_load_config to >> get structure xtensa_config, either dynamically configured or the >> default. >> >> 2017-05-22 Max Filippov >> gcc/ >> * Makefile.in (PLUGIN_HEADERS): Add include/xtensa-dynconfig.h. >> * config.gcc (xtensa*-*-*): Add xtensa-config.o to extra_objs. >> * gcc/config/xtensa/t-xtensa (xtensa-config.o): New rule. >> * gcc/config/xtensa/xtensa-config.c: New file. >> * gcc/config/xtensa/xtensa.h (xtensa-config.h): Replace #include >> with xtensa-dynconfig.h >> (XCHAL_HAVE_MUL32_HIGH, XCHAL_HAVE_RELEASE_SYNC, >> XCHAL_HAVE_S32C1I, XCHAL_HAVE_THREADPTR, >> XCHAL_HAVE_FP_POSTINC): Drop definitions. > > This almost certainly should go through the normal gcc plugin > mechanism instead of the hand-rolled one you have here. > > https://gcc.gnu.org/onlinedocs/gccint/Plugins.html#Plugins > > If there is a reason it can't (and I'm not sufficiently familiar with > the issues here), then you need to ensure that the various protections > enforced by the normal plugin mechanism is used--and someone more > knowledgeable than me needs to review it. (adding Le-Chun Wu, current reviewer of the plugin code) I tried to use plugins initially, but the following considerations made me lean towards this implementation: - we don't actually need any of the functionality available to gcc plugins, we only need to provide a data structure that the compiler knows how to use; - using environment variable makes configuration transparent for gcc, all binutils and gdb, whereas using gcc plugin would require changing gcc invocation command line, which is not always possible; - this implementation is shared between gcc and binutils. OTOH using plugin with gcc suggests using plugin with binutils, where it's substantially different and not universally supported across different binutils components (particularly neither assembler nor objdump have any support for it); - gcc does not support plugins when built for windows host using MinGW; Does the above justify this implementation? If no, are there any suggestions how the above points may be addressed? > Please note that by using a plugin mechanism, there are licensing > issues that come into play, that are different from the usual > licensing issues. I would be absolutely sure that you all are OK with > how the runtime exception applies to this new situation. All code used for building the configuration shared object is either GPL (part of binutils) or MIT (xtensa configuration overlay), so it should be ok? -- Thanks. -- Max
[C++ PATCH] Kill OVL_CURRENT, OVL_NEXT
This patch finally expunges OVL_CURRENT & OVL_NEXT. Everything's
switched over to using the new iterators.
The use in check_explicit_specialization is temporary, until I enable 2D
overload sets, and then it'll just use lookup_add on the overload set.
nathan
--
Nathan Sidwell
2017-05-25 Nathan Sidwell
Kill OVL_CURRENT, OVL_NEXT.
* cp-tree.h (OVL_CURRENT, OVL_NEXT): Delete.
* name-lookup.c (set_decl_namespace): Use ovl_iterator.
(consider_binding_level): Use OVL_FIRST.
(cp_emit_debug_info_for_using): Use lkp_iterator.
* pt.c (check_explicit_specialization): Use ovl_iterator.
Index: cp-tree.h
===
--- cp-tree.h (revision 248467)
+++ cp-tree.h (working copy)
@@ -659,12 +659,6 @@ typedef struct ptrmem_cst * ptrmem_cst_t
(((struct tree_overload*)OVERLOAD_CHECK (NODE))->function)
#define OVL_CHAIN(NODE) TREE_CHAIN (NODE)
-/* Polymorphic access to FUNCTION and CHAIN. */
-#define OVL_CURRENT(NODE) \
- ((TREE_CODE (NODE) == OVERLOAD) ? OVL_FUNCTION (NODE) : (NODE))
-#define OVL_NEXT(NODE) \
- ((TREE_CODE (NODE) == OVERLOAD) ? TREE_CHAIN (NODE) : NULL_TREE)
-
/* If set, this was imported in a using declaration. */
#define OVL_USING_P(NODE) TREE_LANG_FLAG_1 (OVERLOAD_CHECK (NODE))
/* If set, this overload is a hidden decl. */
Index: name-lookup.c
===
--- name-lookup.c (revision 248467)
+++ name-lookup.c (working copy)
@@ -4275,13 +4275,13 @@ set_decl_namespace (tree decl, tree scop
friends in any namespace. */
if (friendp && DECL_USE_TEMPLATE (decl))
return;
- if (is_overloaded_fn (old))
+ if (OVL_P (old))
{
tree found = NULL_TREE;
- tree elt = old;
- for (; elt; elt = OVL_NEXT (elt))
+
+ for (ovl_iterator iter (old); iter; ++iter)
{
- tree ofn = OVL_CURRENT (elt);
+ tree ofn = *iter;
/* Adjust DECL_CONTEXT first so decls_match will return true
if DECL will match a declaration in an inline namespace. */
DECL_CONTEXT (decl) = DECL_CONTEXT (ofn);
@@ -4932,10 +4932,7 @@ consider_binding_level (tree name, best_
/* OVERLOADs or decls from using declaration are wrapped into
TREE_LIST. */
if (TREE_CODE (d) == TREE_LIST)
- {
- d = TREE_VALUE (d);
- d = OVL_CURRENT (d);
- }
+ d = OVL_FIRST (TREE_VALUE (d));
/* Don't use bindings from implicitly declared functions,
as they were likely misspellings themselves. */
@@ -6290,14 +6287,18 @@ cp_emit_debug_info_for_using (tree t, tr
t = BASELINK_FUNCTIONS (t);
/* FIXME: Handle TEMPLATE_DECLs. */
- for (t = OVL_CURRENT (t); t; t = OVL_NEXT (t))
-if (TREE_CODE (t) != TEMPLATE_DECL)
- {
- if (building_stmt_list_p ())
- add_stmt (build_stmt (input_location, USING_STMT, t));
- else
- (*debug_hooks->imported_module_or_decl) (t, NULL_TREE, context, false);
- }
+ for (lkp_iterator iter (t); iter; ++iter)
+{
+ tree fn = *iter;
+ if (TREE_CODE (fn) != TEMPLATE_DECL)
+ {
+ if (building_stmt_list_p ())
+ add_stmt (build_stmt (input_location, USING_STMT, fn));
+ else
+ debug_hooks->imported_module_or_decl (fn,
+ NULL_TREE, context, false);
+ }
+}
}
#include "gt-cp-name-lookup.h"
Index: pt.c
===
--- pt.c (revision 248466)
+++ pt.c (working copy)
@@ -2931,8 +2931,8 @@ check_explicit_specialization (tree decl
/* Glue all these conversion functions together
with those we already have. */
- for (; ovl; ovl = OVL_NEXT (ovl))
- fns = lookup_add (OVL_CURRENT (ovl), fns);
+ for (ovl_iterator iter (ovl); iter; ++iter)
+ fns = lookup_add (*iter, fns);
}
}
Re: C++ PATCH for testsuite failures with -std=c++17
On Thu, May 25, 2017 at 5:08 AM, Jakub Jelinek wrote:
> On Thu, May 25, 2017 at 10:51:56AM +0200, Jakub Jelinek wrote:
>> On Tue, May 09, 2017 at 04:37:16PM -0400, Jason Merrill wrote:
>> > For C++17 aggregate bases, we have started adding base fields for
>> > empty bases. The code for calculating whether a class is standard
>> > layout needs to ignore these.
>> >
>> > The C++17 mode diagnostic for direct-enum-init1.C was incorrect.
>> >
>> > Tested x86_64-pc-linux-gnu, applying to trunk.
>>
>> > commit 9a612cc30d4b3ef905ce45304545d8b99a3cf5b9
>> > Author: Jason Merrill
>> > Date: Tue May 9 14:15:38 2017 -0400
>> >
>> > * class.c (check_bases): Ignore empty bases.
>>
>> This should have referenced PR c++/80605 (and is also a 7 regression).
>>
>> > diff --git a/gcc/cp/class.c b/gcc/cp/class.c
>> > index fc71766..085dbc3 100644
>> > --- a/gcc/cp/class.c
>> > +++ b/gcc/cp/class.c
>> > @@ -1860,7 +1860,9 @@ check_bases (tree t,
>> >members */
>> > for (basefield = TYPE_FIELDS (basetype); basefield;
>> > basefield = DECL_CHAIN (basefield))
>> > - if (TREE_CODE (basefield) == FIELD_DECL)
>> > + if (TREE_CODE (basefield) == FIELD_DECL
>> > + && DECL_SIZE (basefield)
>> > + && !integer_zerop (DECL_SIZE (basefield)))
>>
>> Is that what we really want? I mean, shouldn't we at least also
>> check that the basefield we want to ignore is DECL_ARTIFICIAL,
>> or that it doesn't have DECL_NAME or something similar, to avoid
>> considering user fields with zero size the same?
>> I believe your change changes e.g.:
>> struct S { int a[0]; };
>> struct T : public S { int b[0]; int c; };
>> bool q = __is_standard_layout (T);
>> which previously e.g. with -std=gnu++14 emitted q = false, but
>> now emits q = true.
>
> We even have DECL_FIELD_IS_BASE macro, so can't the above be
> if (TREE_CODE (basefield) == FIELD_DECL
> && !DECL_FIELD_IS_BASE (basefield))
> or
> if (TREE_CODE (basefield) == FIELD_DECL
> && (!DECL_FIELD_IS_BASE (basefield)
> || (DECL_SIZE (basefield)
> && !integer_zerop (DECL_SIZE (basefield)
> or something similar?
Indeed, thanks.
commit 49096cb5bc6c629c619ac9b5e08b971867dd1fc1
Author: Jason Merrill
Date: Thu May 25 15:34:13 2017 -0400
PR c++/80605 - __is_standard_layout and zero-length array
* class.c (check_bases): Use DECL_FIELD_IS_BASE.
diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index 984fb09..eddc118 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -1842,8 +1842,8 @@ check_bases (tree t,
for (basefield = TYPE_FIELDS (basetype); basefield;
basefield = DECL_CHAIN (basefield))
if (TREE_CODE (basefield) == FIELD_DECL
- && DECL_SIZE (basefield)
- && !integer_zerop (DECL_SIZE (basefield)))
+ && !(DECL_FIELD_IS_BASE (basefield)
+ && integer_zerop (DECL_SIZE (basefield
{
if (field)
CLASSTYPE_NON_STD_LAYOUT (t) = 1;
diff --git a/gcc/testsuite/g++.dg/ext/is_std_layout2.C
b/gcc/testsuite/g++.dg/ext/is_std_layout2.C
new file mode 100644
index 000..02dc4f7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/is_std_layout2.C
@@ -0,0 +1,6 @@
+// { dg-do compile { target c++11 } }
+// { dg-options "" }
+
+struct S { int a[0]; };
+struct T : public S { int b[0]; int c; };
+static_assert(!__is_standard_layout (T), "");
Re: [patch, libfortran] AMD-specific versions of library matmul
Hi everybody, I have committed the patch (with the corrections for the name) as rev 248472. The infrastructure is in place, so we will be able to make any fine-tuning easily. Regards Thomas
[patch, committed] Add myself to MAINTAINERS
https://gcc.gnu.org/svnwrite.html#authenticated says "approval from the mailing list is not needed in this one case" so I've gone ahead and committed the attached patch. ChangeLog: 2017-05-25 Eric Gallager * MAINTAINERS: Add self to Write After Approval Index: MAINTAINERS === --- MAINTAINERS (revision 248474) +++ MAINTAINERS (working copy) @@ -387,6 +387,7 @@ Chao-ying Fu Gary Funck Pompapathi V Gadad +Eric Gallager Gopalasubramanian Ganesh Kaveh Ghazi Doug Gilmore
Re: [patch, libfortran] AMD-specific versions of library matmul
On 05/25/2017 02:57 PM, Thomas Koenig wrote: Hi everybody, I have committed the patch (with the corrections for the name) as rev 248472. The infrastructure is in place, so we will be able to make any fine-tuning easily. Regards Thomas Based on my testing I think it is close enough as is. Thanks Thomas Jerry
Re: [patch, libfortran] AMD-specific versions of library matmul
On Thu, May 25, 2017 at 6:43 PM, Jerry DeLisle wrote: > On 05/25/2017 02:57 PM, Thomas Koenig wrote: >> >> Hi everybody, >> >> I have committed the patch (with the corrections for the name) >> as rev 248472. >> >> The infrastructure is in place, so we will be able to make >> any fine-tuning easily. >> >> Regards >> >> Thomas > > > Based on my testing I think it is close enough as is. This patch most likely broke all non-x86 targets: configure: error: conditional "HAVE_AVX128" was never defined. Usually this means the macro was only invoked conditionally. Makefile:19843: recipe for target 'configure-target-libgfortran' failed make[1]: *** [configure-target-libgfortran] Error 1 make[1]: *** Waiting for unfinished jobs Thanks, Andrew > > Thanks Thomas > > Jerry
Re: [PING 2][PATCH] Move the check for any_condjump_p from sched-deps to target macros
Hi, Please consider this as a personal reminder to review the patch at following link and let me know your comments on the same. https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00839.html Thanks, Naveen
Re: [PING 3][PATCH][AArch64] Add addr_type attribute
Hi, Please consider this as a personal reminder to review the patch at following link and let me know your comments on the same. https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00222.html Thanks, Naveen
Re: [PING 3][PATCH] [AArch64] Implement automod load and store for Thunderx2t99
Hi, Please consider this as a personal reminder to review the patch at following link and let me know your comments on the same. https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00226.html Thanks, Naveen
Re: [PING 3][PATCH][AArch64] Add crypto_pmull attribute
Hi, Please consider this as a personal reminder to review the patch at following link and let me know your comments on the same. https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00504.html Thanks, Naveen
Re: [PING 3] [PATCH][AArch64] Add neon_pairwise_add & neon_pairwise_add_q types
Hi, Please consider this as a personal reminder to review the patch at following link and let me know your comments on the same. https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00505.html Thanks, Naveen
Re: [PING 2] [PATCH] [AArch64] PR target/71663 Improve Vector Initializtion
Hi, Please consider this as a personal reminder to review the patch at following link and let me know your comments on the same. https://gcc.gnu.org/ml/gcc-patches/2017-04/msg01260.html Thanks, Naveen
Re: [PING 2] [PATCH] [AArch64] vec_pack_trunc_ should split after register allocator
Hi, Please consider this as a personal reminder to review the patch at following link and let me know your comments on the same. https://gcc.gnu.org/ml/gcc-patches/2017-04/msg01334.html Thanks, Naveen
Re: [PING 2] [PATCH] [AArch64] Implement ALU_BRANCH fusion
Hi, Please consider this as a personal reminder to review the patch at following link and let me know your comments on the same. https://gcc.gnu.org/ml/gcc-patches/2017-04/msg01333.html Thanks, Naveen
