[PING][PATCH][compare-elim] Fix PR rtl-optimization/82597

[Michael Collison]

Ping. Original patch posted here:

https://gcc.gnu.org/ml/gcc-patches/2017-10/msg01317.html

Rename cxx1998 into normal

[François Dumont]

Hi

    We once talk about rename the __cxx1998 namespace into something 
less C++98 biased. Here is the patch to do so.


    Ok with the new name ?

    Tested under Linux x86_64 normal and debug modes.

    Note that pretty printers do not work with Debug mode but for the 
moment I checked the manually the output and it looks good. I'll try to 
make those work in a future patch.


François

diff --git a/libstdc++-v3/include/bits/c++config b/libstdc++-v3/include/bits/c++config
index 21e3fbb..919f269 100644
--- a/libstdc++-v3/include/bits/c++config
+++ b/libstdc++-v3/include/bits/c++config
@@ -192,7 +192,7 @@
 namespace __debug { }
 namespace __parallel { }
 namespace __profile { }
-namespace __cxx1998 { }
+namespace __normal { }
 
 namespace __detail {
   namespace __variant { }// C++17
@@ -317,7 +317,7 @@ namespace std
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   // Non-inline namespace for components replaced by alternates in active mode.
-  namespace __cxx1998
+  namespace __normal
   {
 # if _GLIBCXX_USE_CXX11_ABI
   inline namespace __cxx11 __attribute__((__abi_tag__ ("cxx11"))) { }
@@ -371,7 +371,7 @@ _GLIBCXX_END_NAMESPACE_VERSION
 // _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
 // _GLIBCXX_END_NAMESPACE_CONTAINER
 #if defined(_GLIBCXX_DEBUG) || defined(_GLIBCXX_PROFILE)
-# define _GLIBCXX_STD_C __cxx1998
+# define _GLIBCXX_STD_C __normal
 # define _GLIBCXX_BEGIN_NAMESPACE_CONTAINER \
 	 namespace _GLIBCXX_STD_C {
 # define _GLIBCXX_END_NAMESPACE_CONTAINER }
@@ -382,7 +382,7 @@ _GLIBCXX_END_NAMESPACE_VERSION
 #endif
 
 #ifdef _GLIBCXX_PARALLEL
-# define _GLIBCXX_STD_A __cxx1998
+# define _GLIBCXX_STD_A __normal
 # define _GLIBCXX_BEGIN_NAMESPACE_ALGO \
 	 namespace _GLIBCXX_STD_A {
 # define _GLIBCXX_END_NAMESPACE_ALGO }
diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py b/libstdc++-v3/python/libstdcxx/v6/printers.py
index b7b2a0f..3f928ea 100644
--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -1232,7 +1232,7 @@ class Printer(object):
 # Add a name using _GLIBCXX_BEGIN_NAMESPACE_CONTAINER.
 def add_container(self, base, name, function):
 self.add_version(base, name, function)
-self.add_version(base + '__cxx1998::', name, function)
+self.add_version(base + '__normal::', name, function)
 
 @staticmethod
 def get_basic_type(type):

Re: [006/nnn] poly_int: tree constants

[Martin Sebor]

On 10/25/2017 03:31 PM, Richard Sandiford wrote:

Martin Sebor  writes:

On 10/23/2017 11:00 AM, Richard Sandiford wrote:

+#if NUM_POLY_INT_COEFFS == 1
+extern inline __attribute__ ((__gnu_inline__)) poly_int64
+tree_to_poly_int64 (const_tree t)


I'm curious about the extern inline and __gnu_inline__ here and
not in poly_int_tree_p below.  Am I correct in assuming that
the combination is a holdover from the days when GCC was compiled
using a C compiler, and that the way to write the same definition
in C++ 98 is simply:

   inline poly_int64
   tree_to_poly_int64 (const_tree t)


+{
+  gcc_assert (tree_fits_poly_int64_p (t));
+  return TREE_INT_CST_LOW (t);
+}


If yes, I would suggest to use the C++ form (and at some point,
changing the existing uses of the GCC/C idiom to the C++ form
as well).

Otherwise, if something requires the use of the C form I would
suggest to add a brief comment explaining it.


You probably saw that this is based on tree_to_[su]hwi.  AIUI the
differences from plain C++ inline are that:

a) with __gnu_inline__, an out-of-line definition must still exist.
   That fits this use case well, because the inline is conditional on
   the #ifdef and tree.c has an out-of-line definition either way.
   If we used normal inline, we'd need to add extra #ifs to tree.c
   as well, to avoid multiple definitions.

b) __gnu_inline__ has the strength of __always_inline__, but without the
   correctness implications if inlining is impossible for any reason.
   I did try normal inline first, but it wasn't strong enough.  The
   compiler ended up measurably faster if I copied the tree_to_[su]hwi
   approach.


Thanks for the clarification.  I'm not sure I fully understand
it but I'm happy to take your word for it that's necessary.  I
would just recommend adding a brief comment to this effect since
it isn't obvious.


+
+inline bool
+poly_int_tree_p (const_tree t, poly_int64_pod *value)
+{

...


[This one is unconditionally inline.]


 /* The tree and const_tree overload templates.   */
 namespace wi
 {
+  class unextended_tree
+  {
+  private:
+const_tree m_t;
+
+  public:
+unextended_tree () {}


Defining no-op ctors is quite dangerous and error-prone.  I suggest
to instead default initialize the member(s):

   unextended_tree (): m_t () {}

Ditto everywhere else, such as in:


This is really performance-senesitive code though, so I don't think
we want to add any unnecessary initialisation.  Primitive types are
uninitalised by default too, and the point of this class is to
provide an integer-like interface.


I understand the performance concern (more on that below), but
to clarify the usability issues,  I don't think the analogy with
primitive types is quite fitting here: int() evaluates to zero,
as do the values of i and a[0] and a[1] after an object of type
S is constructed using its default ctor, i.e., S ():

  struct S {
int i;
int a[2];

S (): i (), a () { }
  };

With the new (and some existing) classes that's not so, and it
makes them harder and more error-prone to use (I just recently
learned this the hard way about offset_int and the debugging
experience is still fresh in my memory).

When the cor is inline and the initialization unnecessary then
GCC will in most instances eliminate it, so I also don't think
the suggested change would have a significant impact on
the efficiency of optimized code, but...

...if it is thought essential to provide a no-op ctor, I would
suggest to consider making its property explicit, e.g., like so:

  struct unextended_tree {

struct Uninit { };

// ...
unextended_tree (Uninit) { /* no initialization */ }
// ...
  };

This way the programmer has to explicitly opt in to using the
unsafe ctor.  (This ctor is suitable for single objects, not
arrays of such things, but presumably that would be sufficient.
If not, there are tricks to make that work too.)


In your other message you used the example of explicit default
initialisation, such as:

class foo
{
  foo () : x () {}
  unextended_tree x;
};

But I think we should strongly discourage that kind of thing.
If someone wants to initialise x to a particular value, like
integer_zero_node, then it would be better to do it explicitly.
If they don't care what the initial value is, then for these
integer-mimicing classes, uninitialised is as good as anything
else. :-)


Efficiency is certainly important, but it doesn't have to come
at the expense of usability or correctness.  I think it's possible
(and important) to design interfaces that are usable safely and
intuitively, and difficult to misuse, while also accommodating
advanced efficient use cases.


Note that for this class NULL_TREE is not a safe default value.
The same goes for the wide-int.h classes, where a length or precision
of 0 is undefined and isn't necessarily going to be handled gracefully
or predictably.


For offset_int both precision and length are known so I think
it would make sense to have 

Re: [C++ Patch] PR 80955 (Macros expanded in definition of user-defined literals)

[Mukesh Kapoor]

On 10/25/2017 4:20 AM, Nathan Sidwell wrote:

On 10/25/2017 12:03 AM, Mukesh Kapoor wrote:

Thanks for pointing this out. Checking in the front end will be 
difficult because the front end gets tokens after macro expansion. I 
think the difficulty of fixing this bug comes because of the 
requirement to maintain backward compatibility with the option 
-Wliteral-suffix for -std=c++11.


IIUC the warning's intent is to catch cases of:
printf ("some format"PRIx64 ..., ...);
where there's no space between the string literals and the PRIx64 
macro.  I suspect it's very common for there to be a following 
string-literal, so perhaps the preprocessor could detect:


NON-FN-MACRO

and warn on that sequence?


Yes, this can be done easily and this is also the usage mentioned in the 
man page. I made this change in the compiler, bootstrapped it and ran 
the tests. The following two tests fail after the fix:


g++.dg/cpp0x/Wliteral-suffix.C
g++.dg/cpp0x/warn_cxx0x4.C

Both tests have code similar to the following (from Wliteral-suffix.C):

#define BAR "bar"
#define PLUS_ONE + 1

  char c = '3'PLUS_ONE;   // { dg-warning "invalid suffix on literal" }
  char s[] = "foo"BAR;    // { dg-warning "invalid suffix on literal" }

Other compilers don't accept this code. Maybe I should just modify these 
tests to have error messages instead of warnings and submit my revised fix?


Mukesh



nathan

[PATCH] expand -fdebug-prefix-map documentation

[Jim Wilson]

The current documentation doesn't explain what the option is for, or
how one might use it.  The attached patch expands the documentation a
bit to try to explain this.

Tested with a make doc, and verifying that the gcc.info file looks OK.
 And tested by verifying that the option works the way I think it does..

OK?

Jim
2017-10-25  Jim Wilson  

gcc/
* doc/invoke.texi (-fdebug-prefix-map): Expand documentation.

Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 254023)
+++ gcc/doc/invoke.texi (working copy)
@@ -6981,7 +6981,12 @@ link processing time.  Merging is enabled by defau
 @item -fdebug-prefix-map=@var{old}=@var{new}
 @opindex fdebug-prefix-map
 When compiling files in directory @file{@var{old}}, record debugging
-information describing them as in @file{@var{new}} instead.
+information describing them as in @file{@var{new}} instead.  This can be
+used to replace a build time path with an install time path in the debug info.
+It can also be used to change an absolute path to a relative path by using
+@file{.} for @var{new}.  This can give more reproducible builds, which are
+location independent, but may require an extra command to tell gdb where to
+find the source files.
 
 @item -fvar-tracking
 @opindex fvar-tracking

Re: [PATCH] C: detect more missing semicolons (PR c/7356)

[David Malcolm]

On Wed, 2017-10-25 at 09:59 -0600, Jeff Law wrote:
> On 10/11/2017 01:32 PM, David Malcolm wrote:
> > [This patch assumes the two patches here:
> >  https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00274.html ]
> 
> I see the patch directly referenced in that message on the
> trunk.  But
> I'm not sure what you mean by "two patches".  If there's a prereq
> that
> hasn't been approved, let me know.

Sorry about the confusion; the one at the URL above was:

"[PATCH 2/2] C/C++: add fix-it hints for various missing symbols (v3)",

which is an updated version of:

"[PATCH 2/2] C/C++: add fix-it hints for various missing symbols (v2)"
https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01746.html

the other one I was referring to was:

"[PATCH 1/2] C++: avoid partial duplicate implementation of
cp_parser_error"
https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01745.html


Both these prereqs are in trunk (as r253686 and r253690 respectively).

> 
> > 
> > c_parser_declaration_or_fndef has logic for parsing what might be
> > either a declaration or a function definition.
> > 
> > This patch adds a test to detect cases where a semicolon would have
> > terminated the decls as a declaration, where the token that follows
> > would start a new declaration specifier, and updates the error
> > message
> > accordingly, with a fix-it hint.
> > 
> > This addresses PR c/7356, fixing the case of a stray token before a
> > #include which previously gave inscrutable output, and improving
> > e.g.:
> > 
> >   int i
> >   int j;
> > 
> > from:
> > 
> >   t.c:2:1: error: expected '=', ',', ';', 'asm' or '__attribute__'
> > before 'int'
> >int j;
> >^~~
> > 
> > to:
> > 
> >   t.c:1:6: error: expected ';' before 'int'
> >int i
> > ^
> > ;
> >int j;
> >~~~
> > 
> > The patch also adds a test for PR c/44515 as a baseline.
> 
> Personally I find the current error easier to digest.  It quite
> clearly
> tells me to look before the current token and shove in an appropriate
> thingie :-)   The extra vertical space, to me, makes the error
> message
> harder to parse.

You've been using gcc for multiple decades and are used to the existing
behavior, though ;)

> But I can see how others would prefer to see the point where the
> punctuation was missing.  So I won't let my biases get in the way
> here.

FWIW the benefit is a *lot* clearer for the first case described, where
the two locations are in different source files due to the missing
semicolon being immediately before a #include (PR c/7356), or at the
end of a header; it replaces dozens of crazy-looking errors with a
single sane one.

> > gcc/c/ChangeLog:
> > PR c/7356
> > * c-parser.c (c_parser_declaration_or_fndef): Detect missing
> > semicolons.
> > 
> > gcc/testsuite/ChangeLog:
> > PR c/7356
> > PR c/44515
> > * c-c++-common/pr44515.c: New test case.
> > * gcc.dg/pr7356-2.c: New test case.
> > * gcc.dg/pr7356.c: New test case.
> > * gcc.dg/spellcheck-typenames.c: Update the "singed" char
> > "TODO"
> > case to reflect changes to output.
> > * gcc.dg/noncompile/920923-1.c: Add dg-warning to reflect
> > changes
> > to output.
> 
> OK.

Thanks; committed to trunk as r254093 (and closing out PR c/7356 after
15 years!)

Dave

Re: [PATCH, version 5a], Add support for _Float and _FloatX sqrt, fma, fmin, fmax built-in functions

[Michael Meissner]

On Wed, Oct 25, 2017 at 07:57:09PM -0400, Michael Meissner wrote:
> On Wed, Oct 25, 2017 at 11:41:24PM +, Joseph Myers wrote:
> > My only comment on this version is that the documentation in cpp.texi of 
> > __FP_FAST_* should be updated to mention __FP_FAST_FMAF@var{n} and 
> > __FP_FAST_FMAF@var{n}X.
> 
> Here is the documentation to be added to the previoius patch.  With this
> change, can I check it into the trunk (once Segher approves of the minor bit 
> to
> take out the PowerPC __builtin_{sqrtf128,fmaf128} builtins.
> 
> 2017-10-25  Michael Meissner  
> 
>   * doc/cpp.texi (Common Predefined Macros): Document defining
>   __FP_FAST_FMAF and __FP_FAST_FMAFX if the back supports fma
>   _Float and _FloatX variants.

Sigh, it is the end of the day for me.  The ChangeLog should be:

2017-10-25  Michael Meissner  

* doc/cpp.texi (Common Predefined Macros): Document defining
__FP_FAST_FMAF and __FP_FAST_FMAFX if the backend supports
fma _Float and _FloatX variants.

-- 
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

Re: [PATCH], Enable IBM/IEEE long double format to overriden more easily

[Segher Boessenkool]

Hi Mike,

On Sat, Oct 21, 2017 at 09:09:58AM -0400, Michael Meissner wrote:
> As Segher and I were discussing off-line, I have some problems with the 
> current
> -mabi={ieee,ibm}longdouble switches as we start to planning to modify GCC 9 
> and
> GLIBC 2.27/2.28 to support __float128 as the default long double format for
> power server systems.
> 
> My gripes are:
> 
> 1)Using Warn() in rs6000.opt means that you get two warning 
> messages when
>   you use the switches (one from the driver, and one from cc1).
> 
> 2)I feel you should not get a warning if you select the option 
> that
>   reflects the current default behavior (i.e. -mabi=ibmlongdouble
>   currently for power server systems).
> 
> 3)There is no way to silenece the warning (i.e. -w doesn't work on
>   warnings in the .opt file).  Both GLIBC and LIBGCC will need the
>   ability to build support modules with an explicit long double format.
> 
> 4)In the future we will need a little more flexibility in how the 
> default
>   is set.
> 
> 5)There is a mis-match between the documentation and rs6000.opt, 
> as these
>   switches are documented, but use Undocumented in the rs6000.opt.

Agreed on all.

> These patches fix these issues.  If you use -Wno-psabi, it will silence the
> warning.  I have built these patches on a little endian power8 system, and
> there were no regressions.  Can I check these patches into the trunk?
> 
> 2017-10-21  Michael Meissner  
> 
>   * config/rs6000/aix.h (TARGET_IEEEQUAD_DEFAULT): Set long double
>   default to IBM.
>   * config/rs6000/darwin.h (TARGET_IEEEQUAD_DEFAULT): Likewise.
>   * config/rs6000/rs6000.opt (-mabi=ieeelongdouble): Move the
>   warning to rs6000.c.  Remove the Undocumented flag, since it has
>   been documented.
>   (-mabi=ibmlongdouble): Likewise.

And more importantly, we _want_ it to be documented (right)?

> --- gcc/config/rs6000/rs6000.opt  (revision 253961)
> +++ gcc/config/rs6000/rs6000.opt  (working copy)
> @@ -381,10 +381,10 @@ mabi=d32
>  Target RejectNegative Undocumented Warn(using old darwin ABI) 
> Var(rs6000_darwin64_abi, 0)
>  
>  mabi=ieeelongdouble
> -Target RejectNegative Undocumented Warn(using IEEE extended precision long 
> double) Var(rs6000_ieeequad) Save
> +Target RejectNegative Var(rs6000_ieeequad) Save
>  
>  mabi=ibmlongdouble
> -Target RejectNegative Undocumented Warn(using IBM extended precision long 
> double) Var(rs6000_ieeequad, 0)
> +Target RejectNegative Var(rs6000_ieeequad, 0)

Does this need "Save" as well?

> +  if (!warned_change_long_double && warn_psabi)
> + {
> +   warned_change_long_double = true;
> +   if (TARGET_IEEEQUAD)
> + warning (0, "Using IEEE extended precision long double");
> +   else
> + warning (0, "Using IBM extended precision long double");
> + }

You can put OPT_Wpsabi in place of that 0, it's what that arg is for :-)

Okay with that changed.  Thanks!


Segher

Re: [PATCH], Update __FLOAT128_HARDWARE__ on power9

[Michael Meissner]

On Wed, Oct 25, 2017 at 06:56:20PM -0500, Segher Boessenkool wrote:
> On Fri, Oct 20, 2017 at 04:56:41PM -0400, Michael Meissner wrote:
> > This is a simple patch to add a way that the GLIBC team call tell that 
> > certain
> > __float128 built-in functions are available.  While previous patches of mine
> > set __FAST_FP_FMAF128, which could be used for this purpose, this macro just
> > bumps __FLOAT128_HARDWARE__ to say that the built-in functions are 
> > available in
> > addition to supporting the basic IEEE 128-bit floating point instructions.
> 
> I don't think this is such a great macro name for this purpose.
> 
> What problem does this solve?

The problem was the GLIBC maintainers asked for some way to determine that the
compiler supports fast FMA and SQRT built-ins that generate the XSFMADDQP and
XSSQRTQP instructions on ISA 3.0.

Unfortunately, they can't just check the version number being >= 8 because the
patch might be back ported to older versions of GCC (specificaly the Advance
Toolchain 11.0-n).

At the time, I was struggling with getting the the machine independent support
for FMA, SQRT, etc. using _Float and _FloatX types done in the machine
independent portion of the compiler.  It looks like that is converging, so
assuming I get the approval to check it in, the GLIBC team will be able to
check whether __FP_FAST_FMAF128 is defined to do the same check.

In that case, I was going to suggest disregarding this patch.

-- 
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

Re: [PATCH, version 5a], Add support for _Float and _FloatX sqrt, fma, fmin, fmax built-in functions

[Michael Meissner]

On Wed, Oct 25, 2017 at 11:41:24PM +, Joseph Myers wrote:
> My only comment on this version is that the documentation in cpp.texi of 
> __FP_FAST_* should be updated to mention __FP_FAST_FMAF@var{n} and 
> __FP_FAST_FMAF@var{n}X.

Here is the documentation to be added to the previoius patch.  With this
change, can I check it into the trunk (once Segher approves of the minor bit to
take out the PowerPC __builtin_{sqrtf128,fmaf128} builtins.

2017-10-25  Michael Meissner  

* doc/cpp.texi (Common Predefined Macros): Document defining
__FP_FAST_FMAF and __FP_FAST_FMAFX if the back supports fma
_Float and _FloatX variants.

-- 
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/doc/cpp.texi
===
--- gcc/doc/cpp.texi(revision 254080)
+++ gcc/doc/cpp.texi(working copy)
@@ -2366,6 +2366,21 @@ the include file @file{math.h} can defin
 @code{FP_FAST_FMA}, @code{FP_FAST_FMAF}, and @code{FP_FAST_FMAL}
 for compatibility with the 1999 C standard.
 
+@item __FP_FAST_FMAF16
+@itemx __FP_FAST_FMAF32
+@itemx __FP_FAST_FMAF64
+@itemx __FP_FAST_FMAF128
+@itemx __FP_FAST_FMAF32X
+@itemx __FP_FAST_FMAF64X
+@itemx __FP_FAST_FMAF128X
+These macros are defined with the value 1 if the backend supports the
+@code{fma} functions using the additional @code{_Float@var{n}} and
+@code{_Float@var{n}x} types that are defined in ISO/IEC TS
+18661-3:2015.  The include file @file{math.h} can define the
+@code{FP_FAST_FMAF@var{n}} and @code{FP_FAST_FMAF@var{n}x} macros if
+the user defined @code{__STDC_WANT_IEC_60559_TYPES_EXT__} before
+including @file{math.h}.
+
 @item __GCC_IEC_559
 This macro is defined to indicate the intended level of support for
 IEEE 754 (IEC 60559) floating-point arithmetic.  It expands to a

Re: [PATCH], Update __FLOAT128_HARDWARE__ on power9

[Segher Boessenkool]

On Fri, Oct 20, 2017 at 04:56:41PM -0400, Michael Meissner wrote:
> This is a simple patch to add a way that the GLIBC team call tell that certain
> __float128 built-in functions are available.  While previous patches of mine
> set __FAST_FP_FMAF128, which could be used for this purpose, this macro just
> bumps __FLOAT128_HARDWARE__ to say that the built-in functions are available 
> in
> addition to supporting the basic IEEE 128-bit floating point instructions.

I don't think this is such a great macro name for this purpose.

What problem does this solve?


Segher

Re: [PATCH, version 5], Add support for _Float and _FloatX sqrt, fma, fmin, fmax built-in functions

[Joseph Myers]

My only comment on this version is that the documentation in cpp.texi of 
__FP_FAST_* should be updated to mention __FP_FAST_FMAF@var{n} and 
__FP_FAST_FMAF@var{n}X.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH, rs6000] 2/2 Add x86 SSE2 <emmintrin,h> intrinsics to GCC PPC64LE target

[Segher Boessenkool]

Hi!

On Tue, Oct 17, 2017 at 01:27:16PM -0500, Steven Munroe wrote:
> This it part 2/2 for contributing PPC64LE support for X86 SSE2
> instrisics. This patch includes testsuite/gcc.target tests for the
> intrinsics included by emmintrin.h. 

> --- gcc/testsuite/gcc.target/powerpc/sse2-mmx.c   (revision 0)
> +++ gcc/testsuite/gcc.target/powerpc/sse2-mmx.c   (revision 0)
> @@ -0,0 +1,83 @@
> +/* { dg-do run } */
> +/* { dg-options "-O3 -mdirect-move" } */
> +/* { dg-require-effective-target lp64 } */
> +/* { dg-require-effective-target p8vector_hw } */
> +/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
> "-mcpu=power8" } } */

Why this dg-skip-if?  Also, why -mdirect-move?


Okay for trunk with that taken care of.  Sorry it took a while.

Have you tested this on big endian btw?


Segher

Re: [PATCH, version 5], Add support for _Float and _FloatX sqrt, fma, fmin, fmax built-in functions

[Michael Meissner]

On Wed, Oct 25, 2017 at 08:31:33PM +, Joseph Myers wrote:
> On Wed, 25 Oct 2017, Michael Meissner wrote:
> 
> > > I don't think that, given the availability of fmaf128 etc. built-in 
> > > functions with appropriate options, whether __FP_FAST_* are defined 
> > > should 
> > > actually depend on whether the user has passed options to disable those 
> > > functions (after all, it doesn't for the existing fma / fmaf / fmal, and 
> > > individual built-in functions can be disabled with 
> > > -fno-builtin- 
> > > so the logic you have wouldn't work to detect whether the built-in 
> > > function is disabled anyway).
> > 
> > Ok, I will add a check to see if the functions are disabled.
> 
> My suggestion is to *remove* the checks in this patch for built-in 
> functions being enabled.  That is, to have logic for __FP_FAST_* for these 
> functions exactly the same as for __FP_FAST_FMA, which still gets defined 
> with -std=c90 even though that disables fma as a built-in function while 
> leaving __builtin_fma.

Here is version 5 of the patch.  I added the missing "F64" to gencfn-macros.c.
I made defining __FP_FAST_FMA __FP_FAST_FMAX not dependent on whether the
built-in functions are enabled.  I adjusted the test float128-hw3.c to remove
the check that __FP_FAST_FMAF128 not being defined.

I have done bootstrap builds on a little endian power8 system and a x86-64
system.  There were no regressions.  Can I check this into the trunk?

[gcc]
2017-10-25  Michael Meissner  

* builtins.c (CASE_MATHFN_FLOATN): New helper macro to add cases
for math functions that have _Float and _FloatX variants.
(mathfn_built_in_2): Add support for math functions that have
_Float and _FloatX variants.
(DEF_INTERNAL_FLT_FLOATN_FN): New helper macro.
(expand_builtin_mathfn_ternary): Add support for fma with
_Float and _FloatX variants.
(expand_builtin): Likewise.
(fold_builtin_3): Likewise.
* builtins.def (DEF_EXT_LIB_FLOATN_NX_BUILTINS): New macro to
create math function _Float and _FloatX variants as external
library builtins.
(BUILT_IN_COPYSIGN _Float and _FloatX variants) Use
DEF_EXT_LIB_FLOATN_NX_BUILTINS to make built-in functions using
the __builtin_ prefix and if not strict ansi, without the prefix.
(BUILT_IN_FABS _Float and _FloatX variants): Likewise.
(BUILT_IN_FMA _Float and _FloatX variants): Likewise.
(BUILT_IN_FMAX _Float and _FloatX variants): Likewise.
(BUILT_IN_FMIN _Float and _FloatX variants): Likewise.
(BUILT_IN_NAN _Float and _FloatX variants): Likewise.
(BUILT_IN_SQRT _Float and _FloatX variants): Likewise.
* builtin-types.def (BT_FN_FLOAT16_FLOAT16_FLOAT16_FLOAT16): New
function signatures for fma _Float and _FloatX variants.
(BT_FN_FLOAT32_FLOAT32_FLOAT32_FLOAT32): Likewise.
(BT_FN_FLOAT64_FLOAT64_FLOAT64_FLOAT64): Likewise.
(BT_FN_FLOAT128_FLOAT128_FLOAT128_FLOAT128): Likewise.
(BT_FN_FLOAT32X_FLOAT32X_FLOAT32X_FLOAT32X): Likewise.
(BT_FN_FLOAT64X_FLOAT64X_FLOAT64X_FLOAT64X): Likewise.
(BT_FN_FLOAT128X_FLOAT128X_FLOAT128X_FLOAT128X): Likewise.
* gencfn-macros.c (print_case_cfn): Add support for math functions
that have _Float and _FloatX variants.
(print_define_operator_list): Likewise.
(fltfn_suffixes): Likewise.
(main): Likewise.
* internal-fn.def (DEF_INTERNAL_FLT_FLOATN_FN): New helper macro
for math functions that have _Float and _FloatX variants.
(SQRT): Add support for sqrt, copysign, fmin and fmax _Float
and _FloatX variants.
(COPYSIGN): Likewise.
(FMIN): Likewise.
(FMAX): Likewise.
* fold-const.c (tree_call_nonnegative_warnv_p): Add support for
copysign, fma, fmax, fmin, and sqrt _Float and _FloatX
variants.
(integer_valued_read_call_p): Likewise.
* fold-const-call.c (fold_const_call_ss): Likewise.
(fold_const_call_sss): Add support for copysign, fmin, and fmax
_Float and _FloatX variants.
(fold_const_call_): Add support for fma _Float and
_FloatX variants.
* gimple-ssa-backprop.c (backprop::process_builtin_call_use): Add
support for copysign and fma _Float and _FloatX variants.
(backprop::process_builtin_call_use): Likewise.
* tree-call-cdce.c (can_test_argument_range); Add support for
sqrt _Float and _FloatX variants.
(edom_only_function): Likewise.
(get_no_error_domain): Likewise.
* tree-ssa-math-opts.c (internal_fn_reciprocal): Likewise.
* tree-ssa-reassoc.c (attempt_builtin_copysign): Add support for
copysign _Float and _FloatX variants.
* config/rs6000/rs6000-builtin.def (SQRTF128): Delete, this is now
handled by machine independent code.
(FMAF128): Likewise.

Re: [PATCH] RISC-V: Add Sign/Zero extend patterns for PIC loads

[Palmer Dabbelt]

Committed.

