[Bug tree-optimization/85698] [8/9 Regression] CPU2017 525.x264_r fails starting with r257581

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-15
 Ever confirmed|0   |1

[Bug tree-optimization/83648] missing -Wsuggest-attribute=malloc on a trivial malloc-like function

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #3 from prathamesh3492 at gcc dot gnu.org ---
Author: prathamesh3492
Date: Tue May 15 06:07:48 2018
New Revision: 260250

URL: https://gcc.gnu.org/viewcvs?rev=260250&root=gcc&view=rev
Log:
2018-05-15  Prathamesh Kulkarni  

PR tree-optimization/83648
* ipa-pure-const.c (malloc_candidate_p): Allow function with NULL
return value as malloc candidate.

testsuite/
* gcc.dg/tree-ssa/pr83648.c: New test.
* gcc.dg/tree-ssa/pr83648-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr83648-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr83648.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-pure-const.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/85698] [8/9 Regression] CPU2017 525.x264_r fails starting with r257581

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #8 from Segher Boessenkool  ---
Created attachment 44133
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44133&action=edit
patch

This has existed for five years (r199918).  Wow.

[Bug c++/85783] alloc-size-larger-than fires incorrectly with new[] and can't be disabled

[psmith at gnu dot org]

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

--- Comment #4 from Paul Smith  ---
Well, clearly I disagree with this conclusion and feel this is a bug.

At the very least, the fact that it's impossible to disable the warning needs
to be considered a bug.  The statement on the mailing list from Martin Sebor
was:

> -Walloc-size-larger-than, like most (all?) other middle-end
> warnings, is designed to trigger only for calls that truly have
> an argument in excess of the limit.  Unlike -Wmaybe-uninitialized,
> it is not intended to diagnose case where the argument may but
> need not be excessive (i.e., it's not expected to have false
> positives, and I don't think it is particularly prone to them).

If this WONTFIX resolution means that we are not going to fix known false
positives for this warning, then IMO the above description of the situation is
not accurate and we should add the ability to disable the warning.

[Bug target/85756] [9 regression] wrong code at -Os on x86-64-linux-gnu in 32-bit mode

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Jakub Jelinek  ---
Fixed.

[Bug target/85683] [8 Regression] GCC 8 stopped using RMW (Read Modify Write) instructions on x86[_64]

[jakub at gcc dot gnu.org]

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

Bug 85756 Summary: [9 regression] wrong code at -Os on x86-64-linux-gnu in 
32-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85756

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug ipa/85787] malloc_candidate_p fails to detect malloc attribute on nested phis

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #1 from prathamesh3492 at gcc dot gnu.org ---
Working on a patch.

[Bug ipa/85787] New: malloc_candidate_p fails to detect malloc attribute on nested phis

[prathamesh3492 at gcc dot gnu.org]

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

Bug ID: 85787
   Summary: malloc_candidate_p fails to detect malloc attribute on
nested phis
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prathamesh3492 at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

For the following test-case, g should have been detected as malloc-like
function by malloc_candidate_p().

void *g (int cond1, int cond2, int cond3)
{
  void *ret;
  void *a;
  void *b;

  if (cond1)
a = __builtin_malloc (10);
  else
a = __builtin_malloc (20);

  if (cond2)
b = __builtin_malloc (30);
  else
b = __builtin_malloc (40);

  if (cond3)
ret = a;
  else
ret = b;

  return ret;
}

[Bug c/85562] -Wsuggest-attribute=malloc misleads about "returning normally"

[prathamesh3492 at gcc dot gnu.org]

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

prathamesh3492 at gcc dot gnu.org changed:

   What|Removed |Added

 CC||prathamesh3492 at gcc dot 
gnu.org

--- Comment #3 from prathamesh3492 at gcc dot gnu.org ---
Fix for PR85734 also fixes this bug.

[Bug ipa/85734] --suggest-attribute=malloc misdiagnoses static functions

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #5 from prathamesh3492 at gcc dot gnu.org ---
Fixed on trunk.

[Bug fortran/85786] Segfault in associated intrinsic

[angus at agibson dot me]

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

--- Comment #2 from Angus Gibson  ---
Changing the declaration of e to also be 'target', and associating the pointer:

CS%v(2)%p => e
if (query_ptr(e, CS)) then
...

still causes the segfault.  Perhaps I disconnected this from the original code
too much! Even if CS%v(2)%p wasn't associated, I don't see why there should be
a segfault?

[Bug ipa/85734] --suggest-attribute=malloc misdiagnoses static functions

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #4 from prathamesh3492 at gcc dot gnu.org ---
Author: prathamesh3492
Date: Tue May 15 04:44:33 2018
New Revision: 260249

URL: https://gcc.gnu.org/viewcvs?rev=260249&root=gcc&view=rev
Log:
2018-05-15  Prathamesh Kulkarni  

PR ipa/85734
* ipa-pure-const.c (warn_function_malloc): Pass value of known_finite
param
as true in call to suggest_attribute.

