[PATCH v2] libstdc++: istreambuf_iterator keep attached streambuf

[Petr Ovtchenkov]

istreambuf_iterator should not forget about attached
streambuf when it reach EOF.

Checks in debug mode has no infuence more on character
extraction in istreambuf_iterator increment operators.
In this aspect behaviour in debug and non-debug mode
is similar now.

Test for detached srteambuf in istreambuf_iterator:
When istreambuf_iterator reach EOF of istream, it should not
forget about attached streambuf.
>From fact "EOF in stream reached" not follow that
stream reach end of life and input operation impossible
more.

postfix increment (r++) return isb_iterator_proxy, due to

  copies of the previous value of r are no longer
  required either to be dereferenceable or to be in
  the domain of ==.

i.e. type that usable only for dereference and extraction
"previous" character.
---
 libstdc++-v3/include/bits/streambuf_iterator.h | 60 
 .../24_iterators/istreambuf_iterator/3.cc  | 64 ++
 2 files changed, 100 insertions(+), 24 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/24_iterators/istreambuf_iterator/3.cc

diff --git a/libstdc++-v3/include/bits/streambuf_iterator.h 
b/libstdc++-v3/include/bits/streambuf_iterator.h
index f0451b1..b71bdd2 100644
--- a/libstdc++-v3/include/bits/streambuf_iterator.h
+++ b/libstdc++-v3/include/bits/streambuf_iterator.h
@@ -97,6 +97,21 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   mutable streambuf_type*  _M_sbuf;
   mutable int_type _M_c;
 
+  class isb_iterator_proxy
+  {
+  friend class istreambuf_iterator;
+  private:
+  isb_iterator_proxy(int_type c) :
+  _M_c(c)
+  { }
+  int_type _M_c;
+
+  public:
+  char_type
+  operator*() const
+  { return traits_type::to_char_type(_M_c); }
+  };
+
 public:
   ///  Construct end of input stream iterator.
   _GLIBCXX_CONSTEXPR istreambuf_iterator() _GLIBCXX_USE_NOEXCEPT