On Tue, 24 Oct 2017 10:55:46 PDT (-0700), Palmer Dabbelt wrote:
> Loads on RISC-V are sign-extending by default, but we weren't telling
> GCC this in our PIC load patterns.  This corrects the problem, and adds
> a zero-extending pattern as well.
>
> gcc/ChangeLog
>
> 2017-10-24  Palmer Dabbelt  
>
>* config/riscv/riscv.md (ZERO_EXTEND_LOAD): Define.
>* config/riscv/pic.md (local_pic_load): Rename to local_pic_load_s,
>mark as a sign-extending load.
>(local_pic_load_u): Define.
> ---
>  gcc/config/riscv/pic.md   | 11 +--
>  gcc/config/riscv/riscv.md |  3 +++
>  2 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/config/riscv/pic.md b/gcc/config/riscv/pic.md
> index 6a29ead32d36..03b8f9bc669e 100644
> --- a/gcc/config/riscv/pic.md
> +++ b/gcc/config/riscv/pic.md
> @@ -22,13 +22,20 @@
>  ;; Simplify PIC loads to static variables.
>  ;; These should go away once we figure out how to emit auipc discretely.
>
> -(define_insn "*local_pic_load"
> +(define_insn "*local_pic_load_s"
>[(set (match_operand:ANYI 0 "register_operand" "=r")
> - (mem:ANYI (match_operand 1 "absolute_symbolic_operand" "")))]
> + (sign_extend:ANYI (mem:ANYI (match_operand 1 
> "absolute_symbolic_operand" ""]
>"USE_LOAD_ADDRESS_MACRO (operands[1])"
>"\t%0,%1"
>[(set (attr "length") (const_int 8))])
>
> +(define_insn "*local_pic_load_u"
> +  [(set (match_operand:ZERO_EXTEND_LOAD 0 "register_operand" "=r")
> + (zero_extend:ZERO_EXTEND_LOAD (mem:ZERO_EXTEND_LOAD (match_operand 1 
> "absolute_symbolic_operand" ""]
> +  "USE_LOAD_ADDRESS_MACRO (operands[1])"
> +  "u\t%0,%1"
> +  [(set (attr "length") (const_int 8))])
> +
>  (define_insn "*local_pic_load"
>[(set (match_operand:ANYF 0 "register_operand" "=f")
>   (mem:ANYF (match_operand 1 "absolute_symbolic_operand" "")))
> diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
> index fd9236c7c170..9f056bbcda4f 100644
> --- a/gcc/config/riscv/riscv.md
> +++ b/gcc/config/riscv/riscv.md
> @@ -259,6 +259,9 @@
>  ;; Iterator for QImode extension patterns.
>  (define_mode_iterator SUPERQI [HI SI (DI "TARGET_64BIT")])
>
> +;; Iterator for extending loads.
> +(define_mode_iterator ZERO_EXTEND_LOAD [QI HI (SI "TARGET_64BIT")])
> +
>  ;; Iterator for hardware integer modes narrower than XLEN.
>  (define_mode_iterator SUBX [QI HI (SI "TARGET_64BIT")])

Re: [PATCH 01/13] remove sdbout.h and associated code

[Jim Wilson]

On 10/25/2017 02:28 PM, Jim Wilson wrote:

This just removes the header file and references to symbols defined in
that file.


Sorry, that should be removing sdbout.h header file includes.  The 
actual file removal occurs later in the patch series.


Jim

[PATCH 13/13] fix MIPS files

[Jim Wilson]

Hand tested to verify that I didn't accidentally break passing -g to
the assembler.

Jim
gcc/
* config/mips/mips.h (SUBTARGET_ASM_DEBUGGING_SPEC): Delete gcoff*
support.
---
 gcc/config/mips/mips.h | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
index 550d283..f5c28bf 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -1314,9 +1314,7 @@ struct mips_cpu_info {
 %{g} %{g0} %{g1} %{g2} %{g3} \
 %{ggdb:-g} %{ggdb0:-g0} %{ggdb1:-g1} %{ggdb2:-g2} %{ggdb3:-g3} \
 %{gstabs:-g} %{gstabs0:-g0} %{gstabs1:-g1} %{gstabs2:-g2} %{gstabs3:-g3} \
-%{gstabs+:-g} %{gstabs+0:-g0} %{gstabs+1:-g1} %{gstabs+2:-g2} %{gstabs+3:-g3} \
-%{gcoff:-g} %{gcoff0:-g0} %{gcoff1:-g1} %{gcoff2:-g2} %{gcoff3:-g3} \
-%{gcoff*:-mdebug} %{!gcoff*:-no-mdebug}"
+%{gstabs+:-g} %{gstabs+0:-g0} %{gstabs+1:-g1} %{gstabs+2:-g2} %{gstabs+3:-g3}"
 #endif
 
 /* FP_ASM_SPEC represents the floating-point options that must be passed
-- 
2.7.4

[PATCH 12/13] fix m68k files

[Jim Wilson]

Another trivial patch to drop a reference to the sdb debugger.

Jim
gcc/
* config/m68k/m68kelf.h (DBX_REGISTER_NUMBER): Delete SDB reference.
---
 gcc/config/m68k/m68kelf.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/m68k/m68kelf.h b/gcc/config/m68k/m68kelf.h
index fb1a0a4..159223f 100644
--- a/gcc/config/m68k/m68kelf.h
+++ b/gcc/config/m68k/m68kelf.h
@@ -97,7 +97,7 @@ do {  
\
 
 /* Define how the m68k registers should be numbered for Dwarf output.
The numbering provided here should be compatible with the native
-   SVR4 SDB debugger in the m68k/SVR4 reference port, where d0-d7
+   SVR4 debugger in the m68k/SVR4 reference port, where d0-d7
are 0-7, a0-a8 are 8-15, and fp0-fp7 are 16-23.  */
 
 #undef DBX_REGISTER_NUMBER
-- 
2.7.4

gotools patch committed: Fix PASS/FAIL output for validate_failures

[Ian Lance Taylor]

This patch to gotools fixes the FAIL output so that GCC's
contrib/testsuite-management/validate_failures.py does not complain.
Thanks to Bernhard Reutner-Fischer for pointing this out.
Bootstrapped and ran Go tests on x86_64-pc-linux-gnu.  Committed to
mainline.

Ian


2017-10-25  Ian Lance Taylor  

* Makefile.am (check-go-tool): Output colon after ${fl}.
(check-runtime, check-cgo-test, check-carchive-test): Likewise.
* Makefile.in: Rebuild.
Index: Makefile.am
===
--- Makefile.am (revision 254089)
+++ Makefile.am (working copy)
@@ -193,7 +193,7 @@ check-go-tool: go$(EXEEXT) cgo$(EXEEXT)
$(CHECK_ENV) \
GOPATH=`cd check-go-dir && $(PWD_COMMAND)`; \
export GOPATH; \
-   (cd check-go-dir/src/cmd/go && $(abs_builddir)/go$(EXEEXT) test 
-test.short -test.v) >> cmd_go-testlog 2>&1 || echo "--- $${fl} go test cmd/go 
(0.00s)" >> cmd_go-testlog
+   (cd check-go-dir/src/cmd/go && $(abs_builddir)/go$(EXEEXT) test 
-test.short -test.v) >> cmd_go-testlog 2>&1 || echo "--- $${fl}: go test cmd/go 
(0.00s)" >> cmd_go-testlog
grep '^--- ' cmd_go-testlog | sed -e 's/^--- \(.*\) ([^)]*)$$/\1/' | 
sort -k 2
 
 # check-runtime runs `go test runtime` in our environment.
@@ -215,7 +215,7 @@ check-runtime: go$(EXEEXT) cgo$(EXEEXT)
GOARCH=`$(abs_builddir)/go$(EXEEXT) env GOARCH`; \
GOOS=`$(abs_builddir)/go$(EXEEXT) env GOOS`; \
files=`$(SHELL) $(libgosrcdir)/../match.sh --goarch=$${GOARCH} 
--goos=$${GOOS} --srcdir=$(libgosrcdir)/runtime 
--extrafiles="$(libgodir)/runtime_sysinfo.go $(libgodir)/sigtab.go" 
--tag=libffi`; \
-   $(SHELL) $(libgosrcdir)/../testsuite/gotest --goarch=$${GOARCH} 
--goos=$${GOOS} --basedir=$(libgosrcdir)/.. --srcdir=$(libgosrcdir)/runtime 
--pkgpath=runtime --pkgfiles="$${files}" $(GOTESTFLAGS) -test.v >> 
runtime-testlog 2>&1 || echo "--- $${fl} go test runtime (0.00s)" >> 
runtime-testlog
+   $(SHELL) $(libgosrcdir)/../testsuite/gotest --goarch=$${GOARCH} 
--goos=$${GOOS} --basedir=$(libgosrcdir)/.. --srcdir=$(libgosrcdir)/runtime 
--pkgpath=runtime --pkgfiles="$${files}" $(GOTESTFLAGS) -test.v >> 
runtime-testlog 2>&1 || echo "--- $${fl}: go test runtime (0.00s)" >> 
runtime-testlog
grep '^--- ' runtime-testlog | sed -e 's/^--- \(.*\) ([^)]*)$$/\1/' | 
sort -k 2
 
 # check-cgo-test runs `go test misc/cgo/test` in our environment.
@@ -228,7 +228,7 @@ check-cgo-test: go$(EXEEXT) cgo$(EXEEXT)
$(CHECK_ENV) \
GOTRACEBACK=2; \
export GOTRACEBACK; \
-   (cd cgo-test-dir/misc/cgo/test && $(abs_builddir)/go$(EXEEXT) test 
-test.short -test.v) >> cgo-testlog 2>&1 || echo "--- $${fl} go test 
misc/cgo/test (0.00s)" >> cgo-testlog
+   (cd cgo-test-dir/misc/cgo/test && $(abs_builddir)/go$(EXEEXT) test 
-test.short -test.v) >> cgo-testlog 2>&1 || echo "--- $${fl}: go test 
misc/cgo/test (0.00s)" >> cgo-testlog
grep '^--- ' cgo-testlog | sed -e 's/^--- \(.*\) ([^)]*)$$/\1/' | sort 
-k 2
 
 # check-carchive-test runs `go test misc/cgo/testcarchive/carchive_test.go`
@@ -242,7 +242,7 @@ check-carchive-test: go$(EXEEXT) cgo$(EX
$(CHECK_ENV) \
LIBRARY_PATH=`echo $${abs_libgodir}/.libs:$${LIBRARY_PATH} | sed 
's,::*,:,g;s,^:*,,;s,:*$$,,'`; \
export LIBRARY_PATH; \
-   (cd carchive-test-dir/misc/cgo/testcarchive && 
$(abs_builddir)/go$(EXEEXT) test -test.v carchive_test.go) >> carchive-testlog 
2>&1 || echo "--- $${fl} go test misc/cgo/testcarchive (0.00s)" >> 
carchive-testlog
+   (cd carchive-test-dir/misc/cgo/testcarchive && 
$(abs_builddir)/go$(EXEEXT) test -test.v carchive_test.go) >> carchive-testlog 
2>&1 || echo "--- $${fl}: go test misc/cgo/testcarchive (0.00s)" >> 
carchive-testlog
grep '^--- ' carchive-testlog | sed -e 's/^--- \(.*\) ([^)]*)$$/\1/' | 
sort -k 2
 
 # The check targets runs the tests and assembles the output files.

[PATCH 11/13] drop sdb references in target comments copied from docs

[Jim Wilson]

This is modifying comments that include text copied from the docs,
to match the changes made to the docs in a previous patch.  These are
all trivial changes.

Jim
gcc/
* config/cris/cris.h: Delete SDB reference in comment.
* config/ia64/ia64.h: Likewise.
* config/mmix/mmix.h: Likewise.
* config/nds32/nds32.c: Likewise.
* config/stormy/storym16.h: Likewise.
* config/visium/visium.h: Likewise.
---
 gcc/config/cris/cris.h | 2 +-
 gcc/config/ia64/ia64.h | 2 +-
 gcc/config/mmix/mmix.h | 2 +-
 gcc/config/nds32/nds32.c   | 2 +-
 gcc/config/stormy16/stormy16.h | 2 +-
 gcc/config/visium/visium.h | 5 ++---
 6 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/gcc/config/cris/cris.h b/gcc/config/cris/cris.h
index f9149c7..892a372 100644
--- a/gcc/config/cris/cris.h
+++ b/gcc/config/cris/cris.h
@@ -998,7 +998,7 @@ enum cris_symbol_type
 /* (no definitions) */
 
 
-/* Node: SDB and DWARF */
+/* Node: DWARF */
 /* (no definitions) */
 
 /* Node: Misc */
diff --git a/gcc/config/ia64/ia64.h b/gcc/config/ia64/ia64.h
index e7073d1..eceab5f 100644
--- a/gcc/config/ia64/ia64.h
+++ b/gcc/config/ia64/ia64.h
@@ -1470,7 +1470,7 @@ do {  
\
 /* Likewise.  */
 
 
-/* Macros for SDB and Dwarf Output.  */
+/* Macros for Dwarf Output.  */
 
 /* Define this macro if GCC should produce dwarf version 2 format debugging
output in response to the `-g' option.  */
diff --git a/gcc/config/mmix/mmix.h b/gcc/config/mmix/mmix.h
index 5dafe2d..2ee3592 100644
--- a/gcc/config/mmix/mmix.h
+++ b/gcc/config/mmix/mmix.h
@@ -761,7 +761,7 @@ typedef struct { int regs; int lib; } CUMULATIVE_ARGS;
 /* (empty) */
 
 
-/* Node: SDB and DWARF */
+/* Node: DWARF */
 #define DWARF2_DEBUGGING_INFO 1
 #define DWARF2_ASM_LINE_DEBUG_INFO 1
 
diff --git a/gcc/config/nds32/nds32.c b/gcc/config/nds32/nds32.c
index c1eb66a..b0d5e48 100644
--- a/gcc/config/nds32/nds32.c
+++ b/gcc/config/nds32/nds32.c
@@ -3763,7 +3763,7 @@ nds32_target_alignment (rtx_insn *label)
 
 /* -- File Names in DBX Format.  */
 
-/* -- Macros for SDB and DWARF Output.  */
+/* -- Macros for DWARF Output.  */
 
 /* -- Macros for VMS Debug Format.  */
 
diff --git a/gcc/config/stormy16/stormy16.h b/gcc/config/stormy16/stormy16.h
index 3f8a535..1d70457 100644
--- a/gcc/config/stormy16/stormy16.h
+++ b/gcc/config/stormy16/stormy16.h
@@ -446,7 +446,7 @@ enum reg_class
 #define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG
 
 
-/* Macros for SDB and Dwarf Output.  */
+/* Macros for Dwarf Output.  */
 
 /* Define this macro if addresses in Dwarf 2 debugging info should not
be the same size as pointers on the target architecture.  The
diff --git a/gcc/config/visium/visium.h b/gcc/config/visium/visium.h
index 3b229f1..8573595 100644
--- a/gcc/config/visium/visium.h
+++ b/gcc/config/visium/visium.h
@@ -1527,9 +1527,8 @@ do
\
automatic variable having address X (an RTL expression).  The
default computation assumes that X is based on the frame-pointer
and gives the offset from the frame-pointer.  This is required for
-   targets that produce debugging output for DBX or COFF-style
-   debugging output for SDB and allow the frame-pointer to be
-   eliminated when the `-g' options is used. */
+   targets that produce debugging output for DBX and allow the frame-pointer
+   to be eliminated when the `-g' options is used. */
 #define DEBUGGER_AUTO_OFFSET(X) \
   (GET_CODE (X) == PLUS ? INTVAL (XEXP (X, 1)) : 0)
 
-- 
2.7.4

[PATCH 10/13] fix i386 files

[Jim Wilson]

I changed some sdb references to past tense where they seemed to still
have some use.  Otherwise, sdb references were removed.

Another interesting point here is that the x86 PE-COFF support is using
the gsym.h file to manually emit some sdb symbol info for the linker in
i386_pe_declare_function_type.  I left this alone as it appears to be
needed.  This is the only sdb support remaining after this patch set.
 This is more symbol table info than debug info though, so should not
be a problem.

Jim

gcc/
* config/i386/cygming.h: Don't define SDB_DEBUGGING_INFO.
(ASM_DECLARE_FUNCTION_NAME): Delete SDB reference from comment.
* config/i386/gas.h: Don't define SDB_DEBUGGING_INFO.
* config/i386/i386.c (svr4_dbx_register_map): Change SDB references
to past tense.
(ix86_expand_prologue): Likewise.
* config/i386/winnt.c (i386_pe_start_function): Don't check SDB_DEBUG.
---
 gcc/config/i386/cygming.h |  4 +---
 gcc/config/i386/gas.h |  4 
 gcc/config/i386/i386.c| 16 
 gcc/config/i386/winnt.c   |  3 +--
 4 files changed, 10 insertions(+), 17 deletions(-)

diff --git a/gcc/config/i386/cygming.h b/gcc/config/i386/cygming.h
index a731e2f..1ed9b17 100644
--- a/gcc/config/i386/cygming.h
+++ b/gcc/config/i386/cygming.h
@@ -19,7 +19,6 @@ along with GCC; see the file COPYING3.  If not see
 .  */
 
 #define DBX_DEBUGGING_INFO 1
-#define SDB_DEBUGGING_INFO 1
 #if TARGET_64BIT_DEFAULT || defined (HAVE_GAS_PE_SECREL32_RELOC)
 #define DWARF2_DEBUGGING_INFO 1
 #endif
@@ -308,8 +307,7 @@ do {\
 #define TARGET_SECTION_TYPE_FLAGS  i386_pe_section_type_flags
 
 /* Write the extra assembler code needed to declare a function
-   properly.  If we are generating SDB debugging information, this
-   will happen automatically, so we only need to handle other cases.  */
+   properly.  */
 #undef ASM_DECLARE_FUNCTION_NAME
 #define ASM_DECLARE_FUNCTION_NAME(FILE, NAME, DECL) \
   i386_pe_start_function (FILE, NAME, DECL)
diff --git a/gcc/config/i386/gas.h b/gcc/config/i386/gas.h
index 9b42787..862c1c2 100644
--- a/gcc/config/i386/gas.h
+++ b/gcc/config/i386/gas.h
@@ -40,10 +40,6 @@ along with GCC; see the file COPYING3.  If not see
 #undef DBX_NO_XREFS
 #undef DBX_CONTIN_LENGTH
 
-/* Ask for COFF symbols.  */
-
-#define SDB_DEBUGGING_INFO 1
-
 /* Output #ident as a .ident.  */
 
 #undef TARGET_ASM_OUTPUT_IDENT
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 3fafcfe..0847951 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -301,7 +301,7 @@ int const dbx64_register_map[FIRST_PSEUDO_REGISTER] =
7 for %edi (gcc regno = 5)
The following three DWARF register numbers are never generated by
the SVR4 C compiler or by the GNU compilers, but SDB on x86/svr4
-   believes these numbers have these meanings.
+   believed these numbers have these meanings.
8  for %eip(no gcc equivalent)
9  for %eflags (gcc regno = 17)
10 for %trapno (no gcc equivalent)
@@ -309,20 +309,20 @@ int const dbx64_register_map[FIRST_PSEUDO_REGISTER] =
for the x86 architecture.  If the version of SDB on x86/svr4 were
a bit less brain dead with respect to floating-point then we would
have a precedent to follow with respect to DWARF register numbers
-   for x86 FP registers, but the SDB on x86/svr4 is so completely
+   for x86 FP registers, but the SDB on x86/svr4 was so completely
broken with respect to FP registers that it is hardly worth thinking
of it as something to strive for compatibility with.
-   The version of x86/svr4 SDB I have at the moment does (partially)
+   The version of x86/svr4 SDB I had does (partially)
seem to believe that DWARF register number 11 is associated with
the x86 register %st(0), but that's about all.  Higher DWARF
register numbers don't seem to be associated with anything in
-   particular, and even for DWARF regno 11, SDB only seems to under-
+   particular, and even for DWARF regno 11, SDB only seemed to under-
stand that it should say that a variable lives in %st(0) (when
asked via an `=' command) if we said it was in DWARF regno 11,
-   but SDB still prints garbage when asked for the value of the
+   but SDB still printed garbage when asked for the value of the
variable in question (via a `/' command).
-   (Also note that the labels SDB prints for various FP stack regs
-   when doing an `x' command are all wrong.)
+   (Also note that the labels SDB printed for various FP stack regs
+   when doing an `x' command were all wrong.)
Note that these problems generally don't affect the native SVR4
C compiler because it doesn't allow the use of -O with -g and
because when it is *not* optimizing, it allocates a memory
@@ -13019,7 +13019,7 @@ ix86_expand_prologue (void)
   if (frame_pointer_needed && !m->fs.fp_valid)
 {
   /* Note: AT enter does NOT 

Fix PR middle-end/82062

[Eric Botcazou]

This is the regression in the folding of conditional expressions like

unsigned long f1 (int x)
{
  return x > 0 ? (unsigned long) x : 0;
}

unsigned long f2 (int x, int y)
{
  return x > y ? (unsigned long) x : (unsigned long) y;
}

introduced by the fix for PR middle-end/81814.  These conditional expressions 
are very common in Ada in the size expressions of unconstrained array types.

The attached patch reinstates a limited version of the optimization that was 
disabled by the aforementioned fix.  The long term plan is to move the whole 
thing to match.pd but I'll leave that to specialists.

Bootstrapped/regtested on x86_64-suse-linux, approved by Richard B. in the 
audit trail of the PR, applied on the mainline.


2017-10-25  Eric Botcazou  

PR middle-end/82062
* fold-const.c (operand_equal_for_comparison_p): Also return true
if ARG0 is a simple variant of ARG1 with narrower precision.
(fold_ternary_loc): Always pass unstripped operands to the predicate.


2017-10-25  Eric Botcazou  

* gcc.dg/fold-cond_expr-1.c: Rename to...
* gcc.dg/fold-cond-2.c: ...this.
* gcc.dg/fold-cond-3.c: New test.

-- 
Eric BotcazouIndex: fold-const.c
===
--- fold-const.c	(revision 254037)
+++ fold-const.c	(working copy)
@@ -3366,7 +3366,8 @@ operand_equal_p (const_tree arg0, const_
 #undef OP_SAME_WITH_NULL
 }
 
-/* Similar to operand_equal_p, but strip nops first.  */
+/* Similar to operand_equal_p, but see if ARG0 might be a variant of ARG1
+   with a different signedness or a narrower precision.  */
 
 static bool
 operand_equal_for_comparison_p (tree arg0, tree arg1)
@@ -3381,9 +3382,20 @@ operand_equal_for_comparison_p (tree arg
   /* Discard any conversions that don't change the modes of ARG0 and ARG1
  and see if the inner values are the same.  This removes any
  signedness comparison, which doesn't matter here.  */
-  STRIP_NOPS (arg0);
-  STRIP_NOPS (arg1);
-  if (operand_equal_p (arg0, arg1, 0))
+  tree op0 = arg0;
+  tree op1 = arg1;
+  STRIP_NOPS (op0);
+  STRIP_NOPS (op1);
+  if (operand_equal_p (op0, op1, 0))
+return true;
+
+  /* Discard a single widening conversion from ARG1 and see if the inner
+ value is the same as ARG0.  */
+  if (CONVERT_EXPR_P (arg1)
+  && INTEGRAL_TYPE_P (TREE_TYPE (TREE_OPERAND (arg1, 0)))
+  && TYPE_PRECISION (TREE_TYPE (TREE_OPERAND (arg1, 0)))
+ < TYPE_PRECISION (TREE_TYPE (arg1))
+  && operand_equal_p (arg0, TREE_OPERAND (arg1, 0), 0))
 return true;
 
   return false;
@@ -11169,8 +11181,8 @@ fold_ternary_loc (location_t loc, enum t
 
  Also try swapping the arguments and inverting the conditional.  */
   if (COMPARISON_CLASS_P (arg0)
-	  && operand_equal_for_comparison_p (TREE_OPERAND (arg0, 0), arg1)
-	  && !HONOR_SIGNED_ZEROS (element_mode (arg1)))
+	  && operand_equal_for_comparison_p (TREE_OPERAND (arg0, 0), op1)
+	  && !HONOR_SIGNED_ZEROS (element_mode (op1)))
 	{
 	  tem = fold_cond_expr_with_comparison (loc, type, arg0, op1, op2);
 	  if (tem)
/* { dg-do compile } */
/* { dg-options "-fdump-tree-original" } */

unsigned long f1 (int x)
{
  return x > 0 ? (unsigned long) x : 0;
}

unsigned long f2 (int x, int y)
{
  return x > y ? (unsigned long) x : (unsigned long) y;
}

unsigned long f3 (int x)
{
  return x < 0 ? (unsigned long) x : 0;
}

unsigned long f4 (int x, int y)
{
  return x < y ? (unsigned long) x : (unsigned long) y;
}

unsigned long f5 (unsigned int x, unsigned int y)
{
  return x > y ? (unsigned long) x : (unsigned long) y;
}

unsigned long f6 (unsigned int x, unsigned int y)
{
  return x < y ? (unsigned long) x : (unsigned long) y;
}

/* { dg-final { scan-tree-dump-times "MAX_EXPR" 3 "original"} } */
/* { dg-final { scan-tree-dump-times "MIN_EXPR" 3 "original"} } */

[PATCH 09/13] fix vxworks file

[Jim Wilson]

A trivial vxworks related patch.

Jim
gcc/
* config/vx-common.h (SDB_DEBUGGING_INFO): Delete undef.
---
 gcc/config/vx-common.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/gcc/config/vx-common.h b/gcc/config/vx-common.h
index 5cc965c..d8f04ec 100644
--- a/gcc/config/vx-common.h
+++ b/gcc/config/vx-common.h
@@ -72,7 +72,6 @@ along with GCC; see the file COPYING3.  If not see
 /* None of these other formats is supported.  */
 #undef DWARF_DEBUGGING_INFO
 #undef DBX_DEBUGGING_INFO
-#undef SDB_DEBUGGING_INFO
 #undef XCOFF_DEBUGGING_INFO
 #undef VMS_DEBUGGING_INFO
 
-- 
2.7.4

[PATCH 08/13] fix dbxcoff.h

[Jim Wilson]

This file is only used by cygwin, mingw and msdosdjgpp targets, which
explicitly set PREFERRED_DEBUGGING_TYPE after including this file, so
this change has no effect, except to eliminate an obsolete sdb
reference here.

Jim
gcc/
* config/dbxcoff.h (PREFERRED_DEBUGGING_TYPE): Set to DBX_DEBUG.
---
 gcc/config/dbxcoff.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/config/dbxcoff.h b/gcc/config/dbxcoff.h
index e5eef64..c20b4fe 100644
--- a/gcc/config/dbxcoff.h
+++ b/gcc/config/dbxcoff.h
@@ -25,10 +25,10 @@ along with GCC; see the file COPYING3.  If not see
 
 #define DBX_DEBUGGING_INFO 1
 
-/* Generate SDB debugging information by default.  */
+/* Generate DBX debugging information by default.  */
 
 #ifndef PREFERRED_DEBUGGING_TYPE
-#define PREFERRED_DEBUGGING_TYPE SDB_DEBUG
+#define PREFERRED_DEBUGGING_TYPE DBX_DEBUG
 #endif
 
 /* Be function-relative for block and source line stab directives.  */
-- 
2.7.4

[PATCH 07/13] fix testsuite debug torture lists

[Jim Wilson]

As a side effect, this reduces cygwin C testsuite passes by a bit over
700, because we are no longer torture testing the -gcoff.  This is not
a regression.

An interesting thing to notice here is that we are torture testing
dwarf-2, but are not torture testing any of the later dwarf
versions.  We don't need to torture test all of them, but we probably
should torture test the latest usable one, which is dwarf-4 at the
moment.  This is a separate issue though that I have not tried to fix
here.

Jim
gcc/
* testsuite/lib/gcc-dg.exp (gcc-dg-debug-runtest): Delete -gcoff.
* testsuite/lib/gfortran-dg.exp (gfortran-dg-debug-runtest): Delete
-gcoff.
---
 gcc/testsuite/lib/gcc-dg.exp  | 2 +-
 gcc/testsuite/lib/gfortran-dg.exp | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
index cb5d184..d8f9b7b 100644
--- a/gcc/testsuite/lib/gcc-dg.exp
+++ b/gcc/testsuite/lib/gcc-dg.exp
@@ -560,7 +560,7 @@ proc gcc-dg-debug-runtest { target_compile trivial opt_opts 
testcases } {
 
 if ![info exists DEBUG_TORTURE_OPTIONS] {
set DEBUG_TORTURE_OPTIONS ""
-   foreach type {-gdwarf-2 -gstabs -gstabs+ -gxcoff -gxcoff+ -gcoff} {
+   foreach type {-gdwarf-2 -gstabs -gstabs+ -gxcoff -gxcoff+} {
set comp_output [$target_compile \
"$srcdir/$subdir/$trivial" "trivial.S" assembly \
"additional_flags=$type"]
diff --git a/gcc/testsuite/lib/gfortran-dg.exp 
b/gcc/testsuite/lib/gfortran-dg.exp
index 27b2a69..6f19009 100644
--- a/gcc/testsuite/lib/gfortran-dg.exp
+++ b/gcc/testsuite/lib/gfortran-dg.exp
@@ -162,7 +162,7 @@ proc gfortran-dg-debug-runtest { target_compile trivial 
opt_opts testcases } {
 
 if ![info exists DEBUG_TORTURE_OPTIONS] {
set DEBUG_TORTURE_OPTIONS ""
-   set type_list [list "-gstabs" "-gstabs+" "-gxcoff" "-gxcoff+" "-gcoff" 
"-gdwarf-2" ]
+   set type_list [list "-gstabs" "-gstabs+" "-gxcoff" "-gxcoff+" 
"-gdwarf-2" ]
foreach type $type_list {
set comp_output [$target_compile \
"$srcdir/$subdir/$trivial" "trivial.S" assembly \
-- 
2.7.4

[PATCH 06/13] remove sdb and -gcoff from non-target files

[Jim Wilson]

This removes the -gcoff option, and various sdb related references in
non-target files.  I also poison SDB_DEBUGGING_INFO and SDB_DEBUG.  I
didn't see any point in poisoning the other SDB_* macros, as no one has
used any of them in a very long time.

I noticed one odd thing from removing -gcoff, use of it or any other
unrecognized debug info type now gives an odd looking error message.

palantir:2016$ gcc -gfoo -S tmp.c
cc1: error: unrecognised debug output level ‘foo’
palantir:2017$ 

We probably should only emit this error when we have a number after -g,
and emit some other error when a non-number appears after -g, such as
"unrecognized debug info type 'foo'".  This is a separate problem that
I haven't tried to fix here.

Jim
gcc/
* common.opt (gcoff): Delete.
(gxcoff+): Update Negative chain.
* defaults.h: Delete all references to SDB_DEBUGGING_INFO and
SDB_DEBUG.
* dwarf2out.c (gen_array_type_die): Change SDB to debuggers.
* flag-types.h (enum debug_info_type): Delete SDB_DEBUG.
* function.c (number_blocks): Delete SDB_DEBUGGING_INFO, SDB_DEBUG,
and SDB references.
(expand_function_start): Change sdb reference to past tense.
(expand_function_end): Change sdb reference to past tense.
* gcc.c (cpp_unique_options): Delete gcoff3 reference.
* opts.c (debug_type_names): Delete coff entry.
(common_handle_option): Delete OPT_gcoff case.
* system.h (SDB_DEBUG, SDB_DEBUGGING_INFO): Poison.
---
 gcc/common.opt   |  6 +-
 gcc/defaults.h   |  9 +
 gcc/dwarf2out.c  | 12 ++--
 gcc/flag-types.h |  1 -
 gcc/function.c   | 10 +-
 gcc/gcc.c|  2 +-
 gcc/opts.c   |  6 +-
 gcc/system.h |  3 ++-
 8 files changed, 17 insertions(+), 32 deletions(-)

diff --git a/gcc/common.opt b/gcc/common.opt
index 836f05b..25e86ec 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2868,10 +2868,6 @@ g
 Common Driver RejectNegative JoinedOrMissing
 Generate debug information in default format.
 
-gcoff
-Common Driver JoinedOrMissing Negative(gdwarf)
-Generate debug information in COFF format.
-
 gcolumn-info
 Common Driver Var(debug_column_info,1) Init(1)
 Record DW_AT_decl_column and DW_AT_call_column in DWARF.
@@ -2937,7 +2933,7 @@ Common Driver JoinedOrMissing Negative(gxcoff+)
 Generate debug information in XCOFF format.
 
 gxcoff+
-Common Driver JoinedOrMissing Negative(gcoff)
+Common Driver JoinedOrMissing Negative(gdwarf)
 Generate debug information in extended XCOFF format.
 
 Enum
diff --git a/gcc/defaults.h b/gcc/defaults.h
index 99cd9db..768c987 100644
--- a/gcc/defaults.h
+++ b/gcc/defaults.h
@@ -894,14 +894,10 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
 #define DEFAULT_GDB_EXTENSIONS 1
 #endif
 
-#ifndef SDB_DEBUGGING_INFO
-#define SDB_DEBUGGING_INFO 0
-#endif
-
 /* If more than one debugging type is supported, you must define
PREFERRED_DEBUGGING_TYPE to choose the default.  */
 
-#if 1 < (defined (DBX_DEBUGGING_INFO) + (SDB_DEBUGGING_INFO) \
+#if 1 < (defined (DBX_DEBUGGING_INFO) \
  + defined (DWARF2_DEBUGGING_INFO) + defined (XCOFF_DEBUGGING_INFO) \
  + defined (VMS_DEBUGGING_INFO))
 #ifndef PREFERRED_DEBUGGING_TYPE
@@ -913,9 +909,6 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
 #elif defined DBX_DEBUGGING_INFO
 #define PREFERRED_DEBUGGING_TYPE DBX_DEBUG
 
-#elif SDB_DEBUGGING_INFO
-#define PREFERRED_DEBUGGING_TYPE SDB_DEBUG
-
 #elif defined DWARF2_DEBUGGING_INFO || defined DWARF2_LINENO_DEBUGGING_INFO
 #define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG
 
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 81c95ec..ab66baf 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -20938,12 +20938,12 @@ gen_array_type_die (tree type, dw_die_ref context_die)
 add_AT_unsigned (array_die, DW_AT_ordering, DW_ORD_col_major);
 
 #if 0
-  /* We default the array ordering.  SDB will probably do
- the right things even if DW_AT_ordering is not present.  It's not even
- an issue until we start to get into multidimensional arrays anyway.  If
- SDB is ever caught doing the Wrong Thing for multi-dimensional arrays,
- then we'll have to put the DW_AT_ordering attribute back in.  (But if
- and when we find out that we need to put these in, we will only do so
+  /* We default the array ordering.  Debuggers will probably do the right
+ things even if DW_AT_ordering is not present.  It's not even an issue
+ until we start to get into multidimensional arrays anyway.  If a debugger
+ is ever caught doing the Wrong Thing for multi-dimensional arrays,
+ then we'll have to put the DW_AT_ordering attribute back in.  (But
+ if and when we find out that we need to put these in, we will only do so
  for multidimensional arrays.  */
   add_AT_unsigned (array_die, DW_AT_ordering, DW_ORD_row_major);
 #endif
diff --git a/gcc/flag-types.h b/gcc/flag-types.h
index 

[PATCH 05/13] remove sdb/coff info from docs

[Jim Wilson]

This removes the now obsolete SDB/coff info from the docs.  I also
removed adb and sdb references, as sdb is obsolete, and most people
probably know adb as the android debug bridge, not the assembly
debugger.  There are also some obsolete MIPS/Alpha ECOFF docs removed.

Jim
gcc/
* doc/install.texi (--with-stabs): Delete COFF and ECOFF info.
* doc/invoke.texi (SEEALSO): Delete adb and sdb references.
(Debugging Options): Delete -gcoff.
(-gstabs): Delete SDB reference.
(-gcoff): Delete.
(-gcoff@var{level}): Delete.
* doc/passes.texi (Debugging information output): Delete SDB and
sdbout.c references.
* doc/tm.texi: Regenerate.
* doc/tm.texi.in (DWARF_CIE_DATA_ALIGNMENT): Delete SDB from xref.
(SDB and DWARF): Change node name to DWARF and delete SDB and COFF
references.
(DEBUGGER_AUTO_OFFSET): Delete COFF and SDB references.
(PREFERRED_DEBUGGING_TYPE): Delete SDB_DEBUG and -gcoff references.
(SDB_DEBUGGING_INFO): Delete.
(PUT_SDB_@dots{}, SDB_DELIM, SDB_ALLOW_UNKNOWN_REFERENCES)
SDB_ALLOW_FORWARD_REFERENCES, SDB_OUTPUT_SOURCE_LINE): Delete.
* target.def (output_source_filename): Delete COFF reference.
* fortran/invoke.texi: Delete adb and sdb references.
---
 gcc/doc/install.texi| 25 -
 gcc/doc/invoke.texi | 13 +++
 gcc/doc/passes.texi |  9 
 gcc/doc/tm.texi | 60 +
 gcc/doc/tm.texi.in  | 58 ---
 gcc/fortran/invoke.texi |  2 +-
 gcc/target.def  |  5 ++---
 7 files changed, 29 insertions(+), 143 deletions(-)

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index da360da..9974775 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -1007,31 +1007,6 @@ Specify that stabs debugging
 information should be used instead of whatever format the host normally
 uses.  Normally GCC uses the same debug format as the host system.
 
-On MIPS based systems and on Alphas, you must specify whether you want
-GCC to create the normal ECOFF debugging format, or to use BSD-style
-stabs passed through the ECOFF symbol table.  The normal ECOFF debug
-format cannot fully handle languages other than C@.  BSD stabs format can
-handle other languages, but it only works with the GNU debugger GDB@.
-
-Normally, GCC uses the ECOFF debugging format by default; if you
-prefer BSD stabs, specify @option{--with-stabs} when you configure GCC@.
-
-No matter which default you choose when you configure GCC, the user
-can use the @option{-gcoff} and @option{-gstabs+} options to specify explicitly
-the debug format for a particular compilation.
-
-@option{--with-stabs} is meaningful on the ISC system on the 386, also, if
-@option{--with-gas} is used.  It selects use of stabs debugging
-information embedded in COFF output.  This kind of debugging information
-supports C++ well; ordinary COFF debugging information does not.
-
-@option{--with-stabs} is also meaningful on 386 systems running SVR4.  It
-selects use of stabs debugging information embedded in ELF output.  The
-C++ compiler currently (2.6.0) does not support the DWARF debugging
-information normally used on 386 SVR4 platforms; stabs provide a
-workable alternative.  This requires gas and gdb, as the normal SVR4
-tools can not generate or interpret stabs.
-
 @item --with-tls=@var{dialect}
 Specify the default TLS dialect, for systems were there is a choice.
 For ARM targets, possible values for @var{dialect} are @code{gnu} or
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 3a87956..41040c1 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -45,7 +45,7 @@ remainder.  @command{g++} accepts mostly the same options as 
@command{gcc}.
 @c man end
 @c man begin SEEALSO
 gpl(7), gfdl(7), fsf-funding(7),
-cpp(1), gcov(1), as(1), ld(1), gdb(1), adb(1), dbx(1), sdb(1)
+cpp(1), gcov(1), as(1), ld(1), gdb(1), dbx(1)
 and the Info entries for @file{gcc}, @file{cpp}, @file{as},
 @file{ld}, @file{binutils} and @file{gdb}.
 @c man end
@@ -342,7 +342,7 @@ Objective-C and Objective-C++ Dialects}.
 
 @item Debugging Options
 @xref{Debugging Options,,Options for Debugging Your Program}.
-@gccoptlist{-g  -g@var{level}  -gcoff  -gdwarf  -gdwarf-@var{version} @gol
+@gccoptlist{-g  -g@var{level}  -gdwarf  -gdwarf-@var{version} @gol
 -ggdb  -grecord-gcc-switches  -gno-record-gcc-switches @gol
 -gstabs  -gstabs+  -gstrict-dwarf  -gno-strict-dwarf @gol
 -gcolumn-info  -gno-column-info @gol
@@ -6895,7 +6895,7 @@ in their names, but apply to all currently-supported 
versions of DWARF.
 Produce debugging information in stabs format (if that is supported),
 without GDB extensions.  This is the format used by DBX on most BSD
 systems.  On MIPS, Alpha and System V Release 4 systems this option
-produces stabs debugging output that is not understood by DBX or SDB@.

[C++ PATCH] Kill IDENTIFIER_LABEL_VALUE

[Nathan Sidwell]

This patch removes 'label_value' from lang_identifier, shrinking it from 
72 to 64 bytes (on 64-bit machine).   We replace this by augmenting the 
already used per-function named_labels hash table.  This is a major win, 
because labels are extremely rare and there are many identifiers.  We 
also shring the binding structure by a pointer, as the shadowed_labels 
list goes away.


The slight difficulty is with the declared label extension.  These have 
a regular scope and can hide an outer binding.  We stash the outer 
binding in the named_label_entry and restore it when popping that scope.


Applying to trunk

nathan
--
Nathan Sidwell
2017-10-25  Nathan Sidwell  

	Kill IDENTIFIER_LABEL_VALUE.
	* cp-tree.h (lang_identifier): Delete label_value slot.
	(IDENTIFIER_LABEL_VALUE, SET_IDENTIFIER_LABEL_VALUE): Delete.
	(struct named_label_hasher): Rename to ...
	(struct named_label_hash): ... here.  Reimplement.
	(struct language_function): Adjust x_named_labels.
	* name-lookup.h (struct cp_label_binding): Delete.
	(struct cp_binding_level): Delete shadowed_labels slot.
	* decl.c (struct named_label_entry): Add name and outer slots.
	(pop_label): Rename to ...
	(check_label_used): ... here.  Don't pop.
	(note_label, sort_labels): Delete.
	(pop_labels, pop_local_label): Reimplement.
	(poplevel): Pop local labels as any other decl. Remove
	shadowed_labels handling.
	(named_label_hash::hash, named_label_hash::equal): New.
	(make_label_decl): Absorb into ...
	(lookup_label_1): ... here.  Add making_local_p arg, reimplement.
	(lookup_label, declare_local_label): Adjust.
	(check_goto, define_label): Adjust.
	* lex.c (make_conv_op_name): Don't clear IDENTIFIER_LABEL_VALUE.
	* ptree.c (cxx_print_identifier): Don't print identifier binding.

Index: cp-tree.h
===
--- cp-tree.h	(revision 254086)
+++ cp-tree.h	(working copy)
@@ -561,7 +561,6 @@ extern GTY(()) tree cp_global_trees[CPTI
 struct GTY(()) lang_identifier {
   struct c_common_identifier c_common;
   cxx_binding *bindings;
-  tree label_value;
 };
 
 /* Return a typed pointer version of T if it designates a
@@ -996,11 +995,6 @@ enum GTY(()) abstract_class_use {
 #define SET_IDENTIFIER_TYPE_VALUE(NODE,TYPE) (TREE_TYPE (NODE) = (TYPE))
 #define IDENTIFIER_HAS_TYPE_VALUE(NODE) (IDENTIFIER_TYPE_VALUE (NODE) ? 1 : 0)
 
-#define IDENTIFIER_LABEL_VALUE(NODE) \
-  (LANG_IDENTIFIER_CAST (NODE)->label_value)
-#define SET_IDENTIFIER_LABEL_VALUE(NODE, VALUE)   \
-  IDENTIFIER_LABEL_VALUE (NODE) = (VALUE)
-
 /* Kinds of identifiers.  Values are carefully chosen.  */
 enum cp_identifier_kind {
   cik_normal = 0,	/* Not a special identifier.  */
@@ -1662,12 +1656,22 @@ struct cxx_int_tree_map_hasher : ggc_ptr
   static bool equal (cxx_int_tree_map *, cxx_int_tree_map *);
 };
 
-struct named_label_entry;
+struct named_label_entry; /* Defined in decl.c.  */
 
-struct named_label_hasher : ggc_ptr_hash
+struct named_label_hash : ggc_remove 
 {
-  static hashval_t hash (named_label_entry *);
-  static bool equal (named_label_entry *, named_label_entry *);
+  typedef named_label_entry *value_type;
+  typedef tree compare_type; /* An identifier.  */
+
+  inline static hashval_t hash (value_type);
+  inline static bool equal (const value_type, compare_type);
+
+  inline static void mark_empty (value_type ) {p = NULL;}
+  inline static bool is_empty (value_type p) {return !p;}
+
+  /* Nothing is deletable.  Everything is insertable.  */
+  inline static bool is_deleted (value_type) { return false; }
+  inline static void mark_deleted (value_type) { gcc_unreachable (); }
 };
 
 /* Global state pertinent to the current function.  */
@@ -1696,7 +1700,8 @@ struct GTY(()) language_function {
 
   BOOL_BITFIELD invalid_constexpr : 1;
 
-  hash_table *x_named_labels;
+  hash_table *x_named_labels;
+
   cp_binding_level *bindings;
   vec *x_local_names;
   /* Tracking possibly infinite loops.  This is a vec only because
Index: decl.c
===
--- decl.c	(revision 254086)
+++ decl.c	(working copy)
@@ -189,27 +189,33 @@ struct GTY((chain_next ("%h.next"))) nam
function, and so we can check the validity of jumps to these labels.  */
 
 struct GTY((for_user)) named_label_entry {
-  /* The decl itself.  */
-  tree label_decl;
+
+  tree name;  /* Name of decl. */
+
+  tree label_decl; /* LABEL_DECL, unless deleted local label. */
+
+  named_label_entry *outer; /* Outer shadowed chain.  */
 
   /* The binding level to which the label is *currently* attached.
  This is initially set to the binding level in which the label
  is defined, but is modified as scopes are closed.  */
   cp_binding_level *binding_level;
+
   /* The head of the names list that was current when the label was
  defined, or the inner scope popped.  These are the decls that will
  be skipped when jumping to the label.  */
   tree names_in_scope;
+
   /* A vector of 

[PATCH 04/13] Delete the sdbout files

[Jim Wilson]

This patch deletes the sdbout.c and sdbout.h files.

Jim
gcc/
* Makefile.in (OBJS): Delete sdbout.o.
(GTFILES): Delete $(srcdir)/sdbout.c.
* sdbout.c: Delete.
* sdbout.h: Delete.
---
 gcc/Makefile.in |3 +-
 gcc/sdbout.c| 1661 ---
 gcc/sdbout.h|   26 -
 3 files changed, 1 insertion(+), 1689 deletions(-)
 delete mode 100644 gcc/sdbout.c
 delete mode 100644 gcc/sdbout.h

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 2809619..9b4cedf 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1446,7 +1446,6 @@ OBJS = \
sched-deps.o \
sched-ebb.o \
sched-rgn.o \
-   sdbout.o \
sel-sched-ir.o \
sel-sched-dump.o \
sel-sched.o \
@@ -2525,7 +2524,7 @@ GTFILES = $(CPP_ID_DATA_H) $(srcdir)/input.h 
$(srcdir)/coretypes.h \
   $(srcdir)/lists.c $(srcdir)/optabs-libfuncs.c \
   $(srcdir)/profile.c $(srcdir)/mcf.c \
   $(srcdir)/reg-stack.c $(srcdir)/cfgrtl.c \
-  $(srcdir)/sdbout.c $(srcdir)/stor-layout.c \
+  $(srcdir)/stor-layout.c \
   $(srcdir)/stringpool.c $(srcdir)/tree.c $(srcdir)/varasm.c \
   $(srcdir)/gimple.h \
   $(srcdir)/gimple-ssa.h \
diff --git a/gcc/sdbout.c b/gcc/sdbout.c
deleted file mode 100644
index acd25a3..000
--- a/gcc/sdbout.c
+++ /dev/null
@@ -1,1661 +0,0 @@
-/* Output sdb-format symbol table information from GNU compiler.
-   Copyright (C) 1988-2017 Free Software Foundation, Inc.
-
-This file is part of GCC.
-
-GCC is free software; you can redistribute it and/or modify it under
-the terms of the GNU General Public License as published by the Free
-Software Foundation; either version 3, or (at your option) any later
-version.
-
-GCC is distributed in the hope that it will be useful, but WITHOUT ANY
-WARRANTY; without even the implied warranty of MERCHANTABILITY or
-FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
-for more details.
-
-You should have received a copy of the GNU General Public License
-along with GCC; see the file COPYING3.  If not see
-.  */
-
-/*  m...@tredysvr.tredydev.unisys.com says:
-I modified the struct.c example and have a nm of a .o resulting from the
-AT C compiler.  From the example below I would conclude the following:
-
-1. All .defs from structures are emitted as scanned.  The example below
-   clearly shows the symbol table entries for BoxRec2 are after the first
-   function.
-
-2. All functions and their locals (including statics) are emitted as scanned.
-
-3. All nested unnamed union and structure .defs must be emitted before
-   the structure in which they are nested.  The AT assembler is a
-   one pass beast as far as symbolics are concerned.
-
-4. All structure .defs are emitted before the typedefs that refer to them.
-
-5. All top level static and external variable definitions are moved to the
-   end of file with all top level statics occurring first before externs.
-
-6. All undefined references are at the end of the file.
-*/
-
-#include "config.h"
-#include "system.h"
-#include "coretypes.h"
-#include "gsyms.h"
-#include "tm.h"
-#include "debug.h"
-#include "tree.h"
-#include "varasm.h"
-#include "stor-layout.h"
-
-static GTY(()) tree anonymous_types;
-
-/* Counter to generate unique "names" for nameless struct members.  */
-
-static GTY(()) int unnamed_struct_number;
-
-/* Declarations whose debug info was deferred till end of compilation.  */
-
-static GTY(()) vec *deferred_global_decls;
-
-/* The C front end may call sdbout_symbol before sdbout_init runs.
-   We save all such decls in this list and output them when we get
-   to sdbout_init.  */
-
-static GTY(()) tree preinit_symbols;
-static GTY(()) bool sdbout_initialized;
-
-#include "rtl.h"
-#include "regs.h"
-#include "function.h"
-#include "memmodel.h"
-#include "emit-rtl.h"
-#include "flags.h"
-#include "insn-config.h"
-#include "reload.h"
-#include "output.h"
-#include "diagnostic-core.h"
-#include "tm_p.h"
-#include "langhooks.h"
-#include "target.h"
-
-/* 1 if PARM is passed to this function in memory.  */
-
-#define PARM_PASSED_IN_MEMORY(PARM) \
- (MEM_P (DECL_INCOMING_RTL (PARM)))
-
-/* A C expression for the integer offset value of an automatic variable
-   (C_AUTO) having address X (an RTX).  */
-#ifndef DEBUGGER_AUTO_OFFSET
-#define DEBUGGER_AUTO_OFFSET(X) \
-  (GET_CODE (X) == PLUS ? INTVAL (XEXP (X, 1)) : 0)
-#endif
-
-/* A C expression for the integer offset value of an argument (C_ARG)
-   having address X (an RTX).  The nominal offset is OFFSET.  */
-#ifndef DEBUGGER_ARG_OFFSET
-#define DEBUGGER_ARG_OFFSET(OFFSET, X) (OFFSET)
-#endif
-
-/* Line number of beginning of current function, minus one.
-   Negative means not in a function or not using sdb.  */
-
-int sdb_begin_function_line = -1;
-
-
-extern FILE *asm_out_file;
-
-extern tree current_function_decl;
-
-#include "sdbout.h"
-
-static void sdbout_init(const char *);
-static 

[PATCH 03/13] drop TYPE_SYMTAB_POINTER

[Jim Wilson]

TYPE_SYMTAB_POINTER was only used by sdbout.c, so can now be removed.

Jim
gcc/
* tree-core.h (tree_type_common): Delete pointer field of
tree_type_symtab.
* tree.c (copy_node): Clear TYPE_SYMTAB_DIE instead of
TYPE_SYMTAB_POINTER.
* tree.h (TYPE_SYMTAB_POINTER): Delete.
(TYPE_SYMTAB_IS_POINTER): Delete.
(TYPE_SYMTAB_IS_DIE): Renumber.
---
 gcc/tree-core.h | 1 -
 gcc/tree.c  | 2 +-
 gcc/tree.h  | 8 +---
 3 files changed, 2 insertions(+), 9 deletions(-)

diff --git a/gcc/tree-core.h b/gcc/tree-core.h
index ed35847..f74f145 100644
--- a/gcc/tree-core.h
+++ b/gcc/tree-core.h
@@ -1538,7 +1538,6 @@ struct GTY(()) tree_type_common {
   tree reference_to;
   union tree_type_symtab {
 int GTY ((tag ("TYPE_SYMTAB_IS_ADDRESS"))) address;
-const char * GTY ((tag ("TYPE_SYMTAB_IS_POINTER"))) pointer;
 struct die_struct * GTY ((tag ("TYPE_SYMTAB_IS_DIE"))) die;
   } GTY ((desc ("debug_hooks->tree_type_symtab_field"))) symtab;
   tree canonical;
diff --git a/gcc/tree.c b/gcc/tree.c
index fa6fcb1..28e157f 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -1206,8 +1206,8 @@ copy_node (tree node MEM_STAT_DECL)
 The two statements usually duplicate each other
 (because they clear fields of the same union),
 but the optimizer should catch that.  */
-  TYPE_SYMTAB_POINTER (t) = 0;
   TYPE_SYMTAB_ADDRESS (t) = 0;
+  TYPE_SYMTAB_DIE (t) = 0;
 
   /* Do not copy the values cache.  */
   if (TYPE_CACHED_VALUES_P (t))
diff --git a/gcc/tree.h b/gcc/tree.h
index 7214ae2..277aa91 100644
--- a/gcc/tree.h
+++ b/gcc/tree.h
@@ -2072,11 +2072,6 @@ extern machine_mode vector_type_mode (const_tree);
 #define TYPE_SYMTAB_ADDRESS(NODE) \
   (TYPE_CHECK (NODE)->type_common.symtab.address)
 
-/* Symtab field as a string.  Used by COFF generator in sdbout.c to
-   hold struct/union type tag names.  */
-#define TYPE_SYMTAB_POINTER(NODE) \
-  (TYPE_CHECK (NODE)->type_common.symtab.pointer)
-
 /* Symtab field as a pointer to a DWARF DIE.  Used by DWARF generator
in dwarf2out.c to point to the DIE generated for the type.  */
 #define TYPE_SYMTAB_DIE(NODE) \
@@ -2087,8 +2082,7 @@ extern machine_mode vector_type_mode (const_tree);
union.  */
 
 #define TYPE_SYMTAB_IS_ADDRESS (0)
-#define TYPE_SYMTAB_IS_POINTER (1)
-#define TYPE_SYMTAB_IS_DIE (2)
+#define TYPE_SYMTAB_IS_DIE (1)
 
 #define TYPE_LANG_SPECIFIC(NODE) \
   (TYPE_CHECK (NODE)->type_with_lang_specific.lang_specific)
-- 
2.7.4

Re: [006/nnn] poly_int: tree constants

[Richard Sandiford]

Martin Sebor  writes:
> On 10/23/2017 11:00 AM, Richard Sandiford wrote:
>> +#if NUM_POLY_INT_COEFFS == 1
>> +extern inline __attribute__ ((__gnu_inline__)) poly_int64
>> +tree_to_poly_int64 (const_tree t)
>
> I'm curious about the extern inline and __gnu_inline__ here and
> not in poly_int_tree_p below.  Am I correct in assuming that
> the combination is a holdover from the days when GCC was compiled
> using a C compiler, and that the way to write the same definition
> in C++ 98 is simply:
>
>inline poly_int64
>tree_to_poly_int64 (const_tree t)
>
>> +{
>> +  gcc_assert (tree_fits_poly_int64_p (t));
>> +  return TREE_INT_CST_LOW (t);
>> +}
>
> If yes, I would suggest to use the C++ form (and at some point,
> changing the existing uses of the GCC/C idiom to the C++ form
> as well).
>
> Otherwise, if something requires the use of the C form I would
> suggest to add a brief comment explaining it.

You probably saw that this is based on tree_to_[su]hwi.  AIUI the
differences from plain C++ inline are that:

a) with __gnu_inline__, an out-of-line definition must still exist.
   That fits this use case well, because the inline is conditional on
   the #ifdef and tree.c has an out-of-line definition either way.
   If we used normal inline, we'd need to add extra #ifs to tree.c
   as well, to avoid multiple definitions.

b) __gnu_inline__ has the strength of __always_inline__, but without the
   correctness implications if inlining is impossible for any reason.
   I did try normal inline first, but it wasn't strong enough.  The
   compiler ended up measurably faster if I copied the tree_to_[su]hwi
   approach.

> ...
>> +
>> +inline bool
>> +poly_int_tree_p (const_tree t, poly_int64_pod *value)
>> +{
> ...

[This one is unconditionally inline.]

>>  /* The tree and const_tree overload templates.   */
>>  namespace wi
>>  {
>> +  class unextended_tree
>> +  {
>> +  private:
>> +const_tree m_t;
>> +
>> +  public:
>> +unextended_tree () {}
>
> Defining no-op ctors is quite dangerous and error-prone.  I suggest
> to instead default initialize the member(s):
>
>unextended_tree (): m_t () {}
>
> Ditto everywhere else, such as in:

This is really performance-senesitive code though, so I don't think
we want to add any unnecessary initialisation.  Primitive types are
uninitalised by default too, and the point of this class is to
provide an integer-like interface.

In your other message you used the example of explicit default
initialisation, such as:

class foo
{
  foo () : x () {}
  unextended_tree x;
};

But I think we should strongly discourage that kind of thing.
If someone wants to initialise x to a particular value, like
integer_zero_node, then it would be better to do it explicitly.
If they don't care what the initial value is, then for these
integer-mimicing classes, uninitialised is as good as anything
else. :-)

Note that for this class NULL_TREE is not a safe default value.
The same goes for the wide-int.h classes, where a length or precision
of 0 is undefined and isn't necessarily going to be handled gracefully
or predictably.

>>template 
>>class extended_tree
>>{
>> @@ -5139,11 +5225,13 @@ extern bool anon_aggrname_p (const_tree)
>>  const_tree m_t;
>>
>>public:
>> +extended_tree () {}
>>  extended_tree (const_tree);
> ...
>> Index: gcc/tree.c
>> ===
> ...
>> +
>> +/* Return true if T holds a polynomial pointer difference, storing it in
>> +   *VALUE if so.  A true return means that T's precision is no greater
>> +   than 64 bits, which is the largest address space we support, so *VALUE
>> +   never loses precision.  However, the signedness of the result is
>> +   somewhat arbitrary, since if B lives near the end of a 64-bit address
>> +   range and A lives near the beginning, B - A is a large positive value
>> +   outside the range of int64_t.  A - B is likewise a large negative value
>> +   outside the range of int64_t.  All the pointer difference really
>> +   gives is a raw pointer-sized bitstring that can be added to the first
>> +   pointer value to get the second.  */
>
> I'm not sure I understand the comment about the sign correctly, but
> if I do, I don't think it's correct.
>
> Because their difference wouldn't representable in any basic integer
> type (i.,e., in ptrdiff_t) the pointers described above could never
> point to the same object (or array), and so their difference is not
> meaningful.  C/C++ only define the semantics of a difference between
> pointers to the same object.  That restricts the size of the largest
> possible object typically to SIZE_MAX / 2, or at most SIZE_MAX on
> the handful of targets where ptrdiff_t has greater precision than
> size_t.  But even on those targets, the difference between any two
> pointers to the same object must be representable in ptrdiff_t,
> including the sign.

But does that apply even when no pointer difference of that 

[PATCH 02/13] fix sdbout.c references in xcoffout.c

[Jim Wilson]

This changes some sdbout.c file references to past tense, since they
are still useful to explain why the code was written this way.

Jim
gcc/
* xcoffout.c: Refer to former sdbout.c file.
(xcoffout_begin_prologue): Use past tense for sdbout.c reference.
---
 gcc/xcoffout.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/xcoffout.c b/gcc/xcoffout.c
index 17b201a..cf2064d 100644
--- a/gcc/xcoffout.c
+++ b/gcc/xcoffout.c
@@ -20,7 +20,7 @@ along with GCC; see the file COPYING3.  If not see
 /* Output xcoff-format symbol table data.  The main functionality is contained
in dbxout.c.  This file implements the sdbout-like parts of the xcoff
interface.  Many functions are very similar to their counterparts in
-   sdbout.c.  */
+   the former sdbout.c file.  */
 
 #include "config.h"
 #include "system.h"
@@ -452,7 +452,7 @@ xcoffout_begin_prologue (unsigned int line,
   ASM_OUTPUT_LFB (asm_out_file, line);
   dbxout_parms (DECL_ARGUMENTS (current_function_decl));
 
-  /* Emit the symbols for the outermost BLOCK's variables.  sdbout.c does this
+  /* Emit the symbols for the outermost BLOCK's variables.  sdbout.c did this
  in sdbout_begin_block, but there is no guarantee that there will be any
  inner block 1, so we must do it here.  This gives a result similar to
  dbxout, so it does make some sense.  */
-- 
2.7.4

[PATCH 01/13] remove sdbout.h and associated code

[Jim Wilson]

This just removes the header file and references to symbols defined in
that file.

Jim
gcc/
* debug.h: Delete sdb_debug_hooks.
* final.c: Delete sdbout.h include.
(final_scan_insn): Delete SDB_DEBUG check.
(rest_of_clean_state): Likewise.
* output.h: Delete sdb_begin_function_line.
* toplev.c: Delete sdbout.h include.
(process_options): Delete SDB_DEBUG check.
---
 gcc/debug.h  |  1 -
 gcc/final.c  | 14 ++
 gcc/output.h |  5 -
 gcc/toplev.c |  4 
 4 files changed, 2 insertions(+), 22 deletions(-)

diff --git a/gcc/debug.h b/gcc/debug.h
index 915420b..19b2784 100644
--- a/gcc/debug.h
+++ b/gcc/debug.h
@@ -228,7 +228,6 @@ extern void debug_nothing_tree_charstar_uhwi (tree, const 
char *,
 /* Hooks for various debug formats.  */
 extern const struct gcc_debug_hooks do_nothing_debug_hooks;
 extern const struct gcc_debug_hooks dbx_debug_hooks;
-extern const struct gcc_debug_hooks sdb_debug_hooks;
 extern const struct gcc_debug_hooks xcoff_debug_hooks;
 extern const struct gcc_debug_hooks dwarf2_debug_hooks;
 extern const struct gcc_debug_hooks dwarf2_lineno_debug_hooks;
diff --git a/gcc/final.c b/gcc/final.c
index 0ddf779..840931b 100644
--- a/gcc/final.c
+++ b/gcc/final.c
@@ -92,8 +92,6 @@ along with GCC; see the file COPYING3.  If not see
 #include "dbxout.h"
 #endif
 
-#include "sdbout.h"
-
 /* Most ports that aren't using cc0 don't need to define CC_STATUS_INIT.
So define a null default for it to save conditionalization later.  */
 #ifndef CC_STATUS_INIT
@@ -2328,8 +2326,7 @@ final_scan_insn (rtx_insn *insn, FILE *file, int 
optimize_p ATTRIBUTE_UNUSED,
  TREE_ASM_WRITTEN (NOTE_BLOCK (insn)) = 1;
  BLOCK_IN_COLD_SECTION_P (NOTE_BLOCK (insn)) = in_cold_section_p;
}
- if (write_symbols == DBX_DEBUG
- || write_symbols == SDB_DEBUG)
+ if (write_symbols == DBX_DEBUG)
{
  location_t *locus_ptr
= block_nonartificial_location (NOTE_BLOCK (insn));
@@ -2363,8 +2360,7 @@ final_scan_insn (rtx_insn *insn, FILE *file, int 
optimize_p ATTRIBUTE_UNUSED,
  gcc_assert (BLOCK_IN_COLD_SECTION_P (NOTE_BLOCK (insn))
  == in_cold_section_p);
}
- if (write_symbols == DBX_DEBUG
- || write_symbols == SDB_DEBUG)
+ if (write_symbols == DBX_DEBUG)
{
  tree outer_block = BLOCK_SUPERCONTEXT (NOTE_BLOCK (insn));
  location_t *locus_ptr
@@ -4684,12 +4680,6 @@ rest_of_clean_state (void)
}
 }
 
-  /* In case the function was not output,
- don't leave any temporary anonymous types
- queued up for sdb output.  */
-  if (SDB_DEBUGGING_INFO && write_symbols == SDB_DEBUG)
-sdbout_types (NULL_TREE);
-
   flag_rerun_cse_after_global_opts = 0;
   reload_completed = 0;
   epilogue_completed = 0;
diff --git a/gcc/output.h b/gcc/output.h
index e98a911..ede4447 100644
--- a/gcc/output.h
+++ b/gcc/output.h
@@ -308,11 +308,6 @@ extern void output_quoted_string (FILE *, const char *);
This variable is defined  in final.c.  */
 extern rtx_sequence *final_sequence;
 
-/* The line number of the beginning of the current function.  Various
-   md code needs this so that it can output relative linenumbers.  */
-
-extern int sdb_begin_function_line;
-
 /* File in which assembler code is being written.  */
 
 #ifdef BUFSIZ
diff --git a/gcc/toplev.c b/gcc/toplev.c
index 8c45e1d..81a7cf6 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -88,8 +88,6 @@ along with GCC; see the file COPYING3.  If not see
 #include "dbxout.h"
 #endif
 
-#include "sdbout.h"
-
 #ifdef XCOFF_DEBUGGING_INFO
 #include "xcoffout.h"  /* Needed for external data declarations. */
 #endif
@@ -1467,8 +1465,6 @@ process_options (void)
   else if (write_symbols == XCOFF_DEBUG)
 debug_hooks = _debug_hooks;
 #endif
-  else if (SDB_DEBUGGING_INFO && write_symbols == SDB_DEBUG)
-debug_hooks = _debug_hooks;
 #ifdef DWARF2_DEBUGGING_INFO
   else if (write_symbols == DWARF2_DEBUG)
 debug_hooks = _debug_hooks;
-- 
2.7.4

[PATCH 00/13] Removal of SDB debug info support

[Jim Wilson]

We have no targets that emit SDB debug info by default.  We dropped all
of the SVR3 Unix and embedded COFF targets a while ago.  The only
targets that are still able to emit SDB debug info are cygwin, mingw,
and msdosdjgpp.

I tried a cygwin build with sources modified to emit SDB by default, to
see if the support was still usable.  I ran into multiple problems.
 There is no SDB support for IMPORTED_DECL which was added in 2008.  -
freorder-functions and -freorder-blocks-and-partition did not work and
had to be disabled.  I hit a cgraph assert because sdbout.c uses
assemble_name on types, which fails if there is a function and type
with the same name.  This also causes types to be added to the debug
info with prepended underscores which is wrong.  I then ran into a
problem with the i386_pe_declare_function_type call from
i386_pe_file_end and gave up because I didn't see an easy workaround.

It seems clear that the SDB support is no longer usable, and probably
hasn't been for a while.  This support should just be removed.

SDB is both a debug info format and an old Unix debugger.  There were
some references to the debugger that I left in, changing to past tense,
as the comments are useful history to explain why the code was written
the was it was.  Otherwise, I tried to eliminate all references to sdb
as a debug info format.

This patch series was tested with a C only cross compiler build for all
modified embedded targets, a default languages build for power aix,
i686 cygwin, and x86_64 linux.  I also did gdb testsuite runs for
cygwin and linux.  There were no regressions.

As a debug info maintainer, I can self approve some of this stuff,
would be would be good to get a review from one of the other global
reviewers, and/or target maintainers.

Jim

[C++ PATCH] Label checking cleanups

[Nathan Sidwell]

In killing IDENTIFIER_LABEL_VALUE, I made some cleanups deduping code 
and using modern C++ idioms.


applying to trunk in advance of the Label killer.

nathan
--
Nathan Sidwell
2017-10-25  Nathan Sidwell  

	* decl.c (identifier_goto): Reduce duplication.
	(check_previous_goto_1): Likewise.
	(check_goto): Move var decls to initialization.
	(check_omp_return, define_label_1, define_label): Likewise.

Index: decl.c
===
--- decl.c	(revision 254060)
+++ decl.c	(working copy)
@@ -3091,8 +3091,9 @@ identify_goto (tree decl, location_t loc
 	   diagnostic_t diag_kind)
 {
   bool complained
-= (decl ? emit_diagnostic (diag_kind, loc, 0, "jump to label %qD", decl)
-	: emit_diagnostic (diag_kind, loc, 0, "jump to case label"));
+= emit_diagnostic (diag_kind, loc, 0,
+		   decl ? "jump to label %qD" : "jump to case label",
+		   decl);
   if (complained && locus)
 inform (*locus, "  from here");
   return complained;
@@ -3147,68 +3148,62 @@ check_previous_goto_1 (tree decl, cp_bin
 			"  crosses initialization of %q#D", new_decls);
 	  else
 		inform (DECL_SOURCE_LOCATION (new_decls),
-			"  enters scope of %q#D which has "
+			"  enters scope of %q#D, which has "
 			"non-trivial destructor", new_decls);
 	}
 	}
 
   if (b == level)
 	break;
-  if ((b->kind == sk_try || b->kind == sk_catch) && !saw_eh)
+
+  const char *inf = NULL;
+  location_t loc = input_location;
+  switch (b->kind)
 	{
-	  if (identified < 2)
-	{
-	  complained = identify_goto (decl, input_location, locus,
-	  DK_ERROR);
-	  identified = 2;
-	}
-	  if (complained)
-	{
-	  if (b->kind == sk_try)
-		inform (input_location, "  enters try block");
-	  else
-		inform (input_location, "  enters catch block");
-	}
+	case sk_try:
+	  if (!saw_eh)
+	inf = "enters try block";
 	  saw_eh = true;
-	}
-  if (b->kind == sk_omp && !saw_omp)
-	{
-	  if (identified < 2)
-	{
-	  complained = identify_goto (decl, input_location, locus,
-	  DK_ERROR);
-	  identified = 2;
-	}
-	  if (complained)
-	inform (input_location, "  enters OpenMP structured block");
+	  break;
+
+	case sk_catch:
+	  if (!saw_eh)
+	inf = "enters catch block";
+	  saw_eh = true;
+	  break;
+
+	case sk_omp:
+	  if (!saw_omp)
+	inf = "enters OpenMP structured block";
 	  saw_omp = true;
-	}
-  if (b->kind == sk_transaction && !saw_tm)
-	{
-	  if (identified < 2)
+	  break;
+
+	case sk_transaction:
+	  if (!saw_tm)
+	inf = "enters synchronized or atomic statement";
+	  saw_tm = true;
+	  break;
+
+	case sk_block:
+	  if (!saw_cxif && level_for_constexpr_if (b->level_chain))
 	{
-	  complained = identify_goto (decl, input_location, locus,
-	  DK_ERROR);
-	  identified = 2;
+	  inf = "enters constexpr if statement";
+	  loc = EXPR_LOCATION (b->level_chain->this_entity);
+	  saw_cxif = true;
 	}
-	  if (complained)
-	inform (input_location,
-		"  enters synchronized or atomic statement");
-	  saw_tm = true;
+	  break;
+
+	default:
+	  break;
 	}
-  if (!saw_cxif && b->kind == sk_block
-	  && level_for_constexpr_if (b->level_chain))
+
+  if (inf)
 	{
 	  if (identified < 2)
-	{
-	  complained = identify_goto (decl, input_location, locus,
-	  DK_ERROR);
-	  identified = 2;
-	}
+	complained = identify_goto (decl, input_location, locus, DK_ERROR);
+	  identified = 2;
 	  if (complained)
-	inform (EXPR_LOCATION (b->level_chain->this_entity),
-		"  enters constexpr if statement");
-	  saw_cxif = true;
+	inform (loc, "  %s", inf);
 	}
 }
 
@@ -3236,10 +3231,6 @@ void
 check_goto (tree decl)
 {
   struct named_label_entry *ent, dummy;
-  bool saw_catch = false, complained = false;
-  int identified = 0;
-  tree bad;
-  unsigned ix;
 
   /* We can't know where a computed goto is jumping.
  So we assume that it's OK.  */
@@ -3277,6 +3268,11 @@ check_goto (tree decl)
   return;
 }
 
+  bool saw_catch = false, complained = false;
+  int identified = 0;
+  tree bad;
+  unsigned ix;
+
   if (ent->in_try_scope || ent->in_catch_scope || ent->in_transaction_scope
   || ent->in_constexpr_if
   || ent->in_omp_scope || !vec_safe_is_empty (ent->bad_decls))
@@ -3337,27 +,24 @@ check_goto (tree decl)
 	inform (input_location, "  enters OpenMP structured block");
 }
   else if (flag_openmp)
-{
-  cp_binding_level *b;
-  for (b = current_binding_level; b ; b = b->level_chain)
-	{
-	  if (b == ent->binding_level)
+for (cp_binding_level *b = current_binding_level; b ; b = b->level_chain)
+  {
+	if (b == ent->binding_level)
+	  break;
+	if (b->kind == sk_omp)
+	  {
+	if (identified < 2)
+	  {
+		complained = identify_goto (decl,
+	DECL_SOURCE_LOCATION (decl),
+	_location, DK_ERROR);
+		identified = 2;
+	  }
+	if (complained)
+	  inform 

Re: [PATCH, version 4], Add support for _Float and _FloatX sqrt, fma, fmin, fmax built-in functions

[Joseph Myers]

On Wed, 25 Oct 2017, Michael Meissner wrote:

> > I don't think that, given the availability of fmaf128 etc. built-in 
> > functions with appropriate options, whether __FP_FAST_* are defined should 
> > actually depend on whether the user has passed options to disable those 
> > functions (after all, it doesn't for the existing fma / fmaf / fmal, and 
> > individual built-in functions can be disabled with -fno-builtin- 
> > so the logic you have wouldn't work to detect whether the built-in 
> > function is disabled anyway).
> 
> Ok, I will add a check to see if the functions are disabled.

My suggestion is to *remove* the checks in this patch for built-in 
functions being enabled.  That is, to have logic for __FP_FAST_* for these 
functions exactly the same as for __FP_FAST_FMA, which still gets defined 
with -std=c90 even though that disables fma as a built-in function while 
leaving __builtin_fma.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH, version 4], Add support for _Float and _FloatX sqrt, fma, fmin, fmax built-in functions

[Michael Meissner]

On Wed, Oct 25, 2017 at 08:10:45PM +, Joseph Myers wrote:
> On Wed, 25 Oct 2017, Michael Meissner wrote:
> 
> > +static const char *const fltfn_suffixes[] = { "F16", "F32", "F128", "F32X",
> > + "F64X", "F128X", NULL };
> 
> I'd expect this to include F64.  If there's some reason that's 
> inappropriate and the omission is deliberate, it needs a detailed comment 
> explaining the omission.

Thanks for catching this.  I missed F64.

> I don't think that, given the availability of fmaf128 etc. built-in 
> functions with appropriate options, whether __FP_FAST_* are defined should 
> actually depend on whether the user has passed options to disable those 
> functions (after all, it doesn't for the existing fma / fmaf / fmal, and 
> individual built-in functions can be disabled with -fno-builtin- 
> so the logic you have wouldn't work to detect whether the built-in 
> function is disabled anyway).

Ok, I will add a check to see if the functions are disabled.

-- 
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

Re: [PATCH v3 1/14] D: The front-end (DMD) language implementation and license.

[Iain Buclaw]

On 25 October 2017 at 03:06, Jeff Law  wrote:
> On 10/18/2017 01:33 AM, Iain Buclaw wrote:
>> On 6 October 2017 at 14:51, Ian Lance Taylor  wrote:
>>> On Fri, Oct 6, 2017 at 1:34 AM, Iain Buclaw  wrote:

 Out of curiosity, I did have a look at some of the tops of gofrontend
 sources this morning.  They are all copyright the Go Authors, and are
 licensed as BSD.  So I'm not sure if having copyright FSF and
 distributing under GPL is strictly required.  And from a maintenance
 point of view, it would be easier to merge in upstream changes as-is
 without some diff/merging tool.
>>>
>>> The GCC steering committee accepted the gofrontend code under a
>>> non-GPL license with the understanding that the master code would live
>>> in a separate repository that would be mirrored into the GCC repo (the
>>> master repository for gofrontend is currently at
>>> https://go.googlesource.com/gofrontend/).  Personally I don't see a
>>> problem with doing the same for the D frontend.
>>>
>>> Ian
>>
>> Should I request that maybe Donald from FSF chime in here?  I'd rather
>> avoid another stalemate on this.
> Absolutely, though RMS should probably be included on any discussion
> with Donald.  I think the FSF needs to chime in and I think the steering
> committee needs to chime in once we've got guidance from the FSF.
>
> The first and most important question that needs to be answered is
> whether or not the FSF would be OK including the DMD bits with the
> license (boost) as-is into GCC.
>
> If that's not acceptable, then we'd have to look at some kind of script
> to fix the copyrights.
> Jeff
>

OK, I'll cc in Donald.

Walter/Andrei, the ball may be in your court here if there's any
copyright problems.

Regards
Iain.

Re: [PATCH, version 4], Add support for _Float and _FloatX sqrt, fma, fmin, fmax built-in functions

[Joseph Myers]

On Wed, 25 Oct 2017, Michael Meissner wrote:

> +static const char *const fltfn_suffixes[] = { "F16", "F32", "F128", "F32X",
> + "F64X", "F128X", NULL };

I'd expect this to include F64.  If there's some reason that's 
inappropriate and the omission is deliberate, it needs a detailed comment 
explaining the omission.

I don't think that, given the availability of fmaf128 etc. built-in 
functions with appropriate options, whether __FP_FAST_* are defined should 
actually depend on whether the user has passed options to disable those 
functions (after all, it doesn't for the existing fma / fmaf / fmal, and 
individual built-in functions can be disabled with -fno-builtin- 
so the logic you have wouldn't work to detect whether the built-in 
function is disabled anyway).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Fix gcc.target/i386/pr61403.c

[Evgeny Stupachenko]

Hi Honza,

That should be fine unless vectorization is done using extract/insert
instructions.

Thanks,
Evgeny

On Wed, Oct 25, 2017 at 12:25 PM, Jan Hubicka  wrote:
> Hi,
> my core tuning patch has caused regression gcc.target/i386/pr61403.c which I 
> have
> missed in my testing.  The testcase looks for blend instruction which is no 
> longer
> output.  The reason is that the loop is now vectorized with SLP while before 
> my
> changes the costmodel claimed SLP vectorization is not good and vectorizer
> disabled it.
>
> I have tested that on skylake, the new code is about 11% faster. The PR itself
> is only about vectorizing the loop.  I am not quite sure what was the 
> intention
> of the testcase, but perhaps we can just check that there is vectorized sqrt
> that is output in any case?
>
> Honza
>
> Index: ../../gcc/testsuite/gcc.target/i386/pr61403.c
> ===
> --- ../../gcc/testsuite/gcc.target/i386/pr61403.c   (revision 253935)
> +++ ../../gcc/testsuite/gcc.target/i386/pr61403.c   (working copy)
> @@ -23,4 +23,4 @@ norm (struct XYZ *in, struct XYZ *out, i
>  }
>  }
>
> -/* { dg-final { scan-assembler "blend" } } */
> +/* { dg-final { scan-assembler "rsqrtps" } } */
>

Re: [PATCH] PR libgcc/59714 complex division is surprising on aarch64

[Joseph Myers]

On Wed, 25 Oct 2017, vladimir.mezent...@oracle.com wrote:

> On 10/25/2017 10:28 AM, Joseph Myers wrote:
> > On Wed, 25 Oct 2017, vladimir.mezent...@oracle.com wrote:
> >
> >> +# Disable FMA (floating-point multiply-add) instructions for complex 
> >> division.
> >> +# These instructions can produce different result if two operations 
> >> executed separately.
> >> +LIBGCC2_FFP_CONTRAST_CFLAGS = -ffp-contract=off
> >> +LIB2_DIV3_FUNCS = _divdc3 _divhc3 _divsc3
> > Without regard to whether the change is appropriate in the first place, 
> > I'm doubtful of the logic for selecting floating-point modes.  I'd expect 
> > something that applies to all floating-point modes.  Even if nothing has 
> > fused XFmode operations, some architectures (e.g. s390, powerpc) have 
> > fused operations on TFmode / KFmode.
> 
>    Hello Joseph and GCC-team,
> Different people are giving me different directions.
> I am glad to change my fix but please provide clear directions on how
> you want to see it.

I am unconvinced of the need for a change that reduces accuracy in some 
cases to make things less surprising in other cases.

I am clear that if there is to be such a change, it should be made 
consistently for all affected floating-point modes, including TFmode / 
KFmode where available, since those have fused operations on some 
platforms.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH, version 4], Add support for _Float and _FloatX sqrt, fma, fmin, fmax built-in functions

[Michael Meissner]

Whoops, I missed deleting c.opt from the ChangeLog file.  I did update the
builtins.def text, and c-cppbuiltins.c, but I didn't delete c.opt.

-- 
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

Fix gcc.target/i386/pr61403.c

[Jan Hubicka]

Hi,
my core tuning patch has caused regression gcc.target/i386/pr61403.c which I 
have
missed in my testing.  The testcase looks for blend instruction which is no 
longer
output.  The reason is that the loop is now vectorized with SLP while before my
changes the costmodel claimed SLP vectorization is not good and vectorizer 
disabled it.

I have tested that on skylake, the new code is about 11% faster. The PR itself
is only about vectorizing the loop.  I am not quite sure what was the intention 
of the testcase, but perhaps we can just check that there is vectorized sqrt
that is output in any case?

Honza

Index: ../../gcc/testsuite/gcc.target/i386/pr61403.c
===
--- ../../gcc/testsuite/gcc.target/i386/pr61403.c   (revision 253935)
+++ ../../gcc/testsuite/gcc.target/i386/pr61403.c   (working copy)
@@ -23,4 +23,4 @@ norm (struct XYZ *in, struct XYZ *out, i
 }
 }

-/* { dg-final { scan-assembler "blend" } } */
+/* { dg-final { scan-assembler "rsqrtps" } } */

Re: [PATCH, version 4], Add support for _Float and _FloatX sqrt, fma, fmin, fmax built-in functions

[Michael Meissner]

On Tue, Oct 24, 2017 at 11:08:15PM +, Joseph Myers wrote:
> On Tue, 24 Oct 2017, Michael Meissner wrote:
> 
> > This patch adds a new switch (-fimplicit-math-floatn) that when enabled, it
> > will add implicit declarations for copysign, fabs, fma, fmax, fmin, nan, and
> > sqrt _Float and _FloatX variants.  Like the previous patch, it adds 
> > fma,
> > fmax, fmin, and sqrt builtins to the machine independent built-in support, 
> > and
> > removed the PowerPC specific __builtin_{sqrt,fma}f128 functions.
> 
> I don't see why this new option is needed.  My expectation would be to use 
> DEF_EXT_LIB_BUILTIN, as discussed before (i.e. declare the non-__builtin_* 
> variants by default, but not if flag_iso).
> 
> That they should be declared by default is clear, in line with the normal 
> principle of enabling GNU extensions by default.  That they should not be 
> declared with existing -std=c11 etc. options is also clear.  Sometimes 
> there may be a use for an option to enable particular features of a TS 
> (e.g. -fpermitted-flt-eval-methods=ts-18661-3, 
> -fno-fp-int-builtin-inexact), I just don't see the requirement for it in 
> this particular case.  Of course, if in future TS 18661-3 gets added to 
> C2x, such built-in functions could be enabled for -std=c2x, subject to any 
> questions of the circumstances under which their names are reserved if the 
> relevant feature test macros are not defined.

This patch removes the -fimplicit-math-floatn switch that I put in the previous
patch.  It makes copysign, fabs, fma, fmax, fmin, nan, and sqrt have implicit
_Float and _FloatX variants unless we are in strict ANSI/ISO mode.
Huge_val, inf, and nans do not get implicit functions created.

I have checked this on a little endian power8 system and an x86-64 system.
There were no regressions.  Can I check this into the trunk?

[gcc]
2017-10-25  Michael Meissner  

* builtins.c (CASE_MATHFN_FLOATN): New helper macro to add cases
for math functions that have _Float and _FloatX variants.
(mathfn_built_in_2): Add support for math functions that have
_Float and _FloatX variants.
(DEF_INTERNAL_FLT_FLOATN_FN): New helper macro.
(expand_builtin_mathfn_ternary): Add support for fma with
_Float and _FloatX variants.
(expand_builtin): Likewise.
(fold_builtin_3): Likewise.
* builtins.def (DEF_EXT_LIB_FLOATN_NX_BUILTINS): New macro to
create math function _Float and _FloatX variants as external
library builtins.
(BUILT_IN_COPYSIGN _Float and _FloatX variants) Use
DEF_EXT_LIB_FLOATN_NX_BUILTINS to make built-in functions using
the __builtin_ prefix and if not strict ansi, without the prefix.
(BUILT_IN_FABS _Float and _FloatX variants): Likewise.
(BUILT_IN_FMA _Float and _FloatX variants): Likewise.
(BUILT_IN_FMAX _Float and _FloatX variants): Likewise.
(BUILT_IN_FMIN _Float and _FloatX variants): Likewise.
(BUILT_IN_NAN _Float and _FloatX variants): Likewise.
(BUILT_IN_SQRT _Float and _FloatX variants): Likewise.
* builtin-types.def (BT_FN_FLOAT16_FLOAT16_FLOAT16_FLOAT16): New
function signatures for fma _Float and _FloatX variants.
(BT_FN_FLOAT32_FLOAT32_FLOAT32_FLOAT32): Likewise.
(BT_FN_FLOAT64_FLOAT64_FLOAT64_FLOAT64): Likewise.
(BT_FN_FLOAT128_FLOAT128_FLOAT128_FLOAT128): Likewise.
(BT_FN_FLOAT32X_FLOAT32X_FLOAT32X_FLOAT32X): Likewise.
(BT_FN_FLOAT64X_FLOAT64X_FLOAT64X_FLOAT64X): Likewise.
(BT_FN_FLOAT128X_FLOAT128X_FLOAT128X_FLOAT128X): Likewise.
* fold-const.c (tree_call_nonnegative_warnv_p): Add support for
copysign, fma, fmax, fmin, and sqrt _Float and _FloatX
variants.
(integer_valued_read_call_p): Likewise.
* fold-const-call.c (fold_const_call_ss): Likewise.
(fold_const_call_sss): Add support for copysign, fmin, and fmax
_Float and _FloatX variants.
(fold_const_call_): Add support for fma _Float and
_FloatX variants.
* gencfn-macros.c (print_case_cfn): Add support for math functions
that have _Float and _FloatX variants.
(print_define_operator_list): Likewise.
(fltfn_suffixes): Likewise.
(main): Likewise.
* gimple-ssa-backprop.c (backprop::process_builtin_call_use): Add
support for copysign and fma _Float and _FloatX variants.
(backprop::process_builtin_call_use): Likewise.
* internal-fn.def (DEF_INTERNAL_FLT_FLOATN_FN): New helper macro
for math functions that have _Float and _FloatX variants.
(SQRT): Add support for sqrt, copysign, fmin and fmax _Float
and _FloatX variants.
(COPYSIGN): Likewise.
(FMIN): Likewise.
(FMAX): Likewise.
* tree-call-cdce.c (can_test_argument_range); Add support for
sqrt _Float and _FloatX variants.

Add scatter/gather costs

[Jan Hubicka]

Hi,
this patch adds computation of scatter/gather to i386 cost metric.
The costs for core are set for haswell, skylake has better implementation
so I will have to split the cost tables for cores older and younger than
skylake. I will do that as a followup.

Bootstrapped/regtested x86_64-linux, comitted.

Honza

* i386.c (ix86_builtin_vectorization_cost): Compute scatter/gather
cost correctly.
* i386.h (processor_costs): Add gather_static, gather_per_elt,
scatter_static, scatter_per_elt.
* x86-tune-costs.h: Add new cost entries.
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 254073)
+++ config/i386/i386.c  (working copy)
@@ -44490,7 +44490,6 @@ ix86_builtin_vectorization_cost (enum ve
   /* We should have separate costs for unaligned loads and gather/scatter.
 Do that incrementally.  */
   case unaligned_load:
-  case vector_gather_load:
index = sse_store_index (mode);
 return ix86_vec_cost (mode,
  COSTS_N_INSNS
@@ -44498,13 +44497,28 @@ ix86_builtin_vectorization_cost (enum ve
  true);
 
   case unaligned_store:
-  case vector_scatter_store:
index = sse_store_index (mode);
 return ix86_vec_cost (mode,
  COSTS_N_INSNS
 (ix86_cost->sse_unaligned_store[index]) / 2,
  true);
 
+  case vector_gather_load:
+return ix86_vec_cost (mode,
+ COSTS_N_INSNS
+(ix86_cost->gather_static
+ + ix86_cost->gather_per_elt
+   * TYPE_VECTOR_SUBPARTS (vectype)) / 2,
+ true);
+
+  case vector_scatter_store:
+return ix86_vec_cost (mode,
+ COSTS_N_INSNS
+(ix86_cost->scatter_static
+ + ix86_cost->scatter_per_elt
+   * TYPE_VECTOR_SUBPARTS (vectype)) / 2,
+ true);
+
   case cond_branch_taken:
 return ix86_cost->cond_taken_branch_cost;
 
Index: config/i386/i386.h
===
--- config/i386/i386.h  (revision 254073)
+++ config/i386/i386.h  (working copy)
@@ -253,6 +253,10 @@ struct processor_costs {
   const int mmxsse_to_integer; /* cost of moving mmxsse register to
   integer.  */
   const int ssemmx_to_integer;  /* cost of moving integer to mmxsse register. 
*/
+  const int gather_static, gather_per_elt; /* Cost of gather load is computed
+  as static + per_item * nelts. */
+  const int scatter_static, scatter_per_elt; /* Cost of gather store is
+  computed as static + per_item * nelts.  */
   const int l1_cache_size; /* size of l1 cache, in kilobytes.  */
   const int l2_cache_size; /* size of l2 cache, in kilobytes.  */
   const int prefetch_block;/* bytes moved to cache for prefetch.  */
Index: config/i386/x86-tune-costs.h
===
--- config/i386/x86-tune-costs.h(revision 254073)
+++ config/i386/x86-tune-costs.h(working copy)
@@ -82,6 +82,8 @@ struct processor_costs ix86_size_cost =
   {3, 3, 3, 3, 3}, /* cost of unaligned SSE store
   in 128bit, 256bit and 512bit */
   3, 3,/* SSE->integer and 
integer->SSE moves */
+  5, 0,/* Gather load static, per_elt. 
 */
+  5, 0,/* Gather store static, 
per_elt.  */
   0,   /* size of l1 cache  */
   0,   /* size of l2 cache  */
   0,   /* size of prefetch block */
@@ -166,6 +168,8 @@ struct processor_costs i386_cost = {/*
   in 32,64,128,256 and 512-bit */
   {4, 8, 16, 32, 64},  /* cost of unaligned stores.  */
   3, 3,/* SSE->integer and 
integer->SSE moves */
+  4, 4,/* Gather load static, per_elt. 
 */
+  4, 4,/* Gather store static, 
per_elt.  */
   0,   /* size of l1 cache  */
   0,   /* size of l2 cache  */
   0,   /* size of prefetch block */
@@ -249,6 +253,8 @@ struct processor_costs i486_cost = {/*
   in 32,64,128,256 and 512-bit */
   {4, 8, 16, 32, 64},  /* cost of 

Re: [PATCH] PR libgcc/59714 complex division is surprising on aarch64

[vladimir . mezentsev]

On 10/25/2017 10:28 AM, Joseph Myers wrote:
> On Wed, 25 Oct 2017, vladimir.mezent...@oracle.com wrote:
>
>> +# Disable FMA (floating-point multiply-add) instructions for complex 
>> division.
>> +# These instructions can produce different result if two operations 
>> executed separately.
>> +LIBGCC2_FFP_CONTRAST_CFLAGS = -ffp-contract=off
>> +LIB2_DIV3_FUNCS = _divdc3 _divhc3 _divsc3
> Without regard to whether the change is appropriate in the first place, 
> I'm doubtful of the logic for selecting floating-point modes.  I'd expect 
> something that applies to all floating-point modes.  Even if nothing has 
> fused XFmode operations, some architectures (e.g. s390, powerpc) have 
> fused operations on TFmode / KFmode.

   Hello Joseph and GCC-team,
Different people are giving me different directions.
I am glad to change my fix but please provide clear directions on how
you want to see it.

  michael.hud...@linaro.org created  PR 59714 and suggested to set 
-ffp-contract=off:

> int main(int argc, char** argv)
> {
>  __complex double c = 1.0 + 3.0i;
>  printf("%g\n", __imag__ (c/c));
> }
> ubuntu@arm64:~$ gcc cplx.c -o cplx
> ubuntu@arm64:~$ ./cplx
> -1.66533e-17
>
> This is because libgcc2.c is compiled in a way that lets the compiler used 
> fused multiply add instructions.
> It shouldn't be! > ...

> In general, fma makes it hard to reason about expressions
> like "a*b-c*d" -- which of the multiplications is being done at the
higher precision?
> But I guess arguing to fp-contract to default to off is a war I don't
want to get into fighting.

Thank you,
-Vladimir

[PATCH, FORTRAN, committed] typo in error message in gfc_match_type_is

[Bernhard Reutner-Fischer]

Hi!

Committed as obvious as r254082.

thanks,
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c	(revision 254081)
+++ gcc/fortran/match.c	(working copy)
@@ -6204,7 +6204,7 @@
   return MATCH_YES;
 
 syntax:
-  gfc_error ("Ssyntax error in TYPE IS specification at %C");
+  gfc_error ("Syntax error in TYPE IS specification at %C");
 
 cleanup:
   if (c != NULL)
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog	(revision 254081)
+++ gcc/fortran/ChangeLog	(working copy)
@@ -1,3 +1,7 @@
+2017-10-25  Bernhard Reutner-Fischer  
+
+	* match.c (gfc_match_type_is): Fix typo in error message.
+
 2017-10-21  Paul Thomas  
 
 	PR fortran/82586

Re: [PING][patch] PR81794: have "would be stringified in traditional C" warning in libcpp/macro.c be controlled by -Wtraditional

[Eric Gallager]

On Sat, Sep 30, 2017 at 8:05 PM, Eric Gallager  wrote:
> On Fri, Sep 29, 2017 at 11:15 AM, David Malcolm  wrote:
>> On Sun, 2017-09-17 at 20:00 -0400, Eric Gallager wrote:
>>> Attached is a version of
>>> https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00481.html that
>>> contains
>>> a combination of both the fix and the testcase update, as requested
>>> in
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81794#c2
>>>
>>> I had to use a different computer than I usually use to send this
>>> email, as the hard drive that originally had this patch is currently
>>> unresponsive. Since it's also the one with my ssh keys on it, I can't
>>> commit with it. Sorry if the ChangeLogs get mangled.
>>
>> Thanks for putting this together; sorry about the delay in reviewing
>> it.
>>
>> The patch mostly looks good.
>>
>> Did you perform a full bootstrap and run of the testsuite with this
>> patch?  If so, it's best to state this in the email, so that we know
>> that the patch has survived this level of testing.
>
> Yes, I bootstrapped with it, but I haven't done a full run of the
> testsuite with it yet; just the one testcase I updated.

Update: I've now run the testsuite with it; test results are here:
https://gcc.gnu.org/ml/gcc-testresults/2017-10/msg01751.html
I'm pretty sure all the FAILs are unrelated to this patch.

>
>>
>> Some nits below:
>>
>>> libcpp/ChangeLog:
>>>
>>> 2017-03-24  Eric Gallager  
>>>
>>>  * macro.c (check_trad_stringification): Have warning be
>>> controlled by
>>>  -Wtraditional.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> 2017-09-17  Eric Gallager  
>>>
>>> PR preprocessor/81794
>>> * gcc.dg/pragma-diag-7.c: Update to include check for
>>> stringification.
>>>
>>> On Sat, May 6, 2017 at 11:33 AM, Eric Gallager 
>>> wrote:
>>> > Pinging this: https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01325.h
>>> > tml
>>> >
>>> > On 3/24/17, Eric Gallager  wrote:
>>> > > It seemed odd to me that gcc was issuing a warning about
>>> > > compatibility
>>> > > with traditional C that I couldn't turn off by pushing/popping
>>> > > -Wtraditional over the problem area, so I made the attached
>>> > > (minor)
>>> > > patch to fix it. Survives bootstrap, but the only testing I've
>>> > > done
>>> > > with it has been compiling the one file that was giving me issues
>>> > > previously, which I'd need to reduce further to turn it into a
>>> > > proper
>>> > > test case.
>>> > >
>>> > > Thanks,
>>> > > Eric Gallager
>>> > >
>>> > > libcpp/ChangeLog:
>>> > >
>>> > > 2017-03-24  Eric Gallager  
>>> > >
>>> > >   * macro.c (check_trad_stringification): Have warning be
>>> > > controlled by
>>> > >   -Wtraditional.
>>> > >
>>> >
>>> > So I did the reducing I mentioned above and now have a testcase for
>>> > it; it was pretty similar to the one from here:
>>> > https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01319.html
>>> > so I combined them into a single testcase and have attached the
>>> > combined version. I can confirm that the testcase passes with my
>>> > patch
>>> > applied.
>>
>> [...]
>>
>>> diff --git a/gcc/testsuite/gcc.dg/pragma-diag-7.c 
>>> b/gcc/testsuite/gcc.dg/pragma-diag-7.c
>>> index 402ee56..e06c410 100644
>>> --- a/gcc/testsuite/gcc.dg/pragma-diag-7.c
>>> +++ b/gcc/testsuite/gcc.dg/pragma-diag-7.c
>>> @@ -7,3 +7,16 @@ unsigned long bad = 1UL; /* { dg-warning "suffix" } */
>>>  /* Note the extra space before the pragma on this next line: */
>>>   #pragma GCC diagnostic pop
>>>  unsigned long ok_again = 2UL; /* { dg-bogus "suffix" } */
>>> +
>>> +/* Redundant with the previous pop, but just shows that it fails to stop 
>>> the
>>> + * following warning with an unpatched GCC: */
>>> +#pragma GCC diagnostic ignored "-Wtraditional"
>>> +
>>> +/* { dg-bogus "would be stringified" .+1 } */
>>
>> As far as I can tell, this dg-bogus line doesn't actually get matched;
>> when I run the testsuite without the libcpp fix, I get:
>>
>>   FAIL: gcc.dg/pragma-diag-7.c (test for excess errors)
>>
>> If I update the dg-bogus line to read:
>>
>>   /* { dg-bogus "would be stringified" "" { target *-*-* } .+1 } */
>>
>> then it's matched, and I get:
>>
>>   FAIL: gcc.dg/pragma-diag-7.c  (test for bogus messages, line 16)
>>
>> I believe that as written the ".+1" 2nd argument is interpreted as a
>> human-readable description of the problem, rather than as a line
>> offset; I believe you would need to add positional args for the
>> description and filter so that the line offset is argument 4.
>>
>> That said, I think the dg-bogus here is unnecessary: if the warning is
>> erroneously emitted, we get:
>>
>>   FAIL: gcc.dg/pragma-diag-7.c (test for excess errors)
>>
>> (where "errors" really means "excess errors, warnings and extraneous
>> gunk that isn't a note").
>>
>> So this testcase hunk is good without the dg-bogus line.
>
> OK, the line can be 

[RFA][PATCH] Don't use wi->info to pass gimple location to array warning callbacks in tree-vrp.c

[Jeff Law]

The array dereference warnings in tree-vrp.c use the gimple walkers to
dig down into gimple statements looking for array accesses.  I wasn't
keen to convert all the clients of the gimple walkers to C++ classes at
this time.

And the gimple walkers have a mechanism by which we could pass around a
class instance -- they've got an opaque pointer (wi->info).

THe pointer is already in use to hold a gimple location.  So I initially
thought I'd have to instead have it point to a structure that would hold
the gimple location and a class instance.

However, we can get to the gimple location via other means -- we can
just extract it from the gimple statement which is a first class entity
within the wi structure.  That's all this patch does.


That frees up the opaque pointer and in a future patch I can just shove
the vr_values class instance into it.

Bootstrapped and regression tested on x86_64.

OK for the trunk?

Jeff

ps.  Now to figure out a strategy for vrp_valueize, which are the last
callbacks that need fixing to allow encapsulation of the vr_values bits.

* tree-vrp.c (check_all_array_refs): Do not use wi->info to smuggle
gimple statement locations.
(check_array_bounds): Corresponding changes.  Get the statement's
location directly from wi->stmt.


diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index 2bc485c..9defbce 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -6837,10 +6837,7 @@ check_array_bounds (tree *tp, int *walk_subtree, void 
*data)
   if (EXPR_HAS_LOCATION (t))
 location = EXPR_LOCATION (t);
   else
-{
-  location_t *locp = (location_t *) wi->info;
-  location = *locp;
-}
+location = gimple_location (wi->stmt);
 
   *walk_subtree = TRUE;
 
@@ -6887,9 +6884,6 @@ check_all_array_refs (void)
 
  memset (, 0, sizeof (wi));
 
- location_t loc = gimple_location (stmt);
- wi.info = 
-
  walk_gimple_op (gsi_stmt (si),
  check_array_bounds,
  );

Re: [PATCH 08/22] Add Intel CET support for EH in libgcc.

[H.J. Lu]

On Thu, Oct 12, 2017 at 4:32 PM, Hans-Peter Nilsson  wrote:
> On Thu, 12 Oct 2017, Tsimbalist, Igor V wrote:
>>   * unwind.inc (_Unwind_RaiseException_Phase2): Use FRAMES_P_DECL,
>>   FRAMES_VAR_DECL_1, FRAMES_VAR_INC and FRAMES_P_UPDATE.
>>   (_Unwind_RaiseException): Use FRAMES_VAR_DECL, FRAMES_VAR_P and
>>   FRAMES_VAR.
>>   (_Unwind_ForcedUnwind_Phase2): Use FRAMES_P_DECL,
>>   FRAMES_VAR_DECL_1, FRAMES_VAR_INC, FRAMES_P_UPDATE.
>>   (_Unwind_ForcedUnwind): Use FRAMES_VAR_DECL, FRAMES_VAR_P and
>>   FRAMES_VAR.
>>   (_Unwind_Resume): Use FRAMES_VAR_DECL, FRAMES_VAR_P and
>>   FRAMES_VAR.
>>   (_Unwind_Resume_or_Rethrow): Use FRAMES_VAR_DECL, FRAMES_VAR_P
>>   and FRAMES_VAR.
>
> I think you'll have to test this on a non-CET target too,
> because it looks like this won't fly:
>
> -  uw_install_context (_context, _context);
> +  uw_install_context (_context, _context, FRAMES_VAR);
>
> You'll be introducing a naked comma for the default empty

It is done on purpose.   There are

/* Install TARGET into CURRENT so that we can return to it.  This is a
   macro because __builtin_eh_return must be invoked in the context of
   our caller.  */

#define uw_install_context(CURRENT, TARGET, FRAMES) \
  do\
{   \
  long offset = uw_install_context_1 ((CURRENT), (TARGET)); \
  void *handler = uw_frob_return_addr ((CURRENT), (TARGET));\
  _Unwind_DebugHook ((TARGET)->cfa, handler);   \
  _Unwind_Frames_Extra (FRAMES);\
  __builtin_eh_return (offset, handler);\
}   \
  while (0)

For non-CET targets, we have

#define FRAMES_VAR

[hjl@gnu-6 tmp]$ cat bar.c
#define FRAMES_VAR

#define foo(x, FRAMES) _Unwind_Frames_Extra (FRAMES)

foo (xxx, FRAMES_VAR);
[hjl@gnu-6 tmp]$ gcc -E bar.c
# 1 "bar.c"
# 1 ""
# 1 ""
# 31 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "" 2
# 1 "bar.c"




_Unwind_Frames_Extra ();
[hjl@gnu-6 tmp]$


> FRAMES_VAR.  I like the basic approach though, FWIW.
>
> brgds, H-P

Thanks.

-- 
H.J.

Re: [PATCH] PR libgcc/59714 complex division is surprising on aarch64

[Joseph Myers]

On Wed, 25 Oct 2017, vladimir.mezent...@oracle.com wrote:

> +# Disable FMA (floating-point multiply-add) instructions for complex 
> division.
> +# These instructions can produce different result if two operations executed 
> separately.
> +LIBGCC2_FFP_CONTRAST_CFLAGS = -ffp-contract=off
> +LIB2_DIV3_FUNCS = _divdc3 _divhc3 _divsc3

Without regard to whether the change is appropriate in the first place, 
I'm doubtful of the logic for selecting floating-point modes.  I'd expect 
something that applies to all floating-point modes.  Even if nothing has 
fused XFmode operations, some architectures (e.g. s390, powerpc) have 
fused operations on TFmode / KFmode.

-- 
Joseph S. Myers
jos...@codesourcery.com

[PATCH] PR libgcc/59714 complex division is surprising on aarch64

[vladimir . mezentsev]

From: Vladimir Mezentsev 

FMA (floating-point multiply-add) instructions are supported on aarch64.
These instructions can produce different result if two operations executed 
separately.
-ffp-contract=off doesn't allow the FMA instructions.

Tested on aarch64-unknown-linux-gnu. No regression. Two failed tests now passed.

ChangeLog:
2017-10-25  Vladimir Mezentsev  

PR libgcc/59714
* libgcc/Makefile.in: Add -ffp-contract=off
---
 libgcc/Makefile.in | 8 
 1 file changed, 8 insertions(+)

diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
index a1a392d..f313556 100644
--- a/libgcc/Makefile.in
+++ b/libgcc/Makefile.in
@@ -455,6 +455,14 @@ ifeq ($(LIB2_SIDITI_CONV_FUNCS),)
   lib2funcs += $(subst XX,di,$(dwfloatfuncs))
 endif
 
+# Disable FMA (floating-point multiply-add) instructions for complex division.
+# These instructions can produce different result if two operations executed 
separately.
+LIBGCC2_FFP_CONTRAST_CFLAGS = -ffp-contract=off
+LIB2_DIV3_FUNCS = _divdc3 _divhc3 _divsc3
+lib2-div3-o = $(patsubst %,%$(objext),$(LIB2_DIV3_FUNCS))
+lib2-div3-s-o = $(patsubst %,%_s$(objext),$(LIB2_DIV3_FUNCS))
+$(lib2-div3-o) $(lib2-div3-s-o): LIBGCC2_CFLAGS += 
$(LIBGCC2_FFP_CONTRAST_CFLAGS)
+
 # These might cause a divide overflow trap and so are compiled with
 # unwinder info.
 LIB2_DIVMOD_FUNCS = _divdi3 _moddi3 _divmoddi4 \
-- 
1.8.3.1

Re: [RFA][PATCH] Provide a class interface into substitute_and_fold.

[Jeff Law]

On 10/24/2017 03:45 PM, Jeff Law wrote:
> On 10/24/2017 02:57 PM, David Malcolm wrote:
>> On Tue, 2017-10-24 at 12:44 -0600, Jeff Law wrote:
>>> This is similar to the introduction of the ssa_propagate_engine, but
>>> for
>>> the substitution/replacements bits.
>>>
>>> In a couple places the pass specific virtual functions are just
>>> wrappers
>>> around existing functions.  A good example of this is
>>> ccp_folder::get_value.  Many other routines in tree-ssa-ccp.c want to
>>> use get_constant_value.  Some may be convertable to use the class
>>> instance, but I haven't looked closely.
>>>
>>> Another example is vrp_folder::get_value.  In this case we're
>>> wrapping
>>> op_with_constant_singleton_value.  In a later patch that moves into
>>> the
>>> to-be-introduced vr_values class so we'll delegate to that class
>>> rather
>>> than wrap.
>>>
>>> FWIW I did look at having a single class for the propagation engine
>>> and
>>> the substitution engine.  That turned out to be a bit problematical
>>> due
>>> to the calls into the substitution engine from the evrp bits which
>>> don't
>>> use the propagation engine at all.  Given propagation and
>>> substitution
>>> are distinct concepts I ultimately decided the cleanest path forward
>>> was
>>> to keep the two classes separate.
>>>
>>> Bootstrapped and regression tested on x86_64.  OK for the trunk?
>>>
>>> Jeff
>>>
>>
>> [...snip...] 
>>
>>> diff --git a/gcc/tree-ssa-ccp.c b/gcc/tree-ssa-ccp.c
>>> index fec562e..da06172 100644
>>> --- a/gcc/tree-ssa-ccp.c
>>> +++ b/gcc/tree-ssa-ccp.c
>>> @@ -188,7 +188,6 @@ static ccp_prop_value_t *const_val;
>>>  static unsigned n_const_val;
>>>  
>>>  static void canonicalize_value (ccp_prop_value_t *);
>>> -static bool ccp_fold_stmt (gimple_stmt_iterator *);
>>>  static void ccp_lattice_meet (ccp_prop_value_t *, ccp_prop_value_t
>> *);
>>>  
>>>  /* Dump constant propagation value VAL to file OUTF prefixed by
>> PREFIX.  */
>>> @@ -909,6 +908,24 @@ do_dbg_cnt (void)
>>>  }
>>>  
>>>  
>>> +/* We want to provide our own GET_VALUE and FOLD_STMT virtual
>> methods.  */
>>> +class ccp_folder : public substitute_and_fold_engine
>>> +{
>>> + public:
>>> +  tree get_value (tree);
>>> +  bool fold_stmt (gimple_stmt_iterator *);
>>> +};
>>
>> Should these two methods be marked OVERRIDE? (or indeed "FINAL
>> OVERRIDE"?)  This tells the human reader that they're vfuncs, and C++11
>> onwards can issue a warning if for some reason they stop being vfuncs
>> (e.g. the type signature changes somewhere).
>>
>> (likewise for all the other overrides in subclasses of s_a_f_engine).
> OVERRIDE seems like a no-brainer.  I can't offhand think of a case where
> we'd want to derive further.  FINAL (in theory) ought to help divirt, so
> it seems appropriate as well.  Consider that done :-)
I added both and went through the usual bootstrap and regression
testing.  No issues (as expected).  Good to get the confirmation though.

> 
> I'm also investigating if these classes need a virtual dtor.
My conclusion on the virtual dtor issue is that it's not strictly needed
right  now.

IIUC the issue is you could do something like

base *foo = new derived ();
[ ... ]
delete foo;

If the base's destructor is not virtual and foo is a base * pointing to
a derived object then the deletion invokes undefined behavior.

In theory we shouldn't be doing such things :-)  In fact, if there's a
way to prevent this with some magic on the base class I'd love to know
about it.

jeff

Re: [RFA][PATCH] Provide a class interface to ssa_propagate

[Jeff Law]

On 10/24/2017 02:49 PM, David Malcolm wrote:
> On Tue, 2017-10-24 at 11:40 -0600, Jeff Law wrote:
>> tree-ssa-propagate.c provides a fairly generic engine to propagate
>> values through a lattice while in SSA form.  The engine uses two
>> callbacks to allow passes to provide pass specific handling of
>> statements and phi nodes.
>>
>> The callback mechanism served us well in a C world.  It is however
>> somewhat painful to have state in those callbacks without resorting
>> to
>> global variables or passing around void * objects which contain the
>> class instance pointer.
>>
>> For example, tree-vrp uses the propagation engine to compute global
>> range information.  Its callbacks vrp_visit_stmt and vrp_visit_phi
>> and
>> their children read/modify a variety of tree-vrp.c statics such as
>> vr_data.
>>
>> In some changes I'm working on I'd really like to move vr_data into a
>> distinct class and avoid having direct accesses to the underlying
>> array.
>>
>> So the problem is how are routines like vrp_visit_stmt and
>> vrp_visit_phi
>> and their children supposed to access the class instance?
>>
>> One way would be to just add a void * argument to them and pass the
>> class instance around.  Alternately we could leave the global
>> variable
>> in place and have it set up, checked and wiped clean by the vr_data
>> class's ctor/dtor.  Both are valid and would work, but they're a bit
>> ugly IMHO.
>>
>> This patch takes another approach.  It builds a simple little class
>> around ssa_propagate where the statement and phi visitors are virtual
>> functions.  Thus clients can override the visitors *and* they'll get
>> a
>> class instance pointer.
>>
>> I haven't gone hog wild with C++-ification, basically just enough to
>> get
>> the class around ssa_propagate and its children which are going to
>> need
>> to pass down the class instance to the virtual functions.  There's a
>> lot
>> more that could be done here.
>>
>> As you can see the client side changes are pretty minimal.  They just
>> derive a new class from ssa_propagation_engine to provide their
>> implementations of the statement and phi visitor.  More importantly,
>> they can hang data off that derived class which we'll exploit later.
>>
>> There will be a similar patch for the substitute_and_fold which has
>> callbacks of its own.
>>
>> Bootstrapped and regression tested on x86_64.
>>
>> The ChangeLog makes the patch look huge.  But it's actually
>> relatively
>> small and the client side bits are repetitive.
>>
>> OK for the trunk?
>>
>> Jeff
> 
> Looks like you forgot to attach the patch.
Ugh.  Attached, with the FINAL OVERRIDE addition.


Jeff
* tree-ssa-propagate.h (ssa_prop_visit_stmt_fn): Remove typedef.
(ssa_prop_visit_phi_fn): Likewise.
(class ssa_propagation_engine): New class to provide an interface
into ssa_propagate.
* tree-ssa-propagate.c (ssa_prop_visit_stmt): Remove file scoped
variable.
(ssa_prop_visit_phi): Likewise.
(ssa_propagation_engine::simulate_stmt): Moved into class.
Call visit_phi/visit_stmt from the class rather than via
file scoped static variables.
(ssa_propagation_engine::simulate_block): Moved into class.
(ssa_propagation_engine::process_ssa_edge_worklist): Similarly.
(ssa_propagation_engine::ssa_propagate): Similarly.  No longer
set file scoped statics for the visit_stmt/visit_phi callbacks.
* tree-complex.c (complex_propagate): New class derived from
ssa_propagation_engine.
(complex_propagate::visit_stmt): Renamed from complex_visit_stmt.
(complex_propagate::visit_phi): Renamed from complex_visit_phi.
(tree_lower_complex): Call ssa_propagate via the complex_propagate
class.
* tree-ssa-ccp.c: (ccp_propagate): New class derived from
ssa_propagation_engine.
(ccp_propagate::visit_phi): Renamed from ccp_visit_phi_node.
(ccp_propagate::visit_stmt): Renamed from ccp_visit_stmt.
(do_ssa_ccp): Call ssa_propagate from the ccp_propagate class.
* tree-ssa-copy.c (copy_prop): New class derived from
ssa_propagation_engine.
(copy_prop::visit_stmt): Renamed from copy_prop_visit_stmt.
(copy_prop::visit_phi): Renamed from copy_prop_visit_phi_node.
(execute_copy_prop): Call ssa_propagate from the copy_prop class.
* tree-vrp.c (vrp_prop): New class derived from ssa_propagation_engine.
(vrp_prop::visit_stmt): Renamed from vrp_visit_stmt.
(vrp_prop::visit_phi): Renamed from vrp_visit_phi_node.
(execute_vrp): Call ssa_propagate from the vrp_prop class.



diff --git a/gcc/tree-complex.c b/gcc/tree-complex.c
index e2d93b7..e9e7e2a 100644
--- a/gcc/tree-complex.c
+++ b/gcc/tree-complex.c
@@ -60,6 +60,11 @@ typedef int complex_lattice_t;
 
 #define PAIR(a, b)  ((a) << 2 | (b))
 
+class complex_propagate : public ssa_propagation_engine
+{
+  enum ssa_prop_result visit_stmt 

Re: [006/nnn] poly_int: tree constants

[Martin Sebor]

On 10/23/2017 11:00 AM, Richard Sandiford wrote:

+#if NUM_POLY_INT_COEFFS == 1
+extern inline __attribute__ ((__gnu_inline__)) poly_int64
+tree_to_poly_int64 (const_tree t)


I'm curious about the extern inline and __gnu_inline__ here and
not in poly_int_tree_p below.  Am I correct in assuming that
the combination is a holdover from the days when GCC was compiled
using a C compiler, and that the way to write the same definition
in C++ 98 is simply:

  inline poly_int64
  tree_to_poly_int64 (const_tree t)


+{
+  gcc_assert (tree_fits_poly_int64_p (t));
+  return TREE_INT_CST_LOW (t);
+}


If yes, I would suggest to use the C++ form (and at some point,
changing the existing uses of the GCC/C idiom to the C++ form
as well).

Otherwise, if something requires the use of the C form I would
suggest to add a brief comment explaining it.

...

+
+inline bool
+poly_int_tree_p (const_tree t, poly_int64_pod *value)
+{

...


 /* The tree and const_tree overload templates.   */
 namespace wi
 {
+  class unextended_tree
+  {
+  private:
+const_tree m_t;
+
+  public:
+unextended_tree () {}


Defining no-op ctors is quite dangerous and error-prone.  I suggest
to instead default initialize the member(s):

  unextended_tree (): m_t () {}

Ditto everywhere else, such as in:

...

   template 
   class extended_tree
   {
@@ -5139,11 +5225,13 @@ extern bool anon_aggrname_p (const_tree)
 const_tree m_t;

   public:
+extended_tree () {}
 extended_tree (const_tree);

...

Index: gcc/tree.c
===

...

+
+/* Return true if T holds a polynomial pointer difference, storing it in
+   *VALUE if so.  A true return means that T's precision is no greater
+   than 64 bits, which is the largest address space we support, so *VALUE
+   never loses precision.  However, the signedness of the result is
+   somewhat arbitrary, since if B lives near the end of a 64-bit address
+   range and A lives near the beginning, B - A is a large positive value
+   outside the range of int64_t.  A - B is likewise a large negative value
+   outside the range of int64_t.  All the pointer difference really
+   gives is a raw pointer-sized bitstring that can be added to the first
+   pointer value to get the second.  */


I'm not sure I understand the comment about the sign correctly, but
if I do, I don't think it's correct.

Because their difference wouldn't representable in any basic integer
type (i.,e., in ptrdiff_t) the pointers described above could never
point to the same object (or array), and so their difference is not
meaningful.  C/C++ only define the semantics of a difference between
pointers to the same object.  That restricts the size of the largest
possible object typically to SIZE_MAX / 2, or at most SIZE_MAX on
the handful of targets where ptrdiff_t has greater precision than
size_t.  But even on those targets, the difference between any two
pointers to the same object must be representable in ptrdiff_t,
including the sign.


+bool
+ptrdiff_tree_p (const_tree t, poly_int64_pod *value)
+{


Martin

Re: [03/nn] Allow vector CONSTs

[Jeff Law]

On 10/23/2017 05:18 AM, Richard Sandiford wrote:
> This patch allows (const ...) wrappers to be used for rtx vector
> constants, as an alternative to const_vector.  This is useful
> for SVE, where the number of elements isn't known until runtime.
Right.  It's constant, but not knowable at compile time.  That seems an
exact match for how we've used CONST.

> 
> It could also be useful in future for fixed-length vectors, to
> reduce the amount of memory needed to represent simple constants
> with high element counts.  However, one nice thing about keeping
> it restricted to variable-length vectors is that there is never
> any need to handle combinations of (const ...) and CONST_VECTOR.
Yea, but is the memory consumption of these large vectors a real
problem?  I suspect, relative to other memory issues they're in the noise.

> 
> 
> 2017-10-23  Richard Sandiford  
>   Alan Hayward  
>   David Sherwood  
> 
> gcc/
>   * doc/rtl.texi (const): Update description of address constants.
>   Say that vector constants are allowed too.
>   * common.md (E, F): Use CONSTANT_P instead of checking for
>   CONST_VECTOR.
>   * emit-rtl.c (gen_lowpart_common): Use const_vec_p instead of
>   checking for CONST_VECTOR.
>   * expmed.c (make_tree): Use build_vector_from_val for a CONST
>   VEC_DUPLICATE.
>   * expr.c (expand_expr_real_2): Check for vector modes instead
>   of checking for CONST_VECTOR.
>   * rtl.h (const_vec_p): New function.
>   (const_vec_duplicate_p): Check for a CONST VEC_DUPLICATE.
>   (unwrap_const_vec_duplicate): Handle them here too.
My only worry here is code that is a bit loose in checking for a CONST,
but not the innards and perhaps isn't prepared for for the new forms
that appear inside the CONST.

If we have such problems I'd expect it's in the targets as the targets
have traditionally have had to validate the innards of a CONST to ensure
it could be handled by the assembler/linker.  Hmm, that may save the
targets since they'd likely need an update to LEGITIMATE_CONSTANT_P to
ever see these new forms.

Presumably an aarch64 specific patch to recognize these as valid
constants in LEGITIMATE_CONSTANT_P is in the works?

OK for the trunk.

jeff

Re: Add support for MODE_VECTOR_BOOL

[Richard Biener]

On October 25, 2017 6:05:48 PM GMT+02:00, Richard Sandiford 
 wrote:
>Richard Biener  writes:
>> On October 25, 2017 5:54:02 PM GMT+02:00, Richard Sandiford
>>  wrote:
>>>This patch adds a new mode class to represent vectors of booleans.
>>>GET_MODE_BITSIZE (m) / GET_MODE_NUNITS (m) determines the number
>>>of bits that are used to represent each boolean; this can be 1
>>>for a fully-packed representation or greater than 1 for an unpacked
>>>representation.  In the latter case, the value of bits other than
>>>the lowest is not significant.
>>>
>>>These are used by the SVE port to represent predicates.
>>>
>>>Tested on aarch64-linux-gnu, x86_64-linux-gnu and
>>>powerpc64le-linux-gnu,
>>>on top of the poly_int series.  OK to install?
>>
>> AVX uses integer modes for predicates. Can't you do the same thing,
>with
>> variable size, of course?
>
>Variable-sized integers would be really painful.  The main point of
>the scalar_int_mode series was to take advantage of the fact that
>integers are always fixed size, to avoid poly_int speading even
>further.
>
>I don't think there's any benefit to modelling them as integers for
>SVE.
>We never want to refer to them as integers, but we often want to refer
>to them as vectors.  And treating them as vectors fits with the
>tree representation.
>
>> AVX has moves between predicate registers and GPRs.
>
>SVE doesn't have/need this.  The GPRs have 64 bits and the maximum
>predicate size is 256 bits, so the two aren't necessarily compatible.
>
>I guess you're worried that target-independent code will suddenly
>need to cope with two different representations of the same thing.
>But besides this patch, it all gets hidden behind the existing
>get_mask_mode hook.

OK, fine. I was exactly wondering that. The AVX handling required changes all 
over the place... 

Richard. 

>Thanks,
>Richard
>
>>
>> Richard. 
>>
>>
>>>Richard
>>>
>>>
>>>2017-10-25  Richard Sandiford  
>>> Alan Hayward  
>>> David Sherwood  
>>>
>>>gcc/
>>> * mode-classes.def (MODE_VECTOR_BOOL): New mode class.
>>> * machmode.h (INTEGRAL_MODE_P, VECTOR_MODE_P): Return true
>>> for MODE_VECTOR_BOOL.
>>> * machmode.def (VECTOR_BOOL_MODE): Document.
>>> * genmodes.c (VECTOR_BOOL_MODE): New macro.
>>> (make_vector_bool_mode): New function.
>>> (complete_mode, emit_mode_wider, emit_mode_adjustments): Handle
>>> MODE_VECTOR_BOOL.
>>> * lto-streamer-in.c (lto_input_mode_table): Likewise.
>>> * stor-layout.c (int_mode_for_mode): Likewise.
>>> * tree.c (build_vector_type_for_mode): Likewise.
>>> * varasm.c (output_constant_pool_2): Likewise.
>>> * emit-rtl.c (gen_const_vec_duplicate): Likewise,
>>> (init_emit_once): Make sure that CONST1_RTX (BImode) and
>>> CONSTM1_RTX (BImode) are the same thing.  Initialize const_tiny_rtx
>>> for MODE_VECTOR_BOOL.
>>> * expr.c (expand_expr_real_1): Use VECTOR_MODE_P instead of a list
>>> of mode class checks.
>>> * tree-vect-generic.c (expand_vector_operation): Use VECTOR_MODE_P
>>> instead of a list of mode class checks.
>>> (expand_vector_scalar_condition): Likewise.
>>> (type_for_widest_vector_mode): Handle BImode as an inner mode.
>>>
>>>gcc/c-family/
>>> * c-common.c (c_common_type_for_mode): Handle MODE_VECTOR_BOOL.
>>>
>>>gcc/fortran/
>>> * trans-types.c (gfc_type_for_mode): Handle MODE_VECTOR_BOOL.
>>>
>>>gcc/go/
>>> * go-lang.c (go_langhook_type_for_mode): Handle MODE_VECTOR_BOOL.
>>>
>>>gcc/lto/
>>> * lto-lang.c (lto_type_for_mode): Handle MODE_VECTOR_BOOL.
>>>
>>>Index: gcc/mode-classes.def
>>>===
>>>--- gcc/mode-classes.def 2017-10-25 16:50:18.000869425 +0100
>>>+++ gcc/mode-classes.def 2017-10-25 16:50:35.628184659 +0100
>>>@@ -31,6 +31,7 @@ along with GCC; see the file COPYING3.
>>> DEF_MODE_CLASS (MODE_DECIMAL_FLOAT),/* decimal floating point */
>>>   
>\
>>>   DEF_MODE_CLASS (MODE_COMPLEX_INT),/* complex numbers */   
>>>\
>>>   DEF_MODE_CLASS (MODE_COMPLEX_FLOAT),  
>>>\
>>>+  DEF_MODE_CLASS (MODE_VECTOR_BOOL),/* vectors of single bits */
>>>  
>\
>>>   DEF_MODE_CLASS (MODE_VECTOR_INT), /* SIMD vectors */ \
>>>   DEF_MODE_CLASS (MODE_VECTOR_FRACT),   /* SIMD vectors */  
>>>\
>>>   DEF_MODE_CLASS (MODE_VECTOR_UFRACT),  /* SIMD vectors */  
>>>\
>>>Index: gcc/machmode.h
>>>===
>>>--- gcc/machmode.h   2017-10-25 16:50:31.832332710 +0100
>>>+++ gcc/machmode.h   2017-10-25 16:50:35.628184659 +0100
>>>@@ -108,6 +108,7 @@ #define INTEGRAL_MODE_P(MODE)\
>>>   (GET_MODE_CLASS (MODE) == MODE_INT

Re: [02/nn] Add more vec_duplicate simplifications

[Jeff Law]

On 10/23/2017 05:17 AM, Richard Sandiford wrote:
> This patch adds a vec_duplicate_p helper that tests for constant
> or non-constant vector duplicates.  Together with the existing
> const_vec_duplicate_p, this complements the gen_vec_duplicate
> and gen_const_vec_duplicate added by a previous patch.
> 
> The patch uses the new routines to add more rtx simplifications
> involving vector duplicates.  These mirror simplifications that
> we already do for CONST_VECTOR broadcasts and are needed for
> variable-length SVE, which uses:
> 
>   (const:M (vec_duplicate:M X))
> 
> to represent constant broadcasts instead.  The simplifications do
> trigger on the testsuite for variable duplicates too, and in each
> case I saw the change was an improvement.  E.g.:
> 
[ snip ]

> 
> The best way of testing the new simplifications seemed to be
> via selftests.  The patch cribs part of David's patch here:
> https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00270.html .
Cool.  I really wish I had more time to promote David's work by adding
selftests to various things.  There's certainly cases where it's the
most direct and useful way to test certain bits of lower level
infrastructure we have.  Glad to see you found it useful here.



> 
> 
> 2017-10-23  Richard Sandiford  
>   David Malcolm  
>   Alan Hayward  
>   David Sherwood  
> 
> gcc/
>   * rtl.h (vec_duplicate_p): New function.
>   * selftest-rtl.c (assert_rtx_eq_at): New function.
>   * selftest-rtl.h (ASSERT_RTX_EQ): New macro.
>   (assert_rtx_eq_at): Declare.
>   * selftest.h (selftest::simplify_rtx_c_tests): Declare.
>   * selftest-run-tests.c (selftest::run_tests): Call it.
>   * simplify-rtx.c: Include selftest.h and selftest-rtl.h.
>   (simplify_unary_operation_1): Recursively handle vector duplicates.
>   (simplify_binary_operation_1): Likewise.  Handle VEC_SELECTs of
>   vector duplicates.
>   (simplify_subreg): Handle subregs of vector duplicates.
>   (make_test_reg, test_vector_ops_duplicate, test_vector_ops)
>   (selftest::simplify_rtx_c_tests): New functions.
Thanks for the examples of how this affects various targets.  Seems like
it ought to be a consistent win when they trigger.

jeff

Re: [01/nn] Add gen_(const_)vec_duplicate helpers

[Jeff Law]

On 10/23/2017 05:16 AM, Richard Sandiford wrote:
> This patch adds helper functions for generating constant and
> non-constant vector duplicates.  These routines help with SVE because
> it is then easier to use:
> 
>(const:M (vec_duplicate:M X))
> 
> for a broadcast of X, even if the number of elements in M isn't known
> at compile time.  It also makes it easier for general rtx code to treat
> constant and non-constant duplicates in the same way.
> 
> In the target code, the patch uses gen_vec_duplicate instead of
> gen_rtx_VEC_DUPLICATE if handling constants correctly is potentially
> useful.  It might be that some or all of the call sites only handle
> non-constants in practice, in which case the change is a harmless
> no-op (and a saving of a few characters).
> 
> Otherwise, the target changes use gen_const_vec_duplicate instead
> of gen_rtx_CONST_VECTOR if the constant is obviously a duplicate.
> They also include some changes to use CONSTxx_RTX for easy global
> constants.
> 
> 
> 2017-10-23  Richard Sandiford  
>   Alan Hayward  
>   David Sherwood  
> 
> gcc/
>   * emit-rtl.h (gen_const_vec_duplicate): Declare.
>   (gen_vec_duplicate): Likewise.
>   * emit-rtl.c (gen_const_vec_duplicate_1): New function, split
>   out from...
>   (gen_const_vector): ...here.
>   (gen_const_vec_duplicate, gen_vec_duplicate): New functions.
>   (gen_rtx_CONST_VECTOR): Use gen_const_vec_duplicate for constants
>   whose elements are all equal.
>   * optabs.c (expand_vector_broadcast): Use gen_const_vec_duplicate.
>   * simplify-rtx.c (simplify_const_unary_operation): Likewise.
>   (simplify_relational_operation): Likewise.
>   * config/aarch64/aarch64.c (aarch64_simd_gen_const_vector_dup):
>   Likewise.
>   (aarch64_simd_dup_constant): Use gen_vec_duplicate.
>   (aarch64_expand_vector_init): Likewise.
>   * config/arm/arm.c (neon_vdup_constant): Likewise.
>   (neon_expand_vector_init): Likewise.
>   (arm_expand_vec_perm): Use gen_const_vec_duplicate.
>   (arm_block_set_unaligned_vect): Likewise.
>   (arm_block_set_aligned_vect): Likewise.
>   * config/arm/neon.md (neon_copysignf): Likewise.
>   * config/i386/i386.c (ix86_expand_vec_perm): Likewise.
>   (expand_vec_perm_even_odd_pack): Likewise.
>   (ix86_vector_duplicate_value): Use gen_vec_duplicate.
>   * config/i386/sse.md (one_cmpl2): Use CONSTM1_RTX.
>   * config/ia64/ia64.c (ia64_expand_vecint_compare): Use
>   gen_const_vec_duplicate.
>   * config/ia64/vect.md (addv2sf3, subv2sf3): Use CONST1_RTX.
>   * config/mips/mips.c (mips_gen_const_int_vector): Use
>   gen_const_vec_duplicate.
>   (mips_expand_vector_init): Use CONST0_RTX.
>   * config/powerpcspe/altivec.md (abs2, nabs2): Likewise.
>   (define_split): Use gen_const_vec_duplicate.
>   * config/rs6000/altivec.md (abs2, nabs2): Use CONST0_RTX.
>   (define_split): Use gen_const_vec_duplicate.
>   * config/s390/vx-builtins.md (vec_genmask): Likewise.
>   (vec_ctd_s64, vec_ctd_u64, vec_ctsl, vec_ctul): Likewise.
>   * config/spu/spu.c (spu_const): Likewise.
I'd started looking at this a couple times when it was originally
submitted, but never seemed to get through it.  It seems like a nice
cleanup.

So in gen_const_vector we had an assert to verify that const_tiny_rtx
was set up.  That seems to have been lost.  It's probably not a big
deal, but I mention it in case the loss was unintentional.


OK.  Your call whether or not to re-introduce the assert for const_tiny_rtx.

Jeff

Re: [001/nnn] poly_int: add poly-int.h

[Martin Sebor]

On 10/23/2017 10:57 AM, Richard Sandiford wrote:

This patch adds a new "poly_int" class to represent polynomial integers
of the form:

  C0 + C1*X1 + C2*X2 ... + Cn*Xn

It also adds poly_int-based typedefs for offsets and sizes of various
precisions.  In these typedefs, the Ci coefficients are compile-time
constants and the Xi indeterminates are run-time invariants.  The number
of coefficients is controlled by the target and is initially 1 for all
ports.

Most routines can handle general coefficient counts, but for now a few
are specific to one or two coefficients.  Support for other coefficient
counts can be added when needed.

The patch also adds a new macro, IN_TARGET_CODE, that can be
set to indicate that a TU contains target-specific rather than
target-independent code.  When this macro is set and the number of
coefficients is 1, the poly-int.h classes define a conversion operator
to a constant.  This allows most existing target code to work without
modification.  The main exceptions are:

- values passed through ..., which need an explicit conversion to a
  constant

- ?: expression in which one arm ends up being a polynomial and the
  other remains a constant.  In these cases it would be valid to convert
  the constant to a polynomial and the polynomial to a constant, so a
  cast is needed to break the ambiguity.

The patch also adds a new target hook to return the estimated
value of a polynomial for costing purposes.

The patch also adds operator<< on wide_ints (it was already defined
for offset_int and widest_int).  I think this was originally excluded
because >> is ambiguous for wide_int, but << is useful for converting
bytes to bits, etc., so is worth defining on its own.  The patch also
adds operator% and operator/ for offset_int and widest_int, since those
types are always signed.  These changes allow the poly_int interface to
be more predictable.

I'd originally tried adding the tests as selftests, but that ended up
bloating cc1 by at least a third.  It also took a while to build them
at -O2.  The patch therefore uses plugin tests instead, where we can
force the tests to be built at -O0.  They still run in negligible time
when built that way.


2017-10-23  Richard Sandiford  
Alan Hayward  
David Sherwood  

gcc/
* poly-int.h: New file.
* poly-int-types.h: Likewise.
* coretypes.h: Include them.
(POLY_INT_CONVERSION): Define.
* target.def (estimated_poly_value): New hook.
* doc/tm.texi.in (TARGET_ESTIMATED_POLY_VALUE): New hook.
* doc/tm.texi: Regenerate.
* doc/poly-int.texi: New file.
* doc/gccint.texi: Include it.
* doc/rtl.texi: Describe restrictions on subreg modes.
* Makefile.in (TEXI_GCCINT_FILES): Add poly-int.texi.
* genmodes.c (NUM_POLY_INT_COEFFS): Provide a default definition.
(emit_insn_modes_h): Emit a definition of NUM_POLY_INT_COEFFS.
* targhooks.h (default_estimated_poly_value): Declare.
* targhooks.c (default_estimated_poly_value): New function.
* target.h (estimated_poly_value): Likewise.
* wide-int.h (WI_UNARY_RESULT): Use wi::binary_traits.
(wi::unary_traits): Delete.
(wi::binary_traits::signed_shift_result_type): Define for
offset_int << HOST_WIDE_INT, etc.
(generic_wide_int::operator <<=): Define for all types and use
wi::lshift instead of <<.
(wi::hwi_with_prec): Add a default constructor.
(wi::ints_for): New class.
(operator <<): Define for all wide-int types.
(operator /): New function.
(operator %): Likewise.
* selftest.h (ASSERT_MUST_EQ, ASSERT_MUST_EQ_AT, ASSERT_MAY_NE)
(ASSERT_MAY_NE_AT): New macros.

gcc/testsuite/
* gcc.dg/plugin/poly-int-tests.h,
gcc.dg/plugin/poly-int-test-1.c,
gcc.dg/plugin/poly-int-01_plugin.c,
gcc.dg/plugin/poly-int-02_plugin.c,
gcc.dg/plugin/poly-int-03_plugin.c,
gcc.dg/plugin/poly-int-04_plugin.c,
gcc.dg/plugin/poly-int-05_plugin.c,
gcc.dg/plugin/poly-int-06_plugin.c,
gcc.dg/plugin/poly-int-07_plugin.c: New tests.
* gcc.dg/plugin/plugin.exp: Run them.


I haven't done nearly a thorough review but the dtor followed by
the placement new in the POLY_SET_COEFF() macro caught my eye so
I thought I'd ask sooner rather than later.  Given the macro
definition:

+   The dummy comparison against a null C * is just a way of checking
+   that C gives the right type.  */
+#define POLY_SET_COEFF(C, RES, I, VALUE) \
+  ((void) (&(RES).coeffs[0] == (C *) 0), \
+   wi::int_traits::precision_type == wi::FLEXIBLE_PRECISION \
+   ? (void) ((RES).coeffs[I] = VALUE) \
+   : (void) ((RES).coeffs[I].~C (), new (&(RES).coeffs[I]) C (VALUE)))

is the following use well-defined?

+template
+inline poly_int_pod&
+poly_int_pod::operator <<= 

Re: [C++ Patch] PR 80955 (Macros expanded in definition of user-defined literals)

[Mukesh Kapoor]

On 10/25/2017 9:06 AM, Jason Merrill wrote:

On Wed, Oct 25, 2017 at 7:20 AM, Nathan Sidwell  wrote:

On 10/25/2017 12:03 AM, Mukesh Kapoor wrote:


Thanks for pointing this out. Checking in the front end will be difficult
because the front end gets tokens after macro expansion. I think the
difficulty of fixing this bug comes because of the requirement to maintain
backward compatibility with the option -Wliteral-suffix for -std=c++11.


IIUC the warning's intent is to catch cases of:
printf ("some format"PRIx64 ..., ...);
where there's no space between the string literals and the PRIx64 macro.  I
suspect it's very common for there to be a following string-literal, so
perhaps the preprocessor could detect:

NON-FN-MACRO

and warn on that sequence?

Or perhaps we could limit the current behavior to when the macro
expands to a string literal?


To check this the macro will have to be expanded completely. A macro can 
be defined using other macros. The header  has the following 
definition for PRId64:


#  define __PRI64_PREFIX    "l"
# define PRId64 __PRI64_PREFIX "d"

Mukesh



Jason

Re: [C++ Patch] PR 80955 (Macros expanded in definition of user-defined literals)

[Jason Merrill]

On Wed, Oct 25, 2017 at 7:20 AM, Nathan Sidwell  wrote:
> On 10/25/2017 12:03 AM, Mukesh Kapoor wrote:
>
>> Thanks for pointing this out. Checking in the front end will be difficult
>> because the front end gets tokens after macro expansion. I think the
>> difficulty of fixing this bug comes because of the requirement to maintain
>> backward compatibility with the option -Wliteral-suffix for -std=c++11.
>
>
> IIUC the warning's intent is to catch cases of:
> printf ("some format"PRIx64 ..., ...);
> where there's no space between the string literals and the PRIx64 macro.  I
> suspect it's very common for there to be a following string-literal, so
> perhaps the preprocessor could detect:
>
> NON-FN-MACRO
>
> and warn on that sequence?

Or perhaps we could limit the current behavior to when the macro
expands to a string literal?

Jason

Re: Add support for MODE_VECTOR_BOOL

[Richard Sandiford]

Richard Biener  writes:
> On October 25, 2017 5:54:02 PM GMT+02:00, Richard Sandiford
>  wrote:
>>This patch adds a new mode class to represent vectors of booleans.
>>GET_MODE_BITSIZE (m) / GET_MODE_NUNITS (m) determines the number
>>of bits that are used to represent each boolean; this can be 1
>>for a fully-packed representation or greater than 1 for an unpacked
>>representation.  In the latter case, the value of bits other than
>>the lowest is not significant.
>>
>>These are used by the SVE port to represent predicates.
>>
>>Tested on aarch64-linux-gnu, x86_64-linux-gnu and
>>powerpc64le-linux-gnu,
>>on top of the poly_int series.  OK to install?
>
> AVX uses integer modes for predicates. Can't you do the same thing, with
> variable size, of course?

Variable-sized integers would be really painful.  The main point of
the scalar_int_mode series was to take advantage of the fact that
integers are always fixed size, to avoid poly_int speading even further.

I don't think there's any benefit to modelling them as integers for SVE.
We never want to refer to them as integers, but we often want to refer
to them as vectors.  And treating them as vectors fits with the
tree representation.

> AVX has moves between predicate registers and GPRs.

SVE doesn't have/need this.  The GPRs have 64 bits and the maximum
predicate size is 256 bits, so the two aren't necessarily compatible.

I guess you're worried that target-independent code will suddenly
need to cope with two different representations of the same thing.
But besides this patch, it all gets hidden behind the existing
get_mask_mode hook.

Thanks,
Richard

>
> Richard. 
>
>
>>Richard
>>
>>
>>2017-10-25  Richard Sandiford  
>>  Alan Hayward  
>>  David Sherwood  
>>
>>gcc/
>>  * mode-classes.def (MODE_VECTOR_BOOL): New mode class.
>>  * machmode.h (INTEGRAL_MODE_P, VECTOR_MODE_P): Return true
>>  for MODE_VECTOR_BOOL.
>>  * machmode.def (VECTOR_BOOL_MODE): Document.
>>  * genmodes.c (VECTOR_BOOL_MODE): New macro.
>>  (make_vector_bool_mode): New function.
>>  (complete_mode, emit_mode_wider, emit_mode_adjustments): Handle
>>  MODE_VECTOR_BOOL.
>>  * lto-streamer-in.c (lto_input_mode_table): Likewise.
>>  * stor-layout.c (int_mode_for_mode): Likewise.
>>  * tree.c (build_vector_type_for_mode): Likewise.
>>  * varasm.c (output_constant_pool_2): Likewise.
>>  * emit-rtl.c (gen_const_vec_duplicate): Likewise,
>>  (init_emit_once): Make sure that CONST1_RTX (BImode) and
>>  CONSTM1_RTX (BImode) are the same thing.  Initialize const_tiny_rtx
>>  for MODE_VECTOR_BOOL.
>>  * expr.c (expand_expr_real_1): Use VECTOR_MODE_P instead of a list
>>  of mode class checks.
>>  * tree-vect-generic.c (expand_vector_operation): Use VECTOR_MODE_P
>>  instead of a list of mode class checks.
>>  (expand_vector_scalar_condition): Likewise.
>>  (type_for_widest_vector_mode): Handle BImode as an inner mode.
>>
>>gcc/c-family/
>>  * c-common.c (c_common_type_for_mode): Handle MODE_VECTOR_BOOL.
>>
>>gcc/fortran/
>>  * trans-types.c (gfc_type_for_mode): Handle MODE_VECTOR_BOOL.
>>
>>gcc/go/
>>  * go-lang.c (go_langhook_type_for_mode): Handle MODE_VECTOR_BOOL.
>>
>>gcc/lto/
>>  * lto-lang.c (lto_type_for_mode): Handle MODE_VECTOR_BOOL.
>>
>>Index: gcc/mode-classes.def
>>===
>>--- gcc/mode-classes.def  2017-10-25 16:50:18.000869425 +0100
>>+++ gcc/mode-classes.def  2017-10-25 16:50:35.628184659 +0100
>>@@ -31,6 +31,7 @@ along with GCC; see the file COPYING3.
>> DEF_MODE_CLASS (MODE_DECIMAL_FLOAT), /* decimal floating point */   \
>>   DEF_MODE_CLASS (MODE_COMPLEX_INT), /* complex numbers */   
>>\
>>   DEF_MODE_CLASS (MODE_COMPLEX_FLOAT),   
>>\
>>+  DEF_MODE_CLASS (MODE_VECTOR_BOOL), /* vectors of single bits */   \
>>   DEF_MODE_CLASS (MODE_VECTOR_INT),  /* SIMD vectors */ \
>>   DEF_MODE_CLASS (MODE_VECTOR_FRACT),/* SIMD vectors */  
>>\
>>   DEF_MODE_CLASS (MODE_VECTOR_UFRACT),   /* SIMD vectors */  
>>\
>>Index: gcc/machmode.h
>>===
>>--- gcc/machmode.h2017-10-25 16:50:31.832332710 +0100
>>+++ gcc/machmode.h2017-10-25 16:50:35.628184659 +0100
>>@@ -108,6 +108,7 @@ #define INTEGRAL_MODE_P(MODE) \
>>   (GET_MODE_CLASS (MODE) == MODE_INT \
>>|| GET_MODE_CLASS (MODE) == MODE_PARTIAL_INT \
>>|| GET_MODE_CLASS (MODE) == MODE_COMPLEX_INT \
>>+   || GET_MODE_CLASS (MODE) == MODE_VECTOR_BOOL \
>>|| GET_MODE_CLASS (MODE) == MODE_VECTOR_INT)
>> 
>> /* Nonzero if MODE is a floating-point mode.  */
>>@@ -123,8 +124,9 @@ #define 

Re: [PATCH] C: detect more missing semicolons (PR c/7356)

[Jeff Law]

On 10/11/2017 01:32 PM, David Malcolm wrote:
> [This patch assumes the two patches here:
>  https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00274.html ]
I see the patch directly referenced in that message on the trunk.  But
I'm not sure what you mean by "two patches".  If there's a prereq that
hasn't been approved, let me know.


> 
> c_parser_declaration_or_fndef has logic for parsing what might be
> either a declaration or a function definition.
> 
> This patch adds a test to detect cases where a semicolon would have
> terminated the decls as a declaration, where the token that follows
> would start a new declaration specifier, and updates the error message
> accordingly, with a fix-it hint.
> 
> This addresses PR c/7356, fixing the case of a stray token before a
> #include which previously gave inscrutable output, and improving e.g.:
> 
>   int i
>   int j;
> 
> from:
> 
>   t.c:2:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before 
> 'int'
>int j;
>^~~
> 
> to:
> 
>   t.c:1:6: error: expected ';' before 'int'
>int i
> ^
> ;
>int j;
>~~~
> 
> The patch also adds a test for PR c/44515 as a baseline.
Personally I find the current error easier to digest.  It quite clearly
tells me to look before the current token and shove in an appropriate
thingie :-)   The extra vertical space, to me, makes the error message
harder to parse.

But I can see how others would prefer to see the point where the
punctuation was missing.  So I won't let my biases get in the way here.



> 
> gcc/c/ChangeLog:
>   PR c/7356
>   * c-parser.c (c_parser_declaration_or_fndef): Detect missing
>   semicolons.
> 
> gcc/testsuite/ChangeLog:
>   PR c/7356
>   PR c/44515
>   * c-c++-common/pr44515.c: New test case.
>   * gcc.dg/pr7356-2.c: New test case.
>   * gcc.dg/pr7356.c: New test case.
>   * gcc.dg/spellcheck-typenames.c: Update the "singed" char "TODO"
>   case to reflect changes to output.
>   * gcc.dg/noncompile/920923-1.c: Add dg-warning to reflect changes
>   to output.
OK.
jeff

Add support for adjusting the number of units in a mode

[Richard Sandiford]

We already allow the target to change the size and alignment of a mode.
This patch does the same thing for the number of units, which is needed
to give command-line control of the SVE vector length.

Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu,
on top of the poly_int series.  I think I can approve this under the
gen* maintainership, so if there are no comments in the menatime,
I'll apply it if the prerequisites are approved.

Thanks,
Richard


2017-10-25  Richard Sandiford  
Alan Hayward  
David Sherwood  

gcc/
* machmode.h (mode_precision): Prefix with CONST_MODE_PRECISION.
(mode_nunits): Likewise CONST_MODE_NUNITS.
* machmode.def (ADJUST_NUNITS): Document.
* genmodes.c (mode_data::need_nunits_adj): New field.
(blank_mode): Update accordingly.
(adj_nunits): New variable.
(print_maybe_const_decl): Replace CATEGORY with a NEEDS_ADJ
parameter.
(emit_mode_size_inline): Set need_bytesize_adj for all modes
listed in adj_nunits.
(emit_mode_nunits_inline): Set need_nunits_adj for all modes
listed in adj_nunits.  Don't emit case statements for such modes.
(emit_insn_modes_h): Emit definitions of CONST_MODE_NUNITS
and CONST_MODE_PRECISION.  Make CONST_MODE_SIZE expand to
nothing if adj_nunits is nonnull.
(emit_mode_precision, emit_mode_nunits): Use print_maybe_const_decl.
(emit_mode_unit_size, emit_mode_base_align, emit_mode_ibit)
(emit_mode_fbit): Update use of print_maybe_const_decl.
(emit_move_size): Likewise.  Treat the array as non-const
if adj_nunits.
(emit_mode_adjustments): Handle adj_nunits.

Index: gcc/machmode.h
===
--- gcc/machmode.h  2017-10-25 16:50:35.628184659 +0100
+++ gcc/machmode.h  2017-10-25 16:55:00.469175980 +0100
@@ -23,9 +23,9 @@ #define HAVE_MACHINE_MODES
 typedef opt_mode opt_machine_mode;
 
 extern CONST_MODE_SIZE poly_uint16_pod mode_size[NUM_MACHINE_MODES];
-extern const poly_uint16_pod mode_precision[NUM_MACHINE_MODES];
+extern CONST_MODE_PRECISION poly_uint16_pod mode_precision[NUM_MACHINE_MODES];
 extern const unsigned char mode_inner[NUM_MACHINE_MODES];
-extern const poly_uint16_pod mode_nunits[NUM_MACHINE_MODES];
+extern CONST_MODE_NUNITS poly_uint16_pod mode_nunits[NUM_MACHINE_MODES];
 extern CONST_MODE_UNIT_SIZE unsigned char mode_unit_size[NUM_MACHINE_MODES];
 extern const unsigned short mode_unit_precision[NUM_MACHINE_MODES];
 extern const unsigned char mode_wider[NUM_MACHINE_MODES];
Index: gcc/machmode.def
===
--- gcc/machmode.def2017-10-25 16:50:35.628184659 +0100
+++ gcc/machmode.def2017-10-25 16:55:00.468176022 +0100
@@ -169,6 +169,12 @@ along with GCC; see the file COPYING3.
Unlike a FORMAT argument, if you are adjusting a float format
you must put an & in front of the name of each format structure.
 
+ ADJUST_NUNITS (MODE, EXPR);
+   Like the above, but set the number of nunits of MODE to EXPR.
+   This changes the size and precision of the mode in proportion
+   to the change in the number of units; for example, doubling
+   the number of units doubles the size and precision as well.
+
Note: If a mode is ever made which is more than 255 bytes wide,
machmode.h and genmodes.c will have to be changed to allocate
more space for the mode_size and mode_alignment arrays.  */
Index: gcc/genmodes.c
===
--- gcc/genmodes.c  2017-10-25 16:50:35.627184698 +0100
+++ gcc/genmodes.c  2017-10-25 16:55:00.468176022 +0100
@@ -72,7 +72,9 @@ struct mode_data
   unsigned int counter;/* Rank ordering of modes */
   unsigned int ibit;   /* the number of integral bits */
   unsigned int fbit;   /* the number of fractional bits */
-  bool need_bytesize_adj;  /* true if this mode need dynamic size
+  bool need_nunits_adj;/* true if this mode needs dynamic 
nunits
+  adjustment */
+  bool need_bytesize_adj;  /* true if this mode needs dynamic size
   adjustment */
   unsigned int int_n;  /* If nonzero, then __int will be 
defined */
 };
@@ -85,7 +87,7 @@ static const struct mode_data blank_mode
   0, "", MAX_MODE_CLASS,
   -1U, -1U, -1U, -1U,
   0, 0, 0, 0, 0, 0,
-  "", 0, 0, 0, 0, false, 0
+  "", 0, 0, 0, 0, false, false, 0
 };
 
 static htab_t modes_by_name;
@@ -103,6 +105,7 @@ struct mode_adjust
   unsigned int line;
 };
 
+static struct mode_adjust *adj_nunits;
 static struct mode_adjust *adj_bytesize;
 static struct mode_adjust *adj_alignment;
 static struct mode_adjust *adj_format;
@@ -786,6 +789,7 @@ 

Re: Add support for MODE_VECTOR_BOOL

[Richard Biener]

On October 25, 2017 5:54:02 PM GMT+02:00, Richard Sandiford 
 wrote:
>This patch adds a new mode class to represent vectors of booleans.
>GET_MODE_BITSIZE (m) / GET_MODE_NUNITS (m) determines the number
>of bits that are used to represent each boolean; this can be 1
>for a fully-packed representation or greater than 1 for an unpacked
>representation.  In the latter case, the value of bits other than
>the lowest is not significant.
>
>These are used by the SVE port to represent predicates.
>
>Tested on aarch64-linux-gnu, x86_64-linux-gnu and
>powerpc64le-linux-gnu,
>on top of the poly_int series.  OK to install?

AVX uses integer modes for predicates. Can't you do the same thing, with 
variable size, of course? 

AVX has moves between predicate registers and GPRs. 

Richard. 


>Richard
>
>
>2017-10-25  Richard Sandiford  
>   Alan Hayward  
>   David Sherwood  
>
>gcc/
>   * mode-classes.def (MODE_VECTOR_BOOL): New mode class.
>   * machmode.h (INTEGRAL_MODE_P, VECTOR_MODE_P): Return true
>   for MODE_VECTOR_BOOL.
>   * machmode.def (VECTOR_BOOL_MODE): Document.
>   * genmodes.c (VECTOR_BOOL_MODE): New macro.
>   (make_vector_bool_mode): New function.
>   (complete_mode, emit_mode_wider, emit_mode_adjustments): Handle
>   MODE_VECTOR_BOOL.
>   * lto-streamer-in.c (lto_input_mode_table): Likewise.
>   * stor-layout.c (int_mode_for_mode): Likewise.
>   * tree.c (build_vector_type_for_mode): Likewise.
>   * varasm.c (output_constant_pool_2): Likewise.
>   * emit-rtl.c (gen_const_vec_duplicate): Likewise,
>   (init_emit_once): Make sure that CONST1_RTX (BImode) and
>   CONSTM1_RTX (BImode) are the same thing.  Initialize const_tiny_rtx
>   for MODE_VECTOR_BOOL.
>   * expr.c (expand_expr_real_1): Use VECTOR_MODE_P instead of a list
>   of mode class checks.
>   * tree-vect-generic.c (expand_vector_operation): Use VECTOR_MODE_P
>   instead of a list of mode class checks.
>   (expand_vector_scalar_condition): Likewise.
>   (type_for_widest_vector_mode): Handle BImode as an inner mode.
>
>gcc/c-family/
>   * c-common.c (c_common_type_for_mode): Handle MODE_VECTOR_BOOL.
>
>gcc/fortran/
>   * trans-types.c (gfc_type_for_mode): Handle MODE_VECTOR_BOOL.
>
>gcc/go/
>   * go-lang.c (go_langhook_type_for_mode): Handle MODE_VECTOR_BOOL.
>
>gcc/lto/
>   * lto-lang.c (lto_type_for_mode): Handle MODE_VECTOR_BOOL.
>
>Index: gcc/mode-classes.def
>===
>--- gcc/mode-classes.def   2017-10-25 16:50:18.000869425 +0100
>+++ gcc/mode-classes.def   2017-10-25 16:50:35.628184659 +0100
>@@ -31,6 +31,7 @@ along with GCC; see the file COPYING3.
> DEF_MODE_CLASS (MODE_DECIMAL_FLOAT),  /* decimal floating point */   \
>   DEF_MODE_CLASS (MODE_COMPLEX_INT),  /* complex numbers */  \
>   DEF_MODE_CLASS (MODE_COMPLEX_FLOAT),
>\
>+  DEF_MODE_CLASS (MODE_VECTOR_BOOL),  /* vectors of single bits */   \
>   DEF_MODE_CLASS (MODE_VECTOR_INT),   /* SIMD vectors */ \
>   DEF_MODE_CLASS (MODE_VECTOR_FRACT), /* SIMD vectors */ \
>   DEF_MODE_CLASS (MODE_VECTOR_UFRACT),/* SIMD vectors */  
>\
>Index: gcc/machmode.h
>===
>--- gcc/machmode.h 2017-10-25 16:50:31.832332710 +0100
>+++ gcc/machmode.h 2017-10-25 16:50:35.628184659 +0100
>@@ -108,6 +108,7 @@ #define INTEGRAL_MODE_P(MODE)  \
>   (GET_MODE_CLASS (MODE) == MODE_INT  \
>|| GET_MODE_CLASS (MODE) == MODE_PARTIAL_INT \
>|| GET_MODE_CLASS (MODE) == MODE_COMPLEX_INT \
>+   || GET_MODE_CLASS (MODE) == MODE_VECTOR_BOOL \
>|| GET_MODE_CLASS (MODE) == MODE_VECTOR_INT)
> 
> /* Nonzero if MODE is a floating-point mode.  */
>@@ -123,8 +124,9 @@ #define COMPLEX_MODE_P(MODE)   \
>|| GET_MODE_CLASS (MODE) == MODE_COMPLEX_FLOAT)
> 
> /* Nonzero if MODE is a vector mode.  */
>-#define VECTOR_MODE_P(MODE)   \
>-  (GET_MODE_CLASS (MODE) == MODE_VECTOR_INT   \
>+#define VECTOR_MODE_P(MODE)   \
>+  (GET_MODE_CLASS (MODE) == MODE_VECTOR_BOOL  \
>+   || GET_MODE_CLASS (MODE) == MODE_VECTOR_INT\
>|| GET_MODE_CLASS (MODE) == MODE_VECTOR_FLOAT  \
>|| GET_MODE_CLASS (MODE) == MODE_VECTOR_FRACT  \
>|| GET_MODE_CLASS (MODE) == MODE_VECTOR_UFRACT \
>Index: gcc/machmode.def
>===
>--- gcc/machmode.def   2017-10-25 16:50:18.000869425 +0100
>+++ gcc/machmode.def   2017-10-25 16:50:35.628184659 +0100
>@@ -142,6 +142,12 @@ along with GCC; see the file COPYING3.
>   than two bytes (if CLASS is FLOAT).  CLASS must be INT or
>   FLOAT.  

Add support for MODE_VECTOR_BOOL

[Richard Sandiford]

This patch adds a new mode class to represent vectors of booleans.
GET_MODE_BITSIZE (m) / GET_MODE_NUNITS (m) determines the number
of bits that are used to represent each boolean; this can be 1
for a fully-packed representation or greater than 1 for an unpacked
representation.  In the latter case, the value of bits other than
the lowest is not significant.

These are used by the SVE port to represent predicates.

Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu,
on top of the poly_int series.  OK to install?

Richard


2017-10-25  Richard Sandiford  
Alan Hayward  
David Sherwood  

gcc/
* mode-classes.def (MODE_VECTOR_BOOL): New mode class.
* machmode.h (INTEGRAL_MODE_P, VECTOR_MODE_P): Return true
for MODE_VECTOR_BOOL.
* machmode.def (VECTOR_BOOL_MODE): Document.
* genmodes.c (VECTOR_BOOL_MODE): New macro.
(make_vector_bool_mode): New function.
(complete_mode, emit_mode_wider, emit_mode_adjustments): Handle
MODE_VECTOR_BOOL.
* lto-streamer-in.c (lto_input_mode_table): Likewise.
* stor-layout.c (int_mode_for_mode): Likewise.
* tree.c (build_vector_type_for_mode): Likewise.
* varasm.c (output_constant_pool_2): Likewise.
* emit-rtl.c (gen_const_vec_duplicate): Likewise,
(init_emit_once): Make sure that CONST1_RTX (BImode) and
CONSTM1_RTX (BImode) are the same thing.  Initialize const_tiny_rtx
for MODE_VECTOR_BOOL.
* expr.c (expand_expr_real_1): Use VECTOR_MODE_P instead of a list
of mode class checks.
* tree-vect-generic.c (expand_vector_operation): Use VECTOR_MODE_P
instead of a list of mode class checks.
(expand_vector_scalar_condition): Likewise.
(type_for_widest_vector_mode): Handle BImode as an inner mode.

gcc/c-family/
* c-common.c (c_common_type_for_mode): Handle MODE_VECTOR_BOOL.

gcc/fortran/
* trans-types.c (gfc_type_for_mode): Handle MODE_VECTOR_BOOL.

gcc/go/
* go-lang.c (go_langhook_type_for_mode): Handle MODE_VECTOR_BOOL.

gcc/lto/
* lto-lang.c (lto_type_for_mode): Handle MODE_VECTOR_BOOL.

Index: gcc/mode-classes.def
===
--- gcc/mode-classes.def2017-10-25 16:50:18.000869425 +0100
+++ gcc/mode-classes.def2017-10-25 16:50:35.628184659 +0100
@@ -31,6 +31,7 @@ along with GCC; see the file COPYING3.
   DEF_MODE_CLASS (MODE_DECIMAL_FLOAT), /* decimal floating point */   \
   DEF_MODE_CLASS (MODE_COMPLEX_INT),   /* complex numbers */  \
   DEF_MODE_CLASS (MODE_COMPLEX_FLOAT),\
+  DEF_MODE_CLASS (MODE_VECTOR_BOOL),   /* vectors of single bits */   \
   DEF_MODE_CLASS (MODE_VECTOR_INT),/* SIMD vectors */ \
   DEF_MODE_CLASS (MODE_VECTOR_FRACT),  /* SIMD vectors */ \
   DEF_MODE_CLASS (MODE_VECTOR_UFRACT), /* SIMD vectors */ \
Index: gcc/machmode.h
===
--- gcc/machmode.h  2017-10-25 16:50:31.832332710 +0100
+++ gcc/machmode.h  2017-10-25 16:50:35.628184659 +0100
@@ -108,6 +108,7 @@ #define INTEGRAL_MODE_P(MODE)   \
   (GET_MODE_CLASS (MODE) == MODE_INT   \
|| GET_MODE_CLASS (MODE) == MODE_PARTIAL_INT \
|| GET_MODE_CLASS (MODE) == MODE_COMPLEX_INT \
+   || GET_MODE_CLASS (MODE) == MODE_VECTOR_BOOL \
|| GET_MODE_CLASS (MODE) == MODE_VECTOR_INT)
 
 /* Nonzero if MODE is a floating-point mode.  */
@@ -123,8 +124,9 @@ #define COMPLEX_MODE_P(MODE)\
|| GET_MODE_CLASS (MODE) == MODE_COMPLEX_FLOAT)
 
 /* Nonzero if MODE is a vector mode.  */
-#define VECTOR_MODE_P(MODE)\
-  (GET_MODE_CLASS (MODE) == MODE_VECTOR_INT\
+#define VECTOR_MODE_P(MODE)\
+  (GET_MODE_CLASS (MODE) == MODE_VECTOR_BOOL   \
+   || GET_MODE_CLASS (MODE) == MODE_VECTOR_INT \
|| GET_MODE_CLASS (MODE) == MODE_VECTOR_FLOAT   \
|| GET_MODE_CLASS (MODE) == MODE_VECTOR_FRACT   \
|| GET_MODE_CLASS (MODE) == MODE_VECTOR_UFRACT  \
Index: gcc/machmode.def
===
--- gcc/machmode.def2017-10-25 16:50:18.000869425 +0100
+++ gcc/machmode.def2017-10-25 16:50:35.628184659 +0100
@@ -142,6 +142,12 @@ along with GCC; see the file COPYING3.
than two bytes (if CLASS is FLOAT).  CLASS must be INT or
FLOAT.  The names follow the same rule as VECTOR_MODE uses.
 
+ VECTOR_BOOL_MODE (COUNT, BYTESIZE)
+   Create a vector of booleans with COUNT elements and BYTESIZE bytes.
+   Each boolean occupies (COUNT * BITS_PER_UNIT) / BYTESIZE bits,
+   with the element at index 0 occupying the lsb of the first byte
+   in memory.  Only 

Re: [RFA][PATCH] Convert sprintf warning code to use a dominator walk

[Jeff Law]

On 10/24/2017 11:35 AM, Martin Sebor wrote:
> On 10/23/2017 05:14 PM, Jeff Law wrote:
>>
>> Martin,
>>
>> I'd like your thoughts on this patch.
>>
>> One of the things I'm working on is changes that would allow passes that
>> use dominator walks to trivially perform context sensitive range
>> analysis as a part of their dominator walk.
>>
>> As I outlined earlier this would allow us to easily fix the false
>> positive sprintf warning reported a week or two ago.
>>
>> This patch converts the sprintf warning code to perform a dominator walk
>> rather than just walking the blocks in whatever order they appear in the
>> basic block array.
>>
>> From an implementation standpoint we derive a new class sprintf_dom_walk
>> from the dom_walker class.  Like other dom walkers we walk statements
>> from within the before_dom_children member function.  Very standard
>> stuff.
>>
>> I moved handle_gimple_call and various dependencies into the
>> sprintf_dom_walker class to facilitate calling handle_gimple_call from
>> within the before_dom_children member function.  There's light fallout
>> in various places where the call_info structure was explicitly expected
>> to be found in the pass_sprintf_length class, but is now found in the
>> sprintf_dom_walker class.
>>
>> This has been bootstrapped and regression tested on x86_64-linux-gnu.
>> I've also layered my embedded VRP analysis on top of this work and
>> verified that it does indeed fix the reported false positive.
>>
>> Thoughts?
> 
> If it lets us improve the quality of the range information I can't
> think of a downside.
It's potentially slower simply because the domwalk interface is more
expensive than just iterating over the blocks with FOR_EACH_BB.  But
that's about it.  I think the ability to get more accurate range
information will make the compile-time hit worth it.

> 
> Besides the sprintf pass, a number of other areas depend on ranges,
> most of all the -Wstringop-overflow and truncation warnings and
> now -Wrestrict (once my enhancement is approved).  It would be nice
> to be able to get the same improvements there.  Does it mean that
> those warnings will need to be moved into a standalone pass?  (I'm
> not opposed to it, just wondering what to expect if this is
> the route we want to go.)
They don't necessarily have to be a standalone pass -- they just have to
be implementable as part of a dominator walk to get the cheap context
sensitive range data.

So IIRC you've got some code to add additional warnings within the
strlen pass.  That pass is already a dominator walk.  In theory you'll
just add a member to the strlen_dom_walker class, then a call in
before_dom_children and after_dom_children virtuals and you should be
able to query the context sensitive range information.

For warnings that occur in code that is not easily structured as a
dominator walk, Andrew's work will definitely be a better choice.

Andrew's work will almost certainly also generate even finer grained
ranges because it can work on an arbitrary path through the CFG rather
than relying on dominance relationships.  Consider

A
   / \
  B   C
   \ /
D

Range information implied by the edge A->B is usable within B because
the edge A->B dominates B.  Similarly for range information implied by
A->C being available in C.  But range information implied by A->B is not
available in D because A->B does not dominate D.  SImilarly range
information implied by A->C is not available in D.

I touched on this in a private message recently.  Namely that exploiting
range data in non-dominated blocks feels a *lot* like jump threading and
should likely be structured as a backwards walk query (and thus is more
suitable for Andrew's infrastructure).


jeff

[PATCH][AArch64] Simplify frame pointer logic

[Wilco Dijkstra]

Simplify frame pointer logic based on review comments here
(https://gcc.gnu.org/ml/gcc-patches/2017-10/msg01727.html).

This patch incrementally adds to these frame pointer cleanup patches:
https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00377.html
https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00381.html

Add aarch64_needs_frame_chain to decide when to emit the frame
chain using clearer logic. Introduce aarch64_use_frame_pointer
which contains the value of -fno-omit-frame-pointer
(flag_omit_frame_pointer is set to a magic value so that the mid-end
won't force the frame pointer in all cases, and leaf frame pointer
emission can't be supported).

OK for commit?

2017-10-25  Wilco Dijkstra  

* config/aarch64/aarch64.c (aarch64_use_frame_pointer):
Add new boolean.
(aarch64_needs_frame_chain): New function.
(aarch64_parse_override_string): Set aarch64_parse_override_string.
--

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 
0c0edc100ee4197d027e2d80da56a12b9129fca4..9abde0d66d52ac4fd17d1dc2193a6bbb5f9c65fc
 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -163,6 +163,9 @@ unsigned long aarch64_tune_flags = 0;
 /* Global flag for PC relative loads.  */
 bool aarch64_pcrelative_literal_loads;
 
+/* Global flag for whether frame pointer is enabled.  */
+bool aarch64_use_frame_pointer;
+
 /* Support for command line parsing of boolean flags in the tuning
structures.  */
 struct aarch64_flag_desc
@@ -2871,6 +2874,25 @@ aarch64_output_probe_stack_range (rtx reg1, rtx reg2)
   return "";
 }
 
+/* Determine whether a frame chain needs to be generated.  */
+static bool
+aarch64_needs_frame_chain (void)
+{
+  /* Force a frame chain for EH returns so the return address is at FP+8.  */
+  if (frame_pointer_needed || crtl->calls_eh_return)
+return true;
+
+  /* A leaf function cannot have calls or write LR.  */
+  bool is_leaf = crtl->is_leaf && !df_regs_ever_live_p (LR_REGNUM);
+
+  /* Don't use a frame chain in leaf functions if leaf frame pointers
+ are disabled.  */
+  if (flag_omit_leaf_frame_pointer && is_leaf)
+return false;
+
+  return aarch64_use_frame_pointer;
+}
+
 /* Mark the registers that need to be saved by the callee and calculate
the size of the callee-saved registers area and frame record (both FP
and LR may be omitted).  */
@@ -2883,17 +2905,7 @@ aarch64_layout_frame (void)
   if (reload_completed && cfun->machine->frame.laid_out)
 return;
 
-  /* Force a frame chain for EH returns so the return address is at FP+8.  */
-  cfun->machine->frame.emit_frame_chain
-= frame_pointer_needed || crtl->calls_eh_return;
-
-  /* Emit a frame chain if the frame pointer is enabled.
- If -momit-leaf-frame-pointer is used, do not use a frame chain
- in leaf functions which do not use LR.  */
-  if (flag_omit_frame_pointer == 2
-  && !(flag_omit_leaf_frame_pointer && crtl->is_leaf
-  && !df_regs_ever_live_p (LR_REGNUM)))
-cfun->machine->frame.emit_frame_chain = true;
+  cfun->machine->frame.emit_frame_chain = aarch64_needs_frame_chain ();
 
 #define SLOT_NOT_REQUIRED (-2)
 #define SLOT_REQUIRED (-1)
@@ -9152,12 +9164,12 @@ aarch64_override_options_after_change_1 (struct 
gcc_options *opts)
   /* PR 70044: We have to be careful about being called multiple times for the
  same function.  This means all changes should be repeatable.  */
 
-  /* If the frame pointer is enabled, set it to a special value that behaves
- similar to frame pointer omission.  If we don't do this all leaf functions
- will get a frame pointer even if flag_omit_leaf_frame_pointer is set.
- If flag_omit_frame_pointer has this special value, we must force the
- frame pointer if not in a leaf function.  We also need to force it in a
- leaf function if flag_omit_frame_pointer is not set or if LR is used.  */
+  /* Set aarch64_use_frame_pointer based on -fno-omit-frame-pointer.
+ Disable the frame pointer flag so the mid-end will not use a frame
+ pointer in leaf functions in order to support -fomit-leaf-frame-pointer.
+ Set x_flag_omit_frame_pointer to the special value 2 to differentiate
+ between -fomit-frame-pointer (1) and -fno-omit-frame-pointer (2).  */
+  aarch64_use_frame_pointer = opts->x_flag_omit_frame_pointer != 1;
   if (opts->x_flag_omit_frame_pointer == 0)
 opts->x_flag_omit_frame_pointer = 2;
 

[PATCH, rs6000] add testcase coverage for vec_neg built-ins.

[Will Schmidt]

Hi,

[PATCH, rs6000] add testcase coverage for vec_neg built-ins.
Add testcase coverage for the vec_neg builtins.

Regtest running, (but sniff tests has been clean).  OK for trunk?

Thanks,
-Will

[testsuite]

2017-10-25  Will Schmidt  

* gcc.target/powerpc/fold-vec-neg-char.c: New.
* gcc.target/powerpc/fold-vec-neg-floatdouble.c: New.
* gcc.target/powerpc/fold-vec-neg-int.c: New.
* gcc.target/powerpc/fold-vec-neg-longlong.c: New.
* gcc.target/powerpc/fold-vec-neg-short.c: New.


diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-neg-char.c 
b/gcc/testsuite/gcc.target/powerpc/fold-vec-neg-char.c
new file mode 100644
index 000..19ea3d3
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-neg-char.c
@@ -0,0 +1,19 @@
+/* Verify that overloaded built-ins for vec_neg with char
+   inputs produce the right code.  */
+
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_altivec_ok } */
+/* { dg-options "-maltivec -O2" } */
+
+#include 
+
+vector signed char
+test2 (vector signed char x)
+{
+  return vec_neg (x);
+}
+
+/* { dg-final { scan-assembler-times "xxspltib|vspltisw|vxor" 1 } } */
+/* { dg-final { scan-assembler-times "vsububm" 1 } } */
+/* { dg-final { scan-assembler-times "vmaxsb" 0 } } */
+
diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-neg-floatdouble.c 
b/gcc/testsuite/gcc.target/powerpc/fold-vec-neg-floatdouble.c
new file mode 100644
index 000..79ad924
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-neg-floatdouble.c
@@ -0,0 +1,23 @@
+/* Verify that overloaded built-ins for vec_neg with float and
+   double inputs for VSX produce the right code.  */
+
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_vsx_ok } */
+/* { dg-options "-mvsx -O2" } */
+
+#include 
+
+vector float
+test1 (vector float x)
+{
+  return vec_neg (x);
+}
+
+vector double
+test2 (vector double x)
+{
+  return vec_neg (x);
+}
+
+/* { dg-final { scan-assembler-times "xvnegsp" 1 } } */
+/* { dg-final { scan-assembler-times "xvnegdp" 1 } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-neg-int.c 
b/gcc/testsuite/gcc.target/powerpc/fold-vec-neg-int.c
new file mode 100644
index 000..d6ca128
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-neg-int.c
@@ -0,0 +1,18 @@
+/* Verify that overloaded built-ins for vec_neg with int
+   inputs produce the right code.  */
+
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_altivec_ok } */
+/* { dg-options "-maltivec -O2" } */
+
+#include 
+
+vector signed int
+test1 (vector signed int x)
+{
+  return vec_neg (x);
+}
+
+/* { dg-final { scan-assembler-times "xxspltib|vspltisw|vxor" 1 } } */
+/* { dg-final { scan-assembler-times "vsubuwm" 1 } } */
+/* { dg-final { scan-assembler-times "vmaxsw" 0 } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-neg-longlong.c 
b/gcc/testsuite/gcc.target/powerpc/fold-vec-neg-longlong.c
new file mode 100644
index 000..48f7178
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-neg-longlong.c
@@ -0,0 +1,18 @@
+/* Verify that overloaded built-ins for vec_neg with long long
+   inputs produce the right code.  */
+
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_p8vector_ok } */
+/* { dg-options "-mpower8-vector -O2" } */
+
+#include 
+
+vector signed long long
+test3 (vector signed long long x)
+{
+  return vec_neg (x);
+}
+
+/* { dg-final { scan-assembler-times "xxspltib|vspltisw" 1 } } */
+/* { dg-final { scan-assembler-times "vsubudm" 1 } } */
+/* { dg-final { scan-assembler-times "vmaxsd" 0 } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-neg-short.c 
b/gcc/testsuite/gcc.target/powerpc/fold-vec-neg-short.c
new file mode 100644
index 000..997a9d4
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-neg-short.c
@@ -0,0 +1,18 @@
+/* Verify that overloaded built-ins for vec_neg with short
+   inputs produce the right code.  */
+
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_altivec_ok } */
+/* { dg-options "-maltivec -O2" } */
+
+#include 
+
+vector signed short
+test3 (vector signed short x)
+{
+  return vec_neg (x);
+}
+
+/* { dg-final { scan-assembler-times "xxspltib|vspltisw|vxor" 1 } } */
+/* { dg-final { scan-assembler-times "vsubuhm" 1 } } */
+/* { dg-final { scan-assembler-times "vmaxsh" 0 } } */

Re: [RFC] propagate malloc attribute in ipa-pure-const pass

[Jan Hubicka]

> On 24 October 2017 at 16:26, Jan Hubicka  wrote:
> >> 2017-10-13  Prathamesh Kulkarni  
> >>
> >>   * cgraph.h (set_malloc_flag): Declare.
> >>   * cgraph.c (set_malloc_flag_1): New function.
> >>   (set_malloc_flag): Likewise.
> >>   * ipa-fnsummary.h (ipa_call_summary): Add new field is_return_callee.
> >>   * ipa-fnsummary.c (ipa_call_summary::reset): Set is_return_callee to
> >>   false.
> >>   (read_ipa_call_summary): Add support for reading is_return_callee.
> >>   (write_ipa_call_summary): Stream is_return_callee.
> >>   * ipa-inline.c (ipa_inline): Remove call to ipa_free_fn_summary.
> >>   * ipa-pure-const.c: Add headers ssa.h, alloc-pool.h, 
> >> symbol-summary.h,
> >>   ipa-prop.h, ipa-fnsummary.h.
> >>   (pure_const_names): Change to static.
> >>   (malloc_state_e): Define.
> >>   (malloc_state_names): Define.
> >>   (funct_state_d): Add field malloc_state.
> >>   (varying_state): Set malloc_state to STATE_MALLOC_BOTTOM.
> >>   (check_retval_uses): New function.
> >>   (malloc_candidate_p): Likewise.
> >>   (analyze_function): Add support for malloc attribute.
> >>   (pure_const_write_summary): Stream malloc_state.
> >>   (pure_const_read_summary): Add support for reading malloc_state.
> >>   (dump_malloc_lattice): New function.
> >>   (propagate_malloc): New function.
> >>   (ipa_pure_const::execute): Call propagate_malloc and
> >>   ipa_free_fn_summary.
> >>   (pass_local_pure_const::execute): Add support for malloc attribute.
> >>   * ssa-iterators.h (RETURN_FROM_IMM_USE_STMT): New macro.
> >>
> >> testsuite/
> >>   * gcc.dg/ipa/propmalloc-1.c: New test-case.
> >>   * gcc.dg/ipa/propmalloc-2.c: Likewise.
> >>   * gcc.dg/ipa/propmalloc-3.c: Likewise.
> >
> > OK.
> > Perhaps we could also add -Wsuggest-sttribute=malloc and mention it in 
> > changes.html?
> Done in this version.
> In warn_function_malloc(), I passed false for known_finite param to
> suggest_attribute().
> Does that look OK ?
> Validation in progress. OK to commit if passes ?

OK, thanks!
Honza

[PATCH, rs6000] Gimple folding for vec_madd()

[Will Schmidt]

Hi,

Add support for gimple folding of the vec_madd() (vector multiply-add)
intrinsics.
Testcase coverage is provided by the existing tests 
 gcc.target/powerpc/fold-vec-madd-*.c

Sniff-tests appear clean.  A full regtest is currently running across assorted 
Power systems. (P6-P9).
OK for trunk (pending clean run results)?

Thanks,
-Will

[gcc]

2017-10-25  Will Schmidt 

* config/rs6000/rs6000.c: (rs6000_gimple_fold_builtin) Add support for
  gimple folding of vec_madd() intrinsics.

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 4837e14..04c2b15 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -16606,10 +16606,43 @@ rs6000_gimple_fold_builtin (gimple_stmt_iterator *gsi)
   build_int_cst (arg2_type, 0)), arg0);
 gimple_set_location (g, loc);
 gsi_replace (gsi, g, true);
 return true;
   }
+
+/* vec_madd (Float) */
+case ALTIVEC_BUILTIN_VMADDFP:
+case VSX_BUILTIN_XVMADDDP:
+  {
+   arg0 = gimple_call_arg (stmt, 0);
+   arg1 = gimple_call_arg (stmt, 1);
+   tree arg2 = gimple_call_arg (stmt, 2);
+   lhs = gimple_call_lhs (stmt);
+   gimple *g = gimple_build_assign (lhs, FMA_EXPR , arg0, arg1, arg2);
+   gimple_set_location (g, gimple_location (stmt));
+   gsi_replace (gsi, g, true);
+   return true;
+  }
+/* vec_madd (Integral) */
+case ALTIVEC_BUILTIN_VMLADDUHM:
+  {
+   arg0 = gimple_call_arg (stmt, 0);
+   arg1 = gimple_call_arg (stmt, 1);
+   tree arg2 = gimple_call_arg (stmt, 2);
+   lhs = gimple_call_lhs (stmt);
+   tree lhs_type = TREE_TYPE (lhs);
+   location_t loc = gimple_location (stmt);
+   gimple_seq stmts = NULL;
+   tree mult_result = gimple_build (, loc, MULT_EXPR,
+  lhs_type, arg0, arg1);
+   tree plus_result = gimple_build (, loc, PLUS_EXPR,
+  lhs_type, mult_result, arg2);
+   gsi_insert_seq_before (gsi, stmts, GSI_SAME_STMT);
+   update_call_from_tree (gsi, plus_result);
+   return true;
+  }
+
 default:
if (TARGET_DEBUG_BUILTIN)
   fprintf (stderr, "gimple builtin intrinsic not matched:%d %s %s\n",
fn_code, fn_name1, fn_name2);
   break;

Re: [PATCH] Update C++17 library status documentation

[Jonathan Wakely]

On 25/10/17 15:06 +0100, Jonathan Wakely wrote:

* doc/xml/manual/status_cxx2017.xml: Update C++17 status, and
information on feature-test macros.
* doc/html/*: Regenerate.

Committed to trunk.


And a similar patch for gcc-7-branch.


commit 045ffeb6b5cdd336ebe7592dbec68c0d53cd0c0c
Author: Jonathan Wakely 
Date:   Wed Oct 25 15:01:31 2017 +0100

Update C++17 library status documentation

* doc/xml/manual/status_cxx1998.xml: Correct statement about
what the doc covers.
* doc/xml/manual/status_cxx2011.xml: Likewise.
* doc/xml/manual/status_cxx2014.xml: Likewise.
* doc/xml/manual/status_cxx2017.xml: Update C++17 status, and
information on feature-test macros.
* doc/xml/manual/status_cxxtr1.xml: Correct statement about what
the doc covers.
* doc/xml/manual/status_cxxtr24733.xml: Likewise.
* doc/html/*: Regenerate.

diff --git a/libstdc++-v3/doc/xml/manual/status_cxx1998.xml b/libstdc++-v3/doc/xml/manual/status_cxx1998.xml
index 6afb016a45f..ffdc878ffe8 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx1998.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx1998.xml
@@ -18,8 +18,7 @@ This status table is based on the table of contents of ISO/IEC 14882:2003.
 
 
 
-This page describes the C++ support in mainline GCC SVN, not in any
-particular release.
+This page describes the C++ support in the GCC 7 series.
 
 
 
diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2011.xml b/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
index 705f2eecc60..b72c5f7810d 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
@@ -27,8 +27,7 @@ presence of the required flag.
 
 
 
-This page describes the C++11 support in mainline GCC SVN, not in any
-particular release.
+This page describes the C++11 support in the GCC 7 series.
 
 
 
diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2014.xml b/libstdc++-v3/doc/xml/manual/status_cxx2014.xml
index 6fa5a1d93a3..557e63888e4 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2014.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2014.xml
@@ -20,8 +20,7 @@ presence of the required flag.
 
 
 
-This page describes the C++14 and library TS support in mainline GCC SVN,
-not in any particular release.
+This page describes the C++14 and library TS support in the GCC 7 series.
 
 
 
diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2017.xml b/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
index 6158f96105f..389daefd75d 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
@@ -1,17 +1,17 @@
 http://docbook.org/ns/docbook; version="5.0" 
-	 xml:id="status.iso.201z" xreflabel="Status C++ 201z">
-
+	 xml:id="status.iso.2017" xreflabel="Status C++ 2017">
+
 
-C++ 201z
+C++ 2017
   
 ISO C++
-201z
+2017
   
 
 
 
-In this implementation the -std=gnu++1z or
--std=c++1z flag must be used to enable language
+In this implementation the -std=gnu++17 or
+-std=c++17 flag must be used to enable language
 and library
 features. See dialect
 options. The pre-defined symbol
@@ -20,13 +20,12 @@ presence of the required flag.
 
 
 
-This section describes the C++1z and library TS support in mainline GCC SVN,
-not in any particular release.
+This section describes the C++17 and library TS support in the GCC 7 series.
 
 
 
 The following table lists new library features that have been accepted into
-the C++1z working draft. The "Proposal" column provides a link to the
+the C++17 working draft. The "Proposal" column provides a link to the
 ISO C++ committee proposal that describes the feature, while the "Status"
 column indicates the first version of GCC that contains an implementation of
 this feature (if it has been implemented).
@@ -35,8 +34,8 @@ The "SD-6 Feature Test" column shows the corresponding macro or header from
 Feature-testing recommendations for C++.
 
 
-
-C++ 201z Implementation Status
+
+C++ 2017 Implementation Status
 
 
 
@@ -75,7 +74,7 @@ Feature-testing recommendations for C++.
 	P0137R1
 	
   
-   7 
+   7.1 
__cpp_lib_launder >= 201606 
 
 
@@ -97,9 +96,10 @@ Feature-testing recommendations for C++.
 	P0088R3
 	
   
-   7 
+   7.1 
__has_include(variant),
   __cpp_lib_variant >= 201603
+  (since 7.3, see Note 1)
   
 
 
@@ -110,9 +110,10 @@ Feature-testing recommendations for C++.
 	P0220R1
 	
   
-   7 
+   7.1 
__has_include(optional),
   __cpp_lib_optional >= 201603
+  (since 7.3, see Note 1)
   
 
 
@@ -123,9 +124,10 @@ Feature-testing recommendations for C++.
 	P0220R1
 	
   
-   7 
+   7.1 
__has_include(any),
   __cpp_lib_any >= 201603
+  (since 7.3, see Note 1)
   
 
 
@@ -136,9 +138,10 @@ Feature-testing 

[PATCH] Update C++17 library status documentation

[Jonathan Wakely]

* doc/xml/manual/status_cxx2017.xml: Update C++17 status, and
information on feature-test macros.
* doc/html/*: Regenerate.

Committed to trunk.

commit 4c7972f69c296f73598423b797bb032f1d637400
Author: Jonathan Wakely 
Date:   Wed Oct 25 15:01:31 2017 +0100

Update C++17 library status documentation

* doc/xml/manual/status_cxx2017.xml: Update C++17 status, and
information on feature-test macros.
* doc/html/*: Regenerate.

diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2017.xml 
b/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
index b5a65be12c9..aa0914cff72 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
@@ -1,17 +1,17 @@
 http://docbook.org/ns/docbook; version="5.0" 
-xml:id="status.iso.201z" xreflabel="Status C++ 201z">
-
+xml:id="status.iso.2017" xreflabel="Status C++ 2017">
+
 
-C++ 201z
+C++ 2017
   
 ISO C++
-201z
+2017
   
 
 
 
-In this implementation the -std=gnu++1z or
--std=c++1z flag must be used to enable language
+In this implementation the -std=gnu++17 or
+-std=c++17 flag must be used to enable language
 and library
 features. See dialect
 options. The pre-defined symbol
@@ -20,13 +20,13 @@ presence of the required flag.
 
 
 
-This section describes the C++1z and library TS support in mainline GCC SVN,
+This section describes the C++17 and library TS support in mainline GCC SVN,
 not in any particular release.
 
 
 
 The following table lists new library features that have been accepted into
-the C++1z working draft. The "Proposal" column provides a link to the
+the C++17 working draft. The "Proposal" column provides a link to the
 ISO C++ committee proposal that describes the feature, while the "Status"
 column indicates the first version of GCC that contains an implementation of
 this feature (if it has been implemented).
@@ -35,8 +35,8 @@ The "SD-6 Feature Test" column shows the corresponding macro 
or header from
 Feature-testing recommendations for C++.
 
 
-
-C++ 201z Implementation Status
+
+C++ 2017 Implementation Status
 
 
 
@@ -75,7 +75,7 @@ Feature-testing recommendations for C++.
P0137R1

   
-   7 
+   7.1 
__cpp_lib_launder >= 201606 
 
 
@@ -97,9 +97,10 @@ Feature-testing recommendations for C++.
P0088R3

   
-   7 
+   7.1 
__has_include(variant),
   __cpp_lib_variant >= 201603
+  (since 7.3, see Note 1)
   
 
 
@@ -110,9 +111,10 @@ Feature-testing recommendations for C++.
P0220R1

   
-   7 
+   7.1 
__has_include(optional),
   __cpp_lib_optional >= 201603
+  (since 7.3, see Note 1)
   
 
 
@@ -123,9 +125,10 @@ Feature-testing recommendations for C++.
P0220R1

   
-   7 
+   7.1 
__has_include(any),
   __cpp_lib_any >= 201603
+  (since 7.3, see Note 1)
   
 
 
@@ -136,9 +139,10 @@ Feature-testing recommendations for C++.
P0220R1

   
-   7 
+   7.1 
__has_include(string_view),
   __cpp_lib_string_view >= 201603
+  (since 7.3, see Note 1)
   
 
 
@@ -163,7 +167,7 @@ Feature-testing recommendations for C++.
P0220R1

   
-   7 
+   7.1 
__cpp_lib_apply >= 201603 
 
 
@@ -174,7 +178,7 @@ Feature-testing recommendations for C++.
P0220R1

   
-   7 
+   7.1 
__cpp_lib_shared_ptr_arrays >= 201603 
 
 
@@ -185,7 +189,7 @@ Feature-testing recommendations for C++.
P0220R1

   
-   7 
+   7.1 
__cpp_lib_boyer_moore_searcher >= 201603 
 
 
@@ -196,7 +200,7 @@ Feature-testing recommendations for C++.
P0220R1

   
-   7 
+   7.1 
__cpp_lib_sample >= 201603 
 
 
@@ -207,7 +211,7 @@ Feature-testing recommendations for C++.
P0007R1

   
-   7 
+   7.1 
__cpp_lib_as_const >= 201510 
 
 
@@ -229,7 +233,7 @@ Feature-testing recommendations for C++.
P0209R2

   
-   7 
+   7.1 
__cpp_lib_make_from_tuple >= 201606 
 
 
@@ -256,7 +260,7 @@ Feature-testing recommendations for C++.
P0174R2

   
-   No 
+   No  (kept for backwards compatibility)
   
 
 
@@ -267,7 +271,7 @@ Feature-testing recommendations for C++.
P0074R0

   
-   7 
+   7.1 
__cpp_lib_transparent_operators >= 201510 
 
 
@@ -278,7 +282,7 @@ Feature-testing recommendations for C++.
LWG2296

   
-   7 
+   7.1 
__cpp_lib_addressof_constexpr >= 201603 
 
 
@@ -311,7 +315,7 @@ Feature-testing recommendations for C++.
P0033R1

   
-   7 
+   7.1 
   

[PATCH] PR libstdc++/82716 avoid stupid -Wmismatched-tags warnings

[Jonathan Wakely]

It's just easier to change these than keep having to discuss it.

PR libstdc++/82716
* include/std/array (tuple_size, tuple_element): Change class-key
from class to struct, to avoid annoying Clang warnings.

Tested powerpc64le-linux, committed to trunk.


commit 2e6dfb8a5d44047b7d0e3e2a502218cd68647e5f
Author: Jonathan Wakely 
Date:   Wed Oct 25 14:20:16 2017 +0100

PR libstdc++/82716 avoid stupid -Wmismatched-tags warnings

PR libstdc++/82716
* include/std/array (tuple_size, tuple_element): Change class-key
from class to struct, to avoid annoying Clang warnings.

diff --git a/libstdc++-v3/include/std/array b/libstdc++-v3/include/std/array
index 1c7d6dc4ab1..f058c062145 100644
--- a/libstdc++-v3/include/std/array
+++ b/libstdc++-v3/include/std/array
@@ -339,7 +339,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   /// tuple_size
   template
-class tuple_size;
+struct tuple_size;
 
   /// Partial specialization for std::array
   template
@@ -348,7 +348,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   /// tuple_element
   template
-class tuple_element;
+struct tuple_element;
 
   /// Partial specialization for std::array
   template

Re: Don't query the frontend for unsupported types

[Richard Biener]

On Sun, Oct 1, 2017 at 6:17 PM, Richard Sandiford
 wrote:
> Richard Biener  writes:
>> On Fri, Sep 22, 2017 at 6:42 PM, Richard Sandiford
>>  wrote:
>>> Richard Biener  writes:
 On Thu, Sep 21, 2017 at 2:56 PM, Richard Sandiford
  wrote:
> Richard Biener  writes:
>> On September 20, 2017 2:36:03 PM GMT+02:00, Richard Sandiford
>>  wrote:
>>>When forcing a constant of mode MODE into memory, force_const_mem
>>>asks the frontend to provide the type associated with that mode.
>>>In principle type_for_mode is allowed to return null, and although
>>>one use site correctly handled that, the other didn't.
>>>
>>>I think there's agreement that it's bogus to use type_for_mode for
>>>this kind of thing, since it forces frontends to handle types that
>>>don't exist in that language.  See e.g. http://gcc.gnu.org/PR46805
>>>where the Go frontend was forced to handle vector types even though
>>>Go doesn't have vector types.
>>>
>>>Also, the frontends use code like:
>>>
>>>  else if (VECTOR_MODE_P (mode))
>>>{
>>>  machine_mode inner_mode = GET_MODE_INNER (mode);
>>>  tree inner_type = c_common_type_for_mode (inner_mode, unsignedp);
>>>  if (inner_type != NULL_TREE)
>>>return build_vector_type_for_mode (inner_type, mode);
>>>}
>>>
>>>and there's no guarantee that every vector mode M used by backend
>>>rtl has an associated vector type whose TYPE_MODE is M.  I think
>>>really the type_for_mode hook should only return trees that _do_ have
>>>the requested TYPE_MODE, but PR46805 linked above shows that this is
>>>likely to have too many knock-on consequences.  It doesn't make sense
>>>for force_const_mem to ask about vector modes that aren't valid for
>>>vector types, so this patch handles the condition there instead.
>>>
>>>This is needed for SVE multi-register modes, which are modelled as
>>>vector modes but are not usable as vector types.
>>>
>>>Tested on aarch64-linux-gnu, x86_64-linux-gnu and
>>>powerpc64le-linus-gnu.
>>>OK to install?
>>
>> I think we should get rid of the use entirely.
>
> I first read this as not using type_for_mode at all in force_const_mem,
> which sounded like a good thing :-)

 That's what I meant ;)  A mode doesn't really have a type...

   I tried it overnight on the usual
> at-least-one-target-per-CPU set and diffing the before and after
> assembly for the testsuite.  And it looks like i686 relies on this
> to get an alignment of 16 rather than 4 for XFmode constants:
> GET_MODE_ALIGNMENT (XFmode) == 32 (as requested by i386-modes.def),
> but i386's CONSTANT_ALIGNMENT increases it to 128 for static constants.

 Then the issue is that CONSTANT_ALIGNMENT takes a tree and not a mode...
 even worse than type_for_mode is a use of make_tree!  Incidentially
 ix86_constant_alignment _does_ look at the mode in the end...
>>>
>>> OK, I guess this means another target hook conversion.  The patch
>>> below converts CONSTANT_ALIGNMENT with its current interface.
>>> The definition:
>>>
>>>   #define CONSTANT_ALIGNMENT(EXP, ALIGN) \
>>> (TREE_CODE (EXP) == STRING_CST \
>>>  && (ALIGN) < BITS_PER_WORD ? BITS_PER_WORD : (ALIGN))
>>>
>>> was very common, so the patch adds a canned definition for that,
>>> called constant_alignment_word_strings.  Some ports had a variation
>>> that used a port-local FASTEST_ALIGNMENT instead of BITS_PER_WORD;
>>> the patch uses constant_alignment_word_strings if FASTEST_ALIGNMENT
>>> was always BITS_PER_WORD and a port-local hook function otherwise.
>>>
>>> Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
>>> Also tested by comparing the testsuite assembly output on at least one
>>> target per CPU directory.  I don't think this comes under Jeff's
>>> preapproval due to the constant_alignment_word_strings thing, so:
>>> OK to install?
>>
>> Ok.
>
> Thanks.  A bit later than intended, but here's the follow-on to add
> the new rtx hook.
>
> Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
> Also tested by comparing the testsuite assembly output on at least one
> target per CPU directory.  OK to install?

Ok, sorry for the delay.

Richard.

> Richard
>
>
> 2017-10-01  Richard Sandiford  
>
> gcc/
> * target.def (static_rtx_alignment): New hook.
> * targhooks.h (default_static_rtx_alignment): Declare.
> * targhooks.c (default_static_rtx_alignment): New function.
> * doc/tm.texi.in (TARGET_STATIC_RTX_ALIGNMENT): New hook.
> * doc/tm.texi: Regenerate.
> * varasm.c (force_const_mem): Use 

Re: [000/nnn] poly_int: representation of runtime offsets and sizes

[Richard Biener]

On Wed, Oct 25, 2017 at 1:26 PM, Richard Sandiford
 wrote:
> Richard Biener  writes:
>> On Tue, Oct 24, 2017 at 3:24 PM, Richard Sandiford
>>  wrote:
>>> Richard Biener  writes:
 On Tue, Oct 24, 2017 at 2:48 PM, Richard Sandiford
  wrote:
> Richard Biener  writes:
>> On Tue, Oct 24, 2017 at 1:23 PM, Richard Sandiford
>>  wrote:
>>> Eric Botcazou  writes:
> Yeah.  E.g. for ==, the two options would be:
>
> a) must_eq (a, b)   -> a == b
>must_ne (a, b)   -> a != b
>
>which has the weird property that (a == b) != (!(a != b))
>
> b) must_eq (a, b)   -> a == b
>may_ne (a, b)-> a != b
>
>which has the weird property that a can be equal to b when a != b

 Yes, a) was the one I had in mind, i.e. the traditional operators are
 the must
 variants and you use an outer ! in order to express the may.  Of
 course this
 would require a bit of discipline but, on the other hand, if most of
 the cases
 fall in the must category, that could be less ugly.
>>>
>>> I just think that discipline is going to be hard to maintain in 
>>> practice,
>>> since it's so natural to assume (a == b || a != b) == true.  With the
>>> may/must approach, static type checking forces the issue.
>>>
> Sorry about that.  It's the best I could come up with without losing
> the may/must distinction.

 Which variant is known_zero though?  Must or may?
>>>
>>> must.  maybe_nonzero is the may version.
>>
>> Can you rename known_zero to must_be_zero then?
>
> That'd be OK with me.
>
> Another alternative I wondered about was must_eq_0 / may_ne_0.
>
>> What's wrong with must_eq (X, 0) / may_eq (X, 0) btw?
>
> must_eq (X, 0) generated a warning if X is unsigned, so sometimes you'd
> need must_eq (X, 0) and sometimes must_eq (X, 0U).

 Is that because they are templates?  Maybe providing a partial 
 specialization
 would help?
>>>
>>> I don't think it's templates specifically.  We end up with something like:
>>>
>>>   int f (unsigned int x, const int y)
>>>   {
>>> return x != y;
>>>   }
>>>
>>>   int g (unsigned int x) { return f (x, 0); }
>>>
>>> which generates a warning too.
>>>
 I'd be fine with must_eq_p and may_eq_0.
>>>
>>> OK, I'll switch to that if there are no objections.
>>
>> Hum.  But then we still warn for must_eq_p (x, 1), no?
>
> Yeah.  The patch also had a known_one and known_all_ones for
> those two (fairly) common cases.  For other values the patches
> just add "U" where necessary.
>
> If you think it would be better to use U consistently and not
> have the helpers, then I'm happy to do that instead.
>
>> So why does
>>
>>   int f (unsigned int x)
>>   {
>>  return x != 0;
>>   }
>>
>> not warn?  Probably because of promotion of the arg.
>
> [Jakub's already answered this part.]
>
>> Shouldn't we then simply never have a may/must_*_p (T1, T2)
>> with T1 and T2 being not compatible?  That is, force promotion
>> rules on them with template magic?
>
> This was what I meant by:
>
>   Or we could suppress warnings by forcibly converting the input.
>   Sometimes the warnings are useful though.
>
> We already do this kind of conversion for arithmetic, to ensure
> that poly_uint16 + poly_uint16 -> poly_int64 promotes before the
> addition rather than after it.  But it defeats the point of the
> comparison warning, which is that you're potentially redefining
> the sign bit.
>
> I think the warning's just as valuable for may/must comparison of
> non-literals as it is for normal comparison operators.  It's just
> unfortunate that we no longer get the special handling of literals.

Ok, I see.

I think I have a slight preference for using 0U consistently but I haven't
looked at too many patches yet to see how common/ugly that would be.

Richard.

> Thanks,
> Richard

[PATCH] PR libstdc++/79283 fix filesystem::read_symlink for /proc

[Jonathan Wakely]

For some paths lstat returns st_size == 0, so use a buffer with
non-zero size and then grow it dynamically if it's not big enough.

PR libstdc++/79283
* src/filesystem/ops.cc (read_symlink): Handle st_size being zero.
* src/filesystem/std-ops.cc (read_symlink): Likewise.
(do_copy_file) [!NEED_DO_COPY_FILE]: Avoid multiple definitions.

Tested x86+64-linux, committed to trunk. I'll backport the
experimental::filesystem::read_symlink part to the branches.

commit ef737409818853af3a2b9a8b22984194d8c61de7
Author: Jonathan Wakely 
Date:   Wed Oct 25 02:15:25 2017 +0100

PR libstdc++/79283 fix filesystem::read_symlink for /proc

PR libstdc++/79283
* src/filesystem/ops.cc (read_symlink): Handle st_size being zero.
* src/filesystem/std-ops.cc (read_symlink): Likewise.
(do_copy_file) [!NEED_DO_COPY_FILE]: Avoid multiple definitions.

diff --git a/libstdc++-v3/src/filesystem/ops.cc 
b/libstdc++-v3/src/filesystem/ops.cc
index 61d9c89e616..1ec8883fde9 100644
--- a/libstdc++-v3/src/filesystem/ops.cc
+++ b/libstdc++-v3/src/filesystem/ops.cc
@@ -962,26 +962,45 @@ fs::read_symlink(const path& p)
 
 fs::path fs::read_symlink(const path& p, error_code& ec)
 {
+  path result;
 #ifdef _GLIBCXX_HAVE_SYS_STAT_H
   stat_type st;
   if (::lstat(p.c_str(), ))
 {
   ec.assign(errno, std::generic_category());
-  return {};
+  return result;
 }
-  std::string buf(st.st_size, '\0');
-  ssize_t len = ::readlink(p.c_str(), (), buf.size());
-  if (len == -1)
+  std::string buf(st.st_size ? st.st_size + 1 : 128, '\0');
+  do
 {
-  ec.assign(errno, std::generic_category());
-  return {};
+  ssize_t len = ::readlink(p.c_str(), buf.data(), buf.size());
+  if (len == -1)
+   {
+ ec.assign(errno, std::generic_category());
+ return result;
+   }
+  else if (len == (ssize_t)buf.size())
+   {
+ if (buf.size() > 4096)
+   {
+ ec.assign(ENAMETOOLONG, std::generic_category());
+ return result;
+   }
+ buf.resize(buf.size() * 2);
+   }
+  else
+   {
+ buf.resize(len);
+ result.assign(buf);
+ ec.clear();
+ break;
+   }
 }
-  ec.clear();
-  return path{buf.data(), buf.data()+len};
+  while (true);
 #else
   ec = std::make_error_code(std::errc::not_supported);
-  return {};
 #endif
+  return result;
 }
 
 
diff --git a/libstdc++-v3/src/filesystem/std-ops.cc 
b/libstdc++-v3/src/filesystem/std-ops.cc
index ff7acbfc1e7..947be7ef4c5 100644
--- a/libstdc++-v3/src/filesystem/std-ops.cc
+++ b/libstdc++-v3/src/filesystem/std-ops.cc
@@ -24,6 +24,7 @@
 
 #ifndef _GLIBCXX_USE_CXX11_ABI
 # define _GLIBCXX_USE_CXX11_ABI 1
+# define NEED_DO_COPY_FILE
 #endif
 
 #include 
@@ -251,6 +252,7 @@ namespace std::filesystem
 }
 
 #ifdef _GLIBCXX_HAVE_SYS_STAT_H
+#ifdef NEED_DO_COPY_FILE
 bool
 fs::do_copy_file(const char* from, const char* to,
 copy_options_existing_file options,
@@ -423,6 +425,7 @@ fs::do_copy_file(const char* from, const char* to,
   return true;
 #endif // _GLIBCXX_USE_SENDFILE
 }
+#endif // NEED_DO_COPY_FILE
 #endif // _GLIBCXX_HAVE_SYS_STAT_H
 
 void
@@ -1166,26 +1169,45 @@ fs::read_symlink(const path& p)
 
 fs::path fs::read_symlink(const path& p, error_code& ec)
 {
+  path result;
 #ifdef _GLIBCXX_HAVE_SYS_STAT_H
   stat_type st;
   if (::lstat(p.c_str(), ))
 {
   ec.assign(errno, std::generic_category());
-  return {};
+  return result;
 }
-  std::string buf(st.st_size, '\0');
-  ssize_t len = ::readlink(p.c_str(), (), buf.size());
-  if (len == -1)
+  std::string buf(st.st_size ? st.st_size + 1 : 128, '\0');
+  do
 {
-  ec.assign(errno, std::generic_category());
-  return {};
+  ssize_t len = ::readlink(p.c_str(), buf.data(), buf.size());
+  if (len == -1)
+   {
+ ec.assign(errno, std::generic_category());
+ return result;
+   }
+  else if (len == (ssize_t)buf.size())
+   {
+ if (buf.size() > 4096)
+   {
+ ec.assign(ENAMETOOLONG, std::generic_category());
+ return result;
+   }
+ buf.resize(buf.size() * 2);
+   }
+  else
+   {
+ buf.resize(len);
+ result.assign(buf);
+ ec.clear();
+ break;
+   }
 }
-  ec.clear();
-  return path{buf.data(), buf.data()+len};
+  while (true);
 #else
   ec = std::make_error_code(std::errc::not_supported);
-  return {};
 #endif
+  return result;
 }
 
 fs::path

[PATCH] Fix filesystem::path::lexically_normal algorithm

[Jonathan Wakely]

I missed one of the bullets describing the path normalization
algorithm, and so failed to normalize "/.." to "/" 


This also adjusts tests to compare paths more thoroughly, because
using operator== doesn't catch some unwanted differences, e.g.
filesystem::path("a///b") == "a/b" is true.

* src/filesystem/std-path.cc (path::lexically_normal): Add missing
step to algorithm, for removing dot-dot elements after root-directory.
* testsuite/27_io/filesystem/operations/canonical.cc: Use
compare_paths for more exhaustive checks.
* testsuite/27_io/filesystem/operations/proximate.cc: Likewise.
* testsuite/27_io/filesystem/path/append/path.cc: Likewise.
* testsuite/27_io/filesystem/path/concat/path.cc: Likewise.
* testsuite/27_io/filesystem/path/concat/strings.cc: Fix comment.
* testsuite/27_io/filesystem/path/construct/locale.cc: Likewise.
* testsuite/27_io/filesystem/path/decompose/root_directory.cc:
Likewise.
* testsuite/27_io/filesystem/path/generation/normal.cc: Use
compare_paths for more exhaustive checks. Add extra testcases.
* testsuite/27_io/filesystem/path/generation/proximate.cc: Use
compare_paths for more exhaustive checks.
* testsuite/27_io/filesystem/path/generation/relative.cc: Likewise.
* testsuite/27_io/filesystem/path/generic/generic_string.cc: Remove
unused header.
* testsuite/27_io/filesystem/path/modifiers/make_preferred.cc: Fix
comment.
* testsuite/27_io/filesystem/path/modifiers/remove_filename.cc: Use
compare_paths for more exhaustive checks.
* testsuite/27_io/filesystem/path/modifiers/replace_extension.cc:
Likewise.
* testsuite/27_io/filesystem/path/modifiers/replace_filename.cc:
Likewise.
* testsuite/util/testsuite_fs.h (compare_paths): Also compare native
strings.

Tested powerpc64le-linux, committed to trunk.


commit cf88176f094466edce766145ef48dc3833b9c2b2
Author: Jonathan Wakely 
Date:   Wed Oct 25 01:35:53 2017 +0100

Fix filesystem::path::lexically_normal algorithm

* src/filesystem/std-path.cc (path::lexically_normal): Add missing
step to algorithm, for removing dot-dot elements after 
root-directory.
* testsuite/27_io/filesystem/operations/canonical.cc: Use
compare_paths for more exhaustive checks.
* testsuite/27_io/filesystem/operations/proximate.cc: Likewise.
* testsuite/27_io/filesystem/path/append/path.cc: Likewise.
* testsuite/27_io/filesystem/path/concat/path.cc: Likewise.
* testsuite/27_io/filesystem/path/concat/strings.cc: Fix comment.
* testsuite/27_io/filesystem/path/construct/locale.cc: Likewise.
* testsuite/27_io/filesystem/path/decompose/root_directory.cc:
Likewise.
* testsuite/27_io/filesystem/path/generation/normal.cc: Use
compare_paths for more exhaustive checks. Add extra testcases.
* testsuite/27_io/filesystem/path/generation/proximate.cc: Use
compare_paths for more exhaustive checks.
* testsuite/27_io/filesystem/path/generation/relative.cc: Likewise.
* testsuite/27_io/filesystem/path/generic/generic_string.cc: Remove
unused header.
* testsuite/27_io/filesystem/path/modifiers/make_preferred.cc: Fix
comment.
* testsuite/27_io/filesystem/path/modifiers/remove_filename.cc: Use
compare_paths for more exhaustive checks.
* testsuite/27_io/filesystem/path/modifiers/replace_extension.cc:
Likewise.
* testsuite/27_io/filesystem/path/modifiers/replace_filename.cc:
Likewise.
* testsuite/util/testsuite_fs.h (compare_paths): Also compare native
strings.

diff --git a/libstdc++-v3/src/filesystem/std-path.cc 
b/libstdc++-v3/src/filesystem/std-path.cc
index b5dd36d6ad1..1e2a8fad584 100644
--- a/libstdc++-v3/src/filesystem/std-path.cc
+++ b/libstdc++-v3/src/filesystem/std-path.cc
@@ -365,6 +365,8 @@ path::lexically_normal() const
   - As long as any appear, remove a non-dot-dot filename immediately followed
 by a directory-separator and a dot-dot filename, along with any immediately
 following directory-separator.
+  - If there is a root-directory, remove all dot-dot filenames and any
+directory-separators immediately following them.
   - If the last filename is dot-dot, remove any trailing directory-separator.
   - If the path is empty, add a dot.
   */
@@ -388,7 +390,7 @@ path::lexically_normal() const
{
  if (ret.has_filename() && !is_dotdot(ret.filename()))
ret.remove_filename();
- else
+ else if (ret.has_filename() || !ret.has_root_directory())
ret /= p;
}
   else if (is_dot(p))
diff --git 

Re: [RFC] Make 4-stage PGO bootstrap really working

[Markus Trippelsdorf]

On 2017.08.30 at 11:45 +0200, Martin Liška wrote:
> diff --git a/Makefile.in b/Makefile.in
> index 78db0982ba2..16b76906ad0 100644
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -529,13 +529,14 @@ STAGE1_CONFIGURE_FLAGS = --disable-intermodule 
> $(STAGE1_CHECKING) \
> --disable-coverage --enable-languages="$(STAGE1_LANGUAGES)" \
> --disable-build-format-warnings
>  
> -STAGEprofile_CFLAGS = $(STAGE2_CFLAGS) -fprofile-generate
> +profile_folder=`${PWD_COMMAND}`/gcov-profiles/
> +STAGEprofile_CFLAGS = $(STAGE2_CFLAGS) -fprofile-generate=$(profile_folder)
>  STAGEprofile_TFLAGS = $(STAGE2_TFLAGS)
>  
>  STAGEtrain_CFLAGS = $(STAGE3_CFLAGS)
>  STAGEtrain_TFLAGS = $(STAGE3_TFLAGS)
>  
> -STAGEfeedback_CFLAGS = $(STAGE4_CFLAGS) -fprofile-use
> +STAGEfeedback_CFLAGS = $(STAGE4_CFLAGS) -fprofile-use=$(profile_folder) 
> -fdump-ipa-profile

-fdump-ipa-profile looks like a debugging leftover and should be
dropped.

>  STAGEfeedback_TFLAGS = $(STAGE4_TFLAGS)
>  
>  STAGEautoprofile_CFLAGS = $(STAGE2_CFLAGS) -g
> diff --git a/Makefile.tpl b/Makefile.tpl
> index 5fcd7e358d9..129175a579c 100644
> --- a/Makefile.tpl
> +++ b/Makefile.tpl
> @@ -452,13 +452,14 @@ STAGE1_CONFIGURE_FLAGS = --disable-intermodule 
> $(STAGE1_CHECKING) \
> --disable-coverage --enable-languages="$(STAGE1_LANGUAGES)" \
> --disable-build-format-warnings
>  
> -STAGEprofile_CFLAGS = $(STAGE2_CFLAGS) -fprofile-generate
> +profile_folder=`${PWD_COMMAND}`/gcov-profiles/
> +STAGEprofile_CFLAGS = $(STAGE2_CFLAGS) -fprofile-generate=$(profile_folder)
>  STAGEprofile_TFLAGS = $(STAGE2_TFLAGS)
>  
>  STAGEtrain_CFLAGS = $(STAGE3_CFLAGS)
>  STAGEtrain_TFLAGS = $(STAGE3_TFLAGS)
>  
> -STAGEfeedback_CFLAGS = $(STAGE4_CFLAGS) -fprofile-use
> +STAGEfeedback_CFLAGS = $(STAGE4_CFLAGS) -fprofile-use=$(profile_folder) 
> -fdump-ipa-profile

ditto.


And BTW would it make sense to add -gtoggle to stage2 in bootstrap-lto?

diff --git a/config/bootstrap-lto.mk b/config/bootstrap-lto.mk
index 50b86ef1c81..c0cdee69288 100644
--- a/config/bootstrap-lto.mk
+++ b/config/bootstrap-lto.mk
@@ -1,8 +1,8 @@
 # This option enables LTO for stage2 and stage3 in slim mode
 
-STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1
+STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 -gtoggle
 STAGE3_CFLAGS += -flto=jobserver -frandom-seed=1
-STAGEprofile_CFLAGS += -flto=jobserver -frandom-seed=1
+STAGEprofile_CFLAGS += -flto=jobserver -frandom-seed=1 -gtoggle
 STAGEtrain_CFLAGS += -flto=jobserver -frandom-seed=1
 STAGEfeedback_CFLAGS += -flto=jobserver -frandom-seed=1
 
-- 
Markus

[PATCH][i386,AVX] Enable VAES support [1/5]

[Koval, Julia]

Hi,
This patch enables VAES isaset option. The doc for isaset and instruction: 
https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf

Ok for trunk?

Thanks,
Julia

gcc/
* common/config/i386/i386-common.c (OPTION_MASK_ISA_VAES_SET,
OPTION_MASK_ISA_VAES_UNSET): New.
(ix86_handle_option): Handle -mvaes.
* config/i386/cpuid.h: Define bit_VAES.
* config/i386/driver-i386.c (host_detect_local_cpu): Detect -mvaes.
* config/i386/i386-c.c (__VAES__): New.
* config/i386/i386.c (ix86_target_string): Add -mvaes.
(ix86_valid_target_attribute_inner_p): Ditto.
* config/i386/i386.h (TARGET_VAES, TARGET_VAES_P): New.
* config/i386/i386.opt: Add -mvaes.
* doc/invoke.texi: Ditto.



0001-VAES-option.patch
Description: 0001-VAES-option.patch

Re: [RFC PATCH] Coalesce host to device transfers in libgomp

[Jakub Jelinek]

On Tue, Oct 24, 2017 at 08:39:13PM +0300, Alexander Monakov wrote:
> > +struct gomp_map_cache
> > +{
> > +  void *buf;
> > +  struct target_mem_desc *tgt;
> > +  size_t *chunks;
> > +  long chunk_cnt;
> > +  long use_cnt;
> > +};
> 
> Would really appreciate comments for meaning of fields here.  Also, is the
> struct properly named?  From the patch description I understood it to be a
> copy coalescing buffer, not a cache.
...

Here is an updated patch with some renaming, extra macros, one extra inline
function and comments.

As for async transfers, I think at least right now we need to make sure the
transfers complete by the time we release the device lock, but we could
perhaps gain something by queing the transfers asynchronously and then
waiting for them before releasing the lock (add some 2 further plugin
callbacks and some way how to keep around a device "async" handle).
And we don't really have the async target implemented yet for NVPTX :(,
guess that should be the highest priority after this optimization.

2017-10-25  Jakub Jelinek  

* target.c (struct gomp_coalesce_buf): New type.
(MAX_COALESCE_BUF_SIZE, MAX_COALESCE_BUF_GAP): Define.
(gomp_coalesce_buf_add, gomp_to_device_kind_p): New functions.
(gomp_copy_host2dev): Add CBUF argument, if copying into
the cached ranges, memcpy into buffer instead of copying
into device.
(gomp_map_vars_existing, gomp_map_pointer, gomp_map_fields_existing):
Add CBUF argument, pass it through to other calls.
(gomp_map_vars): Aggregate copies from host to device if small enough
and with small enough gaps in between into memcpy into a buffer and
fewer host to device copies from the buffer.
(gomp_update): Adjust gomp_copy_host2dev caller.

--- libgomp/target.c.jj 2017-10-24 12:07:03.763759657 +0200
+++ libgomp/target.c2017-10-25 13:17:31.608975390 +0200
@@ -177,10 +177,122 @@ gomp_device_copy (struct gomp_device_des
 }
 }
 
+/* Infrastructure for coalescing adjacent or nearly adjacent (in device 
addresses)
+   host to device memory transfers.  */
+
+struct gomp_coalesce_buf
+{
+  /* Buffer into which gomp_copy_host2dev will memcpy data and from which
+ it will be copied to the device.  */
+  void *buf;
+  struct target_mem_desc *tgt;
+  /* Array with offsets, chunks[2 * i] is the starting offset and
+ chunks[2 * i + 1] ending offset relative to tgt->tgt_start device address
+ of chunks which are to be copied to buf and later copied to device.  */
+  size_t *chunks;
+  /* Number of chunks in chunks array, or -1 if coalesce buffering should not
+ be performed.  */
+  long chunk_cnt;
+  /* During construction of chunks array, how many memory regions are within
+ the last chunk.  If there is just one memory region for a chunk, we copy
+ it directly to device rather than going through buf.  */
+  long use_cnt;
+};
+
+/* Maximum size of memory region considered for coalescing.  Larger copies
+   are performed directly.  */
+#define MAX_COALESCE_BUF_SIZE  (32 * 1024)
+
+/* Maximum size of a gap in between regions to consider them being copied
+   within the same chunk.  All the device offsets considered are within
+   newly allocated device memory, so it isn't fatal if we copy some padding
+   in between from host to device.  The gaps come either from alignment
+   padding or from memory regions which are not supposed to be copied from
+   host to device (e.g. map(alloc:), map(from:) etc.).  */
+#define MAX_COALESCE_BUF_GAP   (4 * 1024)
+
+/* Add region with device tgt_start relative offset and length to CBUF.  */
+
+static inline void
+gomp_coalesce_buf_add (struct gomp_coalesce_buf *cbuf, size_t start, size_t 
len)
+{
+  if (len > MAX_COALESCE_BUF_SIZE || len == 0)
+return;
+  if (cbuf->chunk_cnt)
+{
+  if (cbuf->chunk_cnt < 0)
+   return;
+  if (start < cbuf->chunks[2 * cbuf->chunk_cnt - 1])
+   {
+ cbuf->chunk_cnt = -1;
+ return;
+   }
+  if (start < cbuf->chunks[2 * cbuf->chunk_cnt - 1] + MAX_COALESCE_BUF_GAP)
+   {
+ cbuf->chunks[2 * cbuf->chunk_cnt - 1] = start + len;
+ cbuf->use_cnt++;
+ return;
+   }
+  /* If the last chunk is only used by one mapping, discard it,
+as it will be one host to device copy anyway and
+memcpying it around will only waste cycles.  */
+  if (cbuf->use_cnt == 1)
+   cbuf->chunk_cnt--;
+}
+  cbuf->chunks[2 * cbuf->chunk_cnt] = start;
+  cbuf->chunks[2 * cbuf->chunk_cnt + 1] = start + len;
+  cbuf->chunk_cnt++;
+  cbuf->use_cnt = 1;
+}
+
+/* Return true for mapping kinds which need to copy data from the
+   host to device for regions that weren't previously mapped.  */
+
+static inline bool
+gomp_to_device_kind_p (int kind)
+{
+  switch (kind)
+{
+case GOMP_MAP_ALLOC:
+case GOMP_MAP_FROM:
+case GOMP_MAP_FORCE_ALLOC:
+case GOMP_MAP_ALWAYS_FROM:
+  return false;
+

Re: [000/nnn] poly_int: representation of runtime offsets and sizes

[Richard Sandiford]

Richard Biener  writes:
> On Tue, Oct 24, 2017 at 3:24 PM, Richard Sandiford
>  wrote:
>> Richard Biener  writes:
>>> On Tue, Oct 24, 2017 at 2:48 PM, Richard Sandiford
>>>  wrote:
 Richard Biener  writes:
> On Tue, Oct 24, 2017 at 1:23 PM, Richard Sandiford
>  wrote:
>> Eric Botcazou  writes:
 Yeah.  E.g. for ==, the two options would be:

 a) must_eq (a, b)   -> a == b
must_ne (a, b)   -> a != b

which has the weird property that (a == b) != (!(a != b))

 b) must_eq (a, b)   -> a == b
may_ne (a, b)-> a != b

which has the weird property that a can be equal to b when a != b
>>>
>>> Yes, a) was the one I had in mind, i.e. the traditional operators are
>>> the must
>>> variants and you use an outer ! in order to express the may.  Of
>>> course this
>>> would require a bit of discipline but, on the other hand, if most of
>>> the cases
>>> fall in the must category, that could be less ugly.
>>
>> I just think that discipline is going to be hard to maintain in practice,
>> since it's so natural to assume (a == b || a != b) == true.  With the
>> may/must approach, static type checking forces the issue.
>>
 Sorry about that.  It's the best I could come up with without losing
 the may/must distinction.
>>>
>>> Which variant is known_zero though?  Must or may?
>>
>> must.  maybe_nonzero is the may version.
>
> Can you rename known_zero to must_be_zero then?

 That'd be OK with me.

 Another alternative I wondered about was must_eq_0 / may_ne_0.

> What's wrong with must_eq (X, 0) / may_eq (X, 0) btw?

 must_eq (X, 0) generated a warning if X is unsigned, so sometimes you'd
 need must_eq (X, 0) and sometimes must_eq (X, 0U).
>>>
>>> Is that because they are templates?  Maybe providing a partial 
>>> specialization
>>> would help?
>>
>> I don't think it's templates specifically.  We end up with something like:
>>
>>   int f (unsigned int x, const int y)
>>   {
>> return x != y;
>>   }
>>
>>   int g (unsigned int x) { return f (x, 0); }
>>
>> which generates a warning too.
>>
>>> I'd be fine with must_eq_p and may_eq_0.
>>
>> OK, I'll switch to that if there are no objections.
>
> Hum.  But then we still warn for must_eq_p (x, 1), no?

Yeah.  The patch also had a known_one and known_all_ones for
those two (fairly) common cases.  For other values the patches
just add "U" where necessary.

If you think it would be better to use U consistently and not
have the helpers, then I'm happy to do that instead.

> So why does
>
>   int f (unsigned int x)
>   {
>  return x != 0;
>   }
>
> not warn?  Probably because of promotion of the arg.

[Jakub's already answered this part.]

> Shouldn't we then simply never have a may/must_*_p (T1, T2)
> with T1 and T2 being not compatible?  That is, force promotion
> rules on them with template magic?

This was what I meant by:

  Or we could suppress warnings by forcibly converting the input.
  Sometimes the warnings are useful though.

We already do this kind of conversion for arithmetic, to ensure
that poly_uint16 + poly_uint16 -> poly_int64 promotes before the
addition rather than after it.  But it defeats the point of the
comparison warning, which is that you're potentially redefining
the sign bit.

I think the warning's just as valuable for may/must comparison of
non-literals as it is for normal comparison operators.  It's just
unfortunate that we no longer get the special handling of literals.

Thanks,
Richard

Re: [PATCH PR79868 ][aarch64] Fix error calls in aarch64 code so they can be translated (version 2)

[Kyrill Tkachov]

Hi Steve,

On 26/09/17 00:25, Steve Ellcey wrote:

This is a new version of my patch to fix PR target/79868, where some
error messages are impossible to translate correctly due to how the
strings are dynamically constructed.  It also includes some format
changes in the error messags to make the messages more consistent with
each other and with other GCC errors.  This was worked out with help
from Martin Sebor.  I also had to fix some tests to match the new error
string formats.

Tested on Aarch64 with no regressions, OK to checkin?

Steve Ellcey
sell...@cavium.com



This looks ok to me (but I can't approve) with a nit below.
I assume this has been bootstrapped as well as tested on aarch64.



2017-09-25  Steve Ellcey  

PR target/79868
* config/aarch64/aarch64-c.c (aarch64_pragma_target_parse):
Change argument type on aarch64_process_target_attr call.
* config/aarch64/aarch64-protos.h (aarch64_process_target_attr):
Change argument type.
* config/aarch64/aarch64.c (aarch64_attribute_info): Change
field type.
(aarch64_handle_attr_arch): Change argument type, use boolean
argument to use different strings in error calls.
(aarch64_handle_attr_cpu): Ditto.
(aarch64_handle_attr_tune): Ditto.
(aarch64_handle_attr_isa_flags): Ditto.
(aarch64_process_one_target_attr): Ditto.
(aarch64_process_target_attr): Ditto.
(aarch64_option_valid_attribute_p): Change argument type on
aarch64_process_target_attr call.


2017-09-25  Steve Ellcey  

PR target/79868
* gcc.target/aarch64/spellcheck_1.c: Update dg-error string to 
match

new format.
* gcc.target/aarch64/spellcheck_2.c: Ditto.
* gcc.target/aarch64/spellcheck_3.c: Ditto.
* gcc.target/aarch64/target_attr_11.c: Ditto.
* gcc.target/aarch64/target_attr_12.c: Ditto.
* gcc.target/aarch64/target_attr_17.c: Ditto.


 /* Handle the ARCH_STR argument to the arch= target attribute.
-   PRAGMA_OR_ATTR is used in potential error messages.  */
+   IS_PRAGMA is used in potential error messages.  */
 


Please reword this comment to say something along the lines of "IS_PRAGMA is true if 
processing a target pragma rather than a target attribute". Same with other 
occurrences of this change in other functions in this patch. I think the comment above 
aarch64_process_one_target_attr is a pretty good template now.

Thanks,
Kyrill

Re: [C++ Patch] PR 80955 (Macros expanded in definition of user-defined literals)

[Nathan Sidwell]

On 10/25/2017 12:03 AM, Mukesh Kapoor wrote:

Thanks for pointing this out. Checking in the front end will be 
difficult because the front end gets tokens after macro expansion. I 
think the difficulty of fixing this bug comes because of the requirement 
to maintain backward compatibility with the option -Wliteral-suffix for 
-std=c++11.


IIUC the warning's intent is to catch cases of:
printf ("some format"PRIx64 ..., ...);
where there's no space between the string literals and the PRIx64 macro. 
 I suspect it's very common for there to be a following string-literal, 
so perhaps the preprocessor could detect:


NON-FN-MACRO

and warn on that sequence?

nathan

--
Nathan Sidwell

RE: [PATCH][i386,AVX] Enable VBMI2 support [1/7]

[Koval, Julia]

Thanks, fix it.

gcc/
* common/config/i386/i386-common.c (OPTION_MASK_ISA_AVX512VBMI2_SET,
OPTION_MASK_ISA_AVX512VBMI2_UNSET): New.
(ix86_handle_option): Handle -mavx512vbmi2.
* config/i386/cpuid.h: Add bit_AVX512VBMI2.
* config/i386/driver-i386.c (host_detect_local_cpu): Handle new bit.
* config/i386/i386-c.c (__AVX512VBMI2__): New.
* config/i386/i386.c (ix86_target_string): Handle -mavx512vbmi2.
(ix86_valid_target_attribute_inner_p): Ditto.
* config/i386/i386.h (TARGET_AVX512VBMI2, TARGET_AVX512VBMI2_P): New.
* config/i386/i386.opt (mavx512vbmi2): New option.
* doc/invoke.texi: Add new option.


> -Original Message-
> From: Joseph Myers [mailto:jos...@codesourcery.com]
> Sent: Wednesday, October 25, 2017 12:40 AM
> To: Koval, Julia 
> Cc: GCC Patches ; Kirill Yukhin
> 
> Subject: Re: [PATCH][i386,AVX] Enable VBMI2 support [1/7]
> 
> On Tue, 24 Oct 2017, Koval, Julia wrote:
> 
> > config/i386/i386.opt (mavx512vbmi2): New option.
> 
> Any patch adding a new command-line option needs to add documentation of
> it to invoke.texi.
> 
> --
> Joseph S. Myers
> jos...@codesourcery.com


0001-VBMI2-option.patch
Description: 0001-VBMI2-option.patch

Re: [RFC] propagate malloc attribute in ipa-pure-const pass

[Prathamesh Kulkarni]

On 24 October 2017 at 16:26, Jan Hubicka  wrote:
>> 2017-10-13  Prathamesh Kulkarni  
>>
>>   * cgraph.h (set_malloc_flag): Declare.
>>   * cgraph.c (set_malloc_flag_1): New function.
>>   (set_malloc_flag): Likewise.
>>   * ipa-fnsummary.h (ipa_call_summary): Add new field is_return_callee.
>>   * ipa-fnsummary.c (ipa_call_summary::reset): Set is_return_callee to
>>   false.
>>   (read_ipa_call_summary): Add support for reading is_return_callee.
>>   (write_ipa_call_summary): Stream is_return_callee.
>>   * ipa-inline.c (ipa_inline): Remove call to ipa_free_fn_summary.
>>   * ipa-pure-const.c: Add headers ssa.h, alloc-pool.h, symbol-summary.h,
>>   ipa-prop.h, ipa-fnsummary.h.
>>   (pure_const_names): Change to static.
>>   (malloc_state_e): Define.
>>   (malloc_state_names): Define.
>>   (funct_state_d): Add field malloc_state.
>>   (varying_state): Set malloc_state to STATE_MALLOC_BOTTOM.
>>   (check_retval_uses): New function.
>>   (malloc_candidate_p): Likewise.
>>   (analyze_function): Add support for malloc attribute.
>>   (pure_const_write_summary): Stream malloc_state.
>>   (pure_const_read_summary): Add support for reading malloc_state.
>>   (dump_malloc_lattice): New function.
>>   (propagate_malloc): New function.
>>   (ipa_pure_const::execute): Call propagate_malloc and
>>   ipa_free_fn_summary.
>>   (pass_local_pure_const::execute): Add support for malloc attribute.
>>   * ssa-iterators.h (RETURN_FROM_IMM_USE_STMT): New macro.
>>
>> testsuite/
>>   * gcc.dg/ipa/propmalloc-1.c: New test-case.
>>   * gcc.dg/ipa/propmalloc-2.c: Likewise.
>>   * gcc.dg/ipa/propmalloc-3.c: Likewise.
>
> OK.
> Perhaps we could also add -Wsuggest-sttribute=malloc and mention it in 
> changes.html?
Done in this version.
In warn_function_malloc(), I passed false for known_finite param to
suggest_attribute().
Does that look OK ?
Validation in progress. OK to commit if passes ?

Thanks,
Prathamesh
>
> Thanks,
> Honza
2017-10-13  Prathamesh Kulkarni  

* cgraph.h (set_malloc_flag): Declare.
* cgraph.c (set_malloc_flag_1): New function.
(set_malloc_flag): Likewise.
* ipa-fnsummary.h (ipa_call_summary): Add new field is_return_callee.
* ipa-fnsummary.c (ipa_call_summary::reset): Set is_return_callee to
false.
(read_ipa_call_summary): Add support for reading is_return_callee.
(write_ipa_call_summary): Stream is_return_callee.
* ipa-inline.c (ipa_inline): Remove call to ipa_free_fn_summary.
* ipa-pure-const.c: Add headers ssa.h, alloc-pool.h, symbol-summary.h,
ipa-prop.h, ipa-fnsummary.h.
(pure_const_names): Change to static.
(malloc_state_e): Define.
(malloc_state_names): Define.
(funct_state_d): Add field malloc_state.
(varying_state): Set malloc_state to STATE_MALLOC_BOTTOM.
(check_retval_uses): New function.
(malloc_candidate_p): Likewise.
(analyze_function): Add support for malloc attribute.
(pure_const_write_summary): Stream malloc_state.
(pure_const_read_summary): Add support for reading malloc_state.
(dump_malloc_lattice): New function.
(propagate_malloc): New function.
(warn_function_malloc): New function.
(ipa_pure_const::execute): Call propagate_malloc and
ipa_free_fn_summary.
(pass_local_pure_const::execute): Add support for malloc attribute.
* ssa-iterators.h (RETURN_FROM_IMM_USE_STMT): New macro.
* doc/invoke.texi: Document Wsuggest-attribute=malloc.

testsuite/
* gcc.dg/ipa/propmalloc-1.c: New test-case.
* gcc.dg/ipa/propmalloc-2.c: Likewise.
* gcc.dg/ipa/propmalloc-3.c: Likewise.

diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 3d0cefbd46b..0aad90d59ea 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -2530,6 +2530,53 @@ cgraph_node::set_nothrow_flag (bool nothrow)
   return changed;
 }
 
+/* Worker to set malloc flag.  */
+static void
+set_malloc_flag_1 (cgraph_node *node, bool malloc_p, bool *changed)
+{
+  if (malloc_p && !DECL_IS_MALLOC (node->decl))
+{
+  DECL_IS_MALLOC (node->decl) = true;
+  *changed = true;
+}
+
+  ipa_ref *ref;
+  FOR_EACH_ALIAS (node, ref)
+{
+  cgraph_node *alias = dyn_cast (ref->referring);
+  if (!malloc_p || alias->get_availability () > AVAIL_INTERPOSABLE)
+   set_malloc_flag_1 (alias, malloc_p, changed);
+}
+
+  for (cgraph_edge *e = node->callers; e; e = e->next_caller)
+if (e->caller->thunk.thunk_p
+   && (!malloc_p || e->caller->get_availability () > AVAIL_INTERPOSABLE))
+  set_malloc_flag_1 (e->caller, malloc_p, changed);
+}
+
+/* Set DECL_IS_MALLOC on NODE's decl and on NODE's aliases if any.  */
+
+bool
+cgraph_node::set_malloc_flag (bool malloc_p)
+{
+  bool changed = false;
+
+ 

Re: [PATCH][GCC][Testsuite][SPARC][ARM] Fix vect-multitypes-1.c test on SPARC64 and ARMEB.

[Rainer Orth]

Hi Tamar,

> This patch fixes a regression introduced by r253451.
> The target needs all three conditions to be true before it can
> vectorize unaligned accesses. This patch turns the erroneous ||
> into an &&.
>
> regtested on aarch64-none-elf, arm-none-linux-gnueabihf,
> x86_64-pc-linux-gnu, armeb-none-linux-gnueabihf and
> sparc64-unknown-linux-gnu.
>
> OK for trunk?
>
> And for the GCC-7 branch?
>
> Thanks,
> Tamar
>
> gcc/testsuite/
> 2017-10-16  Tamar Christina  
>
>   * gcc.dg/vect/vect-multitypes-1.c: Correct target selector.

Just a nit: we usually keep a space before and after braces in DejaGnu
statements, so

{! vect_hw_misalign } -> { ! vect_hw_misalign }

Ok for mainline with that fixed, and the gcc-7 branch after a bit of
soak time.

Thanks.
Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [000/nnn] poly_int: representation of runtime offsets and sizes

[Jakub Jelinek]

On Wed, Oct 25, 2017 at 12:19:37PM +0200, Richard Biener wrote:
> Hum.  But then we still warn for must_eq_p (x, 1), no?
> 
> So why does
> 
>   int f (unsigned int x)
>   {
>  return x != 0;
>   }
> 
> not warn?  Probably because of promotion of the arg.

Because then one comparison operand is positive constant smaller
than the signed maximum.
We warn when both comparison operands are variable and one is signed and the
other is unsigned.

Jakub

Re: [000/nnn] poly_int: representation of runtime offsets and sizes

[Richard Biener]

On Tue, Oct 24, 2017 at 3:24 PM, Richard Sandiford
 wrote:
> Richard Biener  writes:
>> On Tue, Oct 24, 2017 at 2:48 PM, Richard Sandiford
>>  wrote:
>>> Richard Biener  writes:
 On Tue, Oct 24, 2017 at 1:23 PM, Richard Sandiford
  wrote:
> Eric Botcazou  writes:
>>> Yeah.  E.g. for ==, the two options would be:
>>>
>>> a) must_eq (a, b)   -> a == b
>>>must_ne (a, b)   -> a != b
>>>
>>>which has the weird property that (a == b) != (!(a != b))
>>>
>>> b) must_eq (a, b)   -> a == b
>>>may_ne (a, b)-> a != b
>>>
>>>which has the weird property that a can be equal to b when a != b
>>
>> Yes, a) was the one I had in mind, i.e. the traditional operators are
>> the must
>> variants and you use an outer ! in order to express the may.  Of
>> course this
>> would require a bit of discipline but, on the other hand, if most of
>> the cases
>> fall in the must category, that could be less ugly.
>
> I just think that discipline is going to be hard to maintain in practice,
> since it's so natural to assume (a == b || a != b) == true.  With the
> may/must approach, static type checking forces the issue.
>
>>> Sorry about that.  It's the best I could come up with without losing
>>> the may/must distinction.
>>
>> Which variant is known_zero though?  Must or may?
>
> must.  maybe_nonzero is the may version.

 Can you rename known_zero to must_be_zero then?
>>>
>>> That'd be OK with me.
>>>
>>> Another alternative I wondered about was must_eq_0 / may_ne_0.
>>>
 What's wrong with must_eq (X, 0) / may_eq (X, 0) btw?
>>>
>>> must_eq (X, 0) generated a warning if X is unsigned, so sometimes you'd
>>> need must_eq (X, 0) and sometimes must_eq (X, 0U).
>>
>> Is that because they are templates?  Maybe providing a partial specialization
>> would help?
>
> I don't think it's templates specifically.  We end up with something like:
>
>   int f (unsigned int x, const int y)
>   {
> return x != y;
>   }
>
>   int g (unsigned int x) { return f (x, 0); }
>
> which generates a warning too.
>
>> I'd be fine with must_eq_p and may_eq_0.
>
> OK, I'll switch to that if there are no objections.

Hum.  But then we still warn for must_eq_p (x, 1), no?

So why does

  int f (unsigned int x)
  {
 return x != 0;
  }

not warn?  Probably because of promotion of the arg.

Shouldn't we then simply never have a may/must_*_p (T1, T2)
with T1 and T2 being not compatible?  That is, force promotion
rules on them with template magic?

Richard.


> Thanks,
> Richard

[PATCH] Move FRE/PRE elimination code to tree-ssa-sccvn.c

[Richard Biener]

This is the patch moving the stuff.  Slight changes on-the-way,
renaming the now exported vn_eliminate function and adding
members for the former pre_stats used by elimination.

Moves the FRE pass structure and infrastructure as well
(now if it weren't for blaming I'd rename tree-ssa-sccvn.{c,h}
to tree-ssa-fre.{c,h}).

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

Richard.

2017-10-25  Richard Biener  

* tree-ssa-sccvn.h (vn_eliminate): Declare.
* tree-ssa-pre.c (class eliminate_dom_walker, eliminate,
class pass_fre): Move to ...
* tree-ssa-sccvn.c (class eliminate_dom_walker, vn_eliminate,
class pass_fre): ... here and adjust for statistics.

Index: gcc/tree-ssa-sccvn.h
===
--- gcc/tree-ssa-sccvn.h(revision 254068)
+++ gcc/tree-ssa-sccvn.h(working copy)
@@ -214,6 +214,7 @@ extern vn_ssa_aux_t VN_INFO (tree);
 extern vn_ssa_aux_t VN_INFO_GET (tree);
 tree vn_get_expr_for (tree);
 void run_scc_vn (vn_lookup_kind);
+unsigned int vn_eliminate (bitmap);
 void free_scc_vn (void);
 void scc_vn_restore_ssa_info (void);
 tree vn_nary_op_lookup (tree, vn_nary_op_t *);
Index: gcc/tree-ssa-pre.c
===
--- gcc/tree-ssa-pre.c  (revision 254068)
+++ gcc/tree-ssa-pre.c  (working copy)
@@ -39,7 +39,6 @@ along with GCC; see the file COPYING3.
 #include "gimplify.h"
 #include "gimple-iterator.h"
 #include "tree-cfg.h"
-#include "tree-ssa-loop.h"
 #include "tree-into-ssa.h"
 #include "tree-dfa.h"
 #include "tree-ssa.h"
@@ -50,9 +49,7 @@ along with GCC; see the file COPYING3.
 #include "dbgcnt.h"
 #include "domwalk.h"
 #include "tree-ssa-propagate.h"
-#include "ipa-utils.h"
 #include "tree-cfgcleanup.h"
-#include "langhooks.h"
 #include "alias.h"
 
 /* Even though this file is called tree-ssa-pre.c, we actually
@@ -516,9 +513,6 @@ typedef struct bb_bitmap_sets
optimization PRE was able to perform.  */
 static struct
 {
-  /* The number of RHS computations eliminated by PRE.  */
-  int eliminations;
-
   /* The number of new expressions/temporaries generated by PRE.  */
   int insertions;
 
@@ -4036,807 +4030,6 @@ compute_avail (void)
   free (worklist);
 }
 
-class eliminate_dom_walker : public dom_walker
-{
-public:
-  eliminate_dom_walker (cdi_direction direction, bool do_pre_);
-  ~eliminate_dom_walker ();
-
-  virtual edge before_dom_children (basic_block);
-  virtual void after_dom_children (basic_block);
-
-  tree eliminate_avail (tree op);
-  void eliminate_push_avail (tree op);
-  tree eliminate_insert (gimple_stmt_iterator *gsi, tree val);
-
-  bool do_pre;
-  unsigned int el_todo;
-
-  /* Blocks with statements that have had their EH properties changed.  */
-  bitmap need_eh_cleanup;
-
-  /* Blocks with statements that have had their AB properties changed.  */
-  bitmap need_ab_cleanup;
-
-  auto_vec to_remove;
-  auto_vec to_fixup;
-  auto_vec avail;
-  auto_vec avail_stack;
-};
-
-eliminate_dom_walker::eliminate_dom_walker (cdi_direction direction,
-   bool do_pre_)
-  : dom_walker (direction), do_pre (do_pre_), el_todo (0)
-{
-  need_eh_cleanup = BITMAP_ALLOC (NULL);
-  need_ab_cleanup = BITMAP_ALLOC (NULL);
-}
-
-eliminate_dom_walker::~eliminate_dom_walker ()
-{
-  BITMAP_FREE (need_eh_cleanup);
-  BITMAP_FREE (need_ab_cleanup);
-}
-
-/* Return a leader for OP that is available at the current point of the
-   eliminate domwalk.  */
-
-tree
-eliminate_dom_walker::eliminate_avail (tree op)
-{
-  tree valnum = VN_INFO (op)->valnum;
-  if (TREE_CODE (valnum) == SSA_NAME)
-{
-  if (SSA_NAME_IS_DEFAULT_DEF (valnum))
-   return valnum;
-  if (avail.length () > SSA_NAME_VERSION (valnum))
-   return avail[SSA_NAME_VERSION (valnum)];
-}
-  else if (is_gimple_min_invariant (valnum))
-return valnum;
-  return NULL_TREE;
-}
-
-/* At the current point of the eliminate domwalk make OP available.  */
-
-void
-eliminate_dom_walker::eliminate_push_avail (tree op)
-{
-  tree valnum = VN_INFO (op)->valnum;
-  if (TREE_CODE (valnum) == SSA_NAME)
-{
-  if (avail.length () <= SSA_NAME_VERSION (valnum))
-   avail.safe_grow_cleared (SSA_NAME_VERSION (valnum) + 1);
-  tree pushop = op;
-  if (avail[SSA_NAME_VERSION (valnum)])
-   pushop = avail[SSA_NAME_VERSION (valnum)];
-  avail_stack.safe_push (pushop);
-  avail[SSA_NAME_VERSION (valnum)] = op;
-}
-}
-
-/* Insert the expression recorded by SCCVN for VAL at *GSI.  Returns
-   the leader for the expression if insertion was successful.  */
-
-tree
-eliminate_dom_walker::eliminate_insert (gimple_stmt_iterator *gsi, tree val)
-{
-  /* We can insert a sequence with a single assignment only.  */
-  gimple_seq stmts = VN_INFO (val)->expr;
-  if (!gimple_seq_singleton_p (stmts))
-return NULL_TREE;
-  gassign *stmt = dyn_cast  (gimple_seq_first_stmt (stmts));
-  if 

[testsuite, committed] Fix scan-assembler in tree-ssa/loop-1.c for nvptx

[Tom de Vries]

Hi,

this patch fixes a scan-assembler line in tree-ssa/loop-1.c for nvptx.

Committed.

Thanks,
- Tom
Fix scan-assembler in tree-ssa/loop-1.c for nvptx

2017-10-25  Tom de Vries  

	* gcc.dg/tree-ssa/loop-1.c: Add xfail for nvptx in scan-assembler-times
	line, and add nvptx-specific version.

---
 gcc/testsuite/gcc.dg/tree-ssa/loop-1.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/loop-1.c b/gcc/testsuite/gcc.dg/tree-ssa/loop-1.c
index 0193c6e..01c37a5 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/loop-1.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/loop-1.c
@@ -46,7 +46,7 @@ int xxx(void)
 /* CRIS keeps the address in a register.  */
 /* m68k sometimes puts the address in a register, depending on CPU and PIC.  */
 
-/* { dg-final { scan-assembler-times "foo" 5 { xfail hppa*-*-* ia64*-*-* sh*-*-* cris-*-* crisv32-*-* fido-*-* m68k-*-* i?86-*-mingw* i?86-*-cygwin* x86_64-*-mingw* visium-*-* } } } */
+/* { dg-final { scan-assembler-times "foo" 5 { xfail hppa*-*-* ia64*-*-* sh*-*-* cris-*-* crisv32-*-* fido-*-* m68k-*-* i?86-*-mingw* i?86-*-cygwin* x86_64-*-mingw* visium-*-* nvptx*-*-* } } } */
 /* { dg-final { scan-assembler-times "foo,%r" 5 { target hppa*-*-* } } } */
 /* { dg-final { scan-assembler-times "= foo"  5 { target ia64*-*-* } } } */
 /* { dg-final { scan-assembler-times "call\[ \t\]*_foo" 5 { target i?86-*-mingw* i?86-*-cygwin* } } } */
@@ -55,3 +55,4 @@ int xxx(void)
 /* { dg-final { scan-assembler-times "Jsr \\\$r" 5 { target cris-*-* } } } */
 /* { dg-final { scan-assembler-times "\[jb\]sr" 5 { target fido-*-* m68k-*-* } } } */
 /* { dg-final { scan-assembler-times "bra *tr,r\[1-9\]*,r21" 5 { target visium-*-* } } } */
+/* { dg-final { scan-assembler-times "(?n)\[ \t\]call\[ \t\].*\[ \t\]foo," 5 { target nvptx*-*-* } } } */

[PATCH] Another testcase for PR82436

[Richard Biener]

The original one only failed with -m32, this one failed with 64bits
as well.

Tested on x86_64-unknown-linux-gnu, applied.

Richard.

2017-10-25  Richard Biener  

PR tree-optimization/82436
* gcc.dg/torture/pr82436-2.c: New testcase.

Index: gcc/testsuite/gcc.dg/torture/pr82436-2.c
===
--- gcc/testsuite/gcc.dg/torture/pr82436-2.c(nonexistent)
+++ gcc/testsuite/gcc.dg/torture/pr82436-2.c(working copy)
@@ -0,0 +1,45 @@
+/* { dg-do compile } */
+
+enum
+{
+  a, b, c, d,  e,  f,  g,  h,  j,  k
+};
+
+int l;
+void m (short *s)
+{
+  short n, o, p;
+  float(*q)[k];
+  int r, i;
+  while (l > 0)
+r = l;
+  for (;;)
+{
+  i = 0;
+  for (; i < r; i++)
+   {
+   {
+ float ab = q[i][a];
+ int i = ab;
+ p = i;
+   }
+ ((short *) s)[0] = p;
+   {
+ float ab = q[i][b];
+ int i = ab;
+ o = i;
+   }
+ ((short *) s)[1] = o;
+   {
+ float ab = q[i][f];
+ int i = ab;
+ n = i;
+   }
+ ((short *) s)[2] = n;
+ float ab = q[i][g];
+ int i = ab;
+ ((short *) s)[3] = i;
+ s = (short *) s + 4;
+   }
+}
+}

Re: [PATCH] i386: Don't generate ENDBR if function is only called directly

[Rainer Orth]

Hi H.J.,

> On Tue, Oct 24, 2017 at 2:33 AM, Uros Bizjak  wrote:
>> On Tue, Oct 24, 2017 at 10:39 AM, Tsimbalist, Igor V
>>  wrote:
>>> OK.
>>
>> +/* { dg-final { scan-assembler-times "endbr32" 2 { target ia32 } } } */
>> +/* { dg-final { scan-assembler-times "endbr64" 2 { target { ! ia32 } } } } 
>> */
>>
>> I think we can only check for {\mendbr} in the testcases. There are
>> already plenty of testcases that check for the correct instruction.
>>
>> Otherwise, LGTM
>>
>
> This is what I checked in.

the cet-sjlj-5.c test, like cet-sjlj-3.c, didn't account for an empty
USER_LABEL_PREFIX.  Fixed as the previous one, installed.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


2017-10-25  Rainer Orth  

* gcc.target/i386/cet-sjlj-5.c: Allow for emtpy user label prefix
in setjmp call.

# HG changeset patch
# Parent  bca0754daa2001dcf85a01cd8be2aad3cbd48fcd
Fix gcc.target/i386/cet-sjlj-5.c on Solaris

diff --git a/gcc/testsuite/gcc.target/i386/cet-sjlj-5.c b/gcc/testsuite/gcc.target/i386/cet-sjlj-5.c
--- a/gcc/testsuite/gcc.target/i386/cet-sjlj-5.c
+++ b/gcc/testsuite/gcc.target/i386/cet-sjlj-5.c
@@ -2,7 +2,7 @@
 /* { dg-options "-O -fcf-protection -mcet" } */
 /* { dg-final { scan-assembler-times "endbr32" 2 { target ia32 } } } */
 /* { dg-final { scan-assembler-times "endbr64" 2 { target { ! ia32 } } } } */
-/* { dg-final { scan-assembler-times "call	_setjmp" 1 } } */
+/* { dg-final { scan-assembler-times "call	_?setjmp" 1 } } */
 /* { dg-final { scan-assembler-times "call	longjmp" 1 } } */
 
 #include 

[PATCH] Refactor FRE/PRE elimination

[Richard Biener]

This refactors elimination, removing all global state stuffing
everything into the eliminate_dom_walker class plus merging
eliminate () and fini_eliminate () now that this is possible.

In preparation for moving the whole thing to tree-ssa-sccvn.c for
more tight integration with value-numbering (the rewrite to a RPO
walk, that is).  Helps with showing the real "diff" later on.

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.

Richard.

2017-10-25  Richard Biener  

* tree-ssa-pre.c (need_eh_cleanup, need_ab_cleanup, el_to_remove,
el_to_fixup, el_todo, el_avail, el_avail_stack, eliminate_avail,
eliminate_push_avail, eliminate_insert): Move inside...
(class eliminate_dom_walker): ... this class in preparation
of move.
(fini_eliminate): Remove by merging with ...
(eliminate): ... this function.  Adjust for class changes.
(pass_pre::execute): Remove fini_eliminate call.
(pass_fre::execute): Likewise.

Index: gcc/tree-ssa-pre.c
===
--- gcc/tree-ssa-pre.c  (revision 254036)
+++ gcc/tree-ssa-pre.c  (working copy)
@@ -551,12 +551,6 @@ static unsigned int get_expr_value_id (p
 static object_allocator bitmap_set_pool ("Bitmap sets");
 static bitmap_obstack grand_bitmap_obstack;
 
-/* Set of blocks with statements that have had their EH properties changed.  */
-static bitmap need_eh_cleanup;
-
-/* Set of blocks with statements that have had their AB properties changed.  */
-static bitmap need_ab_cleanup;
-
 /* A three tuple {e, pred, v} used to cache phi translations in the
phi_translate_table.  */
 
@@ -4042,27 +4036,61 @@ compute_avail (void)
   free (worklist);
 }
 
+class eliminate_dom_walker : public dom_walker
+{
+public:
+  eliminate_dom_walker (cdi_direction direction, bool do_pre_);
+  ~eliminate_dom_walker ();
+
+  virtual edge before_dom_children (basic_block);
+  virtual void after_dom_children (basic_block);
+
+  tree eliminate_avail (tree op);
+  void eliminate_push_avail (tree op);
+  tree eliminate_insert (gimple_stmt_iterator *gsi, tree val);
+
+  bool do_pre;
+  unsigned int el_todo;
+
+  /* Blocks with statements that have had their EH properties changed.  */
+  bitmap need_eh_cleanup;
+
+  /* Blocks with statements that have had their AB properties changed.  */
+  bitmap need_ab_cleanup;
 
-/* Local state for the eliminate domwalk.  */
-static vec el_to_remove;
-static vec el_to_fixup;
-static unsigned int el_todo;
-static vec el_avail;
-static vec el_avail_stack;
+  auto_vec to_remove;
+  auto_vec to_fixup;
+  auto_vec avail;
+  auto_vec avail_stack;
+};
+
+eliminate_dom_walker::eliminate_dom_walker (cdi_direction direction,
+   bool do_pre_)
+  : dom_walker (direction), do_pre (do_pre_), el_todo (0)
+{
+  need_eh_cleanup = BITMAP_ALLOC (NULL);
+  need_ab_cleanup = BITMAP_ALLOC (NULL);
+}
+
+eliminate_dom_walker::~eliminate_dom_walker ()
+{
+  BITMAP_FREE (need_eh_cleanup);
+  BITMAP_FREE (need_ab_cleanup);
+}
 
 /* Return a leader for OP that is available at the current point of the
eliminate domwalk.  */
 
-static tree
-eliminate_avail (tree op)
+tree
+eliminate_dom_walker::eliminate_avail (tree op)
 {
   tree valnum = VN_INFO (op)->valnum;
   if (TREE_CODE (valnum) == SSA_NAME)
 {
   if (SSA_NAME_IS_DEFAULT_DEF (valnum))
return valnum;
-  if (el_avail.length () > SSA_NAME_VERSION (valnum))
-   return el_avail[SSA_NAME_VERSION (valnum)];
+  if (avail.length () > SSA_NAME_VERSION (valnum))
+   return avail[SSA_NAME_VERSION (valnum)];
 }
   else if (is_gimple_min_invariant (valnum))
 return valnum;
@@ -4071,27 +4099,27 @@ eliminate_avail (tree op)
 
 /* At the current point of the eliminate domwalk make OP available.  */
 
-static void
-eliminate_push_avail (tree op)
+void
+eliminate_dom_walker::eliminate_push_avail (tree op)
 {
   tree valnum = VN_INFO (op)->valnum;
   if (TREE_CODE (valnum) == SSA_NAME)
 {
-  if (el_avail.length () <= SSA_NAME_VERSION (valnum))
-   el_avail.safe_grow_cleared (SSA_NAME_VERSION (valnum) + 1);
+  if (avail.length () <= SSA_NAME_VERSION (valnum))
+   avail.safe_grow_cleared (SSA_NAME_VERSION (valnum) + 1);
   tree pushop = op;
-  if (el_avail[SSA_NAME_VERSION (valnum)])
-   pushop = el_avail[SSA_NAME_VERSION (valnum)];
-  el_avail_stack.safe_push (pushop);
-  el_avail[SSA_NAME_VERSION (valnum)] = op;
+  if (avail[SSA_NAME_VERSION (valnum)])
+   pushop = avail[SSA_NAME_VERSION (valnum)];
+  avail_stack.safe_push (pushop);
+  avail[SSA_NAME_VERSION (valnum)] = op;
 }
 }
 
 /* Insert the expression recorded by SCCVN for VAL at *GSI.  Returns
the leader for the expression if insertion was successful.  */
 
-static tree
-eliminate_insert (gimple_stmt_iterator *gsi, tree val)
+tree
+eliminate_dom_walker::eliminate_insert (gimple_stmt_iterator *gsi, tree