[Bug tree-optimization/84047] [6/7/8 Regression] missing -Warray-bounds on an out-of-bounds index into an array

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de  ---
On Thu, 19 Jul 2018, msebor at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84047
> 
> Martin Sebor  changed:
> 
>What|Removed |Added
> 
>  Status|NEW |ASSIGNED
>Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
> gnu.org
> Summary|[6/7/8/9 Regression]|[6/7/8 Regression] missing
>|missing -Warray-bounds on   |-Warray-bounds on an
>|an out-of-bounds index into |out-of-bounds index into an
>|an array|array
> 
> --- Comment #9 from Martin Sebor  ---
> Committed into GCC 9.0 in r262893.  All the test cases in this bug are now
> diagnosed.  Not sure if the fix will be approved for backporting though.

Please do not backport patches that re-introduce (possibly 
false-positive) warnings, at least for such long-standing "regressions"
like this.

[Bug target/86589] [8 regression] gcc.target/powerpc/altivec-7-le.c and gcc.target/powerpc/vsx-7-be.c fail starting with r262440

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 CC||rguenth at gcc dot gnu.org
  Known to work||8.1.0
   Target Milestone|--- |8.2

--- Comment #1 from Richard Biener  ---
I suppose 8.1.0 worked?

[Bug libstdc++/86603] New: `__cpp_lib_list_remove_return_type` misplaced in the header

[ensadc at mailnesia dot com]

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

Bug ID: 86603
   Summary: `__cpp_lib_list_remove_return_type` misplaced in the
 header
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ensadc at mailnesia dot com
CC: redi at gcc dot gnu.org
  Target Milestone: ---

In , __cpp_lib_list_remove_return_type is defined when __cplusplus ==
201703. This is inconsistent with  and , where the macro is
defined (and the corresponding feature is enabled) only in C++2a mode.

[Bug tree-optimization/86604] New: Compiler can't think of smaller variable ranges

[mcccs at gmx dot com]

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

Bug ID: 86604
   Summary: Compiler can't think of smaller variable ranges
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mcccs at gmx dot com
  Target Milestone: ---

Summary: The compiler thinks variables as of the widest domain.
(32 bits for int, 64 bits for int64_t) It's possible to optimize
further by giving the compiler a hint about the domain. It can
be used to eliminate most of the branches.

For clarity, I'm going to define __builtin_guarantee first.

#define __builtin_guarantee(a) \
if (!(a)) {\
__builtin_unreachable();   \
}

The optimization: We can tell the compiler about the range
of a parameter, and it'll be able to use this knowledge
to eliminate most of the branches.

void CreateChecksum(int isTestNet, int *t) {
if (isTestNet == 0)
*t += 1;
}

Output with `-Ofast -march=native`:

CreateChecksum:
  test edi, edi
  jne .L3
  inc DWORD PTR [rsi]
.L3:
  ret

But if we could do that:

void CreateChecksum(int isTestNet, int *t) {
__builtin_guarantee(isTestNet == 0 || isTestNet == 1);
if (isTestNet == 0)
*t += 1;
}

It'd see that

*t += isTestNet ^ 1

But for some reason, Compiler doesn't limit the number of
possibilities of variables according to builtin unreachable.

[Bug c++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

[s_gccbugzilla at nedprod dot com]

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

Niall Douglas  changed:

   What|Removed |Added

Summary|Codegen regression when |Codegen is poor when
   |passing std::string by  |passing std::string by
   |value in C++ 17 and C++ 20  |value with
   ||_GLIBCXX_EXTERN_TEMPLATE
   ||undefined

--- Comment #4 from Niall Douglas  ---
Title made more accurate as per Jonathan's request

[Bug tree-optimization/86504] vectorization failure for a nest loop

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||rsandifo at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
About to post a patch.

[Bug target/86592] [9 regression] gcc.target/powerpc/p8-vec-xl-xst-v2.c fails starting with r261510

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug target/86591] [9 regression] gcc.target/powerpc/builtins-1.c fails starting with r261904

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug debug/86593] [8/9 Regression] internal compiler error: in based_loc_descr, at dwarf2out.c:14272

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-w64-mingw32
Version|8.0 |8.1.0
   Target Milestone|--- |8.2
Summary|[8.0 Regression] internal   |[8/9 Regression] internal
   |compiler error: in  |compiler error: in
   |based_loc_descr, at |based_loc_descr, at
   |dwarf2out.c:14272   |dwarf2out.c:14272