@@ -136,29 +151,39 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   istreambuf_iterator&
   operator++()
   {
-   __glibcxx_requires_cond(!_M_at_eof(),
+   __glibcxx_requires_cond(_M_sbuf,
_M_message(__gnu_debug::__msg_inc_istreambuf)
._M_iterator(*this));
if (_M_sbuf)
  {
+#ifdef _GLIBCXX_DEBUG_PEDANTIC
+   int_type __tmp =
+#endif
_M_sbuf->sbumpc();
+#ifdef _GLIBCXX_DEBUG_PEDANTIC
+   
__glibcxx_requires_cond(!traits_type::eq_int_type(__tmp,traits_type::eof()),
+   
_M_message(__gnu_debug::__msg_inc_istreambuf)
+   ._M_iterator(*this));
+#endif
_M_c = traits_type::eof();
  }
return *this;
   }
 
   /// Advance the iterator.  Calls streambuf.sbumpc().
-  istreambuf_iterator
+  isb_iterator_proxy
   operator++(int)
   {
-   __glibcxx_requires_cond(!_M_at_eof(),
+_M_get();
+   __glibcxx_requires_cond(_M_sbuf
+   && 
!traits_type::eq_int_type(_M_c,traits_type::eof()),
_M_message(__gnu_debug::__msg_inc_istreambuf)
._M_iterator(*this));
 
-   istreambuf_iterator __old = *this;
+   isb_iterator_proxy __old(_M_c);
if (_M_sbuf)
  {
-   __old._M_c = _M_sbuf->sbumpc();
+   _M_sbuf->sbumpc();
_M_c = traits_type::eof();
  }
return __old;
@@ -177,18 +202,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   _M_get() const
   {
const int_type __eof = traits_type::eof();
-   int_type __ret = __eof;
-   if (_M_sbuf)
- {
-   if (!traits_type::eq_int_type(_M_c, __eof))
- __ret = _M_c;
-   else if (!traits_type::eq_int_type((__ret = _M_sbuf->sgetc()),
-  __eof))
- _M_c = __ret;
-   else
- _M_sbuf = 0;
- }
-   return __ret;
+   if (_M_sbuf && traits_type::eq_int_type(_M_c, __eof))
+  _M_c = _M_sbuf->sgetc();
+   return _M_c;
   }
 
   bool
@@ -339,7 +355,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   typedef typename __is_iterator_type::streambuf_type  streambuf_type;
   typedef typename traits_type::int_type   int_type;
 
-  if (__first._M_sbuf && !__last._M_sbuf)
+  if (__first._M_sbuf && (__last == istreambuf_iterator<_CharT>()))
{
  streambuf_type* __sb = __first._M_sbuf;
  int_type __c = __sb->sgetc();
@@ -374,7 +390,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   typedef typename __is_iterator_type::streambuf_type  streambuf_type;
   typedef typename traits_type::int_type   int_type;
 
-  if (__first._M_sbuf && !__last._M_sbuf)
+  if (__first._M_sbuf && (__last == istreambuf_iterator<_CharT>()))
{
  const int_type __ival = traits_type::to_int_type(__val);
  

Re: [PATCH] cpp: Correctly handle filenames with newlines

[Matthias Klose]

On 04.10.2017 00:41, Joseph Myers wrote:
> On Sun, 1 Oct 2017, Rasmus Villemoes wrote:
> 
>> 2017-10-01  Rasmus Villemoes  
>>
>> PR preprocessor/64965
>> * gcc.c-torture/compile/pr64965.c: New test.
>>
>> If the current filename contains a newline character, __FILE__ would
>> expand to a string literal containing an actual embedded newline,
>> which is of course illegal. Similarly, even in the absence of __FILE__
>> in the source file, gcc -E produces broken #line directives, making
>> the preprocessed output unsuitable for subsequent processing (though
>> compiling directly does work). Fix it by also escaping newline
>> characters.
> 
> OK.

missing ChangeLog for the libcpp change.

[PATCH] PR target/68256 Defining TARGET_USE_CONSTANT_BLOCKS_P causes go bootstrap failure on aarch64

[vladimir . mezentsev]

From: Vladimir Mezentsev 

Tested on aarch64-linux-gnu.
No regression.
No bootstrap failure.

gcc/ChangeLog:
2017-09-26  Vladimir Mezentsev  

* gcc/config/aarch64/aarch64.c: restore fix in aarch64_use_blocks_for_constant_p
---
 gcc/config/aarch64/aarch64.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 1c14008..b377bc7 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -6193,11 +6193,9 @@ aarch64_can_use_per_function_literal_pools_p (void)
 static bool
 aarch64_use_blocks_for_constant_p (machine_mode, const_rtx)
 {
-  /* Fixme:: In an ideal world this would work similar
- to the logic in aarch64_select_rtx_section but this
- breaks bootstrap in gcc go.  For now we workaround
- this by returning false here.  */
-  return false;
+   /* We can't use blocks for constants when we're using a per-function
+  constant pool.  */
+  return !aarch64_can_use_per_function_literal_pools_p ();
 }
 
 /* Select appropriate section for constants depending
-- 
1.8.3.1

Re: [PATCH] detect incompatible aliases (PR c/81854)

[Martin Sebor]

On 10/03/2017 03:41 PM, Andreas Schwab wrote:

On Aug 17 2017, Martin Sebor  wrote:


* g++.dg/ext/attr-ifunc-1.C: Adjust.
* g++.dg/ext/attr-ifunc-2.C: Same.
* g++.dg/ext/attr-ifunc-3.C: Same.
* g++.dg/ext/attr-ifunc-4.C: Same.


All the tests are now crashing on powerpc.  Klass::resolver doesn't look
like a valid ifunc resolver.


This was reported in bug 82301.  Please check that bug for the status
of the patch.

Martin

Re: [PATCH] C: underline parameters in mismatching function calls

[Joseph Myers]

On Mon, 2 Oct 2017, David Malcolm wrote:

> gcc/c/ChangeLog:
>   * c-decl.c (push_parm_decl): Store c_parm's location into the
>   PARAM_DECL.
>   (build_c_parm): Add "loc" param and store it within the c_parm.
>   * c-parser.c (struct c_parser): Add "last_token_location" field.
>   (c_parser_consume_token): Store location of the token into the
>   new field.
>   (c_parser_declaration_or_fndef): Store params into DECL_ARGUMENTS
>   when handling a FUNCTION_DECL, if it doesn't already have them.
>   (c_parser_parameter_declaration): Generate a location for the
>   parameter, and pass it to the call to build_c_parm.
>   * c-tree.h (struct c_parm): Add field "loc".
>   (build_c_parm): Add location_t param.
>   * c-typeck.c (get_fndecl_argument_location): New function.
>   (inform_for_arg): New function.
>   (convert_for_assignment): Use inform_for_arg when dealing with
>   ic_argpass.
> 
> gcc/testsuite/ChangeLog:
>   * gcc.dg/diagnostic-range-bad-called-object.c: Update expected
>   underlining for param.
>   * gcc.dg/param-type-mismatch.c: Update expected results to reflect
>   highlighting of parameters; add test coverage for trivial
>   parameter decls, and for callback parameters.
>   * gcc.dg/pr68533.c: Update location of two errors to reflect
>   location of params.

OK.

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

Re: [PATCH] cpp: Correctly handle filenames with newlines

[Joseph Myers]

On Sun, 1 Oct 2017, Rasmus Villemoes wrote:

> 2017-10-01  Rasmus Villemoes  
> 
> PR preprocessor/64965
> * gcc.c-torture/compile/pr64965.c: New test.
> 
> If the current filename contains a newline character, __FILE__ would
> expand to a string literal containing an actual embedded newline,
> which is of course illegal. Similarly, even in the absence of __FILE__
> in the source file, gcc -E produces broken #line directives, making
> the preprocessed output unsuitable for subsequent processing (though
> compiling directly does work). Fix it by also escaping newline
> characters.

OK.

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

Re: [PATCH], Add PowerPC ISA 3.0 IEEE 128-bit floating point round to odd built-in functions

[Segher Boessenkool]

On Tue, Oct 03, 2017 at 04:15:23PM -0400, Michael Meissner wrote:
> Here is the patch to add the round to odd instructions using separate UNSPEC
> names instead of putting the operation into the unspec.
> 
> I have done a bootstrap and check on a little endian power8 system and there
> were no regressions.  Can I check this into the trunk?

This looks fine.  Okay for trunk.  Thanks!


Segher


> 2017-10-03  Michael Meissner  
> 
>   * config/rs6000/rs6000-builtin.def (BU_FLOAT128_2_HW): Define new
>   helper macro for IEEE float128 hardware built-in functions.
>   (SQRTF128_ODD): Add built-in functions with the round-to-odd
>   semantics.
>   (TRUNCF128_ODD): Likewise.
>   (ADDF128_ODD): Likewise.
>   (SUBF128_ODD): Likewise.
>   (MULF128_ODD): Likewise.
>   (DIVF128_ODD): Likewise.
>   (FMAF128_ODD): Likewise.
>   * config/rs6000/rs6000.md (UNSPEC_ROUND_TO_ODD): Rename to
>   UNSPEC_TRUNC_ROUND_TO_ODD.
>   (UNSPEC_TRUNC_ROUND_TO_ODD): Likewise.
>   (UNSPEC_ADD_ROUND_TO_ODD): New unspec codes for the IEEE 128-bit
>   floating point round to odd instructions.
>   (UNSPEC_SUB_ROUND_TO_ODD): Likewise.
>   (UNSPEC_MUL_ROUND_TO_ODD): Likewise.
>   (UNSPEC_DIV_ROUND_TO_ODD): Likewise.
>   (UNSPEC_FMA_ROUND_TO_ODD): Likewise.
>   (UNSPEC_SQRT_ROUND_TO_ODD): Likewise.
>   (truncsf2_hw): Change the truncate with round to odd
>   expansion to use UNSPEC_TRUNC_ROUND_TO_ODD.
>   (add3_odd): Add insns for IEEE 128-bit floating point round
>   to odd hardware instructions.
>   (sub3_odd): Likewise.
>   (mul3_odd): Likewise.
>   (div3_odd): Likewise.
>   (sqrt2_odd): Likewise.
>   (fma4_odd): Likewise.
>   (fms4_odd): Likewise.
>   (nfma4_odd): Likewise.
>   (nfms4_odd): Likewise.
>   (truncdf2_odd): Change the truncate with round to odd
>   expansion to use UNSPEC_TRUNC_ROUND_TO_ODD. Add a generator
>   function.
>   * doc/extend.texi (PowerPC built-in functions): Update documentation
>   for existing IEEE float128-bit built-in functions.  Add built-in
>   functions that generate the IEEE 128-bit floating point round to
>   odd instructions.

[PATCH, wwwdocs] update my steering committee info

[Jim Wilson]

I'm no longer at Linaro, so I checked in a patch to update my entry on
the steering committee list page.  This patch was verified as XHTML 1.0
Transitional.

Jim
Index: steering.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/steering.html,v
retrieving revision 1.40
diff -u -r1.40 steering.html
--- steering.html	17 Mar 2015 21:12:09 -	1.40
+++ steering.html	3 Oct 2017 21:37:21 -
@@ -38,7 +38,7 @@
 Ramana Radhakrishnan (ARM)
 Joel Sherrill (OAR Corporation)
 Ian Lance Taylor (Google)
-Jim Wilson (Linaro)
+Jim Wilson
 
 
 and

Re: [PATCH] detect incompatible aliases (PR c/81854)

[Andreas Schwab]

On Aug 17 2017, Martin Sebor  wrote:

>   * g++.dg/ext/attr-ifunc-1.C: Adjust.
>   * g++.dg/ext/attr-ifunc-2.C: Same.
>   * g++.dg/ext/attr-ifunc-3.C: Same.
>   * g++.dg/ext/attr-ifunc-4.C: Same.

All the tests are now crashing on powerpc.  Klass::resolver doesn't look
like a valid ifunc resolver.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Joseph Myers]

On Tue, 3 Oct 2017, Jeff Law wrote:

> /* Copyright (c) 2010-2014 by Digital Mars
>  * All Rights Reserved, written by Walter Bright
>  * http://www.digitalmars.com
>  * Distributed under the Boost Software License, Version 1.0.
>  * (See accompanying file LICENSE or copy at
> http://www.boost.org/LICENSE_1_0.txt)
> 
> If the code was assigned to the FSF in 2011, then the FSF would have
> ownership of the code.  And the FSF would be the only entity that could
> change the license (which according to your message changed to Boost in
> 2014).  So something seems wrong here.

The standard FSF assignment would allow the contributor to distribute 
their own code under such terms as they see fit.

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

Re: [RFA] [PATCH] Add a warning for invalid function casts

[Joseph Myers]

On Tue, 3 Oct 2017, Bernd Edlinger wrote:

> invalid, also if both function types have a non-null TYPE_ARG_TYPES
> I would say this deserves a warning.  As an exception I have

I'm not convinced by the TYPE_ARG_TYPES check, at least for C.

In C, unprototyped function types are not compatible with variadic 
function types or functions with argument types changed by default 
argument promotions (that is, int () and int (char) and int (int, ...) are 
all incompatible).  I'd think it appropriate to warn about such 
conversions, given that they are cases where calling the converted 
function has undefined behavior.

There may well be cases of interfaces where void (*) (void) is used as a 
generic function pointer type (always converted to / from the actual type 
of the function in question), for which this warning would not be 
suitable.

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

Re: Transform (x >> cst) != 0 to x >= (1 << cst) and (x >> cst) == 0 to x < (1 << cst)

[Jeff Law]

On 10/03/2017 03:00 PM, Marc Glisse wrote:
> On Tue, 3 Oct 2017, Jakub Jelinek wrote:
> 
>> On Tue, Oct 03, 2017 at 12:54:39PM -0700, Prathamesh Kulkarni wrote:
>>> Hi,
>>> This follow-up patch implements the patterns mentioned in $subject.
>>> Bootstrap+test in progress on x86_64-unknown-linux-gnu and
>>> aarch64-linux-gnu.
>>> OK to commit if passes ?
>>>
>>> Thanks,
>>> Prathamesh
>>
>>> 2017-10-03  Prathamesh Kulkarni  
>>>
>>> * match.pd ((X >> CST) == 0 -> X < (1 << CST)): New pattern.
>>> ((X >> CST) != 0 -> X >= (1 << CST)): Likewise.
> 
> build_int_cstu doesn't work for vectors, you want build_one_cst. I never
> know if we should check single_use or not :-(
> 
>>> testsuite/
>>> * gcc.dg/tree-ssa/cmpdiv.c: Add test-cases f3 and f4.
>>
>> Why this way and not the other way around?
> 
> For high level gimple optimizations, X < CST is more convenient (and
> smaller, just one insn) than (X >> CST) == 0.
Right.  One could easily argue that Prathamesh's form should be the
preferred form because it is simpler at the gimple level -- and that
x86-isms should be dealt with later in the pipeline.


> 
>> E.g. i?86/x86_64 and various other targets have shift instructions which
>> set condition codes, so (X >> 51) == 0 is certainly smaller
>> smaller and I believe cheaper than the latter.
>> Try:
>> void foo (void);
>>
>> void
>> bar (unsigned long long x)
>> {
>>  if ((x >> 51) == 0)
>>    foo ();
>> }
>>
>> void
>> baz (unsigned long long x)
>> {
>>  if (x < (1LL << 51))
>>    foo ();
>> }
>> with -Os on x86_64, the first function is 4 insns, 12 bytes,
>> the second one 5 insns, 21 bytes.
>>
>> I wonder if this kind of instruction selection stuff shouldn't be
>> done in target.pd instead, with input from the target.
Right, but I think that argues that Prathamesh's patch is the right
direction and that to move forward what needs to happen is something
needs to be fixed at the gimple/rtl border to ensure we get good x86 code.

> 
> At a late stage, maybe during an RTL pass or expansion (or just before
> expansion) it would indeed be good to generate a shift for such
> comparisons, on targets where that sets a cc. The lack of this
> transformation could be considered a blocker for the other one, to avoid
> regressing on bar.
Right.  In fact, I think Jakub's test ought to be added to this work as
part of its basic testing.

jeff

Re: Transform (x >> cst) != 0 to x >= (1 << cst) and (x >> cst) == 0 to x < (1 << cst)

[Marc Glisse]

On Tue, 3 Oct 2017, Jakub Jelinek wrote:


On Tue, Oct 03, 2017 at 12:54:39PM -0700, Prathamesh Kulkarni wrote:

Hi,
This follow-up patch implements the patterns mentioned in $subject.
Bootstrap+test in progress on x86_64-unknown-linux-gnu and aarch64-linux-gnu.
OK to commit if passes ?

Thanks,
Prathamesh



2017-10-03  Prathamesh Kulkarni  

* match.pd ((X >> CST) == 0 -> X < (1 << CST)): New pattern.
((X >> CST) != 0 -> X >= (1 << CST)): Likewise.


build_int_cstu doesn't work for vectors, you want build_one_cst. I never 
know if we should check single_use or not :-(



testsuite/
* gcc.dg/tree-ssa/cmpdiv.c: Add test-cases f3 and f4.


Why this way and not the other way around?


For high level gimple optimizations, X < CST is more convenient (and 
smaller, just one insn) than (X >> CST) == 0.



E.g. i?86/x86_64 and various other targets have shift instructions which
set condition codes, so (X >> 51) == 0 is certainly smaller
smaller and I believe cheaper than the latter.
Try:
void foo (void);

void
bar (unsigned long long x)
{
 if ((x >> 51) == 0)
   foo ();
}

void
baz (unsigned long long x)
{
 if (x < (1LL << 51))
   foo ();
}
with -Os on x86_64, the first function is 4 insns, 12 bytes,
the second one 5 insns, 21 bytes.

I wonder if this kind of instruction selection stuff shouldn't be
done in target.pd instead, with input from the target.


At a late stage, maybe during an RTL pass or expansion (or just before 
expansion) it would indeed be good to generate a shift for such 
comparisons, on targets where that sets a cc. The lack of this 
transformation could be considered a blocker for the other one, to avoid 
regressing on bar.


--
Marc Glisse

Re: [PATCH] libstdc++: istreambuf_iterator keep attached streambuf

[Petr Ovtchenkov]

On Thu, 28 Sep 2017 13:38:06 +0100
Jonathan Wakely  wrote:

> On 28/09/17 15:06 +0300, Petr Ovtchenkov wrote:
> >On Thu, 28 Sep 2017 11:34:25 +0100
> >Jonathan Wakely  wrote:
> >
> >> On 23/09/17 09:54 +0300, Petr Ovtchenkov wrote:
> >> >istreambuf_iterator should not forget about attached
> >> >streambuf when it reach EOF.
> >> >
> >> >Checks in debug mode has no infuence more on character
> >> >extraction in istreambuf_iterator increment operators.
> >> >In this aspect behaviour in debug and non-debug mode
> >> >is similar now.
> >> >
> >> >Test for detached srteambuf in istreambuf_iterator:
> >> >When istreambuf_iterator reach EOF of istream, it should not
> >> >forget about attached streambuf.
> >> From fact "EOF in stream reached" not follow that
> >> >stream reach end of life and input operation impossible
> >> >more.
> >> >---
> >> > libstdc++-v3/include/bits/streambuf_iterator.h | 41 +++
> >> > .../24_iterators/istreambuf_iterator/3.cc  | 61 
> >> > ++
> >> > 2 files changed, 80 insertions(+), 22 deletions(-)
> >> > create mode 100644 
> >> > libstdc++-v3/testsuite/24_iterators/istreambuf_iterator/3.cc
> >> >
> >> >diff --git a/libstdc++-v3/include/bits/streambuf_iterator.h
> >> >b/libstdc++-v3/include/bits/streambuf_iterator.h index f0451b1..45c3d89 
> >> >100644
> >> >--- a/libstdc++-v3/include/bits/streambuf_iterator.h
> >> >+++ b/libstdc++-v3/include/bits/streambuf_iterator.h
> >> >@@ -136,12 +136,20 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >> >   istreambuf_iterator&
> >> >   operator++()
> >> >   {
> >> >- __glibcxx_requires_cond(!_M_at_eof(),
> >> >+ __glibcxx_requires_cond(_M_sbuf,
> >> >  _M_message(__gnu_debug::__msg_inc_istreambuf)
> >> >  ._M_iterator(*this));
> >> >  if (_M_sbuf)
> >> >{
> >> >+#ifdef _GLIBCXX_DEBUG_PEDANTIC
> >> >+ int_type _tmp =
> >> >+#endif
> >> >  _M_sbuf->sbumpc();
> >> >+#ifdef _GLIBCXX_DEBUG_PEDANTIC
> >> >+ 
> >> >__glibcxx_requires_cond(!traits_type::eq_int_type(_tmp,traits_type::eof()),
> >> >+ 
> >> >_M_message(__gnu_debug::__msg_inc_istreambuf)
> >> >+ ._M_iterator(*this));
> >> >+#endif
> >> >  _M_c = traits_type::eof();
> >> >}
> >> >  return *this;
> >> >@@ -151,14 +159,16 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >> >   istreambuf_iterator
> >> >   operator++(int)
> >> >   {
> >> >- __glibcxx_requires_cond(!_M_at_eof(),
> >> >+_M_get();
> >> >+ __glibcxx_requires_cond(_M_sbuf
> >> >+ && 
> >> >!traits_type::eq_int_type(_M_c,traits_type::eof()),
> >> >  _M_message(__gnu_debug::__msg_inc_istreambuf)
> >> >  ._M_iterator(*this));
> >> >
> >> >  istreambuf_iterator __old = *this;
> >> >  if (_M_sbuf)
> >> >{
> >> >- __old._M_c = _M_sbuf->sbumpc();
> >> >+ _M_sbuf->sbumpc();
> >> >  _M_c = traits_type::eof();
> >> >}
> >> >  return __old;
> >> >@@ -177,18 +187,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >> >   _M_get() const
> >> >   {
> >> >  const int_type __eof = traits_type::eof();
> >> >- int_type __ret = __eof;
> >> >- if (_M_sbuf)
> >> >-   {
> >> >- if (!traits_type::eq_int_type(_M_c, __eof))
> >> >-   __ret = _M_c;
> >> >- else if (!traits_type::eq_int_type((__ret = _M_sbuf->sgetc()),
> >> >-__eof))
> >> >-   _M_c = __ret;
> >> >- else
> >> >-   _M_sbuf = 0;
> >> >-   }
> >> >- return __ret;
> >> >+ if (_M_sbuf && traits_type::eq_int_type(_M_c, __eof))
> >> >+  _M_c = _M_sbuf->sgetc();
> >> >+ return _M_c;
> >> >   }
> >> >
> >> >   bool
> >> >@@ -339,7 +340,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >> >   typedef typename __is_iterator_type::streambuf_type  
> >> > streambuf_type;
> >> >   typedef typename traits_type::int_type   int_type;
> >> >
> >> >-  if (__first._M_sbuf && !__last._M_sbuf)
> >> >+  if (__first._M_sbuf && (__last == istreambuf_iterator<_CharT>()))
> >> >  {
> >> >streambuf_type* __sb = __first._M_sbuf;
> >> >int_type __c = __sb->sgetc();
> >> >@@ -374,7 +375,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >> >   typedef typename __is_iterator_type::streambuf_type  
> >> > streambuf_type;
> >> >   typedef typename traits_type::int_type   int_type;
> >> >
> >> >-  if (__first._M_sbuf && !__last._M_sbuf)
> >> >+  if (__first._M_sbuf && (__last == istreambuf_iterator<_CharT>()))
> >> >  {
> >> >const int_type __ival = traits_type::to_int_type(__val);
> >> >streambuf_type* __sb = __first._M_sbuf;
> >> >@@ -395,11 +396,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >> >else
> >> >  __c = __sb->snextc();
> >> >  }
> >> >-
> >> >-   if (!traits_type::eq_int_type(__c, traits_type::eof()))
> >> >- __first._M_c = __c;
> >> >-   else
> >> >- 

Re: Transform (x >> cst) != 0 to x >= (1 << cst) and (x >> cst) == 0 to x < (1 << cst)

[Jakub Jelinek]

On Tue, Oct 03, 2017 at 12:54:39PM -0700, Prathamesh Kulkarni wrote:
> Hi,
> This follow-up patch implements the patterns mentioned in $subject.
> Bootstrap+test in progress on x86_64-unknown-linux-gnu and aarch64-linux-gnu.
> OK to commit if passes ?
> 
> Thanks,
> Prathamesh

> 2017-10-03  Prathamesh Kulkarni  
> 
>   * match.pd ((X >> CST) == 0 -> X < (1 << CST)): New pattern.
>   ((X >> CST) != 0 -> X >= (1 << CST)): Likewise.
> 
> testsuite/
>   * gcc.dg/tree-ssa/cmpdiv.c: Add test-cases f3 and f4.

Why this way and not the other way around?
E.g. i?86/x86_64 and various other targets have shift instructions which
set condition codes, so (X >> 51) == 0 is certainly smaller
smaller and I believe cheaper than the latter.
Try:
void foo (void);

void
bar (unsigned long long x)
{
  if ((x >> 51) == 0)
foo ();
}

void
baz (unsigned long long x)
{
  if (x < (1LL << 51))
foo ();
}
with -Os on x86_64, the first function is 4 insns, 12 bytes,
the second one 5 insns, 21 bytes.

I wonder if this kind of instruction selection stuff shouldn't be
done in target.pd instead, with input from the target.

Jakub

Re: [PATCH], Add PowerPC ISA 3.0 IEEE 128-bit floating point round to odd built-in functions

[Michael Meissner]

Here is the patch to add the round to odd instructions using separate UNSPEC
names instead of putting the operation into the unspec.

I have done a bootstrap and check on a little endian power8 system and there
were no regressions.  Can I check this into the trunk?

[gcc]
2017-10-03  Michael Meissner  

* config/rs6000/rs6000-builtin.def (BU_FLOAT128_2_HW): Define new
helper macro for IEEE float128 hardware built-in functions.
(SQRTF128_ODD): Add built-in functions with the round-to-odd
semantics.
(TRUNCF128_ODD): Likewise.
(ADDF128_ODD): Likewise.
(SUBF128_ODD): Likewise.
(MULF128_ODD): Likewise.
(DIVF128_ODD): Likewise.
(FMAF128_ODD): Likewise.
* config/rs6000/rs6000.md (UNSPEC_ROUND_TO_ODD): Rename to
UNSPEC_TRUNC_ROUND_TO_ODD.
(UNSPEC_TRUNC_ROUND_TO_ODD): Likewise.
(UNSPEC_ADD_ROUND_TO_ODD): New unspec codes for the IEEE 128-bit
floating point round to odd instructions.
(UNSPEC_SUB_ROUND_TO_ODD): Likewise.
(UNSPEC_MUL_ROUND_TO_ODD): Likewise.
(UNSPEC_DIV_ROUND_TO_ODD): Likewise.
(UNSPEC_FMA_ROUND_TO_ODD): Likewise.
(UNSPEC_SQRT_ROUND_TO_ODD): Likewise.
(truncsf2_hw): Change the truncate with round to odd
expansion to use UNSPEC_TRUNC_ROUND_TO_ODD.
(add3_odd): Add insns for IEEE 128-bit floating point round
to odd hardware instructions.
(sub3_odd): Likewise.
(mul3_odd): Likewise.
(div3_odd): Likewise.
(sqrt2_odd): Likewise.
(fma4_odd): Likewise.
(fms4_odd): Likewise.
(nfma4_odd): Likewise.
(nfms4_odd): Likewise.
(truncdf2_odd): Change the truncate with round to odd
expansion to use UNSPEC_TRUNC_ROUND_TO_ODD. Add a generator
function.
* doc/extend.texi (PowerPC built-in functions): Update documentation
for existing IEEE float128-bit built-in functions.  Add built-in
functions that generate the IEEE 128-bit floating point round to
odd instructions.

[gcc/testsuite]
2017-10-03  Michael Meissner  

* gcc.target/powerpc/float128-odd.c: New test.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000-builtin.def
===
--- gcc/config/rs6000/rs6000-builtin.def(revision 253358)
+++ gcc/config/rs6000/rs6000-builtin.def(working copy)
@@ -686,6 +686,14 @@
 | RS6000_BTC_UNARY),   \
CODE_FOR_ ## ICODE) /* ICODE */
 
+#define BU_FLOAT128_2_HW(ENUM, NAME, ATTR, ICODE)   \
+  RS6000_BUILTIN_2 (MISC_BUILTIN_ ## ENUM,  /* ENUM */  \
+   "__builtin_" NAME,  /* NAME */  \
+   RS6000_BTM_FLOAT128_HW, /* MASK */  \
+   (RS6000_BTC_ ## ATTR/* ATTR */  \
+| RS6000_BTC_BINARY),  \
+   CODE_FOR_ ## ICODE) /* ICODE */
+
 #define BU_FLOAT128_3_HW(ENUM, NAME, ATTR, ICODE)   \
   RS6000_BUILTIN_3 (MISC_BUILTIN_ ## ENUM,  /* ENUM */  \
"__builtin_" NAME,  /* NAME */  \
@@ -2365,11 +2373,19 @@ BU_P9_OVERLOAD_2 (CMPEQB,   "byte_in_set")
 BU_FLOAT128_1 (FABSQ,  "fabsq",   CONST, abskf2)
 BU_FLOAT128_2 (COPYSIGNQ,  "copysignq",   CONST, copysignkf3)
 
-/* 1 and 3 argument IEEE 128-bit floating point functions that require ISA 3.0
-   hardware.  These functions use the new 'f128' suffix.  Eventually these
-   should be folded into the common built-in function handling. */
-BU_FLOAT128_1_HW (SQRTF128,"sqrtf128", CONST, sqrtkf2)
-BU_FLOAT128_3_HW (FMAF128, "fmaf128",  CONST, fmakf4_hw)
+/* 1, 2, and 3 argument IEEE 128-bit floating point functions that require ISA
+   3.0 hardware.  These functions use the new 'f128' suffix.  Eventually the
+   standard functions should be folded into the common built-in function
+   handling. */
+BU_FLOAT128_1_HW (SQRTF128, "sqrtf128",   CONST, sqrtkf2)
+BU_FLOAT128_1_HW (SQRTF128_ODD, "sqrtf128_round_to_odd",  CONST, 
sqrtkf2_odd)
+BU_FLOAT128_1_HW (TRUNCF128_ODD, "truncf128_round_to_odd", CONST, 
trunckfdf2_odd)
+BU_FLOAT128_2_HW (ADDF128_ODD,  "addf128_round_to_odd",   CONST, addkf3_odd)
+BU_FLOAT128_2_HW (SUBF128_ODD,  "subf128_round_to_odd",   CONST, subkf3_odd)
+BU_FLOAT128_2_HW (MULF128_ODD,  "mulf128_round_to_odd",   CONST, mulkf3_odd)
+BU_FLOAT128_2_HW (DIVF128_ODD,  "divf128_round_to_odd",   CONST, divkf3_odd)
+BU_FLOAT128_3_HW (FMAF128,  "fmaf128",CONST, fmakf4_hw)

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

[Jeff Law]

On 10/02/2017 02:45 AM, Iain Buclaw wrote:
> Changes since previous are just merge latest 2.076 release.
> 
> Uploaded patch to my ftp due to size limitations.
So if the code was assigned by Walter to the FSF back in 2011 (per your
message on Sep 11 and Walter's reply on  Sep 11) then the copyright
notices seem totally wrong.  For example dfrontend/aav.c:


/* Copyright (c) 2010-2014 by Digital Mars
 * All Rights Reserved, written by Walter Bright
 * http://www.digitalmars.com
 * Distributed under the Boost Software License, Version 1.0.
 * (See accompanying file LICENSE or copy at
http://www.boost.org/LICENSE_1_0.txt)

If the code was assigned to the FSF in 2011, then the FSF would have
ownership of the code.  And the FSF would be the only entity that could
change the license (which according to your message changed to Boost in
2014).  So something seems wrong here.

I'd really like to get the licensing issues and copyright notices
settled before I dig into this further.


Jeff

Transform (x >> cst) != 0 to x >= (1 << cst) and (x >> cst) == 0 to x < (1 << cst)

[Prathamesh Kulkarni]

Hi,
This follow-up patch implements the patterns mentioned in $subject.
Bootstrap+test in progress on x86_64-unknown-linux-gnu and aarch64-linux-gnu.
OK to commit if passes ?

Thanks,
Prathamesh
2017-10-03  Prathamesh Kulkarni  

* match.pd ((X >> CST) == 0 -> X < (1 << CST)): New pattern.
((X >> CST) != 0 -> X >= (1 << CST)): Likewise.

testsuite/
* gcc.dg/tree-ssa/cmpdiv.c: Add test-cases f3 and f4.

diff --git a/gcc/match.pd b/gcc/match.pd
index 43ab226a705..883ad5ba53c 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -1287,6 +1287,18 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
&& (VECTOR_TYPE_P (type) || !VECTOR_TYPE_P (TREE_TYPE (@0
(ocmp @0 @1
 
+/* Transform
+   (x >> cst) != 0 -> x >= (1 << cst)
+   (x >> cst) == 0 -> x < (1 << cst)
+   if x, cst are unsigned.  */
+(for cmp (eq ne)
+ ocmp (lt ge)
+ (simplify
+  (cmp (rshift @0 INTEGER_CST@1) integer_zerop)
+  (if (TYPE_UNSIGNED (TREE_TYPE (@0))
+  && (VECTOR_TYPE_P (type) || !VECTOR_TYPE_P (TREE_TYPE (@0
+   (ocmp @0 (lshift { build_int_cstu (TREE_TYPE (@0), 1); } @1)
+
 /* X == C - X can never be true if C is odd.  */
 (for cmp (eq ne)
  (simplify
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/cmpdiv.c 
b/gcc/testsuite/gcc.dg/tree-ssa/cmpdiv.c
index 14161f5ea6f..fc5bc8c3674 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/cmpdiv.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/cmpdiv.c
@@ -15,4 +15,19 @@ _Bool f2(unsigned x, unsigned y)
   return t2;
 }
 
+_Bool f3(unsigned x)
+{
+  unsigned t1 = x >> 4;
+  _Bool t2 = (t1 != 0);
+  return t2;
+}
+
+_Bool f4(unsigned x)
+{
+  unsigned t1 = x >> 4;
+  _Bool t2 = (t1 == 0);
+  return t2;
+}
+
 /* { dg-final { scan-tree-dump-not "trunc_div_expr" "optimized" } } */
+/* { dg-final { scan-tree-dump-not "rshift_expr" "optimized" } } */

Re: [PATCH][aarch64] Fix pr81356 - copy empty string with wrz, not a ldrb/strb

[Qing Zhao]

I think the change is good.  But I don’t have the permission for approval…

Qing
> On Sep 25, 2017, at 12:36 PM, Steve Ellcey  wrote:
> 
> Ping.
> 
> Steve Ellcey
> sell...@cavium.com
> 
> 
> On Fri, 2017-09-15 at 11:22 -0700, Steve Ellcey wrote:
>> PR 81356 points out that doing a __builtin_strcpy of an empty string on
>> aarch64 does a copy from memory instead of just writing out a zero byte.
>> In looking at this I found that it was because of
>> aarch64_use_by_pieces_infrastructure_p, which returns false for
>> STORE_BY_PIECES.  The comment says:
>> 
>>   /* STORE_BY_PIECES can be used when copying a constant string, but
>>  in that case each 64-bit chunk takes 5 insns instead of 2 (LDR/STR).
>>  For now we always fail this and let the move_by_pieces code copy
>>  the string from read-only memory.  */
>> 
>> But this doesn't seem to be the case anymore.  When I remove this function
>> and the TARGET_USE_BY_PIECES_INFRASTRUCTURE_P macro that uses it the code
>> for __builtin_strcpy of a constant string seems to be either better or the
>> same.  The only time I got more instructions after removing this function
>> was on an 8 byte __builtin_strcpy where we now generate a mov and 3 movk
>> instructions to create the source followed by a store instead of doing a
>> load/store of 8 bytes.  The comment may have been applicable for
>> -mstrict-align at one time but it doesn't seem to be the case now.  I still
>> get better code without this routine under that option as well.
>> 
>> Bootstrapped and tested without regressions, OK to checkin?
>> 
>> Steve Ellcey
>> sell...@cavium.com
>> 
>> 
>> 
>> 2017-09-15  Steve Ellcey  
>> 
>>  PR target/81356
>>  * config/aarch64/aarch64.c
>> (aarch64_use_by_pieces_infrastructure_p):
>>  Remove.
>>  (TARGET_USE_BY_PIECES_INFRASTRUCTURE_P): Remove define.
>> 
>> 
>> 2017-09-15  Steve Ellcey  
>> 
>>  * gcc.target/aarch64/pr81356.c: New test.

Re: [PATCH] Fix fortran/81509

[Janus Weil]

2017-10-03 20:10 GMT+02:00 Steve Kargl :
>> > There is no mechanism available to warn the user of nonstandard code.
>>
>> Of course there is:
>>
>> $ gfortran -std=f2008 a.f90
>> a.f90:4:17:
>>
>> print *, iand(i,j)
>>  1
>> Error: GNU Extension: Different type kinds at (1)
>>
>
> Reread what I wrote.  There is NO MECHANISM TO WARN the user.
> -std=f2008 does not produce a WARNING.  It produces an ERROR.

Sorry, I'm currently traveling and must have misread that.

Anyway, I don't have the feeling this discussion is going anywhere. I
said my opinion, you heard it. You have two OKs, so just go ahead and
commit the patch. I really don't care.

Cheers,
Janus

[RFA] [PATCH] Add a warning for invalid function casts

[Bernd Edlinger]

Hi!

I have implemented a warning -Wcast-function-type that analyzes
type casts which change the function signatures.

I would consider function pointers with different result type
invalid, also if both function types have a non-null TYPE_ARG_TYPES
I would say this deserves a warning.  As an exception I have
used for instance in recog.h, the warning allows casting
a function with the type typedef rtx (*stored_funcptr) (...);
to any function with the same result type.

I would think a warning like that should be enabled with -Wextra.

Attached is a first version of the patch and as you can see
the warning found already lots of suspicious type casts.  The worst
is the splay-tree which always calls functions with uintptr_t
instead of the correct parameter type.  I was unable to find
a solution for this, and just silenced the warning with a
second type-cast.

Note that I also changed one line in libgo, but that is only
a quick hack which I only did to make the boot-strap with
all languages succeed.

I'm not sure if this warning may be a bit too strict, but I think
so far it just triggered on rather questionable code.

Thoughts?


Bernd.
gcc:
2017-10-03  Bernd Edlinger  

* doc/invoke.texi: Document -Wcast-function-type.
* gengtype.c (write_root): Remove cast.
* ggc.h (gt_pch_n_S_nonconst, gt_ggc_m_S_nonconst): Declare.
* ggc-page.c (gt_ggc_m_S_nonconst): New function.
* stringpool.c (gt_pch_n_S_nonconst): New function.
* tree-pass.h (do_per_function_toporder): Adjust header.
* passes.c (do_per_function_toporder): Change signature.
(execute_ipa_pass_list): Remove cast.
* recog.h (f0..f15): Fix return types.
(stored_funcptr): Use variadic parameter list.
* tree-dump.c (dump_node): Avoid warning.
* typed-splay-tree.h (typed_splay_tree): Avoid warning.

libcpp:
2017-10-03  Bernd Edlinger  

* include/symtab.h (ht_forall_internal): Declare.
* symtab.c (ht_forall_internal): New function.
* internal.h (maybe_print_line): Change signature.

c-family:
2017-10-03  Bernd Edlinger  

* c.opt (Wcast-function-type): New warning option.
* c-lex.c (get_fileinfo): Avoid warning.
* c-ppoutput.c (scan_translation_unit_directives_only): Remove cast.

c:
2017-10-03  Bernd Edlinger  

* c-typeck.c (build_c_cast): Implement -Wcast_function_type.

cp:
2017-10-03  Bernd Edlinger  

* cxx-pretty-print.c (pp_c_type_specifier_seq,
pp_c_parameter_declaration_clause): New wrapper functions.
(cxx_pretty_printer::cxx_pretty_printer): Remove cast.
* decl2.c (start_static_storage_duration_function): Aboid warning.
* typeck.c (build_reinterpret_cast_1): Implement -Wcast_function_type.

testsuite:
2017-10-03  Bernd Edlinger  

* c-c++-common/Wcast-function-type.c: New test.
Index: gcc/c/c-typeck.c
===
--- gcc/c/c-typeck.c	(revision 253328)
+++ gcc/c/c-typeck.c	(working copy)
@@ -5667,6 +5667,20 @@ build_c_cast (location_t loc, tree type, tree expr
 	pedwarn (loc, OPT_Wpedantic, "ISO C forbids "
 		 "conversion of object pointer to function pointer type");
 
+  if (TREE_CODE (type) == POINTER_TYPE
+	  && TREE_CODE (otype) == POINTER_TYPE
+	  && TREE_CODE (TREE_TYPE (type)) == FUNCTION_TYPE
+	  && TREE_CODE (TREE_TYPE (otype)) == FUNCTION_TYPE
+	  && (TYPE_ARG_TYPES (TREE_TYPE (type))
+	  && TYPE_ARG_TYPES (TREE_TYPE (otype))
+	  ? !comptypes (TREE_TYPE (type),
+			TREE_TYPE (otype))
+	  : !comptypes (TREE_TYPE (TREE_TYPE (type)),
+			TREE_TYPE (TREE_TYPE (otype)
+	warning_at (loc, OPT_Wcast_function_type,
+		"cast between incompatible function types"
+		" from %qT to %qT", otype, type);
+
   ovalue = value;
   value = convert (type, value);
 
Index: gcc/c-family/c-lex.c
===
--- gcc/c-family/c-lex.c	(revision 253328)
+++ gcc/c-family/c-lex.c	(working copy)
@@ -101,9 +101,11 @@ get_fileinfo (const char *name)
   struct c_fileinfo *fi;
 
   if (!file_info_tree)
-file_info_tree = splay_tree_new ((splay_tree_compare_fn) strcmp,
+file_info_tree = splay_tree_new ((splay_tree_compare_fn)
+ (uintptr_t) strcmp,
  0,
- (splay_tree_delete_value_fn) free);
+ (splay_tree_delete_value_fn)
+ (uintptr_t) free);
 
   n = splay_tree_lookup (file_info_tree, (splay_tree_key) name);
   if (n)
Index: gcc/c-family/c-ppoutput.c
===
--- gcc/c-family/c-ppoutput.c	(revision 253328)
+++ gcc/c-family/c-ppoutput.c	(working copy)
@@ -299,7 +299,7 @@ scan_translation_unit_directives_only (cpp_reader
   struct _cpp_dir_only_callbacks cb;

Require wi::to_wide for trees

[Richard Sandiford]

One of the original requirements for getting wide-int.h accepted
was that it should work efficiently on trees.  Through a process
that I no longer recall exactly, this ended up meaning that we can
use things like:

   wi::add (t, 1)

to add 1 to an INTEGER_CST T in its native precision.  However, we also have:

   wi::to_offset (t)  // Treat T as an offset_int
   wi::to_widest (t)  // Treat T as a widest_int

Recently we also gained:

   wi::to_wide (t, prec)  // Treat T as a wide_int in preccision PREC

I'd like to revisit the decision to treat "wide_int trees" differently.
Requiring:

   wi::to_wide (t)

would be just as efficient, and would make it clearer that a deliberate
choice is being made to treat the tree as a wide_int in its native
precision.  This also removes the inconsistency that

a) wide_int trees can be used without an accessor but must use wi::
   functions instead of C++ operators

b) the other forms need an explicit accessor but the result can be used
   with C++ operators.

It also helps with SVE, where there's the additional possibility
that the tree could be a runtime value.

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?

If so, it might make sense to use wi::to_wide (rtx, mode) for rtxes too.

Richard


2017-10-03  Richard Sandiford  

gcc/
* wide-int.h (wide_int_ref_storage): Make host_dependent_precision
a template parameter.
(WIDE_INT_REF_FOR): Update accordingly.
* tree.h (wi::int_traits ): Delete.
(wi::tree_to_widest_ref, wi::tree_to_offset_ref): New typedefs.
(wi::to_widest, wi::to_offset): Use them.  Expand commentary.
(wi::tree_to_wide_ref): New typedef.
(wi::to_wide): New function.
* calls.c (get_size_range): Use wi::to_wide when operating on
trees as wide_ints.
* cgraph.c (cgraph_node::create_thunk): Likewise.
* config/i386/i386.c (ix86_data_alignment): Likewise.
(ix86_local_alignment): Likewise.
* dbxout.c (stabstr_O): Likewise.
* dwarf2out.c (add_scalar_info, gen_enumeration_type_die): Likewise.
* expr.c (const_vector_from_tree): Likewise.
* fold-const-call.c (host_size_t_cst_p, fold_const_call_1): Likewise.
* fold-const.c (may_negate_without_overflow_p, negate_expr_p)
(fold_negate_expr_1, int_const_binop_1, const_binop)
(fold_convert_const_int_from_real, optimize_bit_field_compare)
(all_ones_mask_p, sign_bit_p, build_range_check, unextend)
(extract_muldiv_1, fold_div_compare, fold_single_bit_test)
(fold_plusminus_mult_expr, pointer_may_wrap_p, expr_not_equal_to)
(fold_binary_loc, fold_ternary_loc, multiple_of_p, fold_negate_const)
(fold_abs_const, fold_not_const, round_up_loc): Likewise.
* gimple-fold.c (gimple_fold_indirect_ref): Likewise.
* gimple-ssa-warn-alloca.c (alloca_call_type_by_arg): Likewise.
(alloca_call_type): Likewise.
* gimple.c (preprocess_case_label_vec_for_gimple): Likewise.
* godump.c (go_output_typedef): Likewise.
* graphite-sese-to-poly.c (tree_int_to_gmp): Likewise.
* internal-fn.c (get_min_precision): Likewise.
* ipa-cp.c (ipcp_store_vr_results): Likewise.
* ipa-polymorphic-call.c
(ipa_polymorphic_call_context::ipa_polymorphic_call_context): Likewise.
* ipa-prop.c (ipa_print_node_jump_functions_for_edge): Likewise.
(ipa_modify_call_arguments): Likewise.
* match.pd: Likewise.
* omp-low.c (scan_omp_1_op, lower_omp_ordered_clauses): Likewise.
* print-tree.c (print_node_brief, print_node): Likewise.
* stmt.c (expand_case): Likewise.
* stor-layout.c (layout_type): Likewise.
* tree-affine.c (tree_to_aff_combination): Likewise.
* tree-cfg.c (group_case_labels_stmt): Likewise.
* tree-data-ref.c (dr_analyze_indices): Likewise.
(prune_runtime_alias_test_list): Likewise.
* tree-dump.c (dequeue_and_dump): Likewise.
* tree-inline.c (remap_gimple_op_r, copy_tree_body_r): Likewise.
* tree-predcom.c (is_inv_store_elimination_chain): Likewise.
* tree-pretty-print.c (dump_generic_node): Likewise.
* tree-scalar-evolution.c (iv_can_overflow_p): Likewise.
(simple_iv_with_niters): Likewise.
* tree-ssa-address.c (addr_for_mem_ref): Likewise.
* tree-ssa-ccp.c (ccp_finalize, evaluate_stmt): Likewise.
* tree-ssa-loop-ivopts.c (constant_multiple_of): Likewise.
* tree-ssa-loop-niter.c (split_to_var_and_offset)
(refine_value_range_using_guard, number_of_iterations_ne_max)
(number_of_iterations_lt_to_ne, number_of_iterations_lt)
(get_cst_init_from_scev, record_nonwrapping_iv)
(scev_var_range_cant_overflow): Likewise.
* 

Re: [Patch][aarch64] Use IFUNCs to enable LSE instructions in libatomic on aarch64

[Steve Ellcey]

On Mon, 2017-10-02 at 15:38 +0100, Szabolcs Nagy wrote:
> 
> looks good to me, but i cannot approve.
> 
> (this will make libatomic depend on ifuncs on aarch64*-linux-gnu.)

If you build GCC with default options, ifunc is enabled on aarch64 and
used by libatomic but if you configure with '--disable-gnu-indirect-
function' then GCC will not recognize the 'resolver' attribute and
libatomic will build the 'old' way and not use IFUNC's.

It seems like using '--disable-version-specific-runtime-libs' should
allow GCC to recognize the 'resolver' attribute for IFUNCs but to not
use them when building libatomic but when I tried that I got ifuncs in
libatomic anyway.  I think that is a bug and I will look into it some
more.

The recent alias checking improvements made to GCC and which caused
some glibc build problems also caused the ifunc check in libatomic to
fail.  That problem has been fixed but it involved a change to
libatomic/ibatomic_i.h that conflicted with this patch so I am
including an updated version that will apply cleanly to the top of
tree.  Only libatomic_i.h changed.

Steve Ellcey
sell...@cavium.com

2017-10-03  Steve Ellcey  

* Makefile.am (ARCH_AARCH64_LINUX): Add IFUNC_OPTIONS and
libatomic_la_LIBADD.
* config/linux/aarch64/host-config.h: New file.
* configure.ac (IFUNC_RESOLVER_ARGS): Define.
(ARCH_AARCH64_LINUX): New conditional for IFUNC builds.
* configure.tgt (aarch64): Set ARCH and try_ifunc.
(aarch64*-*-linux*) Update config_path.
(aarch64*-*-linux*) Set IFUNC_RESOLVER_ARGS.
* libatomic_i.h (GEN_SELECTOR): Add IFUNC_RESOLVER_ARGS argument.
* Makefile.in: Regenerate.
* auto-config.h.in: Regenerate.
* configure: Regenerate.

diff --git a/libatomic/Makefile.am b/libatomic/Makefile.am
index d731406..92d19c6 100644
--- a/libatomic/Makefile.am
+++ b/libatomic/Makefile.am
@@ -122,6 +122,10 @@ libatomic_la_LIBADD = $(foreach s,$(SIZES),$(addsuffix _$(s)_.lo,$(SIZEOBJS)))
 
 ## On a target-specific basis, include alternates to be selected by IFUNC.
 if HAVE_IFUNC
+if ARCH_AARCH64_LINUX
+IFUNC_OPTIONS	 = -march=armv8.1-a
+libatomic_la_LIBADD += $(foreach s,$(SIZES),$(addsuffix _$(s)_1_.lo,$(SIZEOBJS)))
+endif
 if ARCH_ARM_LINUX
 IFUNC_OPTIONS	 = -march=armv7-a -DHAVE_KERNEL64
 libatomic_la_LIBADD += $(foreach s,$(SIZES),$(addsuffix _$(s)_1_.lo,$(SIZEOBJS)))
diff --git a/libatomic/config/linux/aarch64/host-config.h b/libatomic/config/linux/aarch64/host-config.h
index e69de29..08810a9 100644
--- a/libatomic/config/linux/aarch64/host-config.h
+++ b/libatomic/config/linux/aarch64/host-config.h
@@ -0,0 +1,36 @@
+/* Copyright (C) 2017 Free Software Foundation, Inc.
+
+   This file is part of the GNU Atomic Library (libatomic).
+
+   Libatomic 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 of the License, or
+   (at your option) any later version.
+
+   Libatomic 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.
+
+   Under Section 7 of GPL version 3, you are granted additional
+   permissions described in the GCC Runtime Library Exception, version
+   3.1, as published by the Free Software Foundation.
+
+   You should have received a copy of the GNU General Public License and
+   a copy of the GCC Runtime Library Exception along with this program;
+   see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+   .  */
+
+#if HAVE_IFUNC
+#include 
+
+# ifdef HWCAP_ATOMICS
+#  define IFUNC_COND_1	(hwcap & HWCAP_ATOMICS)
+# else
+#  define IFUNC_COND_1	(false)
+# endif
+# define IFUNC_NCOND(N)	(1)
+
+#endif /* HAVE_IFUNC */
+
+#include_next 
diff --git a/libatomic/configure.ac b/libatomic/configure.ac
index 023f172..b717d3d 100644
--- a/libatomic/configure.ac
+++ b/libatomic/configure.ac
@@ -163,6 +163,10 @@ if test -n "$UNSUPPORTED"; then
   AC_MSG_ERROR([Configuration ${target} is unsupported.])
 fi
 
+# Write out the ifunc resolver arg type.
+AC_DEFINE_UNQUOTED(IFUNC_RESOLVER_ARGS, $IFUNC_RESOLVER_ARGS,
+	[Define ifunc resolver function argument.])
+
 # Disable fallbacks to __sync routines from libgcc.  Otherwise we'll
 # make silly decisions about what the cpu can do.
 CFLAGS="$save_CFLAGS -fno-sync-libcalls $XCFLAGS"
@@ -247,6 +251,8 @@ AC_SUBST(LIBS)
 AC_SUBST(SIZES)
 
 AM_CONDITIONAL(HAVE_IFUNC, test x$libat_cv_have_ifunc = xyes)
+AM_CONDITIONAL(ARCH_AARCH64_LINUX,
+	   [expr "$config_path" : ".* linux/aarch64 .*" > /dev/null])
 AM_CONDITIONAL(ARCH_ARM_LINUX,
 	   [expr "$config_path" : ".* linux/arm .*" > /dev/null])
 AM_CONDITIONAL(ARCH_I386,
diff --git a/libatomic/configure.tgt b/libatomic/configure.tgt
index 

Re: [patch] Fix wrong code with small structure return on PowerPC

[Eric Botcazou]

> Reading the patch I think that it gets conservativeness wrong -- shouldn't
> it be
> 
>   if (is_definitely_initialized)
>{
>   SUBREG_PROMOTED_VAR_P (temp) = 1;
>   SUBREG_PROMOTED_SET (temp, unsignedp);
>}
> 
> ?  Of course it's not easy to compute is_definitely_initialized
> conservatively in an ad-hoc way at this place.  It should be relatively
> straight-forward to do a conservative computation somewhere in cfgexpand.c
> by propagating across SSA edges and recording a flag on SSA names though. 
> I assume we can take load destinations as fully initialized (should extend
> properly) as well as call results (the ABI should extend, eventually we can
> query the target if it does), likewise for function arguments.

Yes, that's why the comment read "Try to detect if " and not "Detect if ".

> On your patch:
> 
> + /* Try to detect if the register contains uninitialized bits. 
> */ + if (SSA_NAME_IS_DEFAULT_DEF (ssa_name))
> +   maybe_uninitialized = true;
> 
> if you use ssa_undefined_value_p (ssa_name[, true]) you'd get function
> paramters not undefined (which is probably desired?).  Likewise
> partial initialized complex would get uninitialized (if passed , true).

Ah, yes, I overlooked that.

> Same inside the loop over PHI args though I wonder how pessimizing
> it would be to simply do
> 
>   if (ssa_undefined_value_p (ssa_name, true)
> 
>   || gimple_code (SSA_NAME_DEF_STMT (ssa_name)) == GIMPLE_PHI)
> 
> maybe_uninitialized = true;
> 
> thus make all PHIs possibly uninitialized (your code wouldn't catch a
> chained PHI with undef arg).

Too big a hammer for such a very rare bug I think.

> As said, a better solution would be to do a definitely-initialized
> mini-propagation at RTL expansion time.

I'm not sure if we really need to propagate.  What about the attached patch?  
It computes at expansion time whether the partition the SSA name is a member 
of contains an undefined value and, if so, doesn't set the promoted bit for 
the SUBREG.  My gut feeling is that it's sufficient in practice.


* tree-outof-ssa.h (ssaexpand): Add partitions_for_undefined_values.
(always_initialized_rtx_for_ssa_name_p): New predicate.
* tree-outof-ssa.c (remove_ssa_form): Initialize new field of SA.
(finish_out_of_ssa): Free new field of SA.
* tree-ssa-coalesce.h (get_undefined_value_partitions): Declare.
* tree-ssa-coalesce.c: Include tree-ssa.h.
(get_parm_default_def_partitions): Remove extern keyword.
(get_undefined_value_partitions): New function.
* expr.c (expand_expr_real_1) : For a SSA_NAME, do
not set SUBREG_PROMOTED_VAR_P on the sub-register if it may contain
uninitialized bits.

-- 
Eric BotcazouIndex: expr.c
===
--- expr.c	(revision 253377)
+++ expr.c	(working copy)
@@ -9909,24 +9909,43 @@ expand_expr_real_1 (tree exp, rtx target
 	  && GET_MODE (decl_rtl) != dmode)
 	{
 	  machine_mode pmode;
+	  bool always_initialized_rtx;
 
 	  /* Get the signedness to be used for this variable.  Ensure we get
 	 the same mode we got when the variable was declared.  */
 	  if (code != SSA_NAME)
-	pmode = promote_decl_mode (exp, );
+	{
+	  pmode = promote_decl_mode (exp, );
+	  always_initialized_rtx = true;
+	}
 	  else if ((g = SSA_NAME_DEF_STMT (ssa_name))
 		   && gimple_code (g) == GIMPLE_CALL
 		   && !gimple_call_internal_p (g))
-	pmode = promote_function_mode (type, mode, ,
-	   gimple_call_fntype (g),
-	   2);
+	{
+	  pmode = promote_function_mode (type, mode, ,
+	gimple_call_fntype (g), 2);
+	  always_initialized_rtx
+		= always_initialized_rtx_for_ssa_name_p (ssa_name);
+	}
 	  else
-	pmode = promote_ssa_mode (ssa_name, );
+	{
+	  pmode = promote_ssa_mode (ssa_name, );
+	  always_initialized_rtx
+		= always_initialized_rtx_for_ssa_name_p (ssa_name);
+	}
+
 	  gcc_assert (GET_MODE (decl_rtl) == pmode);
 
 	  temp = gen_lowpart_SUBREG (mode, decl_rtl);
-	  SUBREG_PROMOTED_VAR_P (temp) = 1;
-	  SUBREG_PROMOTED_SET (temp, unsignedp);
+
+	  /* We cannot assume anything about an existing extension if the
+	 register may contain uninitialized bits.  */
+	  if (always_initialized_rtx)
+	{
+	  SUBREG_PROMOTED_VAR_P (temp) = 1;
+	  SUBREG_PROMOTED_SET (temp, unsignedp);
+	}
+
 	  return temp;
 	}
 
Index: tree-outof-ssa.c
===
--- tree-outof-ssa.c	(revision 253377)
+++ tree-outof-ssa.c	(working copy)
@@ -969,6 +969,7 @@ remove_ssa_form (bool perform_ter, struc
   sa->map = map;
   sa->values = values;
   sa->partitions_for_parm_default_defs = get_parm_default_def_partitions (map);
+  sa->partitions_for_undefined_values = get_undefined_value_partitions (map);
 }
 
 
@@ -1144,6 +1145,7 @@ finish_out_of_ssa (struct ssaexpand *sa)
 BITMAP_FREE 

[patch, fortran] Error for non-contiguous pointers

[Thomas Koenig]

Hello world,

I have re-thought and simplified the patch for PR49232.
This now uses gfc_is_simply_contiguous, in the
non-strict version.  I have also opted for an error
because, well, the use cases rejected by this are really
errors, and will very likely lead to wrong code in
user applications.

Regression-tested. OK for trunk?

Thomas

2017-10-03  Thomas Koenig  

PR fortran/49232
* expr.c (gfc_check_pointer_assign): Error
for non-contiguous rhs.

2017-10-03  Thomas Koenig  

PR fortran/49232
* gfortran.dg/contiguous_4.f90: New test.

Index: expr.c
===
--- expr.c	(Revision 253377)
+++ expr.c	(Arbeitskopie)
@@ -3851,6 +3851,14 @@
 	  }
 }
 
+  /* Error for assignments of contiguous pointers to targets which is not
+ contiguous.  Be lenient in the definition of what counts as
+ congiguous.  */
+
+  if (lhs_attr.contiguous && !gfc_is_simply_contiguous (rvalue, false, true))
+gfc_error ("Assignment to contiguous pointer from non-contiguous "
+	   "target at %L", >where);
+
   /* Warn if it is the LHS pointer may lives longer than the RHS target.  */
   if (warn_target_lifetime
   && rvalue->expr_type == EXPR_VARIABLE

Allow non-wi wi

[Richard Sandiford]

This patch uses global rather than member operators for wide-int.h,
so that the first operand can be a non-wide-int type.

The patch also removes the and_not and or_not member functions.
It was already inconsistent to have member functions for these
two operations (one of which was never used) and not other wi::
ones like udiv.  After the operator change, we'd have the additional
inconsistency that "non-wi & wi" would work but "non-wi.and_not (wi)"
wouldn't.

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?

Richard


2017-10-03  Richard Sandiford  

gcc/
* wide-int.h (WI_BINARY_OPERATOR_RESULT): New macro.
(WI_BINARY_PREDICATE_RESULT): Likewise.
(wi::binary_traits::operator_result): New type.
(wi::binary_traits::predicate_result): Likewise.
(generic_wide_int::operator~, unary generic_wide_int::operator-)
(generic_wide_int::operator==, generic_wide_int::operator!=)
(generic_wide_int::operator&, generic_wide_int::and_not)
(generic_wide_int::operator|, generic_wide_int::or_not)
(generic_wide_int::operator^, generic_wide_int::operator+
(binary generic_wide_int::operator-, generic_wide_int::operator*):
Delete.
(operator~, unary operator-, operator==, operator!=, operator&)
(operator|, operator^, operator+, binary operator-, operator*): New
functions.
* expr.c (get_inner_reference): Use wi::bit_and_not.
* fold-const.c (fold_binary_loc): Likewise.
* ipa-prop.c (ipa_compute_jump_functions_for_edge): Likewise.
* tree-ssa-ccp.c (get_value_from_alignment): Likewise.
(bit_value_binop): Likewise.
* tree-ssa-math-opts.c (find_bswap_or_nop_load): Likewise.
* tree-vrp.c (zero_nonzero_bits_from_vr): Likewise.
(extract_range_from_binary_expr_1): Likewise.
(masked_increment): Likewise.
(simplify_bit_ops_using_ranges): Likewise.

Index: gcc/wide-int.h
===
--- gcc/wide-int.h  2017-09-11 17:10:58.656085547 +0100
+++ gcc/wide-int.h  2017-10-03 19:32:39.077055063 +0100
@@ -262,11 +262,22 @@ #define OFFSET_INT_ELTS (ADDR_MAX_PRECIS
 #define WI_BINARY_RESULT(T1, T2) \
   typename wi::binary_traits ::result_type
 
+/* Likewise for binary operators, which excludes the case in which neither
+   T1 nor T2 is a wide-int-based type.  */
+#define WI_BINARY_OPERATOR_RESULT(T1, T2) \
+  typename wi::binary_traits ::operator_result
+
 /* The type of result produced by T1 << T2.  Leads to substitution failure
if the operation isn't supported.  Defined purely for brevity.  */
 #define WI_SIGNED_SHIFT_RESULT(T1, T2) \
   typename wi::binary_traits ::signed_shift_result_type
 
+/* The type of result produced by a sign-agnostic binary predicate on
+   types T1 and T2.  This is bool if wide-int operations make sense for
+   T1 and T2 and leads to substitution failure otherwise.  */
+#define WI_BINARY_PREDICATE_RESULT(T1, T2) \
+  typename wi::binary_traits ::predicate_result
+
 /* The type of result produced by a signed binary predicate on types T1 and T2.
This is bool if signed comparisons make sense for T1 and T2 and leads to
substitution failure otherwise.  */
@@ -382,12 +393,15 @@ #define WIDE_INT_REF_FOR(T) \
   struct binary_traits 
   {
 typedef widest_int result_type;
+/* Don't define operators for this combination.  */
   };
 
   template 
   struct binary_traits 
   {
 typedef wide_int result_type;
+typedef result_type operator_result;
+typedef bool predicate_result;
   };
 
   template 
@@ -397,6 +411,8 @@ #define WIDE_INT_REF_FOR(T) \
so as not to confuse gengtype.  */
 typedef generic_wide_int < fixed_wide_int_storage
   ::precision> > result_type;
+typedef result_type operator_result;
+typedef bool predicate_result;
 typedef bool signed_predicate_result;
   };
 
@@ -404,6 +420,8 @@ #define WIDE_INT_REF_FOR(T) \
   struct binary_traits 
   {
 typedef wide_int result_type;
+typedef result_type operator_result;
+typedef bool predicate_result;
   };
 
   template 
@@ -413,6 +431,8 @@ #define WIDE_INT_REF_FOR(T) \
so as not to confuse gengtype.  */
 typedef generic_wide_int < fixed_wide_int_storage
   ::precision> > result_type;
+typedef result_type operator_result;
+typedef bool predicate_result;
 typedef result_type signed_shift_result_type;
 typedef bool signed_predicate_result;
   };
@@ -420,11 +440,13 @@ #define WIDE_INT_REF_FOR(T) \
   template 
   struct binary_traits 

Re: [PATCH,AIX] Manage Go Closure in libffi for AIX

[David Edelsohn]

I committed the import of AIX Go support from libffi repository into
the GCC copy of libffi.

Thanks, David

Re: [PATCH] Fix fortran/81509

[Steve Kargl]

On Tue, Oct 03, 2017 at 04:27:15PM +0200, Janus Weil wrote:
> >>
> >> ... with regards to the F08 standard, which forbids it, yes. I guess
> >> that is the nature of a "non-standard extension". It can still give a
> >> meaningful result, after the smaller kind is implicitly converted to
> >> the larger kind.
> >
> > F95 and F03 have
> >
> > IAND(I,J)
> >
> > Arguments.
> >
> > I   shall be of type integer.
> > J   shall be of type integer with the same kind type parameter as I.
> >
> > and F08 has
> >
> > I   shall be of type integer or a boz-literal-constant.
> > J   shall be of type integer or a boz-literal-constant. If both I and J
> > are of type integer, they shall have the same kind type parameter.
> > I and J shall not both be boz-literal-constants.
> >
> > If a user wants to mix the kind type parameters, then the user
> > can use AND, OR, and XOR.
> 
> ... which are non-standard, just as differing kinds in IAND. Why would
> AND(i4,i8) be any 'better' than IAND(i4, i8) from your point of view?

You are correct that AND, OR, and XOR are not specified in any Fortran
standard.  However, the Fortran standards permit an implementation to
include additional intrinsic subprograms not specified in a standard.
Fortran 95 has

  A standard-conforming processor may allow additional forms
  and relationships provided that such additions do not conflict
  with the standard forms and relationships.  However, a standard-
  conforming processor may allow additional intrinsic procedures
  even though this could cause a conflict with the name of a procedure
  in a standard-conforming program.  If such a conflict occurs and
  involves the name of an external procedure, the processor is permitted
  to use the intrinsic procedure unless the name is given an interface
  body or the EXTERNAL attribute in the same scoping unit (14).

Similar language appears in F03 and F08.  The gfortran implementation
and documentation for AND, OR, and XOR defined their behavior.

> >>> I withdraw the patch.
> >>
> >> Why? It does fix a rejects-valid bug after all, doesn't it? I
> >> completely agree with Paul's earlier review that this is good and
> >> necessary.
> >>
> >> All I'm saying is that I don't think it's a good idea to turn the
> >> gfc_notify_std into a gfc_error. If you keep the gfc_notify_std, the
> >> patch is ok for trunk from my side.
> >
> > gfortran should encourage users to write standard conforming code.
> 
> I absolutely fully agree here. But it should not do this by
> unimplementing non-standard features, but rather by providing a
> mechanism to let the user choose between
> 
> * "I want my code to strictly comply with my favorite Fortran standard" and
> * "I need to use this or that non-standard feature, for this or that
> reason. I know that Steve doesn't like it, but quite frankly it's not
> his decision to make."

You are correct it is not my decision.  You raised an objection.
You and I have a difference of opinion on the correct action to
take.  So, I withdraw the patch to maintain the status quo.

Since you're adamant about maintaining nonstandard behavior.
Then, please do not cherry-pick from my patch to enforce F2008
semantics for

program foo
   print '(I0)', iand(z'1234',b'1010101')
end program foo

which currently gives

% gfortran6 -static -o z a.f90 && ./z
20

The above nonstandard semantics are currently permitted, and therefore
cannot be changed because someone must have code that uses this feature.

In fact, gfortran current permits

program foo
   x = abs(z'7F7F')
   print *, x
end program foo

% gfcx -o z -std=f2008 -Wall a.f90 && ./z
a.f90:3:7:

x = abs(z'7F7F')
   1
Warning: Change of value in conversion from 'INTEGER(16)' to 'REAL(4)'
at (1) [-Wconversion]
   2.13909504E+09

Please do not change gfortran's behavior of allowing boz-literal-constants
in all intrinsic routines that accept INTEGER(16) as actual argument(s).

> Note that such a mechanism is very nicely provided by the flag
> "-std=...", which is certainly one of the stronger points of gfortran.
> 
> https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html
> 
> > % cat a.f90
> > program foo
> >integer(4) :: i = 4
> >integer(8) :: j = 5
> >print *, iand(i,j)
> > end program foo
> > % gfortran6 -Wall -c a.f90
> > % gfortran6 -Wconversion -c a.f90
> > % gfortran6 -Wall -Wextra -c a.f90
> > % gfortran6 -Wall -Wextra -Wsurprising -c a.f90
> >
> > There is no mechanism available to warn the user of nonstandard code.
> 
> Of course there is:
> 
> $ gfortran -std=f2008 a.f90
> a.f90:4:17:
> 
> print *, iand(i,j)
>  1
> Error: GNU Extension: Different type kinds at (1)
> 

Reread what I wrote.  There is NO MECHANISM TO WARN the user.
-std=f2008 does not produce a WARNING.  It produces an ERROR.

For the record, I am aware that -std=f2008 produces an (un)desirable
result for AND, OR, and XOR.  However, if someone is inclined to
use -std=f2008, then that someone is likely to 

[committed][PATCH][PR target/82358] Fix minor bug in stack-clash tests

[Jeff Law]

On x86, micro architecture selection affects the use of "sub" vs "lea".
The stack-check-11 test was searching for "sub" instructions and of
course failed if the compiler was configured for one of the micro
architecture variants that prefers "lea".

Per HJ's recommendation in the BZ, we can avoid this minor issue by
using -mtune=generic.

Bootstrapped and regression tested on x86.  Also verified that the test
now passes when configured with --with-cpu=slm --with-arch=slm

Installed on the trunk.

Jeff
commit 846968c00caa649e3b1270fd8a9500a7082542f4
Author: law 
Date:   Tue Oct 3 17:09:54 2017 +

PR target/82358
* gcc.target/i386/stack-check-11.c: Use -mtune=generic.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@253385 
138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index e109ea55d55..c5aec6ef564 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2017-10-03  Jeff Law  
+
+   PR target/82358
+   * gcc.target/i386/stack-check-11.c: Use -mtune=generic.
+
 2017-10-03  Martin Jambor  
 
PR tree-optimization/82363
diff --git a/gcc/testsuite/gcc.target/i386/stack-check-11.c 
b/gcc/testsuite/gcc.target/i386/stack-check-11.c
index fe5b2c2b844..90ab6023b42 100644
--- a/gcc/testsuite/gcc.target/i386/stack-check-11.c
+++ b/gcc/testsuite/gcc.target/i386/stack-check-11.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -fstack-clash-protection" } */
+/* { dg-options "-O2 -fstack-clash-protection -mtune=generic" } */
 /* { dg-require-effective-target supports_stack_clash_protection } */
 
 #include 

[PATCH] C++ warning on vexing parse

[Nathan Sidwell]

[non-c++ people on CC, there's a reason ...]

This patch adds a new warning, concerning unnecessary parentheses on a 
declaration.  For instance:

   prettyprinter (pp);
That's a declaration of a pp variable of type prettyprinter -- not a 
call of a prettyprinter function.  The reason is that in C++, anything 
that is syntactically a declaration, is a declaration.  This can lead to 
surprising unexpected code generation, and the documentation I added 
provides motivation:

  std::unique_lock (mymutex);
That is NOT a lock of mymutex.  It's a declaration of a variable called 
mymutex locking no mutex.  If we're in a member function and 'mymutex' 
is a field, Wshadow-parm doesn't trigger either.


This patch notes when a direct-declarator is parenthesized, and then 
warns about it in grokdeclarator.  Obviously, parens are sometimes 
necessary -- when declaring pointers to arrays or functions, and we 
don't warn then.  The simplest way to do that was during the parsing, 
not in grokdeclarator, where the cp_declarator object is constant.  We'd 
either have to change that, or have some other local state.


I added this to -Wparentheses (enabled by -Wall).  It triggered in a few 
cases during bootstrap:


1) in toplev.c we have the above prettyprinter example.  I think that's 
clearly poorly formatted code.


2) caller-save.c: insert_save has 'HARD_REG_SET (*to_save)', which also 
seems poorly formatted to me -- other cases of ptr-to-HRS don't do this.


3) A couple of places do:
   T (name  // line break to avoid wrap
  [LONGEXPR][OTHERLONGEXPR]);

The parens aid the editor's formatter. The patch removes the parens, but 
I can see there may be disagreement.  I suppose we could permit parens 
at the outermost declarator for an array?

Affects ira-int.h (target_ira_int::x_ira_reg_mode_hard_regset)
 reload.h (target_reload::x_regno_save_mode)

3) A set of typedef'd function types (NOT ptr-to-fn).  The name being 
typedef'd is parenthesized and not an idiom I recall seeing before. 
AFAICT these are the only cases of typedefing a plain fn.  We could, I 
suppose, ignore parens on a typedef'd fntype, but that seems a little 
random.

Affects gengtype.c (frul_actionrout_t)
lto-streamer.h (lto_get_section_data_f & to_free_section_data_f)
tree-ssa-threadedge.c (pfn_simplify)

If you've objections to the changes I've made in instances of #3 & #4 
let me know.


Jason, do you have concerns about the C++ patch itself?

nathan
--
Nathan Sidwell
2017-10-03  Nathan Sidwell  

	* caller-save.c (insert_save): Remove parens around TO_SAVE arg.
	* gengtype.c (frul_actionrout_t): Remove parens.
	* ira-int.h (target_ira_int::x_ira_reg_mode_hard_regset): Likewise.
	* lto-streamer.h (lto_get_section_data_f,
	lto_free_section_data_f): Remove parens.
	* reload.h (target_reload::x_regno_save_mode): Remove parens.
	* toplev.c (toplev::main): Remove parens on pp declaration.
	* tree-ssa-threadedge.c (pfn_simplify): Remove parens.
	* doc/invoke.texi (Wparentheses): Document C++ MVP behaviour.

	cp/
	* cp-tree.h (struct cp_declarator): Add parenthesized field.
	* decl.c (grokdeclarator): Warn about unnecessary parens.
	* parser.c (make_declarator): Init parenthesized field.
	(make_call_declarator, make_array_declarator): Conditionally clear
	parenthesized field.
	(token_pair::open_loc): New accessor.
	(cp_parser_direct_declarator): Set parenthesized field.

	testsuite/
	* g++.dg/warn/mvp.C: New.

Index: caller-save.c
===
--- caller-save.c	(revision 253381)
+++ caller-save.c	(working copy)
@@ -1265,7 +1265,7 @@ insert_restore (struct insn_chain *chain
 
 static int
 insert_save (struct insn_chain *chain, int before_p, int regno,
-	 HARD_REG_SET (*to_save), machine_mode *save_mode)
+	 HARD_REG_SET *to_save, machine_mode *save_mode)
 {
   int i;
   unsigned int k;
Index: gengtype.c
===
--- gengtype.c	(revision 253381)
+++ gengtype.c	(working copy)
@@ -1894,7 +1894,7 @@ get_file_gtfilename (const input_file *i
  */
 
 /* Signature of actions in file rules.  */
-typedef outf_p (frul_actionrout_t) (input_file*, char**, char**);
+typedef outf_p frul_actionrout_t (input_file*, char**, char**);
 
 
 struct file_rule_st {
Index: ira-int.h
===
--- ira-int.h	(revision 253381)
+++ ira-int.h	(working copy)
@@ -801,8 +801,8 @@ struct target_ira_int {
 
   /* Map: hard regs X modes -> set of hard registers for storing value
  of given mode starting with given hard register.  */
-  HARD_REG_SET (x_ira_reg_mode_hard_regset
-		[FIRST_PSEUDO_REGISTER][NUM_MACHINE_MODES]);
+  HARD_REG_SET x_ira_reg_mode_hard_regset
+		[FIRST_PSEUDO_REGISTER][NUM_MACHINE_MODES];
 
   /* Maximum cost of moving from a register in one class to a register
  in another class.  Based on TARGET_REGISTER_MOVE_COST.  */
Index: 

[PATCH] Fix PR82396: qsort comparator non-negative on sorted output

[Wilco Dijkstra]

r253236 broke AArch64 bootstrap. Earlier revision r253071 changed scheduling
behaviour on AArch64 as autopref scheduling no longer checks the base.

This patch fixes the bootstrap failure and cleans up autopref scheduling.
The code is greatly simplified.  Sort accesses on the offset first, and
only if the offsets are the same fall back to other comparisons in
rank_for_schedule.  This doesn't at all restore the original behaviour
since we no longer compare the base address, but it now defines a total
sorting order.  More work will be required to improve the sorting so
that only loads/stores with the same base are affected.

AArch64 bootstrap completes. I'd like to commit this ASAP as the AArch64
bootstrap has been broken for days now.

ChangeLog:
2017-10-03  Wilco Dijkstra  

PR rtl-optimization/82396
* gcc/haifa-sched.c (autopref_multipass_init): Simplify
initialization.
(autopref_rank_data): Simplify sort order.
* gcc/sched-int.h (autopref_multipass_data_): Remove
multi_mem_insn_p, min_offset and max_offset.
--

diff --git a/gcc/haifa-sched.c b/gcc/haifa-sched.c
index 
549e8961411ecd0a04ac3b24ba78b5d53e63258a..77ba8c5292a0801bbbcb35ed61ab3040015f6677
 100644
--- a/gcc/haifa-sched.c
+++ b/gcc/haifa-sched.c
@@ -5568,9 +5568,7 @@ autopref_multipass_init (const rtx_insn *insn, int write)
 
   gcc_assert (data->status == AUTOPREF_MULTIPASS_DATA_UNINITIALIZED);
   data->base = NULL_RTX;
-  data->min_offset = 0;
-  data->max_offset = 0;
-  data->multi_mem_insn_p = false;
+  data->offset = 0;
   /* Set insn entry initialized, but not relevant for auto-prefetcher.  */
   data->status = AUTOPREF_MULTIPASS_DATA_IRRELEVANT;
 
@@ -5585,10 +5583,9 @@ autopref_multipass_init (const rtx_insn *insn, int write)
 {
   int n_elems = XVECLEN (pat, 0);
 
-  int i = 0;
-  rtx prev_base = NULL_RTX;
-  int min_offset = 0;
-  int max_offset = 0;
+  int i, offset;
+  rtx base, prev_base = NULL_RTX;
+  int min_offset = INT_MAX;
 
   for (i = 0; i < n_elems; i++)
{
@@ -5596,38 +5593,23 @@ autopref_multipass_init (const rtx_insn *insn, int 
write)
  if (GET_CODE (set) != SET)
return;
 
- rtx base = NULL_RTX;
- int offset = 0;
  if (!analyze_set_insn_for_autopref (set, write, , ))
return;
 
- if (i == 0)
-   {
- prev_base = base;
- min_offset = offset;
- max_offset = offset;
-   }
  /* Ensure that all memory operations in the PARALLEL use the same
 base register.  */
- else if (REGNO (base) != REGNO (prev_base))
+ if (i > 0 && REGNO (base) != REGNO (prev_base))
return;
- else
-   {
- min_offset = MIN (min_offset, offset);
- max_offset = MAX (max_offset, offset);
-   }
+ prev_base = base;
+ min_offset = MIN (min_offset, offset);
}
 
-  /* If we reached here then we have a valid PARALLEL of multiple memory
-ops with prev_base as the base and min_offset and max_offset
-containing the offsets range.  */
+  /* If we reached here then we have a valid PARALLEL of multiple memory 
ops
+with prev_base as the base and min_offset containing the offset.  */
   gcc_assert (prev_base);
   data->base = prev_base;
-  data->min_offset = min_offset;
-  data->max_offset = max_offset;
-  data->multi_mem_insn_p = true;
+  data->offset = min_offset;
   data->status = AUTOPREF_MULTIPASS_DATA_NORMAL;
-
   return;
 }
 
@@ -5637,7 +5619,7 @@ autopref_multipass_init (const rtx_insn *insn, int write)
 return;
 
   if (!analyze_set_insn_for_autopref (set, write, >base,
-  >min_offset))
+  >offset))
 return;
 
   /* This insn is relevant for the auto-prefetcher.
@@ -5646,63 +5628,6 @@ autopref_multipass_init (const rtx_insn *insn, int write)
   data->status = AUTOPREF_MULTIPASS_DATA_NORMAL;
 }
 
-
-/* Helper for autopref_rank_for_schedule.  Given the data of two
-   insns relevant to the auto-prefetcher modelling code DATA1 and DATA2
-   return their comparison result.  Return 0 if there is no sensible
-   ranking order for the two insns.  */
-
-static int
-autopref_rank_data (autopref_multipass_data_t data1,
-autopref_multipass_data_t data2)
-{
-  /* Simple case when both insns are simple single memory ops.  */
-  if (!data1->multi_mem_insn_p && !data2->multi_mem_insn_p)
-return data1->min_offset - data2->min_offset;
-
-  /* Two load/store multiple insns.  Return 0 if the offset ranges
- overlap and the difference between the minimum offsets otherwise.  */
-  else if (data1->multi_mem_insn_p && data2->multi_mem_insn_p)
-{
-  int min1 = data1->min_offset;
-  int max1 = data1->max_offset;
-  int min2 = data2->min_offset;
-  int 

[PING] [PATCH] Fix PR81422[aarch64] internal compiler error: in update_equiv_regs, at ira.c:3425

[Qing Zhao]

Ping

https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg173877.html

> On Sep 19, 2017, at 2:22 PM, Qing Zhao  wrote:
> 
> Hi,
> 
> This patch fixes the aarch64 bug 81422 
> https://gcc.gnu.org/PR81422
> 
> Before adding REG_EQUIV notes in the TLS symbol handling code,
> we should check whether the "dest" is a REG or NOT (sometimes,
> it's a SUBREG as in this bug). Only when the “dest” is a REG, the note
> will be added.
> 
> a new small testing case is added. 
> 
> this change has been tested on aarch64-unknown-linux-gnu with no regression. 
> 
> Thanks!
> 
> Qing
> 
> 
> ===
> 
> gcc/ChangeLog:
> 
>   * config/aarch64/aarch64.c (aarch64_load_symref_appropriately):
>   check whether the dest is REG before adding REG_EQUIV note.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR target/81422
>   * gcc.target/aarch64/pr81422.C: New test.
> 
> ---
> gcc/config/aarch64/aarch64.c   | 12 
> gcc/testsuite/gcc.target/aarch64/pr81422.C | 15 +++
> 2 files changed, 23 insertions(+), 4 deletions(-)
> create mode 100644 gcc/testsuite/gcc.target/aarch64/pr81422.C
> 
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index a2ecd7a..6c3ef76 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -1480,7 +1480,8 @@ aarch64_load_symref_appropriately (rtx dest, rtx imm,
> tp = gen_lowpart (mode, tp);
> 
>   emit_insn (gen_rtx_SET (dest, gen_rtx_PLUS (mode, tp, x0)));
> - set_unique_reg_note (get_last_insn (), REG_EQUIV, imm);
> +if (REG_P (dest)) 
> +   set_unique_reg_note (get_last_insn (), REG_EQUIV, imm);
>   return;
>   }
> 
> @@ -1514,7 +1515,8 @@ aarch64_load_symref_appropriately (rtx dest, rtx imm,
> }
> 
>   emit_insn (gen_rtx_SET (dest, gen_rtx_PLUS (mode, tp, tmp_reg)));
> - set_unique_reg_note (get_last_insn (), REG_EQUIV, imm);
> +if (REG_P (dest)) 
> +   set_unique_reg_note (get_last_insn (), REG_EQUIV, imm);
>   return;
>   }
> 
> @@ -1555,7 +1557,8 @@ aarch64_load_symref_appropriately (rtx dest, rtx imm,
>   gcc_unreachable ();
> }
> 
> - set_unique_reg_note (get_last_insn (), REG_EQUIV, imm);
> +if (REG_P (dest)) 
> +   set_unique_reg_note (get_last_insn (), REG_EQUIV, imm);
>   return;
>   }
> 
> @@ -1584,7 +1587,8 @@ aarch64_load_symref_appropriately (rtx dest, rtx imm,
>   emit_insn (gen_tlsie_tiny_sidi (dest, imm, tp));
> }
> 
> - set_unique_reg_note (get_last_insn (), REG_EQUIV, imm);
> +if (REG_P (dest))
> +   set_unique_reg_note (get_last_insn (), REG_EQUIV, imm);
>   return;
>   }
> 
> diff --git a/gcc/testsuite/gcc.target/aarch64/pr81422.C 
> b/gcc/testsuite/gcc.target/aarch64/pr81422.C
> new file mode 100644
> index 000..5bcc948
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/pr81422.C
> @@ -0,0 +1,15 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O0" } */
> +
> +struct DArray
> +{
> +__SIZE_TYPE__ length;
> +int* ptr;
> +};
> +
> +void foo35(DArray)
> +{
> +static __thread int x[5];
> +foo35({5, (int*)});
> +}
> +
> -- 
> 1.9.1
> 

Re: [PATCH] C++17 P0067R5 std::to_chars and std::from_chars (partial)

[Jonathan Wakely]

On 02/10/17 15:13 +0100, Jonathan Wakely wrote:

+#ifndef _GLIBCXX_CHARCONV
+#define _GLIBCXX_CHARCONV 1
+
+#pragma GCC system_header
+
+#if __cplusplus >= 201402L
+
+#include 
+#include 
+#include 
+#include  // for std::errc


I forgot to mention that I've made this header work for C++14 not just C++17. I
did this for similar reasons as we make some C++17 things available for
-std=gnu++11 and -std=gnu++14:

#if __cplusplus > 201402L || !defined(__STRICT_ANSI__) // c++1z or gnu++11

But in this case  is a completely new header so we don't have to
limit it to -std=gnu++NN modes only. The new functions won't pollute namespace
std unless the new header gets included, which strictly-conforming C++14 code
won't do anyway.

Re: [PATCH] Fix fortran/81509

[Janus Weil]

Hi Steve,

>> >> In general one can argue about whether or not it's a good idea to use
>> >> non-std extensions. But I think gfortran should rather leave the
>> >> choice to its users, whether they want to use 'dirty and covenient'
>> >> code or have very strict checking. We have nice mechanisms for this,
>> >> and I do think we should keep them.
>> >>
>> >
>> > It is undefined behavior.
>>
>> ... with regards to the F08 standard, which forbids it, yes. I guess
>> that is the nature of a "non-standard extension". It can still give a
>> meaningful result, after the smaller kind is implicitly converted to
>> the larger kind.
>
> F95 and F03 have
>
> IAND(I,J)
>
> Arguments.
>
> I   shall be of type integer.
> J   shall be of type integer with the same kind type parameter as I.
>
> and F08 has
>
> I   shall be of type integer or a boz-literal-constant.
> J   shall be of type integer or a boz-literal-constant. If both I and J
> are of type integer, they shall have the same kind type parameter.
> I and J shall not both be boz-literal-constants.
>
> If a user wants to mix the kind type parameters, then the user
> can use AND, OR, and XOR.

... which are non-standard, just as differing kinds in IAND. Why would
AND(i4,i8) be any 'better' than IAND(i4, i8) from your point of view?


>> Btw, contrary to your earlier claim, the extension is actually
>> documented: https://gcc.gnu.org/onlinedocs/gfortran/IAND.html
>
> A parenthetical remark hardly counts as documentation.

It is pretty much better than nothing I'd say. Lack of documentation
is not a good motivation for removing a feature (but rather for
enhancing the documentation).


>>> I withdraw the patch.
>>
>> Why? It does fix a rejects-valid bug after all, doesn't it? I
>> completely agree with Paul's earlier review that this is good and
>> necessary.
>>
>> All I'm saying is that I don't think it's a good idea to turn the
>> gfc_notify_std into a gfc_error. If you keep the gfc_notify_std, the
>> patch is ok for trunk from my side.
>
> gfortran should encourage users to write standard conforming code.

I absolutely fully agree here. But it should not do this by
unimplementing non-standard features, but rather by providing a
mechanism to let the user choose between

* "I want my code to strictly comply with my favorite Fortran standard" and
* "I need to use this or that non-standard feature, for this or that
reason. I know that Steve doesn't like it, but quite frankly it's not
his decision to make."

Note that such a mechanism is very nicely provided by the flag
"-std=...", which is certainly one of the stronger points of gfortran.

https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html



> % cat a.f90
> program foo
>integer(4) :: i = 4
>integer(8) :: j = 5
>print *, iand(i,j)
> end program foo
> % gfortran6 -Wall -c a.f90
> % gfortran6 -Wconversion -c a.f90
> % gfortran6 -Wall -Wextra -c a.f90
> % gfortran6 -Wall -Wextra -Wsurprising -c a.f90
>
> There is no mechanism available to warn the user of nonstandard code.

Of course there is:

$ gfortran -std=f2008 a.f90
a.f90:4:17:

print *, iand(i,j)
 1
Error: GNU Extension: Different type kinds at (1)



> Finally, I have neither the time nor energy to debate the merits of
> a dubious undocumented bug/feature.  I have supplied a patch.  An
> objection has been raised.  I withdraw the patch.

If every patch submitter would withdraw his patches after getting a
review, gfortran wouldn't be going anywhere I guess.

I never claimed that your patch is all bullshit. I told told you one
detail I don't like about it, and I think that's my good right (or
even my duty) as a reviewer. It's actually very simple to fix, but you
already got two OKs, so you can just as well ignore my opinion and
commit your patch as posted.

Cheers,
Janus

Re: Make tests less istreambuf_iterator implementation dependent

[Jonathan Wakely]

On 02/10/17 07:43 +0200, François Dumont wrote:

On 28/09/2017 23:56, Jonathan Wakely wrote:

On 28/09/17 21:59 +0200, François Dumont wrote:


The current istreambuf_iterator implementation capture the current 
streambuf state each time it is tested for eof or evaluated. This 
is why I considered those tests as fragile.


Yes, and I think that's non-conforming.



Good, then we have something to fix.


As I said in the other thread, I'd really like to see references to
the standard used to justify any changes to our istreambuf_iterator


I think _M_c has been introduced to cover this paragraph of the Standard:

24.6.3.1

"1. Class istreambuf_iterator::proxy is for exposition 
only. An implementation is permit-
ted to provide equivalent functionality without providing a class with 
this name. Class istreambuf_-
iterator::proxy provides a temporary placeholder as the 
return value of the post-
increment operator (operator++). It keeps the character pointed to by 
the previous value of the iterator for

some possible future access to get the character."

This is why it is being set in operator++(int):

    istreambuf_iterator __old = *this;
    __old._M_c = _M_sbuf->sbumpc();

It is also the reason why libstdc++ fails:
http://llvm.org/svn/llvm-project/libcxx/trunk/test/std/iterators/stream.iterators/istreambuf.iterator/istreambuf.iterator.cons/proxy.pass.cpp


It looks like this test is simply not Standard conformant.


I think you're right, because it relies on a property that may not be
true:

 any copies of the previous
 value of r are no longer
 required either to be
 dereferenceable or to be in
 the domain of ==.

I guess at some point _M_c started to be used also to cache the 
streambuf::sgetc resulting in current situation.


And arguably that is not "equivalent functionality" to returning a
proxy object. Although the standard seems a bit underspecified.

In attached patch I limit usage of _M_c to cover 24.6.3.1.1 point and 
so made additional changes to 2.cc test case to demonstrate it.


Doesn't the modified test PASS anyway, even without changing how _M_c
is used?

Generally this looks good (I'm not sure if it addresses Petr's
concerns, but I don't think his "stop and go" usage is valid anyway -
it's certainly not portable or guaranteed by the standard).


@@ -103,7 +103,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  : _M_sbuf(0), _M_c(traits_type::eof()) { }

#if __cplusplus >= 201103L
-  istreambuf_iterator(const istreambuf_iterator&) noexcept = default;
+  istreambuf_iterator(const istreambuf_iterator&) = default;


Please don't remove this.

It's present in the standard, and it ensures we don't accidentally add
a member that makes the default noexcept(false).



  ~istreambuf_iterator() = default;
#endif
@@ -122,28 +122,29 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  char_type
  operator*() const
  {
+   int_type __c = _M_get();
+
#ifdef _GLIBCXX_DEBUG_PEDANTIC
// Dereferencing a past-the-end istreambuf_iterator is a
// libstdc++ extension
-   __glibcxx_requires_cond(!_M_at_eof(),
+   __glibcxx_requires_cond(!_S_at_eof(__c),
_M_message(__gnu_debug::__msg_deref_istreambuf)
._M_iterator(*this));
#endif
-   return traits_type::to_char_type(_M_get());
+   return traits_type::to_char_type(__c);
  }

  /// Advance the iterator.  Calls streambuf.sbumpc().
  istreambuf_iterator&
  operator++()
  {
-   __glibcxx_requires_cond(!_M_at_eof(),
+   __glibcxx_requires_cond(_M_sbuf &&
+   (!_S_at_eof(_M_c) || 
!_S_at_eof(_M_sbuf->sgetc())),
_M_message(__gnu_debug::__msg_inc_istreambuf)
._M_iterator(*this));
-   if (_M_sbuf)
- {


This check should be unnecessary, because it's undefined to increment
and end-of-stream iterator, but I wonder if anyone is relying on it
being currently a no-op, rather than crashing.

Let's remove the check, and if it causes too many problems we can
restore it as:

 if (__builtin_expect(_M_sbuf != 0, 1))


+
_M_sbuf->sbumpc();
_M_c = traits_type::eof();
- }
return *this;
  }

@@ -151,16 +152,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  istreambuf_iterator
  operator++(int)
  {
-   __glibcxx_requires_cond(!_M_at_eof(),
+   __glibcxx_requires_cond(_M_sbuf &&
+   (!_S_at_eof(_M_c) || 
!_S_at_eof(_M_sbuf->sgetc())),
_M_message(__gnu_debug::__msg_inc_istreambuf)
._M_iterator(*this));

istreambuf_iterator __old = *this;
-   if (_M_sbuf)
- {
__old._M_c = _M_sbuf->sbumpc();
_M_c = traits_type::eof();
- }
return __old;
  }

@@ -176,26 +175,21 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  int_type
  _M_get() const
  {
-  

[patch, fortran, committed] Handle EXEC_WAIT in Fortran tree dump

[Thomas Koenig]

Hello world,

I noticed that EXEC_WAIT wasn't handled in the Fortran tree dump.
This patch does that.  While preparing this, I also noticed that
the values for the END and EOR tags were interchanged and fixed
this as well.

Committed as obvious and simple.

Just a cleanup for the time when WAIT actually does anything :-)

Regards

Thomas

2017-10-03  Thomas Koenig  

* io.c (match_wait_element): Correctly match END and EOR tags.
* dump-parse-tree.c (show_code_node): Handle EXEC_WAIT.
Index: io.c
===
--- io.c	(Revision 253377)
+++ io.c	(Arbeitskopie)
@@ -4641,8 +4641,8 @@ match_wait_element (gfc_wait *wait)
 
   m = match_etag (_unit, >unit);
   RETM m = match_ltag (_err, >err);
-  RETM m = match_ltag (_end, >eor);
-  RETM m = match_ltag (_eor, >end);
+  RETM m = match_ltag (_end, >end);
+  RETM m = match_ltag (_eor, >eor);
   RETM m = match_etag (_iomsg, >iomsg);
   if (m == MATCH_YES && !check_char_variable (wait->iomsg))
 return MATCH_ERROR;
Index: dump-parse-tree.c
===
--- dump-parse-tree.c	(Revision 253377)
+++ dump-parse-tree.c	(Arbeitskopie)
@@ -2727,6 +2727,41 @@ show_code_node (int level, gfc_code *c)
 	fprintf (dumpfile, " EOR=%d", dt->eor->value);
   break;
 
+case EXEC_WAIT:
+  fputs ("WAIT", dumpfile);
+
+  if (c->ext.wait != NULL)
+	{
+	  gfc_wait *wait = c->ext.wait;
+	  if (wait->unit)
+	{
+	  fputs (" UNIT=", dumpfile);
+	  show_expr (wait->unit);
+	}
+	  if (wait->iostat)
+	{
+	  fputs (" IOSTAT=", dumpfile);
+	  show_expr (wait->iostat);
+	}
+	  if (wait->iomsg)
+	{
+	  fputs (" IOMSG=", dumpfile);
+	  show_expr (wait->iomsg);
+	}
+	  if (wait->id)
+	{
+	  fputs (" ID=", dumpfile);
+	  show_expr (wait->id);
+	}
+	  if (wait->err)
+	fprintf (dumpfile, " ERR=%d", wait->err->value);
+	  if (wait->end)
+	fprintf (dumpfile, " END=%d", wait->end->value);
+	  if (wait->eor)
+	fprintf (dumpfile, " EOR=%d", wait->eor->value);
+	}
+  break;
+
 case EXEC_OACC_PARALLEL_LOOP:
 case EXEC_OACC_PARALLEL:
 case EXEC_OACC_KERNELS_LOOP:

Re: [PATCH] Fix sort_by_operand_rank with qsort checking (PR tree-optimization/82381, #2)

[Richard Biener]

On October 3, 2017 1:55:35 PM GMT+02:00, Jakub Jelinek  wrote:
>On Tue, Oct 03, 2017 at 01:24:32PM +0300, Alexander Monakov wrote:
>> On Tue, 3 Oct 2017, Jakub Jelinek wrote:
>> > The qsort cmp transitivity checks may fail with the
>sort_by_operand_rank
>> > comparator, because if one of the operands has stmt_to_insert and
>the
>> > other doesn't (but likely also if one SSA_NAME is (D) and the other
>is not),
>> > we fallthrough into SSA_NAME_VERSION comparison, but if both aren't
>(D) and
>> > both don't have stmt_to_insert, we use different comparison rules.
>> 
>> When looking at the code I've noticed another issue, so the fix seems
>> incomplete (but I don't know if the other problem can/should be fixed
>> independently), see below:
>> 
>> 
>> > --- gcc/tree-ssa-reassoc.c.jj  2017-10-02 17:33:14.270282226 +0200
>> > +++ gcc/tree-ssa-reassoc.c 2017-10-02 18:18:07.328611132 +0200
>> > @@ -514,36 +514,37 @@ sort_by_operand_rank (const void *pa, co
>> >&& TREE_CODE (oea->op) == SSA_NAME
>> >&& TREE_CODE (oeb->op) == SSA_NAME)
>> >  {
>> 
>> The containing if statement condition reads:
>> 
>>   if (oeb->rank == oea->rank
>>   && TREE_CODE (oea->op) == SSA_NAME
>>   && TREE_CODE (oeb->op) == SSA_NAME)
>> 
>> so as far as I can tell it's possible to have items A, B, C such that
>> all have same rank, A and C correspond to SSA_NAMEs and compare C <
>A,
>> but B does not, so comparisons of A or C against B fall down to 
>> 
>> return oeb->id > oea->id ? 1 : -1;
>> 
>> and ultimately result in A < B < C < A.
>
>I think it is likely only hypothetical, because get_rank for
>non-SSA_NAME
>should be 0 and thus handled earlier (for SSA_NAME I think rank of 0 is
>still possible).
>
>That said, this untested patch reshuffles stuff a little bit, ok for
>trunk
>if it passes testing?

OK. 

Richard. 

>2017-10-03  Jakub Jelinek  
>
>   PR tree-optimization/82381
>   * tree-ssa-reassoc.c (sort_by_operand_rank): Check for different
>   oeN->rank first.  Return 1 or -1 if one op is SSA_NAME and the other
>   is not.
>
>--- gcc/tree-ssa-reassoc.c.jj  2017-10-03 13:24:00.0 +0200
>+++ gcc/tree-ssa-reassoc.c 2017-10-03 13:41:23.098183270 +0200
>@@ -495,10 +495,13 @@ sort_by_operand_rank (const void *pa, co
>   const operand_entry *oea = *(const operand_entry *const *)pa;
>   const operand_entry *oeb = *(const operand_entry *const *)pb;
> 
>+  if (oeb->rank != oea->rank)
>+return oeb->rank > oea->rank ? 1 : -1;
>+
>   /* It's nicer for optimize_expression if constants that are likely
>- to fold when added/multiplied//whatever are put next to each
>+ to fold when added/multiplied/whatever are put next to each
>  other.  Since all constants have rank 0, order them by type.  */
>-  if (oeb->rank == 0 && oea->rank == 0)
>+  if (oea->rank == 0)
> {
>   if (constant_type (oeb->op) != constant_type (oea->op))
>   return constant_type (oeb->op) - constant_type (oea->op);
>@@ -508,51 +511,50 @@ sort_by_operand_rank (const void *pa, co
>   return oeb->id > oea->id ? 1 : -1;
> }
> 
>+  if (TREE_CODE (oea->op) != SSA_NAME)
>+{
>+  if (TREE_CODE (oeb->op) != SSA_NAME)
>+  return oeb->id > oea->id ? 1 : -1;
>+  else
>+  return 1;
>+}
>+  else if (TREE_CODE (oeb->op) != SSA_NAME)
>+return -1;
>+
>   /* Lastly, make sure the versions that are the same go next to each
>  other.  */
>-  if (oeb->rank == oea->rank
>-  && TREE_CODE (oea->op) == SSA_NAME
>-  && TREE_CODE (oeb->op) == SSA_NAME)
>+  if (SSA_NAME_VERSION (oeb->op) != SSA_NAME_VERSION (oea->op))
> {
>-  if (SSA_NAME_VERSION (oeb->op) != SSA_NAME_VERSION (oea->op))
>+  /* As SSA_NAME_VERSION is assigned pretty randomly, because we
>reuse
>+   versions of removed SSA_NAMEs, so if possible, prefer to sort
>+   based on basic block and gimple_uid of the SSA_NAME_DEF_STMT.
>+   See PR60418.  */
>+  gimple *stmta = SSA_NAME_DEF_STMT (oea->op);
>+  gimple *stmtb = SSA_NAME_DEF_STMT (oeb->op);
>+  basic_block bba = gimple_bb (stmta);
>+  basic_block bbb = gimple_bb (stmtb);
>+  if (bbb != bba)
>   {
>-/* As SSA_NAME_VERSION is assigned pretty randomly, because we
>reuse
>-   versions of removed SSA_NAMEs, so if possible, prefer to sort
>-   based on basic block and gimple_uid of the SSA_NAME_DEF_STMT.
>-   See PR60418.  */
>-gimple *stmta = SSA_NAME_DEF_STMT (oea->op);
>-gimple *stmtb = SSA_NAME_DEF_STMT (oeb->op);
>-basic_block bba = gimple_bb (stmta);
>-basic_block bbb = gimple_bb (stmtb);
>-if (bbb != bba)
>-  {
>-/* One of the SSA_NAMEs can be defined in oeN->stmt_to_insert
>-   but the other might not.  */
>-if (!bba)
>-  return 1;
>-if (!bbb)
>-  return -1;
>-/* If neither is, compare bb_rank.  */
>- 

[PATCH] Fix sort_by_operand_rank with qsort checking (PR tree-optimization/82381, #2)

[Jakub Jelinek]

On Tue, Oct 03, 2017 at 01:24:32PM +0300, Alexander Monakov wrote:
> On Tue, 3 Oct 2017, Jakub Jelinek wrote:
> > The qsort cmp transitivity checks may fail with the sort_by_operand_rank
> > comparator, because if one of the operands has stmt_to_insert and the
> > other doesn't (but likely also if one SSA_NAME is (D) and the other is not),
> > we fallthrough into SSA_NAME_VERSION comparison, but if both aren't (D) and
> > both don't have stmt_to_insert, we use different comparison rules.
> 
> When looking at the code I've noticed another issue, so the fix seems
> incomplete (but I don't know if the other problem can/should be fixed
> independently), see below:
> 
> 
> > --- gcc/tree-ssa-reassoc.c.jj   2017-10-02 17:33:14.270282226 +0200
> > +++ gcc/tree-ssa-reassoc.c  2017-10-02 18:18:07.328611132 +0200
> > @@ -514,36 +514,37 @@ sort_by_operand_rank (const void *pa, co
> >&& TREE_CODE (oea->op) == SSA_NAME
> >&& TREE_CODE (oeb->op) == SSA_NAME)
> >  {
> 
> The containing if statement condition reads:
> 
>   if (oeb->rank == oea->rank
>   && TREE_CODE (oea->op) == SSA_NAME
>   && TREE_CODE (oeb->op) == SSA_NAME)
> 
> so as far as I can tell it's possible to have items A, B, C such that
> all have same rank, A and C correspond to SSA_NAMEs and compare C < A,
> but B does not, so comparisons of A or C against B fall down to 
> 
> return oeb->id > oea->id ? 1 : -1;
> 
> and ultimately result in A < B < C < A.

I think it is likely only hypothetical, because get_rank for non-SSA_NAME
should be 0 and thus handled earlier (for SSA_NAME I think rank of 0 is
still possible).

That said, this untested patch reshuffles stuff a little bit, ok for trunk
if it passes testing?

2017-10-03  Jakub Jelinek  

PR tree-optimization/82381
* tree-ssa-reassoc.c (sort_by_operand_rank): Check for different
oeN->rank first.  Return 1 or -1 if one op is SSA_NAME and the other
is not.

--- gcc/tree-ssa-reassoc.c.jj   2017-10-03 13:24:00.0 +0200
+++ gcc/tree-ssa-reassoc.c  2017-10-03 13:41:23.098183270 +0200
@@ -495,10 +495,13 @@ sort_by_operand_rank (const void *pa, co
   const operand_entry *oea = *(const operand_entry *const *)pa;
   const operand_entry *oeb = *(const operand_entry *const *)pb;
 
+  if (oeb->rank != oea->rank)
+return oeb->rank > oea->rank ? 1 : -1;
+
   /* It's nicer for optimize_expression if constants that are likely
- to fold when added/multiplied//whatever are put next to each
+ to fold when added/multiplied/whatever are put next to each
  other.  Since all constants have rank 0, order them by type.  */
-  if (oeb->rank == 0 && oea->rank == 0)
+  if (oea->rank == 0)
 {
   if (constant_type (oeb->op) != constant_type (oea->op))
return constant_type (oeb->op) - constant_type (oea->op);
@@ -508,51 +511,50 @@ sort_by_operand_rank (const void *pa, co
return oeb->id > oea->id ? 1 : -1;
 }
 
+  if (TREE_CODE (oea->op) != SSA_NAME)
+{
+  if (TREE_CODE (oeb->op) != SSA_NAME)
+   return oeb->id > oea->id ? 1 : -1;
+  else
+   return 1;
+}
+  else if (TREE_CODE (oeb->op) != SSA_NAME)
+return -1;
+
   /* Lastly, make sure the versions that are the same go next to each
  other.  */
-  if (oeb->rank == oea->rank
-  && TREE_CODE (oea->op) == SSA_NAME
-  && TREE_CODE (oeb->op) == SSA_NAME)
+  if (SSA_NAME_VERSION (oeb->op) != SSA_NAME_VERSION (oea->op))
 {
-  if (SSA_NAME_VERSION (oeb->op) != SSA_NAME_VERSION (oea->op))
+  /* As SSA_NAME_VERSION is assigned pretty randomly, because we reuse
+versions of removed SSA_NAMEs, so if possible, prefer to sort
+based on basic block and gimple_uid of the SSA_NAME_DEF_STMT.
+See PR60418.  */
+  gimple *stmta = SSA_NAME_DEF_STMT (oea->op);
+  gimple *stmtb = SSA_NAME_DEF_STMT (oeb->op);
+  basic_block bba = gimple_bb (stmta);
+  basic_block bbb = gimple_bb (stmtb);
+  if (bbb != bba)
{
- /* As SSA_NAME_VERSION is assigned pretty randomly, because we reuse
-versions of removed SSA_NAMEs, so if possible, prefer to sort
-based on basic block and gimple_uid of the SSA_NAME_DEF_STMT.
-See PR60418.  */
- gimple *stmta = SSA_NAME_DEF_STMT (oea->op);
- gimple *stmtb = SSA_NAME_DEF_STMT (oeb->op);
- basic_block bba = gimple_bb (stmta);
- basic_block bbb = gimple_bb (stmtb);
- if (bbb != bba)
-   {
- /* One of the SSA_NAMEs can be defined in oeN->stmt_to_insert
-but the other might not.  */
- if (!bba)
-   return 1;
- if (!bbb)
-   return -1;
- /* If neither is, compare bb_rank.  */
- if (bb_rank[bbb->index] != bb_rank[bba->index])
-   return bb_rank[bbb->index] - bb_rank[bba->index];
-   }
-
- bool da = reassoc_stmt_dominates_stmt_p 

Re: [PATCH][GRAPHITE] Test for code generation errors

[Rainer Orth]

Hi Richard,

> What ISL Versions are affected? 

it's 0.18.

>>Besides, there's
>>
>>+UNRESOLVED: gfortran.dg/graphite/pr42393-1.f90   -O  
>>scan-tree-dump-times graphite "code generation error" 1
>>
>>for both 32 and 64-bit.  The log indicates
>>
>>gfortran.dg/graphite/pr42393-1.f90   -O  : dump file does not exist
>>
>>and indeed the test lacks -fdump-tree-graphite-details contrary to
>>ChangeLog.
>
> Oops, I must have missed that one. Will fix tomorrow. 

Fine, thanks.

Rainer

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

Re: [PATCH] Fix sort_by_operand_rank with qsort checking (PR tree-optimization/82381)

[Richard Biener]

On October 3, 2017 12:00:21 PM GMT+02:00, Jakub Jelinek  
wrote:
>Hi!
>
>The qsort cmp transitivity checks may fail with the
>sort_by_operand_rank
>comparator, because if one of the operands has stmt_to_insert and the
>other doesn't (but likely also if one SSA_NAME is (D) and the other is
>not),
>we fallthrough into SSA_NAME_VERSION comparison, but if both aren't (D)
>and
>both don't have stmt_to_insert, we use different comparison rules.
>
>The following patch fixes it, by doing all the checks unconditionally.
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK. Let's fix other things as followup. 

Richard. 

>2017-10-03  Jakub Jelinek  
>
>   PR tree-optimization/82381
>   * tree-ssa-reassoc.c (sort_by_operand_rank): Don't check
>   stmt_to_insert nor wheather SSA_NAMEs are default defs.
>   Return 1 or -1 if one of bba and bbb is NULL. If bb_rank is equal,
>   fallthrough into reassoc_stmt_dominates_stmt_p.
>
>   * gcc.c-torture/compile/pr82381.c: New test.
>
>--- gcc/tree-ssa-reassoc.c.jj  2017-10-02 17:33:14.270282226 +0200
>+++ gcc/tree-ssa-reassoc.c 2017-10-02 18:18:07.328611132 +0200
>@@ -514,36 +514,37 @@ sort_by_operand_rank (const void *pa, co
>   && TREE_CODE (oea->op) == SSA_NAME
>   && TREE_CODE (oeb->op) == SSA_NAME)
> {
>-  /* As SSA_NAME_VERSION is assigned pretty randomly, because we
>reuse
>-   versions of removed SSA_NAMEs, so if possible, prefer to sort
>-   based on basic block and gimple_uid of the SSA_NAME_DEF_STMT.
>-   See PR60418.  */
>-  if (!SSA_NAME_IS_DEFAULT_DEF (oea->op)
>-&& !SSA_NAME_IS_DEFAULT_DEF (oeb->op)
>-&& !oea->stmt_to_insert
>-&& !oeb->stmt_to_insert
>-&& SSA_NAME_VERSION (oeb->op) != SSA_NAME_VERSION (oea->op))
>+  if (SSA_NAME_VERSION (oeb->op) != SSA_NAME_VERSION (oea->op))
>   {
>+/* As SSA_NAME_VERSION is assigned pretty randomly, because we
>reuse
>+   versions of removed SSA_NAMEs, so if possible, prefer to sort
>+   based on basic block and gimple_uid of the SSA_NAME_DEF_STMT.
>+   See PR60418.  */
> gimple *stmta = SSA_NAME_DEF_STMT (oea->op);
> gimple *stmtb = SSA_NAME_DEF_STMT (oeb->op);
> basic_block bba = gimple_bb (stmta);
> basic_block bbb = gimple_bb (stmtb);
> if (bbb != bba)
>   {
>+/* One of the SSA_NAMEs can be defined in oeN->stmt_to_insert
>+   but the other might not.  */
>+if (!bba)
>+  return 1;
>+if (!bbb)
>+  return -1;
>+/* If neither is, compare bb_rank.  */
> if (bb_rank[bbb->index] != bb_rank[bba->index])
>   return bb_rank[bbb->index] - bb_rank[bba->index];
>   }
>-else
>-  {
>-bool da = reassoc_stmt_dominates_stmt_p (stmta, stmtb);
>-bool db = reassoc_stmt_dominates_stmt_p (stmtb, stmta);
>-if (da != db)
>-  return da ? 1 : -1;
>-  }
>-  }
> 
>-  if (SSA_NAME_VERSION (oeb->op) != SSA_NAME_VERSION (oea->op))
>-  return SSA_NAME_VERSION (oeb->op) > SSA_NAME_VERSION (oea->op) ? 1 :
>-1;
>+bool da = reassoc_stmt_dominates_stmt_p (stmta, stmtb);
>+bool db = reassoc_stmt_dominates_stmt_p (stmtb, stmta);
>+if (da != db)
>+  return da ? 1 : -1;
>+
>+return (SSA_NAME_VERSION (oeb->op) > SSA_NAME_VERSION (oea->op)
>+? 1 : -1);
>+  }
>   else
>   return oeb->id > oea->id ? 1 : -1;
> }
>--- gcc/testsuite/gcc.c-torture/compile/pr82381.c.jj   2017-10-02
>18:13:51.532715601 +0200
>+++ gcc/testsuite/gcc.c-torture/compile/pr82381.c  2017-10-02
>18:13:51.532715601 +0200
>@@ -0,0 +1,18 @@
>+/* PR tree-optimization/82381 */
>+/* { dg-do compile } */
>+
>+signed char b, h;
>+unsigned short c, e;
>+short int d, f, g;
>+
>+void
>+foo ()
>+{
>+  if (h)
>+{
>+  short a = -(d + c - b);
>+  f = e - a - -d;
>+}
>+  if (c)
>+g = 0;
>+}
>
>   Jakub

Re: [PATCH][GRAPHITE] Test for code generation errors

[Richard Biener]

On October 3, 2017 11:48:35 AM GMT+02:00, Rainer Orth 
 wrote:
>Hi Richard,
>
>> The following patch adjust GRAPHITE testing to check that existing
>> code generation issues occur and makes code generation ICE with
>> -fchecking --param graphite-allow-codegen-errors=0.  The param
>> is really a testsuite artifact so we can have testcases with
>> issues where we have papered over GRAPHITE issues with aborting
>> code generation.
>>
>> This avoids regressing testcases that do not show code generation
>> issues and it allows detecting testcases that no longer show
>> code generation issues (so we can avoid regressing that feat later).
>>
>> I'm now working on code-generation issues so that's an important
>> feature for me.
>>
>> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to
>trunk.
>>
>> Richard.
>>
>> 2017-10-02  Richard Biener  
>>
>>  * graphite-isl-ast-to-gimple.c (set_codegen_error): With
>>  -fchecking and --param graphite-allow-codegen-errors=0 ICE.
>>  * params.def (PARAM_GRAPHITE_ALLOW_CODEGEN_ERRORS): New param.
>>
>>  * gcc.dg/graphite/graphite.exp: Add -fdump-tree-graphite-details.
>>  * gcc.dg/graphite/id-16.c: Adjust for existing codegen errors.
>>  * gcc.dg/graphite/pr46168.c: Likewise.
>>  * gcc.dg/graphite/pr68756.c: Likewise.
>>  * gcc.dg/graphite/pr69728.c: Likewise.
>>  * gcc.dg/graphite/pr71575-2.c: Likewise.
>>  * gcc.dg/graphite/pr77362.c: Likewise.
>>  * gcc.dg/graphite/pr81373.c: Likewise.
>>  * gcc.dg/graphite/run-id-pr67700-1.c: Likewise.
>>  * gfortran.dg/graphite/interchange-1.f: Likewise.
>>  * gfortran.dg/graphite/pr29581.f90: Likewise.
>>  * gfortran.dg/graphite/pr42334-1.f: Likewise.
>>  * gfortran.dg/graphite/pr42393-1.f90: Likewise.
>>  * gfortran.dg/graphite/pr42393.f90: Likewise.
>>  * gfortran.dg/graphite/pr47019.f: Likewise.
>
>the patch caused a couple of regressions, unfortunately.  E.g.
>
>+FAIL: gfortran.dg/graphite/id-17.f   -O  (internal compiler error)
>+FAIL: gfortran.dg/graphite/id-17.f   -O  (test for excess errors)
>
>Excess errors:
>during GIMPLE pass: graphite
>/vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/graphite/id-17.f:1:0:
>internal compiler error: in set_codegen_error, at
>graphite-isl-ast-to-gimple.c:248
>0x10d5ebb translate_isl_ast_to_gimple::set_codegen_error()
>   /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:247
>0x10d0023 translate_isl_ast_to_gimple::set_codegen_error()
>   /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:247
>0x10d0023 translate_isl_ast_to_gimple::get_rename_from_scev(tree_node*,
>gimple**, loop*, basic_block_def*, basic_block_def*, vecva_heap, vl_ptr>)
>  /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:1510
>0x10d2963 translate_isl_ast_to_gimple::rename_uses(gimple*,
>gimple_stmt_iterator*, basic_block_def*, loop*, vecva_heap, vl_ptr>)
>  /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:1644
>0x10d4217
>translate_isl_ast_to_gimple::graphite_copy_stmts_from_block(basic_block_def*,
>basic_block_def*, vec)
>  /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:2516
>0x10d4653
>translate_isl_ast_to_gimple::copy_bb_and_scalar_dependences(basic_block_def*,
>edge_def*, vec)
>  /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:2717
>0x10d4ecb
>translate_isl_ast_to_gimple::translate_isl_ast_node_user(isl_ast_node*,
>edge_def*, std::map,
>std::allocator > >&)
>   /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:835
>0x10d5147
>translate_isl_ast_to_gimple::translate_isl_ast_for_loop(loop*,
>isl_ast_node*, edge_def*, tree_node*, tree_node*, tree_node*,
>std::map,
>std::allocator > >&)
>   /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:649
>0x10d53ab
>translate_isl_ast_to_gimple::translate_isl_ast_node_for(loop*,
>isl_ast_node*, edge_def*, std::mapstd::less, std::allocator
>> >&)
>   /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:752
>0x10d5477
>translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*,
>isl_ast_node*, edge_def*, std::mapstd::less, std::allocator
>> >&)
>   /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:864
>0x10d5147
>translate_isl_ast_to_gimple::translate_isl_ast_for_loop(loop*,
>isl_ast_node*, edge_def*, tree_node*, tree_node*, tree_node*,
>std::map,
>std::allocator > >&)
>   /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:649
>0x10d53ab

Re: [PATCH] Fix sort_by_operand_rank with qsort checking (PR tree-optimization/82381)

[Alexander Monakov]

On Tue, 3 Oct 2017, Jakub Jelinek wrote:
> The qsort cmp transitivity checks may fail with the sort_by_operand_rank
> comparator, because if one of the operands has stmt_to_insert and the
> other doesn't (but likely also if one SSA_NAME is (D) and the other is not),
> we fallthrough into SSA_NAME_VERSION comparison, but if both aren't (D) and
> both don't have stmt_to_insert, we use different comparison rules.

When looking at the code I've noticed another issue, so the fix seems
incomplete (but I don't know if the other problem can/should be fixed
independently), see below:


> --- gcc/tree-ssa-reassoc.c.jj 2017-10-02 17:33:14.270282226 +0200
> +++ gcc/tree-ssa-reassoc.c2017-10-02 18:18:07.328611132 +0200
> @@ -514,36 +514,37 @@ sort_by_operand_rank (const void *pa, co
>&& TREE_CODE (oea->op) == SSA_NAME
>&& TREE_CODE (oeb->op) == SSA_NAME)
>  {

The containing if statement condition reads:

  if (oeb->rank == oea->rank
  && TREE_CODE (oea->op) == SSA_NAME
  && TREE_CODE (oeb->op) == SSA_NAME)

so as far as I can tell it's possible to have items A, B, C such that
all have same rank, A and C correspond to SSA_NAMEs and compare C < A,
but B does not, so comparisons of A or C against B fall down to 

return oeb->id > oea->id ? 1 : -1;

and ultimately result in A < B < C < A.

Alexander

[PATCH] Fix sort_by_operand_rank with qsort checking (PR tree-optimization/82381)

[Jakub Jelinek]

Hi!

The qsort cmp transitivity checks may fail with the sort_by_operand_rank
comparator, because if one of the operands has stmt_to_insert and the
other doesn't (but likely also if one SSA_NAME is (D) and the other is not),
we fallthrough into SSA_NAME_VERSION comparison, but if both aren't (D) and
both don't have stmt_to_insert, we use different comparison rules.

The following patch fixes it, by doing all the checks unconditionally.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2017-10-03  Jakub Jelinek  

PR tree-optimization/82381
* tree-ssa-reassoc.c (sort_by_operand_rank): Don't check
stmt_to_insert nor wheather SSA_NAMEs are default defs.
Return 1 or -1 if one of bba and bbb is NULL. If bb_rank is equal,
fallthrough into reassoc_stmt_dominates_stmt_p.

* gcc.c-torture/compile/pr82381.c: New test.

--- gcc/tree-ssa-reassoc.c.jj   2017-10-02 17:33:14.270282226 +0200
+++ gcc/tree-ssa-reassoc.c  2017-10-02 18:18:07.328611132 +0200
@@ -514,36 +514,37 @@ sort_by_operand_rank (const void *pa, co
   && TREE_CODE (oea->op) == SSA_NAME
   && TREE_CODE (oeb->op) == SSA_NAME)
 {
-  /* As SSA_NAME_VERSION is assigned pretty randomly, because we reuse
-versions of removed SSA_NAMEs, so if possible, prefer to sort
-based on basic block and gimple_uid of the SSA_NAME_DEF_STMT.
-See PR60418.  */
-  if (!SSA_NAME_IS_DEFAULT_DEF (oea->op)
- && !SSA_NAME_IS_DEFAULT_DEF (oeb->op)
- && !oea->stmt_to_insert
- && !oeb->stmt_to_insert
- && SSA_NAME_VERSION (oeb->op) != SSA_NAME_VERSION (oea->op))
+  if (SSA_NAME_VERSION (oeb->op) != SSA_NAME_VERSION (oea->op))
{
+ /* As SSA_NAME_VERSION is assigned pretty randomly, because we reuse
+versions of removed SSA_NAMEs, so if possible, prefer to sort
+based on basic block and gimple_uid of the SSA_NAME_DEF_STMT.
+See PR60418.  */
  gimple *stmta = SSA_NAME_DEF_STMT (oea->op);
  gimple *stmtb = SSA_NAME_DEF_STMT (oeb->op);
  basic_block bba = gimple_bb (stmta);
  basic_block bbb = gimple_bb (stmtb);
  if (bbb != bba)
{
+ /* One of the SSA_NAMEs can be defined in oeN->stmt_to_insert
+but the other might not.  */
+ if (!bba)
+   return 1;
+ if (!bbb)
+   return -1;
+ /* If neither is, compare bb_rank.  */
  if (bb_rank[bbb->index] != bb_rank[bba->index])
return bb_rank[bbb->index] - bb_rank[bba->index];
}
- else
-   {
- bool da = reassoc_stmt_dominates_stmt_p (stmta, stmtb);
- bool db = reassoc_stmt_dominates_stmt_p (stmtb, stmta);
- if (da != db)
-   return da ? 1 : -1;
-   }
-   }
 
-  if (SSA_NAME_VERSION (oeb->op) != SSA_NAME_VERSION (oea->op))
-   return SSA_NAME_VERSION (oeb->op) > SSA_NAME_VERSION (oea->op) ? 1 : -1;
+ bool da = reassoc_stmt_dominates_stmt_p (stmta, stmtb);
+ bool db = reassoc_stmt_dominates_stmt_p (stmtb, stmta);
+ if (da != db)
+   return da ? 1 : -1;
+
+ return (SSA_NAME_VERSION (oeb->op) > SSA_NAME_VERSION (oea->op)
+ ? 1 : -1);
+   }
   else
return oeb->id > oea->id ? 1 : -1;
 }
--- gcc/testsuite/gcc.c-torture/compile/pr82381.c.jj2017-10-02 
18:13:51.532715601 +0200
+++ gcc/testsuite/gcc.c-torture/compile/pr82381.c   2017-10-02 
18:13:51.532715601 +0200
@@ -0,0 +1,18 @@
+/* PR tree-optimization/82381 */
+/* { dg-do compile } */
+
+signed char b, h;
+unsigned short c, e;
+short int d, f, g;
+
+void
+foo ()
+{
+  if (h)
+{
+  short a = -(d + c - b);
+  f = e - a - -d;
+}
+  if (c)
+g = 0;
+}

Jakub

[committed] Fix combiner ICE with unconditional traps (PR target/82386)

[Jakub Jelinek]

Hi!

LOG_LINKS normally are just within a basic block and various parts of
the combiner assume that this_basic_block is the basic block where all the
i[3210] insns are residing.  Except when we turn a conditional trap into
an unconditional one, we split the block during try_combine and then we can
have LOG_LINKS from the dead basic block after the unconditional trap to the
first part, so this_basic_block might not contain some or all of the
instructions anymore.  This patch fixes it by not trying to optimize
anything in dead basic blocks, we are going to remove them as unreachable
during cfg cleanup anyway.

Bootstrapped/regtested on x86_64-linux, i686-linux, powerpc64-linux (tested
with -m32/-m64), preapproved by Segher in the PR, committed to trunk.

2017-10-03  Jakub Jelinek  

PR target/82386
* combine.c (combine_instructions): Don't combine in unreachable
basic blocks.

* gcc.dg/pr82386.c: New test.

--- gcc/combine.c.jj2017-09-15 17:53:28.0 +0200
+++ gcc/combine.c   2017-10-02 16:04:13.652991681 +0200
@@ -1232,6 +1232,12 @@ combine_instructions (rtx_insn *f, unsig
   FOR_EACH_BB_FN (this_basic_block, cfun)
 {
   rtx_insn *last_combined_insn = NULL;
+
+  /* Ignore instruction combination in basic blocks that are going to
+be removed as unreachable anyway.  See PR82386.  */
+  if (EDGE_COUNT (this_basic_block->preds) == 0)
+   continue;
+
   optimize_this_for_speed_p = optimize_bb_for_speed_p (this_basic_block);
   last_call_luid = 0;
   mem_last_set = -1;
--- gcc/testsuite/gcc.dg/pr82386.c.jj   2017-10-02 16:13:03.345490374 +0200
+++ gcc/testsuite/gcc.dg/pr82386.c  2017-10-02 16:12:20.0 +0200
@@ -0,0 +1,38 @@
+/* PR target/82386 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -w" } */
+/* { dg-additional-options "-misel" { target powerpc*-*-* } } */
+
+long long int fs;
+int vm;
+
+void
+sd (void)
+{
+  fs = 1;
+  vm = 2;
+  goto zf;
+
+  if (0)
+{
+  int y6 = 0;
+  int *uu = 
+  short int he;
+  int of = 0;
+
+ zf:
+  for (;;)
+  {
+  he = of;
+  if (he || (fs |= vm))
+{
+  *uu = fs;
+  fs += vm;
+}
+  if (y6 == vm)
+fs |= he;
+  he = y6 || fs;
+  fs /= 0;
+}
+}
+}

Jakub

Re: [PATCH][GRAPHITE] Test for code generation errors

[Rainer Orth]

Hi Richard,

> The following patch adjust GRAPHITE testing to check that existing
> code generation issues occur and makes code generation ICE with
> -fchecking --param graphite-allow-codegen-errors=0.  The param
> is really a testsuite artifact so we can have testcases with
> issues where we have papered over GRAPHITE issues with aborting
> code generation.
>
> This avoids regressing testcases that do not show code generation
> issues and it allows detecting testcases that no longer show
> code generation issues (so we can avoid regressing that feat later).
>
> I'm now working on code-generation issues so that's an important
> feature for me.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
>
> Richard.
>
> 2017-10-02  Richard Biener  
>
>   * graphite-isl-ast-to-gimple.c (set_codegen_error): With
>   -fchecking and --param graphite-allow-codegen-errors=0 ICE.
>   * params.def (PARAM_GRAPHITE_ALLOW_CODEGEN_ERRORS): New param.
>
>   * gcc.dg/graphite/graphite.exp: Add -fdump-tree-graphite-details.
>   * gcc.dg/graphite/id-16.c: Adjust for existing codegen errors.
>   * gcc.dg/graphite/pr46168.c: Likewise.
>   * gcc.dg/graphite/pr68756.c: Likewise.
>   * gcc.dg/graphite/pr69728.c: Likewise.
>   * gcc.dg/graphite/pr71575-2.c: Likewise.
>   * gcc.dg/graphite/pr77362.c: Likewise.
>   * gcc.dg/graphite/pr81373.c: Likewise.
>   * gcc.dg/graphite/run-id-pr67700-1.c: Likewise.
>   * gfortran.dg/graphite/interchange-1.f: Likewise.
>   * gfortran.dg/graphite/pr29581.f90: Likewise.
>   * gfortran.dg/graphite/pr42334-1.f: Likewise.
>   * gfortran.dg/graphite/pr42393-1.f90: Likewise.
>   * gfortran.dg/graphite/pr42393.f90: Likewise.
>   * gfortran.dg/graphite/pr47019.f: Likewise.

the patch caused a couple of regressions, unfortunately.  E.g.

+FAIL: gfortran.dg/graphite/id-17.f   -O  (internal compiler error)
+FAIL: gfortran.dg/graphite/id-17.f   -O  (test for excess errors)

Excess errors:
during GIMPLE pass: graphite
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/graphite/id-17.f:1:0: 
internal compiler error: in set_codegen_error, at 
graphite-isl-ast-to-gimple.c:248
0x10d5ebb translate_isl_ast_to_gimple::set_codegen_error()
/vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:247
0x10d0023 translate_isl_ast_to_gimple::set_codegen_error()
/vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:247
0x10d0023 translate_isl_ast_to_gimple::get_rename_from_scev(tree_node*, 
gimple**, loop*, basic_block_def*, basic_block_def*, vec)
/vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:1510
0x10d2963 translate_isl_ast_to_gimple::rename_uses(gimple*, 
gimple_stmt_iterator*, basic_block_def*, loop*, vec)
/vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:1644
0x10d4217 
translate_isl_ast_to_gimple::graphite_copy_stmts_from_block(basic_block_def*, 
basic_block_def*, vec)
/vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:2516
0x10d4653 
translate_isl_ast_to_gimple::copy_bb_and_scalar_dependences(basic_block_def*, 
edge_def*, vec)
/vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:2717
0x10d4ecb 
translate_isl_ast_to_gimple::translate_isl_ast_node_user(isl_ast_node*, 
edge_def*, std::map, 
std::allocator > >&)
/vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:835
0x10d5147 translate_isl_ast_to_gimple::translate_isl_ast_for_loop(loop*, 
isl_ast_node*, edge_def*, tree_node*, tree_node*, tree_node*, std::map, std::allocator > >&)
/vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:649
0x10d53ab translate_isl_ast_to_gimple::translate_isl_ast_node_for(loop*, 
isl_ast_node*, edge_def*, std::map, 
std::allocator > >&)
/vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:752
0x10d5477 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*, 
isl_ast_node*, edge_def*, std::map, 
std::allocator > >&)
/vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:864
0x10d5147 translate_isl_ast_to_gimple::translate_isl_ast_for_loop(loop*, 
isl_ast_node*, edge_def*, tree_node*, tree_node*, tree_node*, std::map, std::allocator > >&)
/vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:649
0x10d53ab translate_isl_ast_to_gimple::translate_isl_ast_node_for(loop*, 
isl_ast_node*, edge_def*, std::map, 

Re: [PATCH] Pretty-print GOACC_REDUCTION arguments

[Tom de Vries]

On 09/27/2017 03:46 PM, Thomas Schwinge wrote:

Hi!

On Mon, 25 Sep 2017 16:57:52 +0200, Tom de Vries  wrote:

currently for a GOACC_REDUCTION internal fn call we print:
...
sum_5 = GOACC_REDUCTION (SETUP, _3, 0, 0, 67, 0);
...

This patch adds a comment for some arguments explaining the meaning of
the argument:
...
sum_5 = GOACC_REDUCTION (SETUP, _3, 0, 0 /*gang*/, 67 /*+*/, 0);
...


ACK to the general idea.

However, I note that for the "CODE" we currently *only* print the textual
variant ("SETUP") (just like we're also doing for a few other "IFN_*"),
whereas for "LEVEL" and "OP" you now print both.  Should these really be
different?  I think I actually do prefer the style you're using (print
both).


I chose the c-like syntax to make it easier to copy gimple to test-case 
( based on comment 
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg02180.html ). But 
reflecting on it a bit more, I realized that it's an internal function 
and as such won't work anyway in test-cases, so I'm not sure how 
relevant it is in this case.



I would print the actual "GOMP_DIM_GANG" instead of "gang" etc.,
to make it easier to see where these values are coming from.



Done.


OK for trunk, if testing is ok?




+ case IFN_GOACC_REDUCTION:
+   switch (i)
+ {
+ case 3:
+   switch (tree_to_uhwi (gimple_call_arg (gs, i)))


Something ;-) is wrong.  Running this on
libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-1.c, I run into:

 during GIMPLE pass: omplower
 dump file: reduction-1.c.006t.omplower
 
 In file included from source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-1.c:9:0:

 source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-1.c: In 
function 'test_reductions':
 source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction.h:20:7: 
internal compiler error: in tree_to_uhwi, at tree.c:6606
abort ();\



This seems to be the "LEVEL" being "-1" -- probably meaning "not yet
decided"?  (Haven't looked that up.)



In execute_oacc_device_lower we find:
...
  case IFN_GOACC_REDUCTION:
/* Mark the function for SSA renaming.  */
mark_virtual_operands_for_renaming (cfun);

/* If the level is -1, this ended up being an unused 


   axis.  Handle as a default.  */
if (integer_minus_onep (gimple_call_arg (call, 3)))
  default_goacc_reduction (call);
else
  targetm.goacc.reduction (call);
...

I'm printing it now as GOMP_DIM_NONE.

Bootstrapped and reg-tested on x86_64.

OK for trunk?

Thanks,
- Tom
Pretty-print GOACC_REDUCTION arguments

Prints
  sum_5 = GOACC_REDUCTION (SETUP, _3, 0, 0 /*GOMP_DIM_GANG*/, 67 /*+*/, 0);
instead of
  sum_5 = GOACC_REDUCTION (SETUP, _3, 0, 0, 67, 0);

2017-09-25  Tom de Vries  

	* gimple-pretty-print.c (dump_gimple_call_args): Pretty-print
	GOACC_REDUCTION arguments.

---
 gcc/gimple-pretty-print.c | 42 ++
 1 file changed, 42 insertions(+)

diff --git a/gcc/gimple-pretty-print.c b/gcc/gimple-pretty-print.c
index ed8e51c..33ca45d 100644
--- a/gcc/gimple-pretty-print.c
+++ b/gcc/gimple-pretty-print.c
@@ -41,6 +41,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "stringpool.h"
 #include "attribs.h"
 #include "asan.h"
+#include "gomp-constants.h"
 
 #define INDENT(SPACE)			\
   do { int i; for (i = 0; i < SPACE; i++) pp_space (buffer); } while (0)
@@ -765,6 +766,47 @@ dump_gimple_call_args (pretty_printer *buffer, gcall *gs, dump_flags_t flags)
   if (i)
 	pp_string (buffer, ", ");
   dump_generic_node (buffer, gimple_call_arg (gs, i), 0, flags, false);
+
+  if (gimple_call_internal_p (gs))
+	switch (gimple_call_internal_fn (gs))
+	  {
+	  case IFN_GOACC_REDUCTION:
+	switch (i)
+	  {
+	  case 3:
+		switch (tree_to_shwi (gimple_call_arg (gs, i)))
+		  {
+		  case GOMP_DIM_GANG:
+		pp_string (buffer, " /*GOMP_DIM_GANG*/");
+		break;
+		  case GOMP_DIM_WORKER:
+		pp_string (buffer, " /*GOMP_DIM_WORKER*/");
+		break;
+		  case GOMP_DIM_VECTOR:
+		pp_string (buffer, " /*GOMP_DIM_VECTOR*/");
+		break;
+		  case -1:
+		pp_string (buffer, " /*GOMP_DIM_NONE*/");
+		break;
+		  default:
+		gcc_unreachable ();
+		  }
+		break;
+	  case 4:
+		{
+		  enum tree_code rcode
+		= (enum tree_code)tree_to_shwi (gimple_call_arg (gs, i));
+		  pp_string (buffer, " /*");
+		  pp_string (buffer, op_symbol_code (rcode));
+		  pp_string (buffer, "*/");
+		}
+		break;
+	  default:
+		break;
+	  }
+	  default:
+	break;
+	  }
 }
 
   if (gimple_call_va_arg_pack_p (gs))

GCC 5.5 Status Report (2017-10-02), branch frozen for release

[Jakub Jelinek]

Status
==

The 5.5 branch is now frozen for the final GCC 5.5 release, the release
candidate has been announced.  All changes to the branch require RM
approval.


Quality Data


Priority  #   Change from last report
---   ---
P10
P2  227   -   2
P3   13   +   1
P4   99
P5   27
---   ---
Total P1-P3 240   -   1
Total   366   -   1


Previous Report
===

https://gcc.gnu.org/ml/gcc/2017-09/msg00171.html

[PATCH,AIX] Manage Go Closure in libffi for AIX

[REIX, Tony]

Description:
 * This patch provides changes in libffi for providing the Go closure on AIX.

Tests:
 * AIX: Build of GCC 8 trunk: SUCCESS
   - build made by means of gmake.

ChangeLog:
  * src/powerpc/aix.S (ffi_call_AIX): Add debugging pseudo-op and labels 
for EH.
(ffi_call_go_AIX): New function.
(_GLOBAL__F_libffi_src_powerpc_aix): EH frame.
  * src/powerpc/aix_closure.S (ffi_closure_ASM): Add debugging pseudo-op 
and labels for EH.
(ffi_go_closure_ASM): New function.
(_GLOBAL__F_libffi_src_powerpc_aix_closure): EH frame.
  * src/powrpc/ffi_darwin.c (ffi_call_go): New function.
(ffi_prep_go_closure): New function.
(ffi_closure_helper_common): Rename from ffi_closure_helper_DARWIN.
(ffi_closure_helper_DARWIN): Call ffi_closure_helper_common.
(ffi_go_closure_helper_DARWIN): Call ffi_closure_helper_common.
  * src/powerpc/ffitarget.h (FFI_GO_CLOSURES): Define.


Cordialement,

Tony Reix

Bull - ATOS
IBM Coop Architect & Technical Leader

Office : +33 (0) 4 76 29 72 67
1 rue de Provence - 38432 Échirolles - France
www.atos.netIndex: libffi/ChangeLog
===
--- ./libffi/ChangeLog	(revision 253377)
+++ ./libffi/ChangeLog	(working copy)
@@ -1,3 +1,18 @@
+2017-08-31  Tony Reix  
+
+	* src/powerpc/aix.S (ffi_call_AIX): Add debugging pseudo-op and labels for EH.
+	(ffi_call_go_AIX): New function.
+	(_GLOBAL__F_libffi_src_powerpc_aix): EH frame.
+	* src/powerpc/aix_closure.S (ffi_closure_ASM): Add debugging pseudo-op and labels for EH.
+	(ffi_go_closure_ASM): New function.
+	(_GLOBAL__F_libffi_src_powerpc_aix_closure): EH frame.
+	* src/powrpc/ffi_darwin.c (ffi_call_go): New function.
+	(ffi_prep_go_closure): New function.
+	(ffi_closure_helper_common): Rename from ffi_closure_helper_DARWIN.
+	(ffi_closure_helper_DARWIN): Call ffi_closure_helper_common.
+	(ffi_go_closure_helper_DARWIN): Call ffi_closure_helper_common.
+	* src/powerpc/ffitarget.h (FFI_GO_CLOSURES): Define.
+
 2017-01-21  Jakub Jelinek  
 
 	PR other/79046
Index: libffi/src/powerpc/aix.S
===
--- ./libffi/src/powerpc/aix.S	(revision 253377)
+++ ./libffi/src/powerpc/aix.S	(working copy)
@@ -106,6 +106,10 @@ ffi_call_AIX:
 	.llong .ffi_call_AIX, TOC[tc0], 0
 	.csect .text[PR]
 .ffi_call_AIX:
+	.function .ffi_call_AIX,.ffi_call_AIX,16,044,LFE..0-LFB..0
+	.bf __LINE__
+	.line 1
+LFB..0:
 	/* Save registers we use.  */
 	mflr	r0
 
@@ -115,8 +119,10 @@ ffi_call_AIX:
 	std	r31, -8(r1)
 
 	std	r0, 16(r1)
+LCFI..0:
 	mr	r28, r1		/* our AP.  */
 	stdux	r1, r1, r4
+LCFI..1:
 
 	/* Save arguments over call...  */
 	mr	r31, r5	/* flags, */
@@ -202,12 +208,16 @@ L(fp_return_value):
 L(float_return_value):
 	stfs	f1, 0(r30)
 	b	L(done_return_value)
-
+LFE..0:
 #else /* ! __64BIT__ */
 	
 	.long .ffi_call_AIX, TOC[tc0], 0
 	.csect .text[PR]
 .ffi_call_AIX:
+	.function .ffi_call_AIX,.ffi_call_AIX,16,044,LFE..0-LFB..0
+	.bf __LINE__
+	.line 1
+LFB..0:
 	/* Save registers we use.  */
 	mflr	r0
 
@@ -217,8 +227,10 @@ L(float_return_value):
 	stw	r31, -4(r1)
 
 	stw	r0, 8(r1)
+LCFI..0:
 	mr	r28, r1		/* out AP.  */
 	stwux	r1, r1, r4
+LCFI..1:
 
 	/* Save arguments over call...  */
 	mr	r31, r5	/* flags, */
@@ -304,13 +316,146 @@ L(fp_return_value):
 L(float_return_value):
 	stfs	f1, 0(r30)
 	b	L(done_return_value)
+LFE..0:
 #endif
+	.ef __LINE__
 	.long 0
 	.byte 0,0,0,1,128,4,0,0
 /* END(ffi_call_AIX) */
 
+	/* void ffi_call_go_AIX(extended_cif *ecif, unsigned long bytes,
+	 *		unsigned int flags, unsigned int *rvalue,
+	 *		void (*fn)(),
+	 *		void (*prep_args)(extended_cif*, unsigned *const),
+	 *  void *closure);
+	 * r3=ecif, r4=bytes, r5=flags, r6=rvalue, r7=fn, r8=prep_args, r9=closure
+	 */
+
 .csect .text[PR]
 	.align 2
+	.globl ffi_call_go_AIX
+	.globl .ffi_call_go_AIX
+.csect ffi_call_go_AIX[DS]
+ffi_call_go_AIX:
+#ifdef __64BIT__
+	.llong .ffi_call_go_AIX, TOC[tc0], 0
+	.csect .text[PR]
+.ffi_call_go_AIX:
+	.function .ffi_call_go_AIX,.ffi_call_go_AIX,16,044,LFE..1-LFB..1
+	.bf __LINE__
+	.line 1
+LFB..1:
+	/* Save registers we use.  */
+	mflr	r0
+
+	std	r28,-32(r1)
+	std	r29,-24(r1)
+	std	r30,-16(r1)
+	std	r31, -8(r1)
+
+	std	r9, 8(r1)	/* closure, saved in cr field. */
+	std	r0, 16(r1)
+LCFI..2:
+	mr	r28, r1		/* our AP.  */
+	stdux	r1, r1, r4
+LCFI..3:
+
+	/* Save arguments over call...  */
+	mr	r31, r5	/* flags, */
+	mr	r30, r6	/* rvalue, */
+	mr	r29, r7	/* function address,  */
+	std	r2, 40(r1)
+
+	/* Call ffi_prep_args.  */
+	mr	r4, r1
+	bl	.ffi_prep_args
+	nop
+
+	/* Now do the call.  */
+	ld	r0, 0(r29)
+	ld	r2, 8(r29)
+	ld  r11, 8(r28)	/* closure */
+	/* Set up cr1 with bits 4-7 of the flags.  */
+	mtcrf	0x40, r31
+	mtctr	r0
+	/* Load all those argument registers.  */
+	/* We have set up a nice stack frame, just load it into registers. */
+	ld	r3, 40+(1*8)(r1)
+	ld	r4,