testsuite/
* gcc.dg/ipa/pr85734.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/ipa/pr85734.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-pure-const.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/85786] Segfault in associated intrinsic

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Angus Gibson from comment #0)
> Created attachment 44132 [details]
> Segfaulting example
> 
> I've run into a bit of a heisenbug regarding the associated intrinsic
> (example attached).  On my machine, it'll reliably hit a segmentation fault
> inside the gfortran implementation of the intrinsic.  I've pared it down a
> lot from the original codebase in which it happened, but it's still a bit
> complex.  Curiously, it seems to require a print statement in query_ptr to
> trigger (this actually isn't in the original codebase, but there are a few
> external calls there that I didn't replicate).

So, what is cs%v(2)%p associated to?

if (.not.associated(CS%v(2)%p)) then
  print *, 'in query'
endif

query_ptr = associated(CS%v(2)%p, f_ptr)

[Bug fortran/68950] [fortran] gfc_format_decoder cannot handle %qE

[kargl at gcc dot gnu.org]

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

--- Comment #10 from kargl at gcc dot gnu.org ---
(In reply to Eric Gallager from comment #9)
> (In reply to Tom de Vries from comment #8)
> > (In reply to vries from comment #6)
> > > posted RFC: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01749.html
> > 
> > pinged: https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00831.html
> 
> Please keep pinging!

If you're looking for a Fortran maintainer's approval, then
one may want to submit the patch to fort...@gcc.gnu.org.
Otherwise, it is unlikely that a Fortran maintainer will
take notice.

[Bug fortran/85786] New: Segfault in associated intrinsic

[angus at agibson dot me]

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

Bug ID: 85786
   Summary: Segfault in associated intrinsic
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: angus at agibson dot me
  Target Milestone: ---

Created attachment 44132
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44132&action=edit
Segfaulting example

I've run into a bit of a heisenbug regarding the associated intrinsic (example
attached).  On my machine, it'll reliably hit a segmentation fault inside the
gfortran implementation of the intrinsic.  I've pared it down a lot from the
original codebase in which it happened, but it's still a bit complex. 
Curiously, it seems to require a print statement in query_ptr to trigger (this
actually isn't in the original codebase, but there are a few external calls
there that I didn't replicate).

[Bug c++/66662] Request: Change #error directive displaying

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-15
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Confirmed.

[Bug fortran/68950] [fortran] gfc_format_decoder cannot handle %qE

[egallager at gcc dot gnu.org]

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

--- Comment #9 from Eric Gallager  ---
(In reply to Tom de Vries from comment #8)
> (In reply to vries from comment #6)
> > posted RFC: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01749.html
> 
> pinged: https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00831.html

Please keep pinging!

[Bug target/65604] MIPS -fno-delayed-branch generates incorrect code with -mcheck-zero-division

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-05-15
 Ever confirmed|0   |1

--- Comment #7 from Eric Gallager  ---
(In reply to Eric Gallager from comment #6)
> (In reply to Steve Ellcey from comment #4)
> > Author: sje
> > Date: Fri Jan 29 16:29:58 2016
> > New Revision: 232985
> > 
> > URL: https://gcc.gnu.org/viewcvs?rev=232985&root=gcc&view=rev
> > Log:
> > PR target/65604
> > * config/mips/mips.c (mips_output_division): Check flag_delayed_branch.
> > 
> > Modified:
> > trunk/gcc/ChangeLog
> > trunk/gcc/config/mips/mips.c
> 
> (In reply to Steve Ellcey from comment #5)
> > Author: sje
> > Date: Fri Jan 29 16:31:18 2016
> > New Revision: 232986
> > 
> > URL: https://gcc.gnu.org/viewcvs?rev=232986&root=gcc&view=rev
> > Log:
> > PR target/65604
> > * gcc.target/mips/div-delay.c: New test.
> > 
> > Added:
> > trunk/gcc/testsuite/gcc.target/mips/div-delay.c
> > Modified:
> > trunk/gcc/testsuite/ChangeLog
> 
> Did these commits fix this bug?

WAITING on an answer...

[Bug tree-optimization/85785] New: missing warning on strcat overflow after strcpy

[msebor at gcc dot gnu.org]

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

Bug ID: 85785
   Summary: missing warning on strcat overflow after strcpy
   Product: gcc
   Version: 8.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: ---

In the test case below, GCC correctly detects and diagnoses the buffer overflow
in f() (although it issues a -Warray-bounds when the more suitable warning is
-Wstringop-overflow) but it fails to detect the same overflow in the equivalent
g().

$ cat u.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout u.c
#include 

#undef strcpy
#undef strcat

char d[6];

void f (void)
{
  __builtin_memcpy (d, "1234", 4);
  __builtin_memcpy (d + 4, "5678", 5);   // warning (good)
}

void g (void)
{
  strcat (strcpy (d, "1234"), "5678");   // missing warning
}
u.c: In function ‘f’:
u.c:11:3: warning: ‘__builtin_memcpy’ forming offset [7, 9] is out of the
bounds [0, 6] of object ‘d’ with type ‘char[6]’ [-Warray-bounds]
   __builtin_memcpy (d + 4, "5678", 5);   // warning (good)
   ^~~
u.c:6:6: note: ‘d’ declared here
 char d[6];
  ^

;; Function f (f, funcdef_no=4, decl_uid=2193, cgraph_uid=4, symbol_order=5)

f ()
{
   [local count: 1073741825]:
  __builtin_memcpy (&d, "1234", 4);
  __builtin_memcpy (&MEM[(void *)&d + 4B], "5678", 5); [tail call]
  return;

}



;; Function g (g, funcdef_no=5, decl_uid=2196, cgraph_uid=5, symbol_order=6)

g ()
{
  char * _1;
  char * _5;

   [local count: 1073741825]:
  _1 = __builtin_memcpy (&d, "1234", 4);
  _5 = _1 + 4;
  __builtin_memcpy (_5, "5678", 5); [tail call]
  return;

}

[Bug c++/85783] alloc-size-larger-than fires incorrectly with new[] and can't be disabled

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #3 from Martin Sebor  ---
I can reproduce it with the following reduced semi-valid test case.  (The test
case isn't entirely valid because it defines the array new to exit on failure
rather than to throw, but a nothrow form of the test case reproduces the
warning as well.)

void* operator new[](__SIZE_TYPE__ n)
{
  void* p = __builtin_malloc (n);
  if (p)
return p;

  __builtin_exit (1);
}

struct A
{
  A ();
  ~A ();
};


void* f (__SIZE_TYPE__ n)
{
  if (!n)
return 0;

  return new A[n];
}
In function ‘void* operator new [](long unsigned int)’,
inlined from ‘void* f(long unsigned int)’ at pr85783.C:22:17:
pr85783.C:3:30: warning: argument 1 value ‘18446744073709551615’ exceeds
maximum object size 9223372036854775807 [-Walloc-size-larger-than=]
   void* p = __builtin_malloc (n);
 ~^~~
pr85783.C: In function ‘void* f(long unsigned int)’:
pr85783.C:3:30: note: in a call to built-in allocation function ‘void*
__builtin_malloc(long unsigned int)’

The excessive constant argument is introduced by the C++ front-end, in
cp/build_operator_new_call(), which emits a call to operator new[](size_t). 
The code was added in r190546 as a solution to prevent unsigned wrapping (when
array new expression must compute the amount of space to allocate as a product
of the number of elements and element size).  When the replacement operator
new[] is inlined the excessive argument is propagated to malloc() and
ultimately triggers the warning.

An easy way to suppress the warning is to check the argument in the operator
and have it fail when it's excessive:

  void* operator new[](size_t n)
  {
if (n <= PTRDIFF_MAX)
  {
void* p = malloc (n);
if (p)
  return p;
  }

exit (1);
  }

Otherwise, I'm not sure there is much GCC can do to avoid the warning, or that
it's worth putting effort into.  The use case (defining a non-throwing
replacement operator new inline) is rare and not entirely valid.  Normally, the
operator will be defined out-of-line and while that might still trigger
warnings from the same translation unit, the solution -- handling the excessive
argument in the replacement operator -- seems simple enough.

With that I'm going to resolve this report as WONTFIX.  If someone (e.g., Jeff
who chimed in on the discussion on gcc-help below) feels otherwise please feel
free to reopen it.

https://gcc.gnu.org/ml/gcc-help/2018-05/msg00088.html

[Bug other/85778] unexpected results with -O2, wrong code?

[sesail999 at gmail dot com]

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

Scott E.  changed:

   What|Removed |Added

 CC||sesail999 at gmail dot com

--- Comment #2 from Scott E.  ---
Just to add a few more details, I discovered this via "cronolog", which does
this pattern of stat() with a null pathname. Not that it makes the code
correct, and it could easily be guarded against, however this code has been
working fine since 2001 [1].

There's a few more details in the downstream bug report [2].

[1]
https://github.com/fordmason/cronolog/blame/83f9e99d6bd5cb8f5cc06723f4d79d1265582340/src/cronoutils.c#L250
[2] https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1770676

[Bug libstdc++/84159] filesystem::path::operator/= with has root directory path

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-05-14
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |8.2
 Ever confirmed|0   |1
  Known to fail||8.1.0

--- Comment #1 from Jonathan Wakely  ---
Looks like I changed path::operator/=(const path&) to conform to the C++17
semantics, but not the other overload of path::operator/= that takes strings,
nor the overloads of path::append.

[Bug tree-optimization/85259] [8/9 Regression] Missing -Wstringop-overflow= since r256683

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #5 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00652.html

[Bug libstdc++/67554] runtime error in valarray (NULL passed to memcpy)

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Mon May 14 22:35:44 2018
New Revision: 260244

URL: https://gcc.gnu.org/viewcvs?rev=260244&root=gcc&view=rev
Log:
PR libstdc++/67554 Do not pass null pointers to memcpy

PR libstdc++/67554
* include/bits/valarray_array.h (_Array_copy_ctor<_Tp, true>)
(_Array_copier<_Tp, true>): Do not pass null pointers to memcpy.

Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/include/bits/valarray_array.h

[Bug libstdc++/67554] runtime error in valarray (NULL passed to memcpy)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.5

--- Comment #5 from Jonathan Wakely  ---
Fixed for 6.5, 7.4 and 8.2, thanks for the report.

[Bug libstdc++/82966] node_handle swap fails to compile

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.4
  Known to fail||7.3.0, 8.1.0

--- Comment #4 from Jonathan Wakely  ---
Fixed for 7.4 and 8.2

[Bug libstdc++/82966] node_handle swap fails to compile

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Mon May 14 22:22:23 2018
New Revision: 260242

URL: https://gcc.gnu.org/viewcvs?rev=260242&root=gcc&view=rev
Log:
PR libstdc++/82966 fix swapping of node handles

PR libstdc++/82966
* include/bits/node_handle.h (_Node_handle_common::_M_swap): Use value
instead of type.
* testsuite/23_containers/set/modifiers/node_swap.cc: New.

Added:
   
branches/gcc-7-branch/libstdc++-v3/testsuite/23_containers/set/modifiers/node_swap.cc
Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/include/bits/node_handle.h

[Bug libstdc++/67554] runtime error in valarray (NULL passed to memcpy)

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Mon May 14 22:22:27 2018
New Revision: 260243

URL: https://gcc.gnu.org/viewcvs?rev=260243&root=gcc&view=rev
Log:
PR libstdc++/67554 Do not pass null pointers to memcpy

PR libstdc++/67554
* include/bits/valarray_array.h (_Array_copy_ctor<_Tp, true>)
(_Array_copier<_Tp, true>): Do not pass null pointers to memcpy.

Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/include/bits/valarray_array.h

[Bug libstdc++/81256] basic_filebuf::close doesn't propagate exceptions

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Fixed on trunk, thanks for the report.

[Bug tree-optimization/85698] [8/9 Regression] CPU2017 525.x264_r fails starting with r257581

[pthaugen at gcc dot gnu.org]

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

--- Comment #7 from Pat Haugen  ---
So the problem is that we're generating a stxvw4x insn to write to memory,
which corrupts the contents due to both endian behavior and element size (since
we're dealing with halfword/uint16_t elements).

Value in vector reg = 0x0002fffc0002fff5000e

stvx/good
(gdb) x/8hx $r1+$r8
0x7fffe490: 0x000e  0xfff5  0x0002  0x  0xfffc  0x0002  0x  0x


stxvw4x/bad
(gdb) x/8hx $r7+$r8
0x7fffe470: 0x  0x  0xfffc  0x0002  0x0002  0x  0x000e  0xfff5

[Bug libstdc++/67554] runtime error in valarray (NULL passed to memcpy)

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Mon May 14 21:51:51 2018
New Revision: 260241

URL: https://gcc.gnu.org/viewcvs?rev=260241&root=gcc&view=rev
Log:
PR libstdc++/67554 Do not pass null pointers to memcpy

PR libstdc++/67554
* include/bits/valarray_array.h (_Array_copy_ctor<_Tp, true>)
(_Array_copier<_Tp, true>): Do not pass null pointers to memcpy.

Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/bits/valarray_array.h

[Bug libstdc++/82966] node_handle swap fails to compile

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Mon May 14 21:51:46 2018
New Revision: 260240

URL: https://gcc.gnu.org/viewcvs?rev=260240&root=gcc&view=rev
Log:
PR libstdc++/82966 fix swapping of node handles

PR libstdc++/82966
* include/bits/node_handle.h (_Node_handle_common::_M_swap): Use value
instead of type.
* testsuite/23_containers/set/modifiers/node_swap.cc: New.

Added:
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/set/modifiers/node_swap.cc
Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/bits/node_handle.h

[Bug c++/85783] alloc-size-larger-than fires incorrectly with new[] and can't be disabled

[psmith at gnu dot org]

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

--- Comment #2 from Paul Smith  ---
> Did you try: -Wno-alloc-size-larger-than ?

Yes.

  cc1plus: error: unrecognized command line option
'-Wno-alloc-size-larger-than'

> Also in your code, numberFields is a signed int and then casted to size_t.  
> On LP64 targets (or rather sizeof(size_t) != sizeof(int)), then value is sign 
> extended.

I'm not suggesting the code is well-written.  Just that it shouldn't throw a
warning.

In any event, if I change numberFields to "unsigned int" I still get the same
warning.

[Bug c++/85783] alloc-size-larger-than fires incorrectly with new[] and can't be disabled

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Did you try:
-Wno-alloc-size-larger-than ?

Also in your code, numberFields is a signed int and then casted to size_t.  On
LP64 targets (or rather sizeof(size_t) != sizeof(int)), then value is sign
extended.

[Bug fortran/85781] ICE in gfc_build_array_ref, at fortran/trans.c:393

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed.

[Bug c++/85784] New: False positive with -Wunused-but-set-parameter

[samueljlunt at gmail dot com]

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

Bug ID: 85784
   Summary: False positive with -Wunused-but-set-parameter
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: samueljlunt at gmail dot com
  Target Milestone: ---

Given the following functions:

#include 
#include 

template 
auto foo(Args&&...)
{}

template 
auto bar(std::tuple args, std::index_sequence)
{
return foo(std::forward(std::get(args))...);
}

template 
auto bar(std::tuple args)
{
return bar(std::move(args), std::index_sequence_for{});
}

A function call "bar()" will generate a -Wunused-but-set-parameter warning,
while any call with at least one argument will not generate a warning.

I am guessing that this has something to do with the fact that when "...Args"
is empty, "foo(std::forward(std::get(args))...)" is expanded to
"foo()", and "std::tuple<> args_" is not used. However, I don't see why this
would trigger "-Wunused-but-set-parameter" (since no assignment takes places
here) instead of "-Wunused".

Either way, this seemed like a false positive to me, since in the template
function, args is used. It is only in a specific instantiation of the template
that it is not used.

Also, I noticed making args an rvalue reference, i.e.
bar(std::tuple&& args, std::index_sequence), silences
the warning.

Here is an example on godbolt.org illustrating the warning:
https://godbolt.org/g/VaA979

[Bug c++/85783] New: alloc-size-larger-than fires incorrectly with new[] and can't be disabled

[psmith at gnu dot org]

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

Bug ID: 85783
   Summary: alloc-size-larger-than fires incorrectly with new[]
and can't be disabled
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: psmith at gnu dot org
  Target Milestone: ---

Created attachment 44131
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44131&action=edit
sample source file

GCC 8.1.0 / binutils 2.30
GNU/Linux x86_64 with a sysroot of Red Hat EL 6.5.

Recently I started upgrading from GCC 7.3 to GCC 8.1.  I discovered three
locations in my codebase where the alloc-size-larger-than warning is generated.
 It wasn't ever generated with 7.3.  Since I build with -Wall -Werror this
causes compiles to fail.

The first issue is, I wasn't able to find any way to turn off this warning
other than by removing -Wall which seems entirely too severe.  There should be
some way to disable it; maybe by providing -Walloc-size-larger-than=0 or
similar.

I did work around this issue by casting the value given to new[] to type
unsigned int, but that's unpleasant.

Of course removing the false positive would be helpful as well.

I spent quite a while trying to create a small sample; the results are below. 
Most any change to this file appears to cause the warning to go away: for
example I tried to use a simple template I created rather than
std::shared_ptr<>, or even remove that field altogether: no warning.  If I
remove or modify the if-statements in the method significantly, no warning. 
Etc.  I didn't try all changes of course.  Also without optimization it doesn't
warn but with both -O1 and -O2 it does.

Results of compiling the attached file:

  $ x86_64-rh65-linux-gnu-g++ -v -o /tmp/SP.o -c -O2 -Wall -Werror params.cpp
  Using built-in specs.
 
COLLECT_GCC=/work/src/build/x86_64-linux/cc/generic/bin/x86_64-generic-linux-gnu-g++
  Target: x86_64-generic-linux-gnu
  Configured with: /work/src/cc/gcc-8.1.0/configure --disable-nls
--disable-werror --prefix=/work/src/cc/x86_64-linux/final/generic
--host=x86_64-tools-linux-gnu --target=x86_64-generic-linux-gnu
--with-sysroot=/work/src/build/x86_64-linux/sysroot/generic CFLAGS=-O2
CXXFLAGS=-O2 LDFLAGS=-O2 --enable-gold --enable-languages=c,c++
  Thread model: posix
  gcc version 8.1.0 (GCC) 
  COLLECT_GCC_OPTIONS='-m64' '-isystem' '=/usr/include-fixed' '-v' '-o'
'/tmp/SP.o' '-c' '-O2' '-Wall' '-Werror' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 
/work/src/build/x86_64-linux/cc/generic/bin/../libexec/gcc/x86_64-generic-linux-gnu/8.1.0/cc1plus
-quiet -v -iprefix
/work/src/build/x86_64-linux/cc/generic/bin/../lib/gcc/x86_64-generic-linux-gnu/8.1.0/
-isysroot /work/src/build/x86_64-linux/sysroot/rh65 -D_GNU_SOURCE -isystem
=/usr/include-fixed params.cpp -quiet -dumpbase SortParameters.cpp -m64
-mtune=generic -march=x86-64 -auxbase-strip /tmp/SP.o -O2 -Wall -Werror
-version -o /tmp/ccuJobAh.s
  GNU C++14 (GCC) version 8.1.0 (x86_64-generic-linux-gnu)
compiled by GNU C version 8.1.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.18-GMP

  GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
  Compiler executable checksum: e2fe942476766bd673c0e36030131141
  In function 'void* operator new [](size_t)',
inlined from 'static Params* Params::buildParams(size_t, Info*)' at
params.cpp:52:47:
  params.cpp:8:21: error: argument 1 value '18446744073709551615' exceeds
maximum object size 9223372036854775807 [-Werror=alloc-size-larger-than=]
   void* p = malloc(size);
 ~~^~
...
  /work/src/build/x86_64-linux/sysroot/rh65/usr/include/stdlib.h: In static
member function 'static Params* Params::buildParams(size_t, Info*)':
  /work/src/build/x86_64-linux/sysroot/rh65/usr/include/stdlib.h:471:14: note:
in a call to allocation function 'void* malloc(size_t)' declared here
   extern void *malloc (size_t __size) __THROW __attribute_malloc__ __wur;
^~
  cc1plus: all warnings being treated as errors

[Bug middle-end/85602] -Wsizeof-pointer-memaccess for strncat with size of source

[eggert at gnu dot org]

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

--- Comment #4 from Paul Eggert  ---
Thanks, that workaround is much better for coreutils, and I installed it here:

https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=f6cb50cc991d461f443ea3afc517c9e1e37ef496

[Bug fortran/85780] ICE in resolve_fl_procedure, at fortran/resolve.c:12504

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #1)

> HOwever, I think we then have an accepts invalid as an alternate
> return takes a label.  

Whoops, I may have misread the standard.  The label applies to
the actual argument.  A dummy argument of '*' alone signifies
an alternate return, the patch in #1 indeed fixes the issue.

[Bug fortran/85780] ICE in resolve_fl_procedure, at fortran/resolve.c:12504

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 CC||kargl at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
Paul,

The ICE can be fixed by checking for a NULL pointer.

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 260235)
+++ gcc/fortran/resolve.c   (working copy)
@@ -12501,7 +12501,7 @@ resolve_fl_procedure (gfc_symbol *sym, int mp_flag)
   while (curr_arg != NULL)
 {
   /* Skip implicitly typed dummy args here.  */
- if (curr_arg->sym->attr.implicit_type == 0)
+ if (curr_arg->sym && curr_arg->sym->attr.implicit_type == 0)
if (!gfc_verify_c_interop_param (curr_arg->sym))
  /* If something is found to fail, record the fact so we
 can mark the symbol for the procedure as not being

HOwever, I think we then have an accepts invalid as an alternate
return takes a label.  If I look at gfc_match_formal_arglist in 
decl.c, it looks like your PDT work may have touched the area
that should issue an error.
 81764   dnovillo   if (gfc_match_char ('*') == MATCH_YES)
197389  janus   {
197389  janus sym = NULL;
255311  pault if (!typeparam && !gfc_notify_std (GFC_STD_F95_OBS,
255311  pault"Alternate-return argument at
%C"))
197389  janus   {
197389  janus m = MATCH_ERROR;
197389  janus goto cleanup;
197389  janus   }
255311  pault else if (typeparam)
255311  pault   gfc_error_now ("A parameter name is required at
%C");
197389  janus   }

Do you have any insights?

[Bug target/85756] [9 regression] wrong code at -Os on x86-64-linux-gnu in 32-bit mode

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon May 14 20:17:19 2018
New Revision: 260239

URL: https://gcc.gnu.org/viewcvs?rev=260239&root=gcc&view=rev
Log:
PR target/85756
* gnat.dg/opt70.adb: New test.
* gnat.dg/opt70_pkg.ad[sb]: New helper.

Added:
trunk/gcc/testsuite/gnat.dg/opt70.adb
trunk/gcc/testsuite/gnat.dg/opt70_pkg.adb
trunk/gcc/testsuite/gnat.dg/opt70_pkg.ads
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/85602] -Wsizeof-pointer-memaccess for strncat with size of source

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
I agree that's not an improvement.  Would something like this be better? (at
least until utmp_ent is marked nonstring and GCC taught to suppress the
diagnostic)

  size_t utmpsize = sizeof UT_ID (utmp_ent);
  char *comment = xmalloc (strlen (_("id=")) + utmpsize + 1);

  strcpy (comment, _("id="));
  strncat (comment, UT_ID (utmp_ent), utmpsize);

I'll try to remember to test coreutils with new warnings in the future.

[Bug tree-optimization/85698] [8/9 Regression] CPU2017 525.x264_r fails starting with r257581

[pthaugen at gcc dot gnu.org]

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

--- Comment #6 from Pat Haugen  ---
(In reply to Richard Biener from comment #4)
> I can see what the patch does to this testcase on x86_64 - it enables BB
> vectorization of the first two loops after runrolling.  I don't see anything
> suspicious here on x86_64 and 525.x264_r works fine for me.
> 
> Can you claify whether test, ref or train inputs fail for you?  I tried
> AVX256, AVX128 and plain old SSE sofar without any issue but ref takes some
> time...
> 
> Can you check whether the following reduced file produces the same assembly
> for add4x4_idct as in the complete benchmark?  If so it should be possible to
> generate a runtime testcase from it.  Please attach preprocessed source if
> that doesn't work out.
> 
> Sofar I do suspect we are hitting a latent target issue?
> 
> #include 
> static uint8_t x264_clip_uint8( int x )
> {
>   return x&(~255) ? (-x)>>31 : x;
> }
> void add4x4_idct( uint8_t *p_dst, int16_t dct[16])
> {
>   int16_t d[16];
>   int16_t tmp[16];
>   for( int i = 0; i < 4; i++ )
> {
>   int s02 =  dct[0*4+i] +  dct[2*4+i];
>   int d02 =  dct[0*4+i] -  dct[2*4+i];
>   int s13 =  dct[1*4+i] + (dct[3*4+i]>>1);
>   int d13 = (dct[1*4+i]>>1) -  dct[3*4+i];
>   tmp[i*4+0] = s02 + s13;
>   tmp[i*4+1] = d02 + d13;
>   tmp[i*4+2] = d02 - d13;
>   tmp[i*4+3] = s02 - s13;
> }
>   for( int i = 0; i < 4; i++ )
> {
>   int s02 =  tmp[0*4+i] +  tmp[2*4+i];
>   int d02 =  tmp[0*4+i] -  tmp[2*4+i];
>   int s13 =  tmp[1*4+i] + (tmp[3*4+i]>>1);
>   int d13 = (tmp[1*4+i]>>1) -  tmp[3*4+i];
>   d[0*4+i] = ( s02 + s13 + 32 ) >> 6;
>   d[1*4+i] = ( d02 + d13 + 32 ) >> 6;
>   d[2*4+i] = ( d02 - d13 + 32 ) >> 6;
>   d[3*4+i] = ( s02 - s13 + 32 ) >> 6;
> }
>   for( int y = 0; y < 4; y++ )
> {
>   for( int x = 0; x < 4; x++ )
> p_dst[x] = x264_clip_uint8( p_dst[x] + d[y*4+x] );
>   p_dst += 32;
> }
> }

Yes, that produces similar code, and adding the following to it produces an
executable test that fails at -O3.

void main()
{
  uint8_t dst[128];
  int16_t dct[16];
  int i;

  for (i = 0; i < 16; i++)
dct[i] = i*10 + i;
  for (i = 0; i < 128; i++)
dst[i] = i;

  add4x4_idct(dst, dct);

  if (dst[0] != 14 || dst[1] != 0 || dst[2] != 4 || dst[3] != 2 
  || dst[32] != 28 || dst[33] != 35 || dst[34] != 33 || dst[35] != 35)
abort();

}

Continuing to debug further...

[Bug fortran/85779] ICE in gfc_typename, at fortran/misc.c:156

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from kargl at gcc dot gnu.org ---
This fixes the problem.  Watch for cut-n-paste corruption of tabs.

Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c  (revision 260235)
+++ gcc/fortran/decl.c  (working copy)
@@ -9961,8 +9975,12 @@ gfc_match_derived_decl (void)

   if (!gensym->attr.generic && gensym->ts.type != BT_UNKNOWN)
 {
-  gfc_error ("Derived type name %qs at %C already has a basic type "
-"of %s", gensym->name, gfc_typename (&gensym->ts));
+  if (gensym->ts.u.derived)
+   gfc_error ("Derived type name %qs at %C already has a basic type "
+  "of %s", gensym->name, gfc_typename (&gensym->ts));
+  else
+   gfc_error ("Derived type name %qs at %C already has a basic type",
+  gensym->name);
   return MATCH_ERROR;
 }

[Bug c++/85782] New: acc loops with continue statements ICE in c++

[cesar at gcc dot gnu.org]

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

Bug ID: 85782
   Summary: acc loops with continue statements ICE in c++
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cesar at gcc dot gnu.org
  Target Milestone: ---

Created attachment 44130
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44130&action=edit
test.cpp

G++ ICEs when it encounters OpenACC loops that contains continue statements as
demonstrated in the attached test case. Gcc, in contrast, does not suffer from
this defect.

This bug is present in GCC 6, 7, 8 and trunk.

[Bug middle-end/85602] -Wsizeof-pointer-memaccess for strncat with size of source

[eggert at gnu dot org]

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

--- Comment #2 from Paul Eggert  ---
Thanks for looking into it. For what it's worth, the practical effect of this
new warning was that I changed that part of coreutils to not use strncat,
causing 3 lines of code to grow to 8 lines. See the end of:

https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=9781fcd532f30afe174239a22816a83c40528b27

Another part of coreutils still uses strncat (also correctly). Let's hope GCC
doesn't start warning about it too

[Bug fortran/85781] ICE in gfc_build_array_ref, at fortran/trans.c:393

[gs...@t-online.de]

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

--- Comment #1 from G. Steinmetz  ---

Some variants that are actually compiling :


$ cat z2.f90
subroutine s(x) bind(c)
   use iso_c_binding, only: c_char
   character(kind=c_char), value :: x
   print *, x(1:0)
end


$ cat z3.f90
subroutine s(x)
   use iso_c_binding, only: c_char
   character(kind=c_char), value :: x
   print *, x(2:1)
end

[Bug fortran/85781] New: ICE in gfc_build_array_ref, at fortran/trans.c:393

[gs...@t-online.de]

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

Bug ID: 85781
   Summary: ICE in gfc_build_array_ref, at fortran/trans.c:393
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects also versions down to at least 4.8 :

$ cat z1.f90
subroutine s(x) bind(c)
   use iso_c_binding, only: c_char
   character(kind=c_char), value :: x
   print *, x(2:1)
end


$ gfortran-9-20180513 -c z1.f90
z1.f90:4:0:

print *, x(2:1)

internal compiler error: in gfc_build_array_ref, at fortran/trans.c:393
0x74c15b gfc_build_array_ref(tree_node*, tree_node*, tree_node*, tree_node*)
../../gcc/fortran/trans.c:393
0x7821e5 gfc_conv_substring
../../gcc/fortran/trans-expr.c:2301
0x782524 gfc_conv_variable
../../gcc/fortran/trans-expr.c:2766
0x77f312 gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:7930
0x785bba gfc_conv_expr_reference(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8022
0x7a5d76 gfc_trans_transfer(gfc_code*)
../../gcc/fortran/trans-io.c:2585
0x74b647 trans_code
../../gcc/fortran/trans.c:2044
0x7a3827 build_dt
../../gcc/fortran/trans-io.c:2027
0x74b667 trans_code
../../gcc/fortran/trans.c:2016
0x772c49 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6507
0x701d40 translate_all_program_units
../../gcc/fortran/parse.c:6121
0x701d40 gfc_parse_file()
../../gcc/fortran/parse.c:6324
0x748adf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/85780] New: ICE in resolve_fl_procedure, at fortran/resolve.c:12504

[gs...@t-online.de]

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

Bug ID: 85780
   Summary: ICE in resolve_fl_procedure, at
fortran/resolve.c:12504
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least 4.8 :

$ cat z1.f90
subroutine s(*) bind(c)
end


$ gfortran-9-20180513 -c z1.f90
f951: internal compiler error: Segmentation fault
0xb9f4bf crash_signal
../../gcc/toplev.c:325
0x71bbfd resolve_fl_procedure
../../gcc/fortran/resolve.c:12504
0x71bbfd resolve_symbol
../../gcc/fortran/resolve.c:15157
0x73639b do_traverse_symtree
../../gcc/fortran/symbol.c:4149
0x71cb1a resolve_types
../../gcc/fortran/resolve.c:16456
0x71839c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16570
0x701b6a resolve_all_program_units
../../gcc/fortran/parse.c:6060
0x701b6a gfc_parse_file()
../../gcc/fortran/parse.c:6310
0x748adf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/85779] ICE in gfc_typename, at fortran/misc.c:156

[gs...@t-online.de]

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

--- Comment #1 from G. Steinmetz  ---

Related :

$ cat z3.f90
class(t) function f()
   type f
   end type
end


$ gfortran-9-20180513 -c z3.f90
f951: internal compiler error: Segmentation fault
0xb9f4bf crash_signal
../../gcc/toplev.c:325
0x6de494 gfc_typename(gfc_typespec*)
../../gcc/fortran/misc.c:159
0x69d9b6 gfc_match_derived_decl()
../../gcc/fortran/decl.c:9964
0x6f7139 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6fb1c5 match_word
../../gcc/fortran/parse.c:569
0x6fb1c5 decode_statement
../../gcc/fortran/parse.c:569
0x6fc754 next_free
../../gcc/fortran/parse.c:1230
0x6fc754 next_statement
../../gcc/fortran/parse.c:1462
0x6fdea0 parse_spec
../../gcc/fortran/parse.c:3870
0x700533 parse_progunit
../../gcc/fortran/parse.c:5667
0x701ec1 gfc_parse_file()
../../gcc/fortran/parse.c:6221
0x748adf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/85779] New: ICE in gfc_typename, at fortran/misc.c:156

[gs...@t-online.de]

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

Bug ID: 85779
   Summary: ICE in gfc_typename, at fortran/misc.c:156
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With invalid code, down to at least 4.8 :


$ cat z1.f90
type(t) function f()
   type f
   end type
end


$ cat z2.f90
type(t) function f() result(z)
   type z
   end type
end


$ gfortran-9-20180513 -c z1.f90
f951: internal compiler error: Segmentation fault
0xb9f4bf crash_signal
../../gcc/toplev.c:325
0x6de45c gfc_typename(gfc_typespec*)
../../gcc/fortran/misc.c:156
0x69d9b6 gfc_match_derived_decl()
../../gcc/fortran/decl.c:9964
0x6f7139 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6fc0b1 match_word
../../gcc/fortran/parse.c:265
0x6fc0b1 decode_specification_statement
../../gcc/fortran/parse.c:265
0x6fc0b1 decode_statement
../../gcc/fortran/parse.c:314
0x6fc754 next_free
../../gcc/fortran/parse.c:1230
0x6fc754 next_statement
../../gcc/fortran/parse.c:1462
0x6fe56c parse_spec
../../gcc/fortran/parse.c:3670
0x700533 parse_progunit
../../gcc/fortran/parse.c:5667
0x701ec1 gfc_parse_file()
../../gcc/fortran/parse.c:6221
0x748adf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug libstdc++/81256] basic_filebuf::close doesn't propagate exceptions

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Mon May 14 18:57:45 2018
New Revision: 260236

URL: https://gcc.gnu.org/viewcvs?rev=260236&root=gcc&view=rev
Log:
PR libstdc++/81256 fix exception handling in basic_filebuf::close

PR libstdc++/81256
* include/bits/fstream.tcc (basic_filebuf::close): Do not swallow
exceptions from _M_terminate_output().
* include/std/fstream (basic_filebuf::~basic_filebuf): Swallow any
exceptions from close().
* testsuite/27_io/basic_filebuf/close/81256.cc: New.

Added:
trunk/libstdc++-v3/testsuite/27_io/basic_filebuf/close/81256.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/fstream.tcc
trunk/libstdc++-v3/include/std/fstream

[Bug other/85778] unexpected results with -O2, wrong code?

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
It depends on if glibc is adding the nonnull attribute to stat or is it GCC. 
Also what does the C (and POSIX) standard says about a null pointer being
passed as the string to stat.

[Bug middle-end/85602] -Wsizeof-pointer-memaccess for strncat with size of source

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-05-14
 CC||msebor at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
Summary|[8/9 Regression] regression |-Wsizeof-pointer-memaccess
   |with strncat and -Wall in   |for strncat with size of
   |GCC 8   |source
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
(The warning behaves as designed so this is not a regression.  I've changed the
Summary to reflect that.)

The code in the test case is correct and safe, and reflects one of the original
and intended uses of the function.  Unfortunately, due to a poor understanding
of the various string functions[1], many calls to strncat() with either the
size of the source or (to a lesser extent) the size of the destination have
been mistakes that have led to either buffer overflow or inadvertent
truncation.  To avoid these mistakes the recommended way to call the function
is to pass it the amount of space remaining in the destination, e.g., like
so[2]:

  strncat (dst, src, dstsize - strlen (d) - 1);

The warning is designed to help detect these mistakes and encourage this idiom.

Ideally, the warning would detect the safe calls (like the one in the test
case) and avoid triggering for them, but it's not always possible.  In the test
case, it's impossible to detect the length of the destination string at the
point where GCC sees the use of 'sizeof source' in the strncat() call; at the
point where the length is known the fact that the bound is the result of
'sizeof source' has been lost.

Since in the test case strncat() is being used to constrain the copy to avoid
reading past the end of a non-string (i.e., an array of characters not
necessarily terminated by a NUL) I'll see if GCC can be taught to recognize the
attribute in this context to suppress the warning.  Until then (or if
annotating the member isn't an option), the warning can be suppressed either by
a #pragma GCC diagnostic, or by introducing a temporary pointer pointing to the
member array and passing the pointer to strncat, or by introducing a temporary
for the size of the source and passing it to the function as the bound:

  char* __attribute__ ((nonstring)) p = u.ut_user;
  enum { N = sizeof u.ut_user };
  strncat (buf, u.ut_user, N);

[1]
https://www.usenix.org/legacy/event/usenix99/full_papers/millert/millert.pdf
[2]
https://www.us-cert.gov/bsi/articles/knowledge/coding-practices/strncpy-and-strncat

[Bug other/85778] New: unexpected results with -O2, wrong code?

[doko at gcc dot gnu.org]

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

Bug ID: 85778
   Summary: unexpected results with -O2, wrong code?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen with GCC 5 and all newer version. Is this wrong-code?

$ cat testcase.c 
#include 
#include 

#define PRINT \
  if (foo == NULL) \
printf("foo in func() is %p, NULL (expected)\n", foo); \
  else \
printf("foo in func() is %p, not NULL (NOT EXPECTED!)\n", foo);

void func(const char *foo) {
  struct stat stat_buf;

  PRINT;
  stat(foo, &stat_buf);
  PRINT;
}

int main() {
  const char *foo = NULL;
  struct stat stat_buf;

  func(NULL);

  PRINT;
  stat(foo, &stat_buf);
  PRINT;
  return 0;
}

$ gcc -O0 testcase.c && ./a.out 
foo in func() is (nil), NULL (expected)
foo in func() is (nil), NULL (expected)
foo in func() is (nil), NULL (expected)
foo in func() is (nil), NULL (expected)
$ gcc -O2 testcase.c && ./a.out 
foo in func() is (nil), NULL (expected)
foo in func() is (nil), not NULL (NOT EXPECTED!)
foo in func() is (nil), NULL (expected)
foo in func() is (nil), NULL (expected)

[Bug libstdc++/85768] [9 Regression] FreeBSD bootstrap fails due to undefined reference to 'backtrace'

[fdumont at gcc dot gnu.org]

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

François Dumont  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |fdumont at gcc dot 
gnu.org

--- Comment #3 from François Dumont  ---
I used this function cause it was already being used by the libstdc++ profile
mode so I was expecting it to be quite safe. As profile mode is not used on
bootstrap or in general I guess this problem never show up.

I'll move to libbacktrace with proper checks.

Waiting for the fix shall I revert the change ?

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

[jan at jki dot io]

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

--- Comment #12 from Jan  ---
And yes I use a gentoo system. But I'm using the gcc patches from clear linux
but this bug doesn't seem relate to that.

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

[jan at jki dot io]

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

--- Comment #11 from Jan  ---
I can reproduce it with vanilla gcc 8.1.0 no patches applied.

[Bug c++/85739] [8/9 Regression] internal compiler error: in finish_member_declaration, at cp/semantics.c:3057

[ensadc at mailnesia dot com]

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

ensadc at mailnesia dot com changed:

   What|Removed |Added

 CC||ensadc at mailnesia dot com

--- Comment #4 from ensadc at mailnesia dot com ---
struct l { int k; };
template  class b { };
template  class B { using e = int; };
template 
bool operator!=(B, b);

bool bb = (B<&l::k>() != b<&l::k>());

also reproduces it.

[Bug target/85769] [8/9 Regression] ICE in extract_constrain_insn, at recog.c:2205 for -mcpu=thunderx

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

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

[Bug libstdc++/71098] uniform initialization for nested tuples work in c++11/14 mode but should only work >=c++17

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Jonathan Wakely  ---
I assume you're referring to the conditionally EXPLICIT constructors. That
fixed a defect and is supported all the way back to C++11, as per our usual
policy.

[Bug target/85756] [9 regression] wrong code at -Os on x86-64-linux-gnu in 32-bit mode

[uros at gcc dot gnu.org]

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

--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon May 14 15:53:58 2018
New Revision: 260231

URL: https://gcc.gnu.org/viewcvs?rev=260231&root=gcc&view=rev
Log:
PR target/85756
* config/i386/i386.md: Disallow non-commutative arithmetics in
last twpeephole for mem {+,-,&,|,^}= x; mem != 0 after cmpelim
optimization.  Use COMMUTATIVE_ARITH_P test rather than != MINUS
in the peephole2 before it.

testsuite/ChangeLog:

* gcc.c-torture/execute/pr85756.c: New test.


Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr85756.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/67554] runtime error in valarray (NULL passed to memcpy)

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Mon May 14 15:35:06 2018
New Revision: 260229

URL: https://gcc.gnu.org/viewcvs?rev=260229&root=gcc&view=rev
Log:
PR libstdc++/67554 Do not pass null pointers to memcpy

PR libstdc++/67554
* include/bits/valarray_array.h (_Array_copy_ctor<_Tp, true>)
(_Array_copier<_Tp, true>): Do not pass null pointers to memcpy.

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

[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 #5 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #4 from Martin Liška  ---
[...]
> According to log file alias support is mission on solaris. Thus following 
> patch
> should fix that by skipping the test:
>
> diff --git a/gcc/testsuite/gcc.dg/ipa/ipa-icf-38.c
> b/gcc/testsuite/gcc.dg/ipa/ipa-icf-38.c
> index 85531ab1cf3..45525844551 100644
> --- a/gcc/testsuite/gcc.dg/ipa/ipa-icf-38.c
> +++ b/gcc/testsuite/gcc.dg/ipa/ipa-icf-38.c
> @@ -1,4 +1,5 @@
>  /* { dg-do link } */
> +/* { dg-require-alias "" } */
>  /* { dg-options "-O2 -fdump-ipa-icf -flto -fdump-tree-fixup_cfg4" } */
>  /* { dg-require-effective-target lto } */
>  /* { dg-additional-sources "ipa-icf-38a.c" }*/
>
> Can you please verify that?

The patch doesn't make a difference as Solaris *does* support attribute
alias, even when using as and ld.  However, I noticed that the
unmodified test PASSes when using gas/gld instead, so there is a
toolchain difference that causes this failure.

[Bug sanitizer/85777] [7/8 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear

[vincent-gcc at vinc17 dot net]

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

--- Comment #1 from Vincent Lefèvre  ---
I've cleaned up the testcase:

int d;
int h(void);
void e(void)
{
  int f[2];
  int g = 0;
  if (d)
g++;
  if (d == 1)
f[g++] = 2;
  (void) (f[0] || (g && h()));
}

Now:

cventin% gcc-snapshot -Werror=uninitialized -Werror=maybe-uninitialized -O2 -c
file.c
file.c: In function 'e':
file.c:11:3: error: 'f[0]' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
   (void) (f[0] || (g && h()));
   ^~~
cc1: some warnings being treated as errors
cventin%

but

cventin% gcc-snapshot -Werror=uninitialized -Werror=maybe-uninitialized -O2 -c
file.c -fsanitize=undefined
cventin%

(no errors).

Note (this may be a separate issue): If I understand correctly, f[0] is
actually *always* used uninitialized in this function. Indeed, f[0] might be
initialized only via "f[g++] = 2;", thus only if d == 1. But in this case, it
is actually f[1] that is initialized.

[Bug sanitizer/85777] New: [7/8 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear

[vincent-gcc at vinc17 dot net]

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

Bug ID: 85777
   Summary: [7/8 Regression] -fsanitize=undefined makes a
-Wmaybe-uninitialized warning disappear
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

On some C files, adding the -fsanitize=undefined option makes a
-Wmaybe-uninitialized warning disappear.

In the past, I reported PR81981, which was fixed for the provided testcase. But
this was just a simplified testcase of tests/turandom.c in MPFR revision 11663,
and the problem still occurs for this revision of MPFR.

I've used creduce with the following test under Debian/unstable in order to
obtain another simplified testcase:


#!/bin/sh

cmd="gcc-snapshot -Werror=uninitialized -Werror=maybe-uninitialized -O2 -c
file.c"
$cmd -fsanitize=undefined && ! $cmd


The obtained file.c file is:


enum { a, b } typedef c;
d;
e() {
  c f[2];
  int g = 0;
  if (d)
g++;
  if (d == b)
f[g++] = 2;
  f[0] || g &&h();
}


I get the "‘f[0]’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]" error with:
  * gcc-6 -Werror=maybe-uninitialized -O2 -c file.c
  * gcc-6 -Werror=maybe-uninitialized -O2 -c file.c -fsanitize=undefined
  * gcc-7 -Werror=maybe-uninitialized -O2 -c file.c
  * gcc-8 -Werror=maybe-uninitialized -O2 -c file.c
  * gcc-snapshot -Werror=maybe-uninitialized -O2 -c file.c

but not with:
  * gcc-7 -Werror=maybe-uninitialized -O2 -c file.c -fsanitize=undefined
  * gcc-8 -Werror=maybe-uninitialized -O2 -c file.c -fsanitize=undefined
  * gcc-snapshot -Werror=maybe-uninitialized -O2 -c file.c -fsanitize=undefined

FYI, currently under Debian/unstable:
  * gcc-6 (Debian 6.4.0-17) 6.4.0 20180424
  * gcc-7 (Debian 7.3.0-19) 7.3.0
  * gcc-8 (Debian 8.1.0-3) 8.1.0
  * gcc (Debian 20180512-1) 9.0.0 20180512 (experimental) [trunk revision
260194]

[Bug libstdc++/82966] node_handle swap fails to compile

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Mon May 14 14:27:54 2018
New Revision: 260226

URL: https://gcc.gnu.org/viewcvs?rev=260226&root=gcc&view=rev
Log:
PR libstdc++/82966 fix swapping of node handles

PR libstdc++/82966
* include/bits/node_handle.h (_Node_handle_common::_M_swap): Use value
instead of type.
* testsuite/23_containers/set/modifiers/node_swap.cc: New.

Added:
trunk/libstdc++-v3/testsuite/23_containers/set/modifiers/node_swap.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/node_handle.h

[Bug c++/85776] New: ICE when compiling `boost::thread` with `-std=c++11` on mingw-w64

[lh_mouse at 126 dot com]

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

Bug ID: 85776
   Summary: ICE when compiling `boost::thread` with `-std=c++11`
on mingw-w64
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lh_mouse at 126 dot com
  Target Milestone: ---

Created attachment 44129
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44129&action=edit
(though not minimal) testcase

Compiling the attached program using `-std=c++11` with boost 1.66 results in an
ICE:

```
E:\Desktop>g++ -std=c++11 test.cc
In file included from
C:/MinGW/MSYS2/mingw32/include/boost/thread/detail/thread.hpp:23,
 from
C:/MinGW/MSYS2/mingw32/include/boost/thread/thread_only.hpp:22,
 from
C:/MinGW/MSYS2/mingw32/include/boost/thread/thread.hpp:12,
 from C:/MinGW/MSYS2/mingw32/include/boost/thread.hpp:13,
 from test.cc:1:
C:/MinGW/MSYS2/mingw32/include/boost/thread/detail/invoke.hpp: In function
'decltype (*(forward)(boost::detail::invoke::a0).*boost::detail::invoke::f)
boost::detail::invoke(Fp&&, A0&&) [with Fp = void (A::*)(); A0 = A*]':
C:/MinGW/MSYS2/mingw32/include/boost/thread/detail/invoke.hpp:102:43: internal
compiler error: in gimplify_expr, at gimplify.c:12188
 return (*boost::forward(a0)).*f;
   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
```

This is confirmed to be the case on 5.4 (native and cross from Linux) and 8.1.1
(native).


Preprocessing the testcase results in such an enormous file (5+ MiB) that
CReduce has been unable to reduce it at all (it resulted in a `}` only, which
was apparently a bug).

[Bug c++/85775] New: False positive with -Wparentheses

[insertinterestingnamehere at gmail dot com]

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

Bug ID: 85775
   Summary: False positive with -Wparentheses
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: insertinterestingnamehere at gmail dot com
  Target Milestone: ---

g++ 8.1 warns about unnecessary parentheses in some cases where they are
actually needed to designate something as a single argument to a macro. Here's
a minimal example:

#define M(x) x

template 
struct A {
static const volatile char *M(B);
};

template 
const volatile char *M((A::B)) = nullptr;


As it stands, the compiler warns that the double parentheses are unnecessary,
but if they are removed the preprocessor complains that two arguments are being
passed to a macro that only expects one. The only work around, for now, is to
locally disable the warning with pragmas.

[Bug c++/85731] [8/9 Regression] Inner class method declaration changes meaning of outer template class template method

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 CC||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Started with r251438

PR c++/81236 - ICE with template-id in generic lambda

* semantics.c (finish_id_expression): Remove special dependent
case.
Avoid some later pieces when dependent.
(finish_qualified_id_expr): Do normal BASELINK handling in a
template.  Always build a SCOPE_REF for a destructor BIT_NOT_EXPR.
(parsing_default_capturing_generic_lambda_in_template): Remove.
* parser.c (cp_parser_postfix_dot_deref_expression): Always give an
error for types that will never be complete.
* mangle.c (write_expression): Add sanity check.
* tree.c (build_qualified_name): Add sanity check.
(cp_walk_subtrees): Walk into the class context of a BASELINK.
* lambda.c (add_capture): Improve diagnostic for generic lambda
capture failure.
* call.c (build_new_method_call_1): Print the right constructor
name.

[Bug sanitizer/85774] New: Incorrect stack-use-after-scope caused by missing cleanup of shadow bytes

[jwyatt at feralinteractive dot com]

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

Bug ID: 85774
   Summary: Incorrect stack-use-after-scope caused by missing
cleanup of shadow bytes
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jwyatt at feralinteractive dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

The code:

#include 

void DoSomething(){}

void DoFunc(const std::function& func)
{
func();
}

void Setup()
{
switch (1)
{
case 1:
{
DoFunc([](){});
break;
}
case 2:
{
DoFunc([](){});
break;
}
default:
break;
}

DoSomething();
}

void DemostrateBadPoisoning()
{
DoFunc([](){});
}

int main()
{
Setup();
DemostrateBadPoisoning();
return 0;
}

will cause an AddressSanitizer stack-use-after-scope error in
DemonstrateBadPoisoning. This appears to be because the shadow bytes for the
stack of Setup are not completely zeroed on function exit.

Compiled with: g++ -O0 -g -fsanitize=address -Wall -Wextra

gcc version 8.1.1 20180502 (Red Hat 8.1.1-1) (GCC)

[Bug libstdc++/85184] Remove __glibcxx_assert uses from std::variant

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 Ever confirmed|0   |1

[Bug libstdc++/85319] std::char_traits::length does not always function in constexpr context

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 CC||palves at redhat dot com
 Ever confirmed|0   |1

[Bug libstdc++/82966] node_handle swap fails to compile

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-05-14
Version|unknown |7.3.0
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug libstdc++/82452] defines macros for getc and putc

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 Ever confirmed|0   |1

[Bug libstdc++/81522] c++17/old-abi/cygwin empty stringstream invalid memory access

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Possibly related to PR 82172 (which was due to a binutils bug) but that
apparently only occurs when using LTO.

[Bug libstdc++/81263] Work around CWG issue 1558 (guarantee SFINAE when using `void_t`)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Jonathan Wakely  ---
CWG 1558 was implemented in GCC ages ago (though given that you haven't said
what version you're using, maybe it isn't for you).

This is not a library bug though, it's a limitation of void_t and the current
core language.

[Bug libstdc++/81256] basic_filebuf::close doesn't propagate exceptions

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 Ever confirmed|0   |1

[Bug libstdc++/72830] istream::seekg should not reset eofbit if -std=c++98

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #3)
> No, it's not a bug. The old behaviour was considered a defect in the
> language, and so the fix is applied unconditionally.

Invalid as stated above.

[Bug libstdc++/71301] std::tuple move constructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 Ever confirmed|0   |1

[Bug libstdc++/71098] uniform initialization for nested tuples work in c++11/14 mode but should only work >=c++17

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-05-14
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to Klaus Rudolph from comment #0)
> uniform initialization for nested std::tuple works in c++11/14 mode but
> should work not before c++17.

Why not?

[Bug libstdc++/69191] Wrong equality comparison between error_code and error_condition + segfault

[redi at gcc dot gnu.org]

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

--- Comment #17 from Jonathan Wakely  ---
(In reply to Chip Salzenberg from comment #16)
> Still happening in 7.2

What is?

[Bug libstdc++/67011] division by zero in std::exponential_distribution

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 Ever confirmed|0   |1

--- Comment #4 from Jonathan Wakely  ---
(In reply to Matthias Kretz from comment #3)
> The problem is that (result_type(1) - __aurng()) must never be zero (because
> std::log might raise FE_DIVBYZERO for std::log(0)). If __aurng() is a
> distribution guaranteed to exclude result_type(1) then this works fine.
> AFAIK std::generate_canoncial sometimes generates a 1 (cf.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63176).

PR 63176 is fixed now.

> Also, I'm wondering whether the 1 - rng wouldn't reduce the randomness.
> Consider:
> std::log(numeric_limits::min()) -> -87.3365478515625
> std::log(1.f - nextafter(1.f, 0.f))-> -16.635532379150390625
> IIUC, the effect of log(1 - rng) is that the distance between random values
> from std::exponential_distribution is considerable larger than for log(rng).

Hmm, let's confirm the bug for that, instead of the division-by-zero that
should be fixed.

[Bug libstdc++/67554] runtime error in valarray (NULL passed to memcpy)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 Ever confirmed|0   |1

[Bug libstdc++/62119] dangling reference : gslice_array's copy constructor

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
PR 63314 points out the same problem exists in mask_array and indirect_array.

[Bug libstdc++/63314] valarray mask/indices refers to temporary

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Very similar to PR 62119 which has a complete testcase.

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

[Bug libstdc++/62119] dangling reference : gslice_array's copy constructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||helloworld922 at hotmail dot 
com

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

[Bug libstdc++/62196] running time segment fault with valarray

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
abcdefghijklmnopqrstuvwxyz
=
==15899==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x60200036 at pc 0x004024c5 bp 0x7ffe7350f5f0 sp 0x7ffe7350f5e0
READ of size 1 at 0x60200036 thread T0
#0 0x4024c4 in void std::__valarray_copy(std::_Array, unsigned
long, std::_Array, std::_Array) (/tmp/a.out+0x4024c4)
#1 0x402092 in std::mask_array::operator=(std::valarray const&)
const (/tmp/a.out+0x402092)
#2 0x40154c in main (/tmp/a.out+0x40154c)
#3 0x7f3736481f29 in __libc_start_main (/lib64/libc.so.6+0x20f29)
#4 0x400ef9 in _start (/tmp/a.out+0x400ef9)

0x60200036 is located 0 bytes to the right of 6-byte region
[0x60200030,0x60200036)
allocated by thread T0 here:
#0 0x7f37371e0158 in operator new(unsigned long)
(/lib64/libasan.so.4+0xe0158)
#1 0x40187a in std::__valarray_get_memory(unsigned long)
(/tmp/a.out+0x40187a)
#2 0x402155 in bool* restrict std::__valarray_get_storage(unsigned
long) (/tmp/a.out+0x402155)
#3 0x401a35 in std::valarray::valarray(bool const*, unsigned long)
(/tmp/a.out+0x401a35)
#4 0x4013e8 in main (/tmp/a.out+0x4013e8)
#5 0x7f3736481f29 in __libc_start_main (/lib64/libc.so.6+0x20f29)

SUMMARY: AddressSanitizer: heap-buffer-overflow (/tmp/a.out+0x4024c4) in void
std::__valarray_copy(std::_Array, unsigned long, std::_Array,
std::_Array)
Shadow bytes around the buggy address:
  0x0c047fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c047fff8000: fa fa 06 fa fa fa[06]fa fa fa fa fa fa fa fa fa
  0x0c047fff8010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==15899==ABORTING

[Bug libstdc++/85773] Embedded nulls in filesystem::path cause problems

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Possible solutions:

1) Detect embedded nulls when constructing paths (and forming them by
concatenation and other modifications). Opinions differ on whether this is
allowed, as filesystem::path objects are purely lexical and can represent
invalid or impossible paths.

2) Check for embedded nulls every time we call an OS function with the NTBS
returned by c_str(). This is tedious and error-prone.

3) Add a workaround to recursive_directory_iterator only.

[Bug libstdc++/85773] New: Embedded nulls in filesystem::path cause problems

[redi at gcc dot gnu.org]

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

Bug ID: 85773
   Summary: Embedded nulls in filesystem::path cause problems
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 
int main()
{
  std::filesystem::create_directories("a/b");
  std::string s("a\0/..", 5);
  for (auto f : std::filesystem::recursive_directory_iterator(s))
  { }
}

$ GCC 8 -std=c++17 null.cc -lstdc++fs
$ ./a.out
terminate called after throwing an instance of
'std::filesystem::__cxx11::filesystem_error'
  what():  filesystem error: cannot increment recursive directory iterator: Too
many open files
Aborted (core dumped)


The problem is that we call opendir(pathname.c_str()) which only reads up to
the null terminator, so we open "a"  but then the pathname for the first
element in the iteration sequence is formed by concatenating "a\0/.." / "b" and
then recursing by calling opendir(path("a\0/../b").c_str()) which opens "a"
again. This keeps looping, opening "a" every time until we reach the ulimit for
open files.

[Bug libstdc++/85772] __gnu_cxx::__versa_string doesn't support C++11 allocators

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 Ever confirmed|0   |1

[Bug libstdc++/85772] __gnu_cxx::__versa_string doesn't support C++11 allocators

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Also review it for noexcept, so that for example the copy constructor is
noexcept when using the COW base:

diff --git a/libstdc++-v3/include/ext/rc_string_base.h
b/libstdc++-v3/include/ext/rc_string_base.h
index 46f189331f7..7e027cf6fb6 100644
--- a/libstdc++-v3/include/ext/rc_string_base.h
+++ b/libstdc++-v3/include/ext/rc_string_base.h
@@ -311,7 +311,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

   __rc_string_base(const _Alloc& __a);

-  __rc_string_base(const __rc_string_base& __rcs);
+  __rc_string_base(const __rc_string_base& __rcs) _GLIBCXX_USE_NOEXCEPT;

 #if __cplusplus >= 201103L
   __rc_string_base(__rc_string_base&& __rcs)
diff --git a/libstdc++-v3/include/ext/vstring.h
b/libstdc++-v3/include/ext/vstring.h
index 605311e9a28..8834bdcc36e 100644
--- a/libstdc++-v3/include/ext/vstring.h
+++ b/libstdc++-v3/include/ext/vstring.h
@@ -143,6 +143,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
*  @param  __str  Source string.
*/
   __versa_string(const __versa_string& __str)
+ 
_GLIBCXX_NOEXCEPT_IF(std::is_nothrow_copy_constructible<__vstring_base>())
   : __vstring_base(__str) { }

 #if __cplusplus >= 201103L

[Bug libstdc++/85771] `std::variant<...>` insanely slow to compile compared to `union` (256 types)

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
This should be completely unsurprising, obviously std::variant is different to
a union. The type safety and other features come at a cost, and 2s isn't
insane.

[Bug libstdc++/85772] New: __gnu_cxx::__versa_string doesn't support C++11 allocators

[redi at gcc dot gnu.org]

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

Bug ID: 85772
   Summary: __gnu_cxx::__versa_string doesn't support C++11
allocators
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

This would be useful to support, for people who want a COW string type when
using the cxx11 ABI (so can't use std::string).

[Bug libstdc++/62119] dangling reference : gslice_array's copy constructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
I can't reproduce a segfault but ASan shows the problem:

=
==12423==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000b0
at pc 0x0040276f bp 0x7fff6678eb50 sp 0x7fff6678eb48
READ of size 8 at 0x606000b0 thread T0
#0 0x40276e in std::valarray::size() const
/home/jwakely/gcc/9/include/c++/9.0.0/valarray:938
#1 0x40232f in std::gslice_array::operator=(int const&) const
/home/jwakely/gcc/9/include/c++/9.0.0/bits/gslice_array.h:165
#2 0x401616 in main /tmp/gs.cc:17
#3 0x7f01d4f65f29 in __libc_start_main ../csu/libc-start.c:308
#4 0x401159 in _start (/tmp/a.out+0x401159)

0x606000b0 is located 48 bytes inside of 64-byte region
[0x60600080,0x606000c0)
freed by thread T0 here:
#0 0x7f01d5ccbe78 in operator delete(void*, unsigned long)
/home/jwakely/src/gcc/gcc/libsanitizer/asan/asan_new_delete.cc:151
#1 0x401b65 in std::gslice::~gslice()
/home/jwakely/gcc/9/include/c++/9.0.0/bits/gslice.h:166
#2 0x40159c in main /tmp/gs.cc:15
#3 0x7f01d4f65f29 in __libc_start_main ../csu/libc-start.c:308

previously allocated by thread T0 here:
#0 0x7f01d5ccaa80 in operator new(unsigned long)
/home/jwakely/src/gcc/gcc/libsanitizer/asan/asan_new_delete.cc:90
#1 0x401a18 in std::gslice::gslice(unsigned long, std::valarray const&, std::valarray const&)
/home/jwakely/gcc/9/include/c++/9.0.0/bits/gslice.h:155
#2 0x40154e in main /tmp/gs.cc:15
#3 0x7f01d4f65f29 in __libc_start_main ../csu/libc-start.c:308

SUMMARY: AddressSanitizer: heap-use-after-free
/home/jwakely/gcc/9/include/c++/9.0.0/valarray:938 in std::valarray::size() const
Shadow bytes around the buggy address:
  0x0c0c7fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c0c7fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c0c7fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c0c7fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c0c7fff8000: fa fa fa fa 00 00 00 00 00 00 00 04 fa fa fa fa
=>0x0c0c7fff8010: fd fd fd fd fd fd[fd]fd fa fa fa fa fa fa fa fa
  0x0c0c7fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==12423==ABORTING

[Bug libstdc++/85771] New: `std::variant<...>` insanely slow to compile compared to `union` (256 types)

[vittorio.romeo at outlook dot com]

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

Bug ID: 85771
   Summary: `std::variant<...>` insanely slow to compile compared
to `union` (256 types)
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vittorio.romeo at outlook dot com
  Target Milestone: ---

Consider the following set of types:

struct Type0 { int x; };
struct Type1 { int x; };
struct Type2 { int x; };
// ...
struct Type253 { int x; };
struct Type254 { int x; };
struct Type255 { int x; };

Now imagine creating both a `std::variant` and a `union` out of them, then
compiling some code that prints out the active alternative with `-O3`:

union MyVariant { Type0 type0; /* ... */; Type255 type255; };
std::variant v;

These are the *compilation time* results I get:

UNION
real0m0.182s
user0m0.104s
sys 0m0.068s

VARIANT
real0m2.259s
user0m1.960s
sys 0m0.280s

I can get similar results on widely different machines (40 core company
development box, my laptop, and an online compiler).

Fully-reproducible live demo on coliru:
http://coliru.stacked-crooked.com/a/65d2ec5f4d7eb1ca

I think that this kind of difference is unacceptable, and `std::variant` types
with a lot of alternatives can occur in realistic use cases. If we want to
promote safety and abstraction over C-style code, the compilation time costs
must be sane.

[Bug libstdc++/84118] filesystem::path concat does not accept value_type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Jonathan Wakely  ---
(In reply to Ethan Smith from comment #0)
> As I have read the filesystem TS, I believe concat on path items should have
> an overload following:
> 
> path& operator+=(value_type x);

It does have that overload.

> However, on trying to use 7.2.0 this overload seems not to work correctly.
> 
> https://wandbox.org/permlink/S4DZ3witD15xz0lT

But you're using path::concat(value_type) not path::operator+=(value_type).

> TL;DR it would allow for constructs such as
> .concat(fs::path::preferred_separator)

No it wouldn't, because that uses concat, not operator+=

[Bug target/85770] New: [9 Regression] ICE: in lra_eliminate, at lra-eliminations.c:1439 with -march=nano-1000

[zsojka at seznam dot cz]

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

Bug ID: 85770
   Summary: [9 Regression] ICE: in lra_eliminate, at
lra-eliminations.c:1439 with -march=nano-1000
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 44128
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44128&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -march=nano-1000 -fnon-call-exceptions
-fno-tree-coalesce-vars testcase.c 
during RTL pass: reload
testcase.c: In function 'foo':
testcase.c:13:1: internal compiler error: in lra_eliminate, at
lra-eliminations.c:1439
 }
 ^
0xba5ed0 lra_eliminate(bool, bool)
/repo/gcc-trunk/gcc/lra-eliminations.c:1439
0xb82de9 lra(_IO_FILE*)
/repo/gcc-trunk/gcc/lra.c:2555
0xb26a19 do_reload
/repo/gcc-trunk/gcc/ira.c:5465
0xb26a19 execute
/repo/gcc-trunk/gcc/ira.c:5649
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-260223-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-260223-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
gcc version 9.0.0 20180514 (experimental) (GCC)

[Bug target/85769] [8/9 Regression] ICE in extract_constrain_insn, at recog.c:2205 for -mcpu=thunderx

[tnfchris at gcc dot gnu.org]

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

--- Comment #2 from Tamar Christina  ---
It's not r250673, That was committed 2017-07-28 and a GCC built 2017-08-17
does the correct thing for non-Armv8.2-a. It promotes the fp16 values to 32
bits does the operations and converts them back to fp16.

somewhere along the line something has decided to no longer do this. I can fix
the ICE by adding the missing pattern explicitly, but it should have not
generated this insn to begin with.

[Bug libstdc++/83891] std::filesystem::path::is_absolute for Windows

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 Ever confirmed|0   |1