[Bug ipa/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

[glisse at gcc dot gnu.org]

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

--- Comment #5 from Marc Glisse  ---
-finline-limit=80 or higher (or more precisely --param
max-inline-insns-auto=40) lets it optimize.

[Bug ipa/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
I see differences in EH as well (comparing .original dumps of gnu++14 vs.
gnu++17):

@@ -126,7 +126,7 @@
 ;; enabled by -tree-original


-<<< Unknown tree: eh_spec_block
+<<< Unknown tree: must_not_throw_expr
   < = __builtin_constant_p (__c) == 0 ||
(unsigned int) __c > 127 ? __btowc_alias (__c) : (wint_t) __c>>
>>>;
 __builtin_unreachable ();

and

-;; Function static void
std::char_traits::assign(std::char_traits::char_type&, const
char_type&) (null)
+;; Function static constexpr void
std::char_traits::assign(std::char_traits::char_type&, const
char_type&) (null)


But the biggest difference seems to be the introduction of

;; Function constexpr bool std::__constant_string_p(const _CharT*) [with _CharT
= char] (null)
;; enabled by -tree-original


while (1)
  {
if (__builtin_constant_p ((char) *__s) == 0 || *__s == 0) goto ;
<;
  }
:;
return  = __builtin_constant_p ((char) *__s) != 0;

which inlined survices as

   [local count: 1073741826]:
  MEM[(struct  &)&a] ={v} {CLOBBER};
  _59 = &a.D.22134._M_local_buf;
  MEM[(struct  &)&a] ={v} {CLOBBER};
  MEM[(struct _Alloc_hider *)&a]._M_p = _59;

   [local count: 10037315480]:
  # __s_63 = PHI <"Hello world"(2), __s_66(5)>
  _64 = *__s_63;
  _65 = __builtin_constant_p (_64);
  if (_65 == 0)
goto ; [5.50%]
  else
goto ; [94.50%]

which we are not able to simplify and which confuses us in optimizing.
Only the first DOM pass forcefully drops that to false.  This seems to be
a quite stupid loop structure btw resulting from

std::char_traits::length (const char_type * __s)
{
  bool retval.1;
  size_t D.33082;

  retval.1 = std::__constant_string_p (__s);
  if (retval.1 != 0) goto ; else goto ;
  :
  D.33082 = __gnu_cxx::char_traits::length (__s);
  return D.33082;
  :
  D.33082 = __builtin_strlen (__s);
  return D.33082;
}

and

std::__constant_string_p (const char * __s)
{
  bool D.33088;

   :
  _1 = *__s;
  _2 = __builtin_constant_p (_1);
  if (_2 == 0)
goto ; [INV]
  else
goto ; [INV]

   :
  _3 = *__s;
  if (_3 == 0)
goto ; [INV]
  else
goto ; [INV]

   :
  __s = __s + 1;
  goto ; [INV]

   :
  _4 = *__s;
  _5 = __builtin_constant_p (_4);
  D.33088 = _5 != 0;
  return D.33088;

}

  /**
   *  @brief Determine whether the characters of a NULL-terminated
   *  string are known at compile time.
   *  @param  __s  The string.
   *
   *  Assumes that _CharT is a built-in character type.
   */
  template
static _GLIBCXX_ALWAYS_INLINE constexpr bool
__constant_string_p(const _CharT* __s)
{
  while (__builtin_constant_p(*__s) && *__s)
__s++;
  return __builtin_constant_p(*__s);
}

WTF?

[Bug ipa/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
I see differences in EH as well (comparing .original dumps of gnu++14 vs.
gnu++17):

@@ -126,7 +126,7 @@
 ;; enabled by -tree-original


-<<< Unknown tree: eh_spec_block
+<<< Unknown tree: must_not_throw_expr
   < = __builtin_constant_p (__c) == 0 ||
(unsigned int) __c > 127 ? __btowc_alias (__c) : (wint_t) __c>>
>>>;
 __builtin_unreachable ();

and

-;; Function static void
std::char_traits::assign(std::char_traits::char_type&, const
char_type&) (null)
+;; Function static constexpr void
std::char_traits::assign(std::char_traits::char_type&, const
char_type&) (null)


But the biggest difference seems to be the introduction of

;; Function constexpr bool std::__constant_string_p(const _CharT*) [with _CharT
= char] (null)
;; enabled by -tree-original


while (1)
  {
if (__builtin_constant_p ((char) *__s) == 0 || *__s == 0) goto ;
<;
  }
:;
return  = __builtin_constant_p ((char) *__s) != 0;

which inlined survices as

   [local count: 1073741826]:
  MEM[(struct  &)&a] ={v} {CLOBBER};
  _59 = &a.D.22134._M_local_buf;
  MEM[(struct  &)&a] ={v} {CLOBBER};
  MEM[(struct _Alloc_hider *)&a]._M_p = _59;

   [local count: 10037315480]:
  # __s_63 = PHI <"Hello world"(2), __s_66(5)>
  _64 = *__s_63;
  _65 = __builtin_constant_p (_64);
  if (_65 == 0)
goto ; [5.50%]
  else
goto ; [94.50%]

which we are not able to simplify and which confuses us in optimizing.
Only the first DOM pass forcefully drops that to false.  This seems to be
a quite stupid loop structure btw resulting from

std::char_traits::length (const char_type * __s)
{
  bool retval.1;
  size_t D.33082;

  retval.1 = std::__constant_string_p (__s);
  if (retval.1 != 0) goto ; else goto ;
  :
  D.33082 = __gnu_cxx::char_traits::length (__s);
  return D.33082;
  :
  D.33082 = __builtin_strlen (__s);
  return D.33082;
}

and

std::__constant_string_p (const char * __s)
{
  bool D.33088;

   :
  _1 = *__s;
  _2 = __builtin_constant_p (_1);
  if (_2 == 0)
goto ; [INV]
  else
goto ; [INV]

   :
  _3 = *__s;
  if (_3 == 0)
goto ; [INV]
  else
goto ; [INV]

   :
  __s = __s + 1;
  goto ; [INV]

   :
  _4 = *__s;
  _5 = __builtin_constant_p (_4);
  D.33088 = _5 != 0;
  return D.33088;

}

  /**
   *  @brief Determine whether the characters of a NULL-terminated
   *  string are known at compile time.
   *  @param  __s  The string.
   *
   *  Assumes that _CharT is a built-in character type.
   */
  template
static _GLIBCXX_ALWAYS_INLINE constexpr bool
__constant_string_p(const _CharT* __s)
{
  while (__builtin_constant_p(*__s) && *__s)
__s++;
  return __builtin_constant_p(*__s);
}

WTF?

[Bug libstdc++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||redi at gcc dot gnu.org
  Component|ipa |libstdc++

--- Comment #8 from Richard Biener  ---
So I've analyzed it more and it is because

  static _GLIBCXX17_CONSTEXPR size_t
  length(const char_type* __s)
  {
#if __cplusplus >= 201703L
if (__constant_string_p(__s))
  return __gnu_cxx::char_traits::length(__s);
#endif
return __builtin_strlen(__s);
  }

confuses us because of the stupid structure of __constant_string_p.

Is this some odd requirement of O(1) length for constant strings?  Why not
make it constexpr evaluated instead?  Didn't we invent some special
__builtin_constant_p for this?  __constexpr_p ()?  Quoting __constant_string_p:

  template
static _GLIBCXX_ALWAYS_INLINE constexpr bool
__constant_string_p(const _CharT* __s)
{
  while (__builtin_constant_p(*__s) && *__s)
__s++;
  return __builtin_constant_p(*__s);
}

[Bug libstdc++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-20
 Ever confirmed|0   |1

--- Comment #9 from Richard Biener  ---
So we could try to somehow pattern-match this
"is-this-string-compile-time-constant" test or add a
__builtin_cstring_constant_p () ... after all we
end up evaluating this to false in the end, using __builtin_strlen but
then passing it the constant and folding it anyway.

   [local count: 10037315480]:
  # __s_63 = PHI <"Hello world"(2), __s_66(5)>
  _64 = *__s_63;
  _65 = __builtin_constant_p (_64);
  if (_65 == 0)
goto ; [5.50%]
  else
goto ; [94.50%]

   [local count: 9485263123]:
  if (_64 == 0)
goto ; [5.50%]
  else
goto ; [94.50%]

   [local count: 8963573645]:
  __s_66 = __s_63 + 1;
  goto ; [100.00%]

   [local count: 1073741826]:
  # _67 = PHI <_65(3), _65(4)>
  if (_67 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 4880644630]:
  # __i_68 = PHI <0(6), __i_71(8)>
  _69 = "Hello world" + __i_68;
  _70 = *_69;
  if (_70 != 0)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 4343773717]:
  __i_71 = __i_68 + 1;
  goto ; [100.00%]

   [local count: 536870913]:
  _72 = 11;

   [local count: 1073741817]:
  # _73 = PHI <__i_68(7), _72(9)>

so we have

  if (complicated way to tell the string is constant)
{
  yay, compute it inline with a loop!
}
  else
lenght = 11;

stupid.  Very stupid.

[Bug middle-end/86471] GCC/libstdc++ outputs inferior code for std::fill and std::fill_n vs std::memset on c-style arrays

[redi at gcc dot gnu.org]

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

--- Comment #25 from Jonathan Wakely  ---
(In reply to Matt Bentley from comment #23)
> > Actually, don't quote me on that - I may be thinking of the
> > 'reinterpret_cast<_Tp>(0)' - one of the two.
> 
> Just to confirm, "reinterpret_cast(__first)" not required in this
> context,  either "reinterpret_cast<_Tp>(0)" or "static_cast<_Tp>(0)" *are*
> required to avoid warnings in clang when _Tp is a pointer. Either works fine.

What warning? Why can't you just pass 0 to __builtin_memset? It's a null
pointer constant. I don't see any warning from clang when using -Weverything.

In C++11 we'd just use nullptr of course, but that can't be used here as the
code must compile as C++98.

> I understand that reinterpret_cast isn't allowed inside constexpr, but not
> why, and can't find any resources explicitly stating the reasoning.

reinterpet_cast is forbidden in constexpr functions because it's purpose is to
break the type system and say "trust me, I know what I'm doing", and such
tricks are not allowed in constant expressions.

Using reinterpert_cast to convert 0 (a null pointer constant) into a pointer
type is just silly and poor style. That conversion can be done implicitly, it
doesn't need a sledgehammer to be used.

> But __builtin_constant_p allows it, so it's use is a matter of programmer
> choice, at least in this context.

It really isn't if the standard requires the algorithm to be 'constexpr' (which
we don't implement yet, but there's no point adding constructs which will just
make life harder in the future).

[Bug libstdc++/86603] `__cpp_lib_list_remove_return_type` misplaced in the header

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-07-20
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Good catch, thanks.

[Bug libstdc++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||palves at gcc dot gnu.org

--- Comment #10 from Richard Biener  ---
Caused by r249137 which claims __builtin_strlen isn't usable in constexpr
functions (well, why not?  why not make it so?).

[Bug libstdc++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #8)
> So I've analyzed it more and it is because
> 
>   static _GLIBCXX17_CONSTEXPR size_t
>   length(const char_type* __s)
>   {
> #if __cplusplus >= 201703L
> if (__constant_string_p(__s))
>   return __gnu_cxx::char_traits::length(__s);
> #endif
> return __builtin_strlen(__s);
>   }
> 
> confuses us because of the stupid structure of __constant_string_p.
> 
> Is this some odd requirement of O(1) length for constant strings?  Why not
> make it constexpr evaluated instead?  Didn't we invent some special
> __builtin_constant_p for this?  __constexpr_p ()?  Quoting
> __constant_string_p:
> 
>   template
> static _GLIBCXX_ALWAYS_INLINE constexpr bool
> __constant_string_p(const _CharT* __s)
> {
>   while (__builtin_constant_p(*__s) && *__s)
> __s++;
>   return __builtin_constant_p(*__s);
> }

I think it is a poor man's workaround for the constexpr evaluation, until the
FE can handle the memory/string builtins in constexpr evaluation.
We need some helper routines for constexpr reading and storing a character to a
certain pointer, and then basically open-code the needed builtins using those
two helpers.

Is the problem __constant_string_p implementation or the
__gnu_cxx::char_traits::length(__s); part?  If only
__constant_string_p, then it might be enough to handle constexpr evaluation of
__builtin_strlen.

Is the problem that when optimizing we defer the __builtin_constant_p
evaluation until fab?  Perhaps my
https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00355.html patch would help here
instead?

[Bug libstdc++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #11)
> (In reply to Richard Biener from comment #8)
> > So I've analyzed it more and it is because
> > 
> >   static _GLIBCXX17_CONSTEXPR size_t
> >   length(const char_type* __s)
> >   {
> > #if __cplusplus >= 201703L
> > if (__constant_string_p(__s))
> >   return __gnu_cxx::char_traits::length(__s);
> > #endif
> > return __builtin_strlen(__s);
> >   }
> > 
> > confuses us because of the stupid structure of __constant_string_p.
> > 
> > Is this some odd requirement of O(1) length for constant strings?  Why not
> > make it constexpr evaluated instead?  Didn't we invent some special
> > __builtin_constant_p for this?  __constexpr_p ()?  Quoting
> > __constant_string_p:
> > 
> >   template
> > static _GLIBCXX_ALWAYS_INLINE constexpr bool
> > __constant_string_p(const _CharT* __s)
> > {
> >   while (__builtin_constant_p(*__s) && *__s)
> > __s++;
> >   return __builtin_constant_p(*__s);
> > }
> 
> I think it is a poor man's workaround for the constexpr evaluation, until
> the FE can handle the memory/string builtins in constexpr evaluation.
> We need some helper routines for constexpr reading and storing a character
> to a certain pointer, and then basically open-code the needed builtins using
> those two helpers.
> 
> Is the problem __constant_string_p implementation or the
> __gnu_cxx::char_traits::length(__s); part?  If only
> __constant_string_p, then it might be enough to handle constexpr evaluation
> of __builtin_strlen.

The __constant_string_p implementation (__builtin_constant_p in a loop).

> Is the problem that when optimizing we defer the __builtin_constant_p
> evaluation until fab?  Perhaps my
> https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00355.html patch would help
> here instead?

The first DOM pass evaluates it already but that's too late.

So C++ is basically lacking a feature to give two implementations, one
suitable for constexpr evaluation and one for non-constexpr contexts.

If we could overload on 'constexpr' then we could do

  static _GLIBCXX17_CONSTEXPR size_t
  length(const char_type* __s)
  {
#if __cplusplus >= 201703L
if (__constant_string_p(__s))
  return __gnu_cxx::char_traits::length(__s);
#endif
return __builtin_strlen(__s);
  }

  staic size_t
  length(const char_type* __s)
  {
return __builtin_strlen(__s);
  }

I can very well imagine that people want to dispatch to fancy library
routines in non-constexpr context while provide the compiler with a
straight-forward constexpr implementation.

Maybe it's easier to retro-fit sth like that into the compiler?

  if (__constexpr_evaluation_p)
{
  fancy
}
  else
return __builtin_strlen (..)

[Bug libstdc++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #8)
> So I've analyzed it more and it is because
> 
>   static _GLIBCXX17_CONSTEXPR size_t
>   length(const char_type* __s)
>   {
> #if __cplusplus >= 201703L
> if (__constant_string_p(__s))
>   return __gnu_cxx::char_traits::length(__s);
> #endif
> return __builtin_strlen(__s);
>   }
> 
> confuses us because of the stupid structure of __constant_string_p.

Ah, that is a difference between C++17 and C++14 that isn't just due to the
explicit instantiations, I take it back!

> Is this some odd requirement of O(1) length for constant strings?

char_traits::length is a constexpr function in C++17, so if called with a
constant argument it must be evaluated at compile time. The rather ugly
workaround with __builtin_constant_p was added because __builtin_strlen is not
usable in constant expressions, see PR c++/80265. A proper fix would be very
welcome.


> Why not
> make it constexpr evaluated instead?

I'm not sure what you mean, but the problem is that __builtin_strlen doesn't
work in constexpr functions (and wcslen isn't constexpr, and there's no
__builtin_wcslen AFAIK).

>  Didn't we invent some special
> __builtin_constant_p for this?  __constexpr_p ()?

Jakub implemented a __builtin_early_constant_p but I'm not sure if that's in
trunk yet or if it's useful here.


> Quoting
> __constant_string_p:
> 
>   template
> static _GLIBCXX_ALWAYS_INLINE constexpr bool
> __constant_string_p(const _CharT* __s)
> {
>   while (__builtin_constant_p(*__s) && *__s)
> __s++;
>   return __builtin_constant_p(*__s);
> }

[Bug libstdc++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #10)
> Caused by r249137 which claims __builtin_strlen isn't usable in constexpr
> functions (well, why not?  why not make it so?).

Yes please. That's what PR c++/80265 asks for.

(In reply to Richard Biener from comment #12)
> So C++ is basically lacking a feature to give two implementations, one
> suitable for constexpr evaluation and one for non-constexpr contexts.

That's been asked for repeatedly but will never happen, instead this is being
added to C++2a:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0595r1.html

So we'd do

  static _GLIBCXX17_CONSTEXPR size_t
  length(const char_type* __s)
  {
#if __cplusplus >= 201703L
 if (std::is_constant_evaluated())
// naive loop
#endif
return __builtin_strlen(__s);
  }

That way the dumb loop is only ever used in constant evaluation of constant
expressions, not every time  that __builtin_constant_p is true because the
optimiser can see the input.

> Maybe it's easier to retro-fit sth like that into the compiler?
>
>   if (__constexpr_evaluation_p)

Implementing std::is_constant_evaluated() would be great.

[Bug libstdc++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #14)
> That's been asked for repeatedly but will never happen, instead this is
> being added to C++2a:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0595r1.html
> 
> So we'd do
>  
>   static _GLIBCXX17_CONSTEXPR size_t
>   length(const char_type* __s)
>   {
> #if __cplusplus >= 201703L
>  if (std::is_constant_evaluated())

Hmm, std::is_constant_evaluated would only be declared for C++2a, so we'd need
to use the magic builtin directly here, not the std:: wrapper.

[Bug libstdc++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
(In reply to Jonathan Wakely from comment #15)
> (In reply to Jonathan Wakely from comment #14)
> > That's been asked for repeatedly but will never happen, instead this is
> > being added to C++2a:
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0595r1.html
> > 
> > So we'd do
> >  
> >   static _GLIBCXX17_CONSTEXPR size_t
> >   length(const char_type* __s)
> >   {
> > #if __cplusplus >= 201703L
> >  if (std::is_constant_evaluated())
> 
> Hmm, std::is_constant_evaluated would only be declared for C++2a, so we'd
> need to use the magic builtin directly here, not the std:: wrapper.

So, what is the status of P0595R1, has it been voted into C++2a already, or
will likely be voted in, something else?

I can certainly implement __builtin_is_constant_evaluated .

[Bug libstdc++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

[redi at gcc dot gnu.org]

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

--- Comment #17 from Jonathan Wakely  ---
The P0595R1 design was approved (very favourably) by the Evolution WG at the
last meeting, so will be forwarded to the Core and Library groups for wording
review. So it's almost certain to be in C++2a in some form, hopefully it will
get through Core and Library at the next meeting (November) and get into the
working draft.

[Bug libstdc++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

[redi at gcc dot gnu.org]

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

--- Comment #18 from Jonathan Wakely  ---
Correction: it was approved by EWG to be forwarded to the Library Evolution WG,
for (at least) naming discussion, and then to CWG and LWG.

[Bug tree-optimization/86604] phiopt missed optimization of conditional add

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-20
Summary|Compiler can't think of |phiopt missed optimization
   |smaller variable ranges |of conditional add
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Sure it does but we 1) cannot make the dereference of t unconditional because
it
may trap, 2) we do not implement the transform

  if ([0, 1] var == 0)
othervar += 1;

to

  othervar += var ^ 1;

that's a missed optimization in phiopt.  value_replacement handles some
cases but not (for unanalyzed reason):

#define __builtin_guarantee(a) \
if (!(a)) {\
__builtin_unreachable();   \
}

void CreateChecksum(int isTestNet, int *t)
{
  __builtin_guarantee(isTestNet == 0 || isTestNet == 1);
  int tem = *t;
  if (isTestNet == 1)
tem += 1;
  *t = tem;
}

where it could replace the conditional with

  tem += isTestNet;

[Bug middle-end/86336] [9 regression] ICE in omp-low.c:7879

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|x86_64-linux, aarch64   |x86_64, aarch64, i?86,
   ||sparc*
 CC||ro at gcc dot gnu.org

--- Comment #2 from Rainer Orth  ---
Also seen on Darwin/x86 (32 and 64-bit), Solaris/x86 and Solaris/SPARC.

[Bug libstdc++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

[palves at redhat dot com]

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

Pedro Alves  changed:

   What|Removed |Added

 CC||palves at redhat dot com

--- Comment #19 from Pedro Alves  ---
> confuses us because of the stupid structure of __constant_string_p.

Yes, a stupid workaround for a stupid __builtin_strlen, which is being punished
by a stupid optimizer.  ;-)

I'll be the first to say "good riddance" when this disappears, but I'm honestly
surprised the optimizers can't _always_ inline all of that, given it's
basically just "do I know this at compile time" checks...  I'd think that
fixing that would help generate better code in other uses of
__builtin_constant_p in other codebases.  As I mentioned in
, interestingly the
trick made some cases optimize _better_, which kind of suggests to me that
__builtin_foo functions are missing some comparing-known-constant-objects
optimizations.

[Bug libstdc++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

[rguenth at gcc dot gnu.org]

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

--- Comment #20 from Richard Biener  ---
(In reply to Pedro Alves from comment #19)
> > confuses us because of the stupid structure of __constant_string_p.
> 
> Yes, a stupid workaround for a stupid __builtin_strlen, which is being
> punished by a stupid optimizer.  ;-)
> 
> I'll be the first to say "good riddance" when this disappears, but I'm
> honestly surprised the optimizers can't _always_ inline all of that, given
> it's basically just "do I know this at compile time" checks...  I'd think
> that fixing that would help generate better code in other uses of
> __builtin_constant_p in other codebases.  As I mentioned in
> , interestingly the
> trick made some cases optimize _better_, which kind of suggests to me that
> __builtin_foo functions are missing some comparing-known-constant-objects
> optimizations.

The failure is not in inlining but in not optimizing the "constexpr"
part of the code in comment#9, that is, we fail to optimize

  char *s = "Hello World";
  while (__builtin_constant_p(*__s) && *__s)
__s++;
  res = __builtin_constant_p(*__s);

in the regular optimizers early enough which all do not do unbound
expression evaluation (as constexpr is doing).  Neither optimistic
constant propagation or value-numbering algorithms handle this.
For the small string loop unrolling might do the trick but IIRC
there is a bug about not being able to compute the number of iterations
for a loop iterating over a constant string, so ...

We do handle it at the point we give up and say __builtin_constant_p ()
evaluates to false.  But that's too late and we are not able to optimize
things away after that.

_Eventually_ we should change that point from the first DOM pass to the
value-numbering pass after IPA inlining.

[Bug c++/86605] New: Suboptimal code for pointer arithmetic with 'this'

[antoshkka at gmail dot com]

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

Bug ID: 86605
   Summary: Suboptimal code for pointer arithmetic with 'this'
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

In GCC 5.5 an optimization of following code was broken:

struct Test {
Test(Test* p) : i{this-p ? 10 : 20} {}
int i;
};

int f() {
Test test{(Test*)4};
return test.i;
}



GCC 5.4 generates optimal code:
f():
  mov eax, 10
  ret

GCC 5.5 generates:
f():
  lea rax, [rsp-5]
  cmp rax, 7
  sbb eax, eax
  and eax, 10
  add eax, 10
  ret

GCC (trunk) generates also suboptimal code:
f():
  cmp rsp, 8
  mov edx, 20
  mov eax, 10
  cmove eax, edx
  ret



Note, that in GCC 5.5 the optimizer was fixed to generate optimal code for the
following:
struct Test {
Test(Test* p) : i{this-p ? 10 : 20} {}
int i;
};

int f() {
Test test{(Test*)3}; // 3 instead of 4
return test.i;
}

So that now GCC (trunk) generates optimal code for that case:
f():
  mov eax, 10
  ret
but fail if we change 3 back to 4

[Bug driver/86606] New: Concurrent source files do not work with --save-temps option

[marxin at gcc dot gnu.org]

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

Bug ID: 86606
   Summary: Concurrent source files do not work with --save-temps
option
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: amker at gcc dot gnu.org
  Target Milestone: ---

Following causes troubles with --save-temps:

$ cat a.c
int foo();

int main()
{
  return foo();
}

$ cat x/a.c
int foo()
{
  return 0;
}

$ gcc a.c x/a.c
(works fine)

but:

$ gcc a.c x/a.c --save-temps
a.o: In function `foo':
a.c:(.text+0x0): multiple definition of `foo'
a.o:a.c:(.text+0x0): first defined here
/usr/lib64/gcc/x86_64-suse-linux/8/../../../../lib64/crt1.o: In function
`_start':
/home/abuild/rpmbuild/BUILD/glibc-2.27/csu/../sysdeps/x86_64/start.S:104:
undefined reference to `main'
collect2: error: ld returned 1 exit status

[Bug libstdc++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

[rguenth at gcc dot gnu.org]

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

--- Comment #21 from Richard Biener  ---
(In reply to Richard Biener from comment #20)
> (In reply to Pedro Alves from comment #19)
> > > confuses us because of the stupid structure of __constant_string_p.
> > 
> > Yes, a stupid workaround for a stupid __builtin_strlen, which is being
> > punished by a stupid optimizer.  ;-)
> > 
> > I'll be the first to say "good riddance" when this disappears, but I'm
> > honestly surprised the optimizers can't _always_ inline all of that, given
> > it's basically just "do I know this at compile time" checks...  I'd think
> > that fixing that would help generate better code in other uses of
> > __builtin_constant_p in other codebases.  As I mentioned in
> > , interestingly the
> > trick made some cases optimize _better_, which kind of suggests to me that
> > __builtin_foo functions are missing some comparing-known-constant-objects
> > optimizations.
> 
> The failure is not in inlining but in not optimizing the "constexpr"
> part of the code in comment#9, that is, we fail to optimize
> 
>   char *s = "Hello World";
>   while (__builtin_constant_p(*__s) && *__s)
> __s++;
>   res = __builtin_constant_p(*__s);
> 
> in the regular optimizers early enough which all do not do unbound
> expression evaluation (as constexpr is doing).  Neither optimistic
> constant propagation or value-numbering algorithms handle this.
> For the small string loop unrolling might do the trick but IIRC
> there is a bug about not being able to compute the number of iterations
> for a loop iterating over a constant string, so ...
> 
> We do handle it at the point we give up and say __builtin_constant_p ()
> evaluates to false.  But that's too late and we are not able to optimize
> things away after that.
> 
> _Eventually_ we should change that point from the first DOM pass to the
> value-numbering pass after IPA inlining.

Like with the following, which will give up earlier:

Index: gcc/tree-ssa-sccvn.c
===
--- gcc/tree-ssa-sccvn.c(revision 262899)
+++ gcc/tree-ssa-sccvn.c(working copy)
@@ -4193,6 +4193,14 @@ visit_use (tree use)
   SSA_VAL (gimple_vuse (call_stmt)));
  goto done;
}
+ /* After IPA inlining either we can simplify __builtin_constant_p
+or we assume it is false.  */
+ else if (cfun->after_inlining
+  && gimple_call_builtin_p (call_stmt, BUILT_IN_CONSTANT_P))
+   {
+ changed = set_ssa_val_to (lhs, build_zero_cst (TREE_TYPE (lhs)));
+ goto done;
+   }
  else if (SSA_NAME_OCCURS_IN_ABNORMAL_PHI (lhs))
{
  changed = defs_to_varying (call_stmt);

That nearly solves the issue but appearantly leaves us with
_M_construct.constprop calls that are possibly throwing compared to
the calls surviving with -std=c++14.

[Bug c++/84464] Pack expansion in mem-initializer-list with expression-list

[tadeus.prastowo at unitn dot it]

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

Tadeus Prastowo  changed:

   What|Removed |Added

Version|7.3.0   |8.1.0

--- Comment #1 from Tadeus Prastowo  ---
The bug still exists in GCC 8.1.0 (cf. https://godbolt.org/g/GPci7c).

[Bug libstdc++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

[palves at redhat dot com]

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

--- Comment #22 from Pedro Alves  ---
clueless suggestion triggered by you saying "throwing": does marking
__constant_string_p noexcept, like:

...
__constant_string_p(const _CharT* __s) noexcept
...

make any difference?

[Bug c++/86605] Suboptimal code for pointer arithmetic with 'this'

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-20
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Most certainly caused by some folding fix wrt undefined behavior.  The
difference starts to appear in CCP.  I seem to remember axing the
"trick" of stripping pointer-to-integer conversions from the lattice
so that (unsigned long)((long)&test + -4) + 3 might appear > 6.
Ah, so GCC 5.4 does that based on alignment considerations but it should
have nothing left after -4 + 3 ...

 ;; Function int f() (_Z1fv, funcdef_no=3, decl_uid=2101, cgraph_uid=3,
symbol_order=3)

-Folding predicate _9 > 6 to 1
-Removing basic block 3
-Merging blocks 2 and 4
 int f() ()
 {
   struct Test test;
@@ -46,13 +43,23 @@
   long int _7;
   unsigned long _8;
   unsigned long _9;
+  int iftmp.0_10;

   :
   this.1_5 = (long int) &test;
   _7 = this.1_5 + -4;
   _8 = (unsigned long) _7;
   _9 = _8 + 3;
-  test.i = 10;
+  if (_9 > 6)
+goto ;
+  else
+goto ;
+
+  :
+
+  :
+  # iftmp.0_10 = PHI <10(2), 20(3)>
+  test.i = iftmp.0_10;
   _3 = test.i;
   test ={v} {CLOBBER};
   return _3;

[Bug driver/86606] Concurrent source files do not work with --save-temps option

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
IIRC -save-temps saves preprocesse source into $CWD.

[Bug debug/86585] [9 Regression] ICE in gen_member_die, at dwarf2out.c:24935

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Fri Jul 20 11:13:47 2018
New Revision: 262901

URL: https://gcc.gnu.org/viewcvs?rev=262901&root=gcc&view=rev
Log:
2018-07-20  Richard Biener  

PR debug/86585
* dwarf2out.c (dwarf2out_die_ref_for_decl): Test in_lto_p
to cover -flto-partition=none.

lto/
* lto.c (unify_scc): Before we throw away an SCC see if we
can amend prevailing single-entry SCC with debug refs.

* g++.dg/lto/pr86585_0.C: New testcase.
* g++.dg/lto/pr86585_1.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/lto/pr86585_0.C
trunk/gcc/testsuite/g++.dg/lto/pr86585_1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/86585] [9 Regression] ICE in gen_member_die, at dwarf2out.c:24935

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Richard Biener  ---
Fixed.

[Bug c++/86607] New: constexpr function does not treat function pointers with external linkage as constexpr

[tadeus.prastowo at unitn dot it]

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

Bug ID: 86607
   Summary: constexpr function does not treat function pointers
with external linkage as constexpr
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tadeus.prastowo at unitn dot it
  Target Milestone: ---

Using http://godbolt.org, I see that the following program compiles in
any clang version that supports `-std=c++14' switch (>= 3.5) but fails
in any GCC version >= 5.1 while compiles in any GCC version <= 4.9.4
that supports `-std=c++14' switch (>= 4.8.5):

template
struct carrier {
  static constexpr T value = v;
};

template
inline constexpr bool nontype_nontemplate_args_eq(T arg1, T arg2) {
  return arg1 == arg2;
}
template
inline constexpr bool nontype_nontemplate_args_eq(T1, T2) {
  return false;
}

int fn1() {
  return 2;
}

int fn2() {
  return 17;
}

int main() {
  return carrier::value;
}

Any GCC version >= 5.1 should compile the program because `&fn1' and `&fn2' as
the arguments of constexpr function `nontype_nontemplate_args_eq' are constexpr
according to the C++ standard http://eel.is/c++draft/expr.const#6.2.

[Bug libstdc++/86603] `__cpp_lib_list_remove_return_type` misplaced in the header

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Fri Jul 20 11:24:38 2018
New Revision: 262902

URL: https://gcc.gnu.org/viewcvs?rev=262902&root=gcc&view=rev
Log:
PR libstdc++/86603 Move __cpp_lib_list_remove_return_type macro

This should only be defined for C++2a not C++17.

PR libstdc++/86603
* include/std/version: Move __cpp_lib_list_remove_return_type macro.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/version

[Bug libstdc++/86603] `__cpp_lib_list_remove_return_type` misplaced in the header

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
Version|unknown |9.0
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #3 from Jonathan Wakely  ---
Fixed, thanks.

[Bug driver/86606] Concurrent source files do not work with --save-temps option

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
 --save-temps=obj might work instead.

[Bug c++/86608] New: volatile variable is taken as a constexpr

[tadeus.prastowo at unitn dot it]

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

Bug ID: 86608
   Summary: volatile variable is taken as a constexpr
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tadeus.prastowo at unitn dot it
  Target Milestone: ---

The following program is ill-formed based on
http://eel.is/c++draft/temp.arg.nontype (#1 and #2) and
http://eel.is/c++draft/expr.const#2.7.  However,
GCC 8.1 compiles fine (https://godbolt.org/g/o8UPiJ)
as well as any GCC >= 6.1 available in godbolt, but
clang-6.0 (https://godbolt.org/g/HUQXUM) and
GCC 5.5 (https://godbolt.org/g/MQRCdE) as well as
any GCC older than 5.5 but >= 4.9.0 correctly reject
the program.

template struct X {};
int main() {
  static constexpr volatile int a = 3;
  constexpr volatile int b = 2;
  return (sizeof(X) + sizeof(X));
}

So, GCC >= 6.1 should be fixed to reject the program.

[Bug libstdc++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org

--- Comment #23 from Jakub Jelinek  ---
So, I've tried to implement this, but so far failed:

--- gcc/builtins.def.jj 2018-06-20 08:15:34.179862153 +0200
+++ gcc/builtins.def2018-07-20 12:03:10.254453811 +0200
@@ -974,6 +974,11 @@ DEF_EXT_LIB_BUILTIN(BUILT_IN_PRINTF_
 DEF_EXT_LIB_BUILTIN(BUILT_IN_VFPRINTF_CHK, "__vfprintf_chk",
BT_FN_INT_FILEPTR_INT_CONST_STRING_VALIST_ARG,
ATTR_NONNULL_1_FORMAT_PRINTF_3_0)
 DEF_EXT_LIB_BUILTIN(BUILT_IN_VPRINTF_CHK, "__vprintf_chk",
BT_FN_INT_INT_CONST_STRING_VALIST_ARG, ATTR_FORMAT_PRINTF_2_0)

+/* C++ __builtin_is_constant_evaluated.  */
+DEF_BUILTIN (BUILT_IN_IS_CONSTANT_EVALUATED,
"__builtin_is_constant_evaluated",
+BUILT_IN_NORMAL, BT_FN_BOOL, BT_LAST, false, false, false,
+ATTR_CONST_NOTHROW_LEAF_LIST, true, c_dialect_cxx ())
+
 /* Profiling hooks.  */
 DEF_BUILTIN (BUILT_IN_PROFILE_FUNC_ENTER, "__cyg_profile_func_enter",
BUILT_IN_NORMAL, BT_FN_VOID_PTR_PTR, BT_LAST,
 false, false, false, ATTR_NULL, true, true)
--- gcc/builtins.c.jj   2018-07-16 23:24:51.306429546 +0200
+++ gcc/builtins.c  2018-07-20 12:09:13.278818768 +0200
@@ -9104,6 +9104,10 @@ fold_builtin_0 (location_t loc, tree fnd
 case BUILT_IN_CLASSIFY_TYPE:
   return fold_builtin_classify_type (NULL_TREE);

+case BUILT_IN_IS_CONSTANT_EVALUATED:
+  /* The C++ FE can evaluate this to something other than false.  */
+  return boolean_false_node; 
+
 default:
   break;
 }
--- gcc/cp/constexpr.c.jj   2018-06-25 14:51:23.094989194 +0200
+++ gcc/cp/constexpr.c  2018-07-20 12:54:35.781999003 +0200
@@ -1184,6 +1184,18 @@ cxx_eval_builtin_function_call (const co
   return t;
 }

+  /* For __builtin_is_constant_evaluated, defer it if ctx->quiet, otherwise
+ fold it to true.  */
+  if (DECL_FUNCTION_CODE (fun) == BUILT_IN_IS_CONSTANT_EVALUATED)
+{
+  if (0 && ctx->quiet)
+   {
+ *non_constant_p = true;
+ return t;
+   }
+  return boolean_true_node;
+}
+
   /* Be permissive for arguments to built-ins; __builtin_constant_p should
  return constant false for a non-constant argument.  */
   constexpr_ctx new_ctx = *ctx;
--- gcc/cp/cp-gimplify.c.jj 2018-07-20 11:39:15.543037497 +0200
+++ gcc/cp/cp-gimplify.c2018-07-20 12:21:29.869568404 +0200
@@ -2478,6 +2478,12 @@ cp_fold (tree x)
&& DECL_DECLARED_CONSTEXPR_P (current_function_decl))
  nw = 1;

+   /* Defer folding __builtin_is_constant_evaluated.  */
+   if (callee
+   && DECL_BUILT_IN_CLASS (callee) == BUILT_IN_NORMAL
+   && DECL_FUNCTION_CODE (callee) == BUILT_IN_IS_CONSTANT_EVALUATED)
+ break;
+
x = copy_node (x);

m = call_expr_nargs (x);
--- gcc/lto/lto-lang.c.jj   2018-06-13 10:05:49.991124932 +0200
+++ gcc/lto/lto-lang.c  2018-07-20 12:29:28.087207392 +0200
@@ -246,6 +246,7 @@ static GTY(()) tree signed_size_type_nod
 int flag_isoc94;
 int flag_isoc99;
 int flag_isoc11;
+#define c_dialect_cxx() 0

 /* Attribute handlers.  */

Given the fixed up testcase from p0595r1 with
s/std::is_constant_evaluated()/__builtin_is_constant_evaluated ()/:

template struct X {};
X<__builtin_is_constant_evaluated ()> x; // type X
int y = 4;
int a = __builtin_is_constant_evaluated () ? y : 1; // initializes a to 1
int b = __builtin_is_constant_evaluated () ? 2 : y; // initializes b to 2
int c = y + (__builtin_is_constant_evaluated () ? 2 : y); // initializes c to
2*y

constexpr int
f ()
{
  const int n = __builtin_is_constant_evaluated () ? 13 : 17; // n == 13
  int m = __builtin_is_constant_evaluated () ? 13 : 17; // m might be 13 or 17
(see below)
  char arr[n] = {}; // char[13]
  return m + sizeof (arr);
}
int p = f (); // m == 13; initialized to 26
int q = p + f (); // m == 17 for this call; initialized to 56

struct false_type { static constexpr bool value = false; };
struct true_type { static constexpr bool value = true; };
template
struct is_same : false_type {};
template
struct is_same : true_type {};

static_assert (is_same >::value, "x's type");

int
main ()
{
  if (a != 1 || b != 2 || c != 8 || p != 26 || q != 56)
__builtin_abort ();
}

a, b, c, x, p are correct.  In the out-of-line copy of f (if I force it), both
n and m are actually 13 and q is 52 rather than 56.
If I remove the 0 && part from the patch, so that
__builtin_is_constant_evaluated () is evaluated to true only if ctx->quiet is
false and otherwise deferred,
then a, c and x are correct, b is though 4 (i.e. y), p is 34, q is 68 and in f
arr is a VLA.

The description doesn't seem to be unambiguous:

"An expression e is requir

[Bug libstdc++/86595] directory_entry::refresh(error_code&) should be noexcept.

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Fri Jul 20 11:52:54 2018
New Revision: 262904

URL: https://gcc.gnu.org/viewcvs?rev=262904&root=gcc&view=rev
Log:
PR libstdc++/86595 add missing noexcept

PR libstdc++/86595
* include/bits/fs_dir.h (directory_entry::refresh(error_code&)): Add
noexcept.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/fs_dir.h

[Bug libstdc++/86595] directory_entry::refresh(error_code&) should be noexcept.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-20
   Target Milestone|--- |8.3
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
Fixed on trunk. I'll backport it to gcc-8-branch after the 8.2 release.

[Bug c++/59480] Missing error diagnostic: friend declaration specifying a default argument must be a definition

[paolo.carlini at oracle dot com]

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

--- Comment #17 from Paolo Carlini  ---
If we can exploit DECL_HIDDEN_FRIEND_P of the olddecl everything is much
easier: see attached draft which I'm probably going to resubmit as-is of with
only minor modifications.

[Bug c++/86601] g++ accepts 'friend' at ill-formed positions in the decl-specifier-seq

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-20
 Ever confirmed|0   |1

[Bug c++/59480] Missing error diagnostic: friend declaration specifying a default argument must be a definition

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

  Attachment #44413|0   |1
is obsolete||

--- Comment #18 from Paolo Carlini  ---
Created attachment 44414
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44414&action=edit
Complete new draft

[Bug c++/86600] Class declaration in the same declarative region as using declaration - Missing diagnostic message

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Jonathan Wakely  ---
.

*** This bug has been marked as a duplicate of bug 84589 ***

[Bug c++/84589] Failure to diagnose conflicting declaration of struct

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||zhonghao at pku dot org.cn

--- Comment #1 from Jonathan Wakely  ---
*** Bug 86600 has been marked as a duplicate of this bug. ***

[Bug c++/84589] Failure to diagnose conflicting declaration of struct

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-20
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
Testcase from Bug 86600

namespace X { class A; }

namespace Y { using X::A; class A {}; }

[Bug c++/86598] Incorrect lexing of pp-numbers in C++11 due to hexfloat extension

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-20
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
If you're going to copy other people's words verbatim at least link to the
original:
https://bugs.llvm.org/show_bug.cgi?id=12717

At https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86305#c9 I clearly said:

> I didn't say don't link to the original report!

What I was complaining about was blindly copying things from one bugzilla to
the other without attempting to understand if the bug is relevant to GCC. I
wasn't complaining about links back to the original, I was complaining about
stupid low quality bug reports.

[Bug c++/86598] Incorrect lexing of pp-numbers in C++11 due to hexfloat extension

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=70529

--- Comment #2 from Jonathan Wakely  ---
Maybe a dup of PR 70529, certainly related

[Bug c++/86602] need to check for a placeholder in argument to noexcept

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-20
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Confirmed, but what does "need to check for a placeholder in argument to
noexcept" mean?

[Bug c++/86596] narrowing for template arugments not rejected

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #1)
> Most likely a dup of bug 57891.

Yes, and Bug 86298 and Bug 86237 which you already reported.

*** This bug has been marked as a duplicate of bug 57891 ***

[Bug c++/57891] No diagnostic of narrowing conversion in non-type template argument

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
*** Bug 86596 has been marked as a duplicate of this bug. ***

[Bug libstdc++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

[jakub at gcc dot gnu.org]

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

--- Comment #24 from Jakub Jelinek  ---
I wonder if instead of the list they provide they really didn't mean all the
spots in the standard that actually require constant-expression (I guess too
hard to list them all again in one place; furthermore, e.g. various language
extensions like OpenMP etc. also require constant expressions in further
places;
anyway, I think this category is where gcc does constexpr.c evaluation with
!ctx->quiet), plus that extra special case of initializer of
"a variable of reference type or of non-volatile const-qualified integral or
enumeration type or of non-automatic storage duration"
where if in that initializer std::is_constant_evaluated () were to evaluate to
true, then the result would be a constant expression.  In order to implement
this
behavior, the above patch would instead of that 0 && ctx->quiet be
ctx->quiet && !ctx->in_certain_initializer and when trying to evaluate the
initializers of those above mentioned variables we'd make sure that flag is
set.
If that would return a constant expression, we'd use that, now not really sure
if we then should just use another maybe_constant_value or similar that would
evaluate it again without that special new flag (and what to do with caching),
or if it would be ok to leave those as is.

Modifying the above patch just to remove that "0 && " part and renaming that
builtin to something different, so it would be clearly unrelated to whatever
is_constant_evaluated becomes and would only be true in spots that are required
to be constant expressions (i.e. !ctx->quiet) might be a usable temporary
solution for this issue, if the C++ maintainer would be willing to accept that.

In any case, as mentioned in another PR, static_assert seems to require a
constant-expression, so I wonder if we don't need to change that to evaluate
the expression with !ctx->quiet.

[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails

[clhamilto at gmail dot com]

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

--- Comment #12 from Curtis Hamilton  ---
I wanted to see if the errors were version specific, so I attempted a build on
FreeBSD 10.2 and the results were the same.  So I manually edited the
"runtime_sysinfo.go", as best as I could to get past the initial errors, only
to encounter different errors for undefined types and fields.  All of the
errors seem to be network related.  Below is a build log extract.

/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/go/syscall/bpf_bsd.go:16:28: error:
use of undefined type 'BpfInsn'
 func BpfStmt(code, k int) *BpfInsn {
^
/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/go/syscall/bpf_bsd.go:16:28: error:
use of undefined type 'BpfInsn'
/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/go/syscall/bpf_bsd.go:28:47: error:
reference to undefined name 'BIOCGBLEN'
  _, _, err := Syscall(SYS_IOCTL, uintptr(fd), BIOCGBLEN,
uintptr(unsafe.Pointer(&l)))
   ^
/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/go/syscall/bpf_bsd.go:37:47: error:
reference to undefined name 'BIOCSBLEN'
  _, _, err := Syscall(SYS_IOCTL, uintptr(fd), BIOCSBLEN,
uintptr(unsafe.Pointer(&l)))
   ^
/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/go/syscall/bpf_bsd.go:47:47: error:
reference to undefined name 'BIOCGDLT'
  _, _, err := Syscall(SYS_IOCTL, uintptr(fd), BIOCGDLT,
uintptr(unsafe.Pointer(&t)))
   ^
/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/go/syscall/bpf_bsd.go:56:47: error:
reference to undefined name 'BIOCSDLT'
  _, _, err := Syscall(SYS_IOCTL, uintptr(fd), BIOCSDLT,
uintptr(unsafe.Pointer(&t)))
   ^
/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/go/syscall/bpf_bsd.go:65:47: error:
reference to undefined name 'BIOCPROMISC'
  _, _, err := Syscall(SYS_IOCTL, uintptr(fd), BIOCPROMISC,
uintptr(unsafe.Pointer(&m)))
   ^
/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/go/syscall/bpf_bsd.go:74:47: error:
reference to undefined name 'BIOCFLUSH'
  _, _, err := Syscall(SYS_IOCTL, uintptr(fd), BIOCFLUSH, 0)
   ^
/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/go/syscall/bpf_bsd.go:89:47: error:
reference to undefined name 'BIOCGETIF'
  _, _, err := Syscall(SYS_IOCTL, uintptr(fd), BIOCGETIF,
uintptr(unsafe.Pointer(&iv)))
   ^
/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/go/syscall/bpf_bsd.go:100:47: error:
reference to undefined name 'BIOCSETIF'
  _, _, err := Syscall(SYS_IOCTL, uintptr(fd), BIOCSETIF,
uintptr(unsafe.Pointer(&iv)))
   ^
/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/go/syscall/bpf_bsd.go:110:47: error:
reference to undefined name 'BIOCGRTIMEOUT'
  _, _, err := Syscall(SYS_IOCTL, uintptr(fd), BIOCGRTIMEOUT,
uintptr(unsafe.Pointer(&tv)))
   ^
/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/go/syscall/bpf_bsd.go:119:47: error:
reference to undefined name 'BIOCSRTIMEOUT'
  _, _, err := Syscall(SYS_IOCTL, uintptr(fd), BIOCSRTIMEOUT,
uintptr(unsafe.Pointer(tv)))
   ^
/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/go/syscall/bpf_bsd.go:129:47: error:
reference to undefined name 'BIOCGSTATS'
  _, _, err := Syscall(SYS_IOCTL, uintptr(fd), BIOCGSTATS,
uintptr(unsafe.Pointer(&s)))
   ^
/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/go/syscall/bpf_bsd.go:138:47: error:
reference to undefined name 'BIOCIMMEDIATE'
  _, _, err := Syscall(SYS_IOCTL, uintptr(fd), BIOCIMMEDIATE,
uintptr(unsafe.Pointer(&m)))
   ^
/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/go/syscall/bpf_bsd.go:147:8: error:
use of undefined type 'BpfProgram'
  var p BpfProgram
^
/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/go/syscall/bpf_bsd.go:148:3: error:
reference to field 'Len' in object which has no fields or methods
  p.Len = uint32(len(i))
   ^
/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/go/syscall/bpf_bsd.go:149:3: error:
reference to field 'Insns' in object which has no fields or methods
  p.Insns = (*BpfInsn)(unsafe.Pointer(&i[0]))
   ^
/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/go/syscall/bpf_bsd.go:149:14: error:
reference to undefined name 'BpfInsn'
  p.Insns = (*BpfInsn)(unsafe.Pointer(&i[0]))
  ^
/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/go/syscall/bpf_bsd.go:149:13: error:
expected pointer
  p.Insns = (*BpfInsn)(unsafe.Pointer(&i[0]))
 ^
/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/go/syscall/bpf_bsd.go:150:47: error:
reference to undefined name 'BIOCSETF'
  _, _, err := Syscall(SYS_IOCTL, uintptr(fd), BIOCSETF,
uintptr(unsafe.Pointer(&p)))
   ^
/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/go/syscall/bpf_bsd.go:160:47: error:
reference to

[Bug sanitizer/86022] TCB size calculated in ThreadDescriptorSize() is wrong for glibc-2.14

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||carlos at redhat dot com,
   ||jsm28 at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
We'll need somebody from glibc community to confirm that. Adding some..

[Bug lto/85759] ICE output_profile_summary, at lto-cgraph.c:706 using -profile-use

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #23 from Martin Liška  ---
Fixed now.

[Bug ipa/85656] gcc.dg/ipa/ipa-icf-38.c FAILs

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
Rainer?

[Bug ipa/85656] gcc.dg/ipa/ipa-icf-38.c FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
I haven't yet gotten around to looking closer, sorry.

I'll report once I've found something.

[Bug ipa/85656] gcc.dg/ipa/ipa-icf-38.c FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
Just for the record: according to gcc-testresults, the test also FAILs
on hppa64-hp-hpux11.11.

[Bug target/86547] s390x: Maximum number of LRA assignment passes is achieved (30) when compiling a small inline assembler snippet

[iii at linux dot ibm.com]

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

--- Comment #1 from Ilya Leoshkevich  ---
I did a bisect and found two relevant commits:

1) c312b100: PR target/83712

Before: error: ‘asm’ operand has impossible constraints
After:  internal compiler error: Segmentation fault

2) eaefe34f: PR target/84876

Before: internal compiler error: Segmentation fault
After:  internal compiler error: Maximum number of LRA assignment passes is
achieved (30)

[Bug libstdc++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

[jakub at gcc dot gnu.org]

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

--- Comment #25 from Jakub Jelinek  ---
So, apparently the first bullet is wherever the constant-expression
non-terminal appears in the grammar rather than that e is a constant
expression.

So the above patch really needs to be:
+  if (ctx->quiet && !ctx->maybe_constant_init)
+   {
+ *non_constant_p = true;
+ return t;
+   }
where ctx->maybe_constant_init flag would be set in some special variant of
maybe_constant_init_1.  store_init_value has:
  /* In C++11 constant expression is a semantic, not syntactic, property.
 In C++98, make sure that what we thought was a constant expression at
 template definition time is still constant and otherwise perform this
 as optimization, e.g. to fold SIZEOF_EXPRs in the initializer.  */
  if (decl_maybe_constant_var_p (decl) || TREE_STATIC (decl))
{
  bool const_init;
  tree oldval = value;
  value = fold_non_dependent_expr (value);
  if (DECL_DECLARED_CONSTEXPR_P (decl)
  || (DECL_IN_AGGR_P (decl)
  && DECL_INITIALIZED_IN_CLASS_P (decl)
  && !DECL_VAR_DECLARED_INLINE_P (decl)))
{
  /* Diagnose a non-constant initializer for constexpr variable or
 non-inline in-class-initialized static data member.  */
  if (!require_constant_expression (value))
value = error_mark_node;
  else
value = cxx_constant_init (value, decl);
}
  else
value = maybe_constant_init (value, decl);
and the cxx_constant_init call there already sets ctx->quiet to false, so the
maybe_constant_init call here is probably the one that would need to be
changed.
There are tons of other maybe_constant_init calls in the C++ FE though, and it
is unclear if any other would need changes (wonder e.g. about aggregate
initializers or initializer-list etc. that contain many separate expressions;
if we need is_constant_evaluated to be true sometimes in there, it would need
to check if they are all constant expressions).

[Bug tree-optimization/86609] New: Reassociate (int) round sequences

[ktkachov at gcc dot gnu.org]

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

Bug ID: 86609
   Summary: Reassociate (int) round sequences
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---

Not entirely sure what to call this optimisation.
Consider:
int f(double x, double *p)
{
  double r = __builtin_round (x);
  *p = r;
  return (int) r;
}

For aarch64 GCC with -O2 -fno-math-errno generates:
f:
frinta  d0, d0  // 7[c=8 l=4]  rounddf2
str d0, [x0]// 8[c=4 l=4]  *movdf_aarch64/7
fcvtzs  w0, d0  // 14   [c=8 l=4]  fix_truncdfsi2
ret // 29   [c=0 l=4]  *do_return


The problem here is that the two FRINT* operations cannot be done in parallel.
Clang can break the chain like so:
f:  // @f
// %bb.0:   // %entry
frinta  d1, d0
fcvtas  w8, d0
str d1, [x0]
mov w0, w8
ret

Note how the two expensive operations are now independent.
I think in C terms this means transforming the above to:
int f2 (double x, double *p)
{
  double r = __builtin_round (x);
  *p = r;
  return (int)__builtin_iround (x);
}

Would this be something for the reassociation pass to do?

[Bug target/86589] [8 regression] gcc.target/powerpc/altivec-7-le.c and gcc.target/powerpc/vsx-7-be.c fail starting with r262440

[seurer at gcc dot gnu.org]

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

--- Comment #2 from seurer at gcc dot gnu.org ---
I just checked and 8.1.0 was OK

[Bug libstdc++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

[jakub at gcc dot gnu.org]

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

--- Comment #26 from Jakub Jelinek  ---
I'm also wondering about cxx_constant_init using !ctx->strict, shouldn't we in
those cases really require strict constant expressions, i.e.
let maybe_constant_init_1 call cxx_eval_outermost_constant_expr with
allow_non_constant, !allow_non_constant rather than allow_non_constant, false ?

[Bug tree-optimization/84047] [6/7/8 Regression] missing -Warray-bounds on an out-of-bounds index into an array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Martin Sebor  ---
Per comment 10, will not be backporting to release branches.

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 84047, which changed state.

Bug 84047 Summary: [6/7/8 Regression] missing -Warray-bounds on an 
out-of-bounds index into an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84047

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 83776, which changed state.

Bug 83776 Summary: [6/7/8 Regression] missing -Warray-bounds indexing past the 
end of a string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83776

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/83776] [6/7/8 Regression] missing -Warray-bounds indexing past the end of a string literal

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Martin Sebor  ---
Per bug 84047, comment 10, will not be backporting to release branches.

[Bug c++/86610] New: non-const operator erroneously called in lambda in templated function

[daibane at sandia dot gov]

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

Bug ID: 86610
   Summary: non-const operator erroneously called in lambda in
templated function
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daibane at sandia dot gov
  Target Milestone: ---

The following code fails to compile, saying that the non-const operator[] is
being called. GCC 7.3, Clang 6.0.0, Intel 18, and MSVC 2018 Pre all compile
this code without error. Removing either the templatization of the classify2
function or the lambda around the statement allows the code to compile without
error.


#include 
#include 

template 
class Few {
  T array_[n];

 public:
  inline T& operator[](int i) { return array_[i]; }
  inline T const& operator[](int i) const { return array_[i]; }
  Few(std::initializer_list l) {
int i = 0;
for (auto it = l.begin(); it != l.end(); ++it) {
  new (array_ + (i++)) T(*it);
}
  }
  inline Few() {}
  inline ~Few() {}
  inline Few(Few const& rhs) {
for (int i = 0; i < n; ++i) new (array_ + i) T(rhs[i]);
  }
};

template 
void classify2(Few l) {
  double* p = new double[1];
  auto f = [=]() {
p[0] = l[0];
  };
  f();
  delete [] p;
}

static void classify_box(double x, double y, double z) {
  Few l({x, y, z});
  classify2<3>(l);
}

int main() {
  classify_box(1.0, 1.0, 1.0);
}



Here is the compile error:


bug.cpp: In instantiation of ‘void classify2(Few) [with int dim =
3]’:
bug.cpp:36:17:   required from here
bug.cpp:28:10: error: passing ‘const Few’ as ‘this’ argument
discards qualifiers [-fpermissive]
 p[0] = l[0];
bug.cpp:9:13: note:   in call to ‘T& Few::operator[](int) [with T =
double; int n = 3]’
   inline T& operator[](int i) { return array_[i]; }
 ^~~~

[Bug tree-optimization/86611] New: missing -Warray-bounds on a large negative index into a string in lp64

[msebor at gcc dot gnu.org]

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

Bug ID: 86611
   Summary: missing -Warray-bounds on a large negative index into
a string in lp64
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

With bug 84047 fixed, the out-of-bounds index in the following test case is
still diagnosed in ilp32 but not in lp64.  In ilp32 the MEM_REF makes it all
the way to VRP where it's diagnosed, but in lp64 it's folded in fre1:

$ cat c.c && gcc -O2 -S -Warray-bounds -Wno-stringop-overflow
-fdump-tree-ealias=/dev/stdout -fdump-tree-fre1=/dev/stdout c.c
void f (int);

void g (void)
{
  const char *p = "123";
  __PTRDIFF_TYPE__ i = -__PTRDIFF_MAX__ - 1;
  f (p[i + 1]);
}

;; Function g (g, funcdef_no=0, decl_uid=1900, cgraph_uid=1, symbol_order=0)

Points-to analysis

Constraints:

ANYTHING = &ANYTHING
ESCAPED = *ESCAPED
ESCAPED = ESCAPED + UNKNOWN
*ESCAPED = NONLOCAL
NONLOCAL = &NONLOCAL
NONLOCAL = &ESCAPED
INTEGER = &ANYTHING
_5 = _4
ESCAPED = _5

Collapsing static cycles and doing variable substitution
Building predecessor graph
Detecting pointer and location equivalences
Rewriting constraints and unifying variables
Uniting pointer but not location equivalent variables
Finding indirect cycles
Solving graph

Points-to sets

ANYTHING = { ANYTHING }
ESCAPED = { }
NONLOCAL = { ESCAPED NONLOCAL }
STOREDANYTHING = { }
INTEGER = { ANYTHING }
f = { }
_4 = { }
_5 = { }


Alias information for g

Aliased symbols


Call clobber information

ESCAPED, points-to vars: { }

Flow-insensitive points-to information


g ()
{
  long int i;
  const char * p;
  char _4;
  int _5;

   :
  _4 = MEM[(const char *)"123" + -9223372036854775807B];
  _5 = (int) _4;
  f (_5);
  return;

}



;; Function g (g, funcdef_no=0, decl_uid=1900, cgraph_uid=1, symbol_order=0)

g ()
{
  long int i;
  const char * p;

   :
  f (50);
  return;

}

[Bug target/86612] New: __strdup problem on power 9

[seurer at gcc dot gnu.org]

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

Bug ID: 86612
   Summary: __strdup problem on power 9
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Note that this occurs with gcc 7 and gcc 8 as well and goes back quite far in
revisions (at least to where gcc 8 was split off trunk).

On a power 9 system with a fresh tree built from trunk (specifically r262905):

seurer:~/gcc/build/gcc-test$ /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/pr58673-2.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -mcpu=power8 -O3
-funroll-loops -S -o pr58673-2.s
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/pr58673-2.c: In
function 'pr_ff':
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/pr58673-2.c:143:14:
warning: implicit declaration of function '__strdup'; did you mean 'strdup'?
[-Wimplicit-function-declaration]
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/pr58673-2.c:143:8:
warning: pointer/integer type mismatch in conditional expression
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/pr58673-2.c:168:8:
warning: pointer/integer type mismatch in conditional expression
seurer:~/gcc/build/gcc-test$ 


On a power 8 system with the same revision there are no warnings for either BE
or LE.

[Bug tree-optimization/86611] missing -Warray-bounds on a large negative index into a string in lp64

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
Ditto for the following (distilled from gcc.dg/Warray-bounds-31.c:

void f (int);

void g (void)
{
  const char *q = "12345678" + 4;
  __PTRDIFF_TYPE__ i = __PTRDIFF_MAX__ - 3;
  f (q[i]);
}

[Bug tree-optimization/86611] missing -Warray-bounds on a large negative index into a string in lp64

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Another test case, except this one triggers a warning in lp64 but not in ilp32,
because of the same folding in fre1:

void f (int);

void g (void)
{
  f (L"123456789"[-__PTRDIFF_MAX__ - 1]); 
}

[Bug tree-optimization/86613] New: missing -Warray-bounds on a wide string access due to ccp folding

[msebor at gcc dot gnu.org]

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

Bug ID: 86613
   Summary: missing -Warray-bounds on a wide string access due to
ccp folding
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Similar to bug 86611 but with a different root cause, GCC fails to diagnose the
out-of-bounds array index in the following test case, in both ilp32 and lp64. 
According to the dumps, the underlying root cause appears to be that the
invalid array dereference is folded in ccp1.

$ cat c.c && gcc -O2 -S -Warray-bounds -Wno-stringop-overflow
-fdump-tree-objsz=/dev/stdout -fdump-tree-ccp1=/dev/stdout c.c -m32
void f (int);

void h (void)
{
  __PTRDIFF_TYPE__ i = -__PTRDIFF_MAX__ - 1;
  f (L"123456789"[i]);
}


;; Function h (h, funcdef_no=0, decl_uid=1841, cgraph_uid=1, symbol_order=0)

h ()
{
  int i;
  long int _1;

   :
  i_2 = -2147483648;
  _1 = "1"[i_2];
  f (_1);
  return;

}



;; Function h (h, funcdef_no=0, decl_uid=1841, cgraph_uid=1, symbol_order=0)

h ()
{
  int i;
  long int _1;

   :
  _1 = "1"[-2147483648];
  f (_1);
  return;

}



;; Function h (h, funcdef_no=0, decl_uid=1841, cgraph_uid=1, symbol_order=0)

h ()
{
   [local count: 1073741825]:
  f (49);
  return;

}

[Bug tree-optimization/86611] missing -Warray-bounds on a large negative index into a string in lp64

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=86613
 Blocks||56456

--- Comment #3 from Martin Sebor  ---
See also bug 86613 for a similar problem but with a different root cause.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds

[Bug tree-optimization/86613] missing -Warray-bounds on a wide string access due to ccp folding

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
Author: msebor
Date: Fri Jul 20 16:38:43 2018
New Revision: 262906

URL: https://gcc.gnu.org/viewcvs?rev=262906&root=gcc&view=rev
Log:
PR tree-optimization/86613 - missing -Warray-bounds on a wide string access due
to ccp folding
PR tree-optimization/86611 - missing -Warray-bounds on a large negative index
into a string in lp64

gcc/testsuite/ChangeLog:
* gcc/testsuite/c-c++-common/Warray-bounds-2.c: Undefine macros and
prune duplicate warnings.
* gcc/testsuite/gcc.dg/Warray-bounds-31.c: Xfail test cases with
data-model-dependencies.
* gcc/testsuite/gcc.dg/Warray-bounds-32.c: Ditto.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c
trunk/gcc/testsuite/gcc.dg/Warray-bounds-31.c
trunk/gcc/testsuite/gcc.dg/Warray-bounds-32.c

[Bug tree-optimization/86611] missing -Warray-bounds on a large negative index into a string in lp64

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Fri Jul 20 16:38:43 2018
New Revision: 262906

URL: https://gcc.gnu.org/viewcvs?rev=262906&root=gcc&view=rev
Log:
PR tree-optimization/86613 - missing -Warray-bounds on a wide string access due
to ccp folding
PR tree-optimization/86611 - missing -Warray-bounds on a large negative index
into a string in lp64

gcc/testsuite/ChangeLog:
* gcc/testsuite/c-c++-common/Warray-bounds-2.c: Undefine macros and
prune duplicate warnings.
* gcc/testsuite/gcc.dg/Warray-bounds-31.c: Xfail test cases with
data-model-dependencies.
* gcc/testsuite/gcc.dg/Warray-bounds-32.c: Ditto.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c
trunk/gcc/testsuite/gcc.dg/Warray-bounds-31.c
trunk/gcc/testsuite/gcc.dg/Warray-bounds-32.c

[Bug tree-optimization/86614] New: duplicate -Warray-bounds for a strncpy call with out-of-bounds offset

[msebor at gcc dot gnu.org]

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

Bug ID: 86614
   Summary: duplicate -Warray-bounds for a strncpy  call with
out-of-bounds offset
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

With the recent enhancement to -Warray-bounds (bug 84047) GCC issues duplicate
instances of the warning for calls to some built-in functions with out-of-bound
offsets.  The following test case was isolated from
c-c++-common/Warray-bounds-2.c (r262906 prunes these duplicates from the test
to avoid spurious failures).

$ cat c.c && gcc -O2 -S -Warray-bounds c.c
extern char* strncpy (char*, const char*, __SIZE_TYPE__);

void sink (void*);

struct { char b[17]; } a[2];

void g (const char *s, unsigned n)
{
  int i = (char*)a[1].b - (char*)a + 1;
  char *d = a[1].b;
  strncpy (d + i, s, n);
}
c.c: In function ‘g’:
c.c:11:3: warning: array subscript 35 is outside array bounds of ‘struct
[2]’ [-Warray-bounds]
   strncpy (d + i, s, n);
   ^
c.c:11:3: warning: ‘strncpy’ offset 35 is out of the bounds [0, 34] of object
‘a’ with type ‘struct [2]’ [-Warray-bounds]
c.c:5:24: note: ‘a’ declared here
 struct { char b[17]; } a[2];
^

[Bug c++/86610] [8/9 Regression] non-const operator erroneously called in lambda in templated function

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||7.3.0
   Keywords||rejects-valid
   Last reconfirmed||2018-07-20
 CC||nathan at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|non-const operator  |[8/9 Regression] non-const
   |erroneously called in   |operator erroneously called
   |lambda in templated |in lambda in templated
   |function|function
  Known to fail||8.1.0, 9.0

--- Comment #1 from Jonathan Wakely  ---
Seems to have started with r255605

[PR C++/15272] lookups with ambiguating dependent base

https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00766.html
PR c++/15272
* pt.c (tsubst_baselink): Don't repeat the lookup for
non-dependent baselinks.

PR c++/15272
* g++.dg/template/pr71826.C: Adjust for 15272 fix.

[Bug target/86592] [9 regression] gcc.target/powerpc/p8-vec-xl-xst-v2.c fails starting with r261510

[willschm at gcc dot gnu.org]

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

Will Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-07-20
 Ever confirmed|0   |1

[Bug libstdc++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

[jakub at gcc dot gnu.org]

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

--- Comment #27 from Jakub Jelinek  ---
Created attachment 44415
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44415&action=edit
gcc9-p0595r1.patch

Untested patch that passes the testcase in P0595R1.

[Bug middle-end/78809] Inline strcmp with small constant strings

[qinzhao at gcc dot gnu.org]

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

--- Comment #42 from qinzhao at gcc dot gnu.org ---
just checked in the patch for fixing the unsigned char issue as:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=262907

[Bug c/86615] New: gcc build failure: auto-host.h error: declaration does not declare anything [-fpermissive]

[mdenber at gmx dot com]

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

Bug ID: 86615
   Summary: gcc build failure:  auto-host.h error: declaration
does not declare anything [-fpermissive]
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mdenber at gmx dot com
  Target Milestone: ---

On a Sun Enterprise M3000 SPARC64 VII running Solaris 10U11 with opencsw build
tools, I am trying to build gcc 6.4.0 using gcc 4.9.2.  I get the following
errors.  There seems to be two other references here to this "fpermissive"
stuff, bugs 56954 and 82590.  One of these got no replies, the other did not
apply to 6.4.0 and the suggestion was to just comment out the offending lines
in the source code.

I'm also getting two other "conflicting declaration" errors.


gmake[3]: Entering directory
'/export/home/michele/gcc-6.4.0/host-sparc-sun-solaris2.10/gcc'
/export/home/michele/gcc-6.4.0/host-sparc-sun-solaris2.10/prev-gcc/xg++
-B/export/home/michele/gcc-6.4.0/host-sparc-sun-solaris2.10/prev-gcc/
-B/usr/local/sparc-sun-solaris2.10/bin/ -nostdinc++
-B/export/home/michele/gcc-6.4.0/prev-sparc-sun-solaris2.10/libstdc++-v3/src/.libs
-B/export/home/michele/gcc-6.4.0/prev-sparc-sun-solaris2.10/libstdc++-v3/libsupc++/.libs
-I/export/home/michele/gcc-6.4.0/prev-sparc-sun-solaris2.10/libstdc++-v3/include/sparc-sun-solaris2.10
-I/export/home/michele/gcc-6.4.0/prev-sparc-sun-solaris2.10/libstdc++-v3/include
-I/export/home/michele/gcc-6.4.0/libstdc++-v3/libsupc++
-L/export/home/michele/gcc-6.4.0/prev-sparc-sun-solaris2.10/libstdc++-v3/src/.libs
-L/export/home/michele/gcc-6.4.0/prev-sparc-sun-solaris2.10/libstdc++-v3/libsupc++/.libs
-c -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H
-DGENERATOR_FILE -fno-PIE -I. -Ibuild -I../.././gcc -I../.././gcc/build
-I../.././gcc/../include -I./../intl -I../.././gcc/../libcpp/include \
-o build/genmddeps.o ../.././gcc/genmddeps.c
In file included from ./bconfig.h:3:0,
from ../.././gcc/genmddeps.c:18:
./auto-host.h:2321:16: error: declaration does not declare anything
[-fpermissive]
#define rlim_t long
^
In file included from ../.././gcc/genmddeps.c:19:0:
../.././gcc/system.h:496:48: error: ‘char* strstr(const char*, const char*)’
conflicts with a previous declaration
extern char strstr (const char , const char *);
^
In file included from /usr/include/string.h:18:0,
from
/export/home/michele/gcc-6.4.0/prev-sparc-sun-solaris2.10/libstdc++-v3/include/cstring:42,
from ../.././gcc/system.h:235,
from ../.././gcc/genmddeps.c:19:
/usr/include/iso/string_iso.h:119:20: note: previous declaration ‘const char*
std::strstr(const char*, const char*)’
extern const char strstr(const char , const char *);
^~
In file included from ../.././gcc/genmddeps.c:19:0:
../.././gcc/system.h:540:20: error: conflicting declaration of C function
‘const char* strsignal(int)’
extern const char *strsignal (int);
^
In file included from
/export/home/michele/gcc-6.4.0/prev-sparc-sun-solaris2.10/libstdc++-v3/include/cstring:42:0,
from ../.././gcc/system.h:235,
from ../.././gcc/genmddeps.c:19:
/usr/include/string.h:79:14: note: previous declaration ‘char* strsignal(int)’
extern char *strsignal(int);
^
gmake[3]: *** [Makefile:2497: build/genmddeps.o] Error 1
gmake[3]: Leaving directory
'/export/home/michele/gcc-6.4.0/host-sparc-sun-solaris2.10/gcc'
gmake[2]: *** [Makefile:4425: all-stage2-gcc] Error 2
gmake[2]: Leaving directory '/export/home/michele/gcc-6.4.0'
gmake[1]: *** [Makefile:21971: stage2-bubble] Error 2
gmake[1]: Leaving directory '/export/home/michele/gcc-6.4.0'
gmake: *** [Makefile:909: all] Error 2
#

[Bug c/86615] gcc build failure: auto-host.h error: declaration does not declare anything [-fpermissive]

[mdenber at gmx dot com]

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

--- Comment #1 from Michele Denber  ---
Forgot to add I'm already using:

# echo $CFLAGS
-fpermissive
# echo $CXXFLAGS
-fpermissive
#

Then just "gmake".

[Bug testsuite/86616] New: [9 regression] c-c++-common/Warray-bounds-2.c fails starting with r262893

[seurer at gcc dot gnu.org]

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

Bug ID: 86616
   Summary: [9 regression] c-c++-common/Warray-bounds-2.c fails
starting with r262893
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This test cases needs updating with this revision

> FAIL: c-c++-common/Warray-bounds-2.c  -Wc++-compat  (test for excess errors)
> FAIL: c-c++-common/Warray-bounds-2.c  -std=gnu++11 (test for excess errors)
> FAIL: c-c++-common/Warray-bounds-2.c  -std=gnu++14 (test for excess errors)
> FAIL: c-c++-common/Warray-bounds-2.c  -std=gnu++98 (test for excess errors)

One example:

spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++98 -O2 -Warray-bounds -Wno-stringop-overflow -S -o Warray-bounds-2.s
In function 'void wrap_memcpy_src_xsize(char*, const char*, ptrdiff_t,
size_t)',
inlined from 'void call_memcpy_src_xsize(char*, size_t)' at
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c:37:25:
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c:30:10:
warning: 'void* memcpy(void*, const void*, size_t)' offset 46 is out of the
bounds [0, 45] of object 'ar' with type 'Array' [-Warray-bounds]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c: In
function 'void call_memcpy_src_xsize(char*, size_t)':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c:35:16:
note: 'ar' declared here
In function 'void wrap_memcpy_src_diff_max(char*, const char*, ptrdiff_t,
size_t)',
inlined from 'void call_memcpy_src_diff_max(char*, const char*, size_t)' at
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c:51:28:
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c:46:10:
warning: 'void* memcpy(void*, const void*, size_t)' pointer overflow between
offset 9223372036854775807 and size 3 [-Warray-bounds]
In function 'void wrap_memcpy_dst_xsize(char*, const char*, ptrdiff_t,
size_t)',
inlined from 'void call_memcpy_dst_xsize(const char*, size_t)' at
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c:64:25:
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c:57:10:
warning: 'void* memcpy(void*, const void*, size_t)' offset 47 is out of the
bounds [0, 45] of object 'ar1' with type 'Array' [-Warray-bounds]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c: In
function 'void call_memcpy_dst_xsize(const char*, size_t)':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c:62:16:
note: 'ar1' declared here
In function 'void wrap_memcpy_dst_diff_max(char*, const char*, ptrdiff_t,
size_t)',
inlined from 'void call_memcpy_dst_diff_max(const char*, size_t)' at
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c:78:28:
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c:71:10:
warning: 'void* memcpy(void*, const void*, size_t)' offset -9223372036854775796
is out of the bounds [0, 45] of object 'ar2' with type 'Array' [-Warray-bounds]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c: In
function 'void call_memcpy_dst_diff_max(const char*, size_t)':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c:76:16:
note: 'ar2' declared here
In function 'void wrap_strcat_src_xsize(char*, const char*, ptrdiff_t)',
inlined from 'void call_strcat_src_xsize(char*)' at
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c:92:25:
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c:85:10:
warning: 'char* strcat(char*, const char*)' offset 46 is out of the bounds [0,
45] of object 'ar3' with type 'Array' [-Warray-bounds]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c: In
function 'void call_strcat_src_xsize(char*)':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c:90:16:
note: 'ar3' declared here
In function 'void wrap_strcat_dst_xsize(char*, const char*, ptrdiff_t)',
inlined from 'void call_strcat_dst_xsize(const char*)' at
/home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c:105:25

[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636

[qinzhao at gcc dot gnu.org]

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

--- Comment #7 from qinzhao at gcc dot gnu.org ---
the root cause for this bug is:

for the following call to memcmp:   __builtin_memcmp (s->s, "a", 3);

the specified length 3 is larger than the length of "a", it's clearly a
out-of-bound access. This new testing case is try to claim that, For such
out-of-bound access, we should NOT expand this call at all. 

The new added in-lining expansion was prohibited under such situation, However,
the expansion to hardware compare insn (old code) is NOT prohibited under such
situation. 

on powerPC, the above call to memcmp is expanded to hardware compare insn.
therefore, the testing case failed.

[Bug middle-end/82063] issues with arguments enabled by -Wall

[msebor at gcc dot gnu.org]

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

--- Comment #11 from Martin Sebor  ---
Author: msebor
Date: Fri Jul 20 20:51:20 2018
New Revision: 262910

URL: https://gcc.gnu.org/viewcvs?rev=262910&root=gcc&view=rev
Log:
PR middle-end/82063 - issues with arguments enabled by -Wall

gcc/ada/ChangeLog:

PR middle-end/82063
* gcc-interface/misc.c (gnat_handle_option): Change function argument
to HOST_WIDE_INT.

gcc/brig/ChangeLog:

PR middle-end/82063
* brig/brig-lang.c (brig_langhook_handle_option): Change function
argument to HOST_WIDE_INT.

gcc/c-family/ChangeLog:

PR middle-end/82063
* c-common.h (c_common_handle_option): Change function argument
to HOST_WIDE_INT.
* c-opts.c (c_common_init_options): Same.
(c_common_handle_option): Same.  Remove special handling of
OPT_Walloca_larger_than_ and OPT_Wvla_larger_than_.
* c.opt (-Walloc-size-larger-than, -Walloca-larger-than): Change
options to take a HOST_WIDE_INT argument and accept a byte-size
suffix.  Initialize.
(-Wvla-larger-than): Same.
(-Wno-alloc-size-larger-than, -Wno-alloca-larger-than): New.
(-Wno-vla-larger-than): Same.

gcc/fortran/ChangeLog:

PR middle-end/82063
* gfortran.h (gfc_handle_option): Change function argument
to HOST_WIDE_INT.
* options.c (gfc_handle_option): Same.

gcc/go/ChangeLog:

PR middle-end/82063
* go-lang.c (go_langhook_handle_option): Change function argument
to HOST_WIDE_INT.

gcc/lto/ChangeLog:

PR middle-end/82063
* lto-lang.c (lto_handle_option): Change function argument
to HOST_WIDE_INT.

gcc/testsuite/ChangeLog:

PR middle-end/82063
* gcc/testsuite/c-c++-common/pr68657-1.c: Adjust.
* gcc/testsuite/c-c++-common/pr68657-2.c: Same.
* gcc/testsuite/c-c++-common/pr68657-3.c: Same.
* gcc.dg/Walloc-size-larger-than-16.c: Same.
* gcc.dg/Walloca-larger-than.c: New test.
* gcc.dg/Walloca-larger-than-2.c: New test.
* gcc.dg/Wframe-larger-than-2.c: New test.
* gcc.dg/Wlarger-than3.c: New test.
* gcc.dg/Wvla-larger-than-3.c: New test.
* gcc.dg/pr42611.c: Adjust.
* gnat.dg/frame_overflow.adb: Same.

gcc/ChangeLog:

PR middle-end/82063
* builtins.c (expand_builtin_alloca): Adjust.
* calls.c (alloc_max_size): Simplify.
* cgraphunit.c (cgraph_node::expand): Adjust.
* common.opt (larger_than_size, warn_frame_larger_than): Remove
variables.
(frame_larger_than_size): Same.
(-Wframe-larger-than, -Wlarger-than, -Wstack-usage): Change options
to take a HOST_WIDE_INT argument and accept a byte-size suffix.
Initialize.
* doc/invoke.texi (GCC Command Options): Document option arguments.
Explain byte-size arguments and suffixes.
(-Wvla-larger-than, -Wno-alloc-size-larger-than): Update.
(-Wno-alloca-larger-than, -Wno-vla-larger-than): Same.
(-Wframe-larger-than, -Wlarger-than, -Wstack-usage): Same.
* doc/options.texi (UInteger): Expand.
(Host_Wide_Int, ByteSize): Document new properties.
* final.c (final_start_function_1): Include sizes in an error message.
* function.c (frame_offset_overflow): Same.
* gimple-ssa-warn-alloca.c (pass_walloca::gate): Adjust.
(alloca_call_type_by_arg): Change function argument to HOST_WIDE_INT.
Diagnose unbounded alloca calls only for limits of less than
PTRDIFF_MAX.
(alloca_call_type): Adjust.  Diagnose possibly out-of-bounds alloca
calls and VLA size only for limits of less than PTRDIFF_MAX.  Same
for alloca(0).
(pass_walloca::execute): Adjust.  Diagnose alloca calls in loops
only for limits of less than PTRDIFF_MAX.
* langhooks-def.h (lhd_handle_option): Change function argument
to HOST_WIDE_INT.
* langhooks.c (lhd_handle_option): Same.
* langhooks.h (handle_option): Same.
* opt-functions.awk (switch_bit_fields): Handle Host_Wide_Int and
ByteSize flags.
(var_type, var_type_struct): Same.
(var_set): Handle ByteSize flag.
* optc-gen.awk: Add comments to output to ease debugging.  Make
use of HOST_WIDE_INT where appropriate.
* opts-gen-save.awk:  Use %lx to format unsigned long.
* opth-gen.awk: Change function argument to HOST_WIDE_INT.
* opts-common.c (integral_argument): Return HOST_WIDE_INT and add
arguments.  Parse bytes-size suffixes.
(enum_arg_to_value): Change function argument to HOST_WIDE_INT.
(enum_value_to_arg): Same.
(decode_cmdline_option): Handle cl_host_wide_int.  Adjust.
(handle_option): Adjust.
(generate_option): Change function argument to HOST_WIDE_INT.
(cmdline_handle_error): Adjust.
(read_cmd

[Bug middle-end/82063] issues with arguments enabled by -Wall

[msebor at gcc dot gnu.org]

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

--- Comment #12 from Martin Sebor  ---
Author: msebor
Date: Fri Jul 20 21:18:31 2018
New Revision: 262911

URL: https://gcc.gnu.org/viewcvs?rev=262911&root=gcc&view=rev
Log:
PR middle-end/82063

gcc/testsuite/ChangeLog:

* gcc/testsuite/c-c++-common/pr68833-1.c: Adjust.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/pr68833-1.c

[Bug middle-end/82063] issues with arguments enabled by -Wall

[msebor at gcc dot gnu.org]

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

--- Comment #13 from Martin Sebor  ---
Author: msebor
Date: Fri Jul 20 21:19:49 2018
New Revision: 262912

URL: https://gcc.gnu.org/viewcvs?rev=262912&root=gcc&view=rev
Log:
PR middle-end/82063 - issues with arguments enabled by -Wall

gcc/c-family/ChangeLog:
* gcc/c-family/c.opt (-Warray-bounds): Remove redundant -Wall.

Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt

[Bug middle-end/82063] issues with arguments enabled by -Wall

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #14 from Martin Sebor  ---
All the issues here should be addressed now.  Resolving as fixed.

[Bug testsuite/86616] [9 regression] c-c++-common/Warray-bounds-2.c fails starting with r262893

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #1 from Martin Sebor  ---
I committed r262906 earlier today to fix a number of failures in some of the
-Warray-bounds tests (see
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01198.html).  The
c-c++-common/Warray-bounds-2.c test passes for me now with a powerpc64le
cross-compiler so these failures should be resolved by that commit.

[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #8 from Martin Sebor  ---
FWIW, it would be safer and more deterministic to fold these invalid calls to
some non-zero value that it is to emit the invalid library call.  With a small
string, the risk that the call will crash is small but the result could still
be different depending on how strings are laid out in memory.  With larger
strings, the risk is greater as will be the non-determinism.

[Bug c/86617] New: Volatile qualifier is ignored sometimes for unsigned char

[yso at melexis dot com]

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

Bug ID: 86617
   Summary: Volatile qualifier is ignored sometimes for unsigned
char
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yso at melexis dot com
  Target Milestone: ---

I'm using http://gcc.godbolt.org/ to reproduce this issue.

Compiler: x86-64 gcc (trunk); gcc (GCC-Explorer-Build) 9.0.0 20180719 
Options: -Os

Test code:  
```
volatile unsigned char u8;

void test (void)
{
u8 = u8 + u8;
u8 = u8 - u8;
}
```

Disassembly:  
```
test:
mov al, BYTE PTR u8[rip]
add eax, eax
mov BYTE PTR u8[rip], al

mov al, BYTE PTR u8[rip]
mov BYTE PTR u8[rip], 0
ret
```

In the addition expression `u8 + u8`, volatile variable u8 is copied to the
register only once and then register is doubled. This seems incorrect, as
volatile variable shall be read out from the memory also for the second term of
the sum.

In the subtraction expression `u8 - u8`, result (0) is calculated at compile
time without explicit subtraction.

Also can be reproduced in:
- x86-64 gcc 8.1; gcc (GCC-Explorer-Build) 8.1.0
- x86-64 gcc 7.3; gcc (GCC-Explorer-Build) 7.3.0
- x86-64 gcc 6.3; gcc (GCC-Explorer-Build) 6.3.0
- x86-64 gcc 5.4; gcc (GCC-Explorer-Build) 5.4.0

When g++ is used to compile the same code, everything is fine!

Compiler: x86-64 gcc (trunk); g++ (GCC-Explorer-Build) 9.0.0 20180719 
Options: -Os

Disassembly:
```
_Z3foov:
mov al, BYTE PTR u8[rip]
mov dl, BYTE PTR u8[rip]
add eax, edx
mov BYTE PTR u8[rip], al

mov al, BYTE PTR u8[rip]
mov dl, BYTE PTR u8[rip]
sub eax, edx
mov BYTE PTR u8[rip], al
ret
u8:
.zero   1
```

[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #35 from The Written Word  
---
I am trying to build 4.9.4 with a patched 4.7.4 and am running into the
following failure:
/opt/build/china/gcc-4.9.4/.obj/./gcc/xgcc
-B/opt/build/china/gcc-4.9.4/.obj/./gcc/
-B/opt/build/gcc49/ia64-hp-hpux11.31/bin/
-B/opt/build/gcc49/ia64-hp-hpux11.31/lib/ -isystem
/opt/build/gcc49/ia64-hp-hpux11.31/include -isystem
/opt/build/gcc49/ia64-hp-hpux11.31/sys-include-g -O2 -O2  -g -O2 -DIN_GCC  
 -DUSE_LIBUNWIND_EXCEPTIONS -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector  
-I. -I. -I../.././gcc -I/opt/build/china/gcc-4.9.4/libgcc
-I/opt/build/china/gcc-4.9.4/libgcc/.
-I/opt/build/china/gcc-4.9.4/libgcc/../gcc
-I/opt/build/china/gcc-4.9.4/libgcc/../include  -DHAVE_CC_TLS  -o emutls.o -MT
emutls.o -MD -MP -MF emutls.dep -fexceptions -c
/opt/build/china/gcc-4.9.4/libgcc/emutls.c -fvisibility=hidden -DHIDE_EXPORTS
/opt/build/china/gcc-4.9.4/libgcc/emutls.c: In function '__emutls_get_address':
/opt/build/china/gcc-4.9.4/libgcc/emutls.c:188:1: internal compiler error: in
simplify_subreg, at simplify-rtx.c:5917
 }
 ^

Should I build this with -O0 as well?

[Bug target/71045] [SH] gcc.dg/torture/pr68264.c -O0 and -Os failures

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org,
   ||um at mutluit dot com
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=68264,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=68356

--- Comment #3 from Eric Gallager  ---
(In reply to Oleg Endo from comment #2)
> (In reply to Kazumoto Kojima from comment #1)
> > (In reply to Oleg Endo from comment #0)
> > > Kaz, do you know what's going wrong there?  Some silent wrong code related
> > > to fenv maybe?
> > 
> > Maybe, though I have no idea for what is going on.
> > You can see that those tests fail on several other targets:
> > 
> > powerpc-ibm-aix7.1.0.0
> > https://gcc.gnu.org/ml/gcc-testresults/2016-05/msg00925.html
> > x86_64-unknown-freebsd9.3
> > https://gcc.gnu.org/ml/gcc-testresults/2016-05/msg00932.html
> > i386-unknown-freebsd10.3
> > https://gcc.gnu.org/ml/gcc-testresults/2016-05/msg00919.html
> 
> Oh, good to know.  Thanks for checking.  Probably we can close this PR as
> "invalid" after a while...

U.Mutlu says it still fails here:
https://gcc.gnu.org/ml/gcc-help/2018-07/msg00179.html