[Bug libstdc++/81857] istreambuf_iterator not work as input iterator

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
istreambuf_iterator is specified to call sbumpc() only on increment, not upon
construction; the implementation is as specified.

The copy_n aspect is https://cplusplus.github.io/LWG/issue2471.

[Bug c++/81911] Constant expression from permitted result of a constant expression is not constexpr

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
The full-expression of the initialization of c0 includes the lvalue-to-rvalue
conversion on someVar[0], which is not allowed in a core constant expression;
see [expr.const]/2.7. Note that [expr.const]/2.7.1 only applies to complete
objects, which someVar[0] is not (it's a subobject).

[Bug tree-optimization/81934] New: after install of 7.2.0 the libcilkrts.la has extra quote chars in it for dependency_libs

[dclarke at blastwave dot org]

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

Bug ID: 81934
   Summary: after install of 7.2.0 the libcilkrts.la has extra
quote chars in it for dependency_libs
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dclarke at blastwave dot org
  Target Milestone: ---

After installation of gcc 7.2.0 there exists two libtool "dot-la" files both
named libcilkrts.la but for 32-bit and 64-bit as this is sparc. 

Thus : 

/usr/local/gcc7/lib/libcilkrts.la
and
/usr/local/gcc7/lib/sparcv9/libcilkrts.la

They both have extra single quote chars inside the dependency_libs value 
and had to be manually scrubbed out : 

# diff ./gcc7/lib/libcilkrts.la /usr/local/gcc7/lib/libcilkrts.la
20c20
< dependency_libs=' -lpthread /usr/local/gcc7/lib/libstdc++.la'
---
> dependency_libs=' -lpthread '/usr/local/gcc7/lib'/libstdc++.la'

# diff gcc7/lib/sparcv9/libcilkrts.la /usr/local/gcc7/lib/sparcv9/libcilkrts.la
20c20
< dependency_libs=' -lpthread /usr/local/gcc7/lib/sparcv9/libstdc++.la'
---
> dependency_libs=' -lpthread '/usr/local/gcc7/lib/sparcv9'/libstdc++.la'

Not sure how they ended up in there but all the other .la type files seem
fine.

Also, for this bug there is no clear component for "install" and I can not
choose "no component" so I randomly took "tree-optimization".
That will need to be fixed most likely.

[Bug c++/81933] New: [7 Regression] Invalid "constexpr call flows off the end of the function" error

[ldionne.2 at gmail dot com]

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

Bug ID: 81933
   Summary: [7 Regression] Invalid "constexpr call flows off the
end of the function" error
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ldionne.2 at gmail dot com
  Target Milestone: ---

The following code does not compile with GCC 7, std=c++14:


#include 

struct any_udt { };

template 
constexpr auto flatten(Tuples ...tuples) {
  auto all = std::make_tuple(tuples...);
  auto flat = std::make_tuple(
std::get<0>(std::get<1>(all)),
std::get<0>(std::get<2>(all))
  );
  return flat;
}

constexpr auto fail = ::flatten(std::make_tuple(),
std::make_tuple(any_udt{}),
std::make_tuple(any_udt{}));

int main() { }


It triggers the following error:

foo.cpp:17:59:   in constexpr expansion of 'flatten(Tuples ...) 
  [with Tuples = {std::tuple<>, std::tuple, std::tuple}]
(std::make_tuple(_Elements&& ...) [with _Elements = {any_udt}](), 
 std::make_tuple(_Elements&& ...) [with _Elements = {any_udt}]())'

foo.cpp:17:59: error: constexpr call flows off the end of the function
 std::make_tuple(any_udt{}));
   ^


Note that the code compiles just fine with GCC 6 and all Clang versions I've
tried, so this looks like a 7 regression.

Working example (GCC 6.3.0, -std=c++14):
https://wandbox.org/permlink/5AjQ50OSxNjJPP8r
Working example (GCC 6.3.0, -std=c++1z):
https://wandbox.org/permlink/dKegxu0QeVXtzObB

Failing example (GCC 7.2.0, -std=c++14):
https://wandbox.org/permlink/hfbI0Ndg5UyCIF9W
Working example (GCC 7.2.0, -std=c++1z):
https://wandbox.org/permlink/Hz1gm6EipU5Ej5jy

Failing example (GCC 8.0.0, -std=c++14):
https://wandbox.org/permlink/jSHOPt8zXosccp8a
Working example (GCC 8.0.0, -std=c++1z):
https://wandbox.org/permlink/Nj7tNIYWu8Ueury7

[Bug bootstrap/81926] go/parse.o differs between stage2 and stage3 for gcc 7.2.0

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

  Component|go  |bootstrap
   Assignee|ian at airs dot com|unassigned at gcc dot 
gnu.org

--- Comment #10 from Eric Botcazou  ---
Recategorizing.

[Bug go/81926] go/parse.o differs between stage2 and stage3 for gcc 7.2.0

[dclarke at blastwave dot org]

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

--- Comment #9 from Dennis Clarke  ---
If I remove the "go" language from the mix then I get reasonable results : 

https://gcc.gnu.org/ml/gcc-testresults/2017-08/msg02064.html


I will install that and then try again with the "all" languages selection 
after stage1.

[Bug target/81924] [5 Regression] ICE: in simplify_binary_operation_1, at simplify-rtx.c:3678 on powerpc64le-linux-gnu

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Maybe related to PR 68805.

[Bug target/81907] memset called when it does not need to be; -mtune=cortex-a9

[dongkyun.s at samsung dot com]

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

--- Comment #15 from dongkyun.s at samsung dot com ---
> There's nothing in the compiler that explicitly says: use memset for these 
> cores and not for others.  The choice will be down to available instructions 
> and their relative costs.

Agreed, but, I'm just wondering why it has diffrent behavior according by GCC
version with -Os. (It should be same result if the choice is made by their
instructions and costs)

[Bug c++/80598] -Wunused triggers for functions used in uninstantiated templates

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-23
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed, although I think there might be a duplicate around here somewhere,
the part about uninstantiated templates sounds familiar...

[Bug c++/80518] -Wsuggest-override does not warn about missing override on destructor

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-23
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug c++/80351] Inconsistent warning for constexpr auto constant when using initializer list (-Wunused-variable)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-23
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed that it warns where you say it does.

[Bug c++/60342] -Wsign-conversion ignores explicit conversion

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||ian at geometrian dot com

--- Comment #3 from Eric Gallager  ---
*** Bug 80157 has been marked as a duplicate of this bug. ***

[Bug c++/80157] Spurious "Wsign-conversion" warning with const, size_t, array.

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Eric Gallager  ---
(In reply to Ian Mallett from comment #0)
> Minimal example (compile GCC >= ~6.1 with -Wsign-conversion):
> 
> #include 
> bool f(size_t const xy[2], int z) {
>   return xy[0] + xy[1] < static_cast(z);
> }
> 
> Produces an erroneous warning:
> 
> : In function 'bool f(const size_t*, int)':
> :3:25: warning: conversion to 'long unsigned int' from 'int' may
> change the sign of the result [-Wsign-conversion]
>   return xy[0] + xy[1] < static_cast(z);
>  ^~
> Compiler exited with result code 0
> 
> Taking the const out, using unsigned, or passing x and y separately rather
> than as an array resolves the warning.  Doesn't occur on Clang, MSVC, or
> earlier GCC.
> 
> May be related to bug 66170.

I closed that one as a dup of bug 60342 so I'm gonna do likewise with this one,
too. (Just like those two the warning is gone here with gcc8, too)

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

[Bug c++/80151] Add a warning to catch implicit string to bool conversion (-Wstring-conversion)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-23
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Eric Gallager  ---
Confirming as an enhancement. After adding a missing semicolon to get it to
compile, there's only a warning from -Wunused-but-set-variable:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic -Wwrite-strings -Wconversion
-Wsign-conversion 80151.cc
80151.cc: In function ‘int main()’:
80151.cc:3:7: warning: variable ‘b’ set but not used
[-Wunused-but-set-variable]
  bool b;
   ^
$

[Bug c++/80140] missing -Wignored-attributes on function arguments

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-23
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed. Also the location info for the one where it does print a
-Wattributes warning could be improved, too, to underline the whole attribute
rather than just a closing parenthesis.

[Bug fortran/81296] derived type I/o problem

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #7 from Jerry DeLisle  ---
Fixed on trunk and 7.3, closing.

[Bug fortran/81296] derived type I/o problem

[jvdelisle at gcc dot gnu.org]

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

--- Comment #6 from Jerry DeLisle  ---
Author: jvdelisle
Date: Wed Aug 23 00:41:10 2017
New Revision: 251301

URL: https://gcc.gnu.org/viewcvs?rev=251301=gcc=rev
Log:
2017-08-22  Jerry DeLisle  

Backport from trunk
PR fortran/81296
* trans-io.c (get_dtio_proc): Add check for format label and set
formatted flag accordingly. Reorganize the code a little.

* gfortran.dg/dtio_12.f90: Update test.

Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/trans-io.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/dtio_12.f90

[Bug go/81926] go/parse.o differs between stage2 and stage3 for gcc 7.2.0

[dclarke at blastwave dot org]

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

--- Comment #8 from Dennis Clarke  ---
(In reply to Eric Botcazou from comment #7)
> See PR bootstrap/77995 for a similar issue on x86-64/Solaris.

Looks like a distant relation at best. That seemed to have something
to do with complex types and build_complex_type() requiring a second
"named" bool parameter. In the same ballpark perhaps but only as the
ballboy selling hot dogs watching the game. 

My bootstrap of 7.2.0 did complete fine and the testsuite is running. 
I think I shall circle back to 6.4.0 and try a bootstrap with "go" as
an enabled language after stage1 and see what happens. On sparc only.

I could try this on Solaris x86_64 but I don't have any of that around 
and have not seen it in the wild for some years.

[Bug go/81926] go/parse.o differs between stage2 and stage3 for gcc 7.2.0

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  ---
See PR bootstrap/77995 for a similar issue on x86-64/Solaris.

[Bug c++/79707] missing -Wunused-result on an unused new expression

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-22
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug c++/79658] [-Wuninitialized] referencing uninitialized field of POD struct should warn

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-22
 CC||egallager at gcc dot gnu.org
 Blocks||24639
 Ever confirmed|0   |1

--- Comment #9 from Eric Gallager  ---
confirmed that reproducer v4 warns for f1 and f3 but not f0 or f2.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug c++/79695] spurious -Wunused-variable on a static global of a type declared unused

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-22
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug other/81931] [8 regression] r251260 breaks many tests on powerpc64

[seurer at gcc dot gnu.org]

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

--- Comment #1 from seurer at gcc dot gnu.org ---
I think this may also be causing bootstrap builds of gcc to hang on powerpc64.

[Bug c++/79585] spurious -Wunused-variable on a pointer with attribute unused in function template

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-22
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.0.1, 8.0

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

[Bug other/80923] RTEMS SH ICE building gcc-7.1.0 on FreeBSD 11.0

[Anders.Montonen at iki dot fi]

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

Anders Montonen  changed:

   What|Removed |Added

 CC||Anders.Montonen at iki dot fi

--- Comment #1 from Anders Montonen  ---
The same error happens building GCC 7.2.0 on macOS 10.12.6 host, sh-unknown-elf
target.

/Users/anders/work/toolchain/gcc/7.2.0/sh-elf/./gcc/xgcc
-B/Users/anders/work/toolchain/gcc/7.2.0/sh-elf/./gcc/ -nostdinc
-B/Users/anders/work/toolchain/gcc/7.2.0/sh-elf/sh-elf/newlib/ -isystem
/Users/anders/work/toolchain/gcc/7.2.0/sh-elf/sh-elf/newlib/targ-include
-isystem /Users/anders/work/toolchain/gcc/7.2.0/gcc-7.2.0/newlib/libc/include
-B/Users/anders/work/toolchain/gcc/7.2.0/sh-elf/sh-elf/libgloss/sh
-L/Users/anders/work/toolchain/gcc/7.2.0/sh-elf/sh-elf/libgloss/libnosys
-L/Users/anders/work/toolchain/gcc/7.2.0/gcc-7.2.0/libgloss/sh
-B/Users/anders/local/sh-elf/bin/ -B/Users/anders/local/sh-elf/lib/ -isystem
/Users/anders/local/sh-elf/include -isystem
/Users/anders/local/sh-elf/sys-include-g -O2 -ml -O2  -g -O2 -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector
-Dinhibit_libc  -I. -I. -I../../.././gcc -I../../../../gcc-7.2.0/libgcc
-I../../../../gcc-7.2.0/libgcc/. -I../../../../gcc-7.2.0/libgcc/../gcc
-I../../../../gcc-7.2.0/libgcc/../include  -DHAVE_CC_TLS  -o _negdi2.o -MT
_negdi2.o -MD -MP -MF _negdi2.dep -DL_negdi2 -c
../../../../gcc-7.2.0/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
../../../../gcc-7.2.0/libgcc/unwind-dw2.c: In function 'execute_stack_op':
../../../../gcc-7.2.0/libgcc/unwind-dw2.c:840:10: internal compiler error: in
emit_move_insn, at expr.c:3698
   result = (_Unwind_Sword) second / (_Unwind_Sword) first;
   ~~~^~~~
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[4]: *** [unwind-dw2-Os-4-200.o] Error 1
make[4]: *** Waiting for unfinished jobs
mv -f _ic_invalidate_array.visT _ic_invalidate_array.vis
make[3]: *** [multi-do] Error 1
make[2]: *** [all-multi] Error 2
make[1]: *** [all-target-libgcc] Error 2
make: *** [all] Error 2

[Bug c++/81932] New: Template arguments of type unsigned generate incorrect debugging information

[psmith at gnu dot org]

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

Bug ID: 81932
   Summary: Template arguments of type unsigned generate incorrect
debugging information
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: psmith at gnu dot org
  Target Milestone: ---

I've upgraded from GCC 6.2/binutils 2.27 to GCC 7.2/binutils 2.29 (compiled
myself), running on GNU/Linux on x86_64.  Everything is fine except that GDB
(I've tried both 7.11 and 8.0) can no longer correctly print objects of one of
my templated classes, which I have created a Python printer for.

My template is complex but it's basically:

  template
  class TreeVector
  {
...
  class Tree
  {
...
  private:
  uint const _depth;
  };
...
  Tree* tree;
  uint64 _maxIndex;
...
  };

When I compile with GCC 6.2, I'm able to see the type of my object via GDB
Python macros:

  (gdb) ptype tv
  type = class TreeVector [with T = Pod] {
private:
  TreeVector::Tree *tree;
  volatile uint64 _maxIndex;
...

  (gdb) ptype tv.tree
  type = class TreeVector::Tree {
private:
  const uint _depth;
...

  (gdb) python
  >class tv(gdb.Function):
  >def __init__(self):
  >gdb.Function.__init__(self, "tv")
  >def invoke(self, vector):
  >gdb.write("vector: %s\n" % (str(vector.type)))
  >gdb.write("tree: %s\n" % (str(vector['tree'].type)))
  >gdb.write("depth: %d\n" % (vector['tree']['_depth']))
  >tt = gdb.lookup_type("TreeVector::Tree")
  >return 0
  >tv()
  >^D

  (gdb) p $tv(tv)
  vector: TreeVector
  tree: TreeVector::Tree *
  depth: 3
  $1 = 0

Note here how the value for the second template argument is "2u" and everything
works.

Now I compile this same code with GCC 7.2/binutils 2.29 and use the same GDB,
and my results are different:

  (gdb) ptype tv
  type = class TreeVector [with T = Pod] {
private:
  TreeVector::Tree *tree;
  volatile uint64 _maxIndex;
...

  (gdb) ptype tv.tree
  type = class TreeVector::Tree {
private:
  const uint _depth;
...

  (gdb) p $tv(tv)
  vector: TreeVector
  tree: TreeVector::Tree *
  warning: RTTI symbol not found for class 'TreeVector::Tree'
  depth: 3
  Python Exception  No type named TreeVector::Tree.: 
  Error occurred in Python convenience function: No type named TreeVector::Tree.

Note how the value in the template is just "2", not "2u".  But, when GDB shows
the RTTI warning it's still looking for the "2u" in the type.  However that
type definitely doesn't exist (we get an error trying to look it up).

If I change my template to use "int" instead of "unsigned int", then everything
works in both versions of GCC (removing the now-invalid gdb.lookup_type call):

  (gdb) ptype tv
  type = class TreeVector [with T = Pod] {
...

  (gdb) p $tv(tv)
  vector: TreeVector
  tree: TreeVector::Tree *
  depth: 3
  $1 = 0

[Bug go/81926] go/parse.o differs between stage2 and stage3 for gcc 7.2.0

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
> elfdump in Solaris says stage2 section ".debug_info" size is 0x1636a2:  
> 
> Section Header[37]:  sh_name: .debug_info
> sh_addr:  0   sh_flags:   0
> sh_size:  0x1636a2sh_type:[ SHT_PROGBITS ]
> sh_offset:0x1faa0 sh_entsize: 0
> sh_link:  0   sh_info:0
> sh_addralign: 0x1
> 
> Whereas stage3 reports : 
> 
> Section Header[37]:  sh_name: .debug_info
> sh_addr:  0   sh_flags:   0
> sh_size:  0x163698sh_type:[ SHT_PROGBITS ]
> sh_offset:0x1faa0 sh_entsize: 0
> sh_link:  0   sh_info:0
> sh_addralign: 0x1
> 
> 
> Not exactly 8 bytes. Looks like 10 bytes diff. All other "sh_size" section
> size data matches. 

OK, thanks, this rings a bell.  Unlike other platforms, the bootstrap process
on Solaris involves comparing the debug info, so things like this might go
unnoticed by the developers using other platforms.

[Bug go/81926] go/parse.o differs between stage2 and stage3 for gcc 7.2.0

[dclarke at blastwave dot org]

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

--- Comment #5 from Dennis Clarke  ---
Minor note, the gcc 6.4.0 compiler I am using was not built with support for
"go". I rarely ever build "go" as I have never had a use for it however I
really should. It is possible some small bug has slipped under the radar
because I just did a three stage bootstrap of 7.2.0 without "go" with 
success. Perhaps something subtle at work strictly in the "go" code area.

I will run a testsuite and then get back to perhaps a build with stage1
languages as just C, C++ and then stage2 onwards as "all".

[Bug go/81926] go/parse.o differs between stage2 and stage3 for gcc 7.2.0

[dclarke at blastwave dot org]

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

--- Comment #4 from Dennis Clarke  ---
elfdump in Solaris says stage2 section ".debug_info" size is 0x1636a2:  

Section Header[37]:  sh_name: .debug_info
sh_addr:  0   sh_flags:   0
sh_size:  0x1636a2sh_type:[ SHT_PROGBITS ]
sh_offset:0x1faa0 sh_entsize: 0
sh_link:  0   sh_info:0
sh_addralign: 0x1

Whereas stage3 reports : 

Section Header[37]:  sh_name: .debug_info
sh_addr:  0   sh_flags:   0
sh_size:  0x163698sh_type:[ SHT_PROGBITS ]
sh_offset:0x1faa0 sh_entsize: 0
sh_link:  0   sh_info:0
sh_addralign: 0x1


Not exactly 8 bytes. Looks like 10 bytes diff. All other "sh_size" section size
data matches. 

The output from elfdump is 75k lines long with 1134 lines of diff : 

d$ elfdump ./stage3-gcc/go/parse.o > /tmp/go_parse_elfdump.3
d$ elfdump ./stage2-gcc/go/parse.o > /tmp/go_parse_elfdump.2
d$ wc -l /tmp/go_parse_elfdump.3
   75428 /tmp/go_parse_elfdump.3
d$ wc -l /tmp/go_parse_elfdump.2
   75428 /tmp/go_parse_elfdump.2

d$ diff /tmp/go_parse_elfdump.2 /tmp/go_parse_elfdump.3 | wc -l 
1134

[Bug other/81931] [8 regression] r251260 breaks many tests on powerpc64

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-22
 Ever confirmed|0   |1

[Bug other/81931] New: [8 regression] r251260 breaks many tests on powerpc64

[seurer at gcc dot gnu.org]

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

Bug ID: 81931
   Summary: [8 regression] r251260 breaks many tests on powerpc64
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This change to wide-int.h breaks many tests on powerpc64 both LE and BE.  The
symptom is the compiled code hangs.  There are hundreds of test cases that time
out then fail.  One example:

Running /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/atomic/atomic.exp ...
WARNING: program timed out.
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c   -O1  execution test
WARNING: program timed out.
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c   -O2  execution test
WARNING: program timed out.
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
WARNING: program timed out.
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c   -O3 -g  execution test
WARNING: program timed out.
...etc...

That particular one is doing floating point arithmetic tests on atomic floats
using threads.  At least some (not sure if all) of the other failing tests are
doing similar things.

[Bug c++/79008] missing detail in -Wbuiltin-declaration-mismatch

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-22
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
(In reply to Martin Sebor from comment #0)
> In C++ (but not in C) -Wbuiltin-declaration-mismatch prints the conflicting
> declarations of the function as shown below.  This is helpful when the
> declarations visibly differ but not so much when they look the same as is
> likely to be common in code that declares the function based on the C or
> POSIX standards.
> 
> To avoid this problem, when the conflict is due to missing attributes, the
> warning should also include the attributes that cause the conflict.

Do you have an example that uses attributes? The one you included here doesn't
show any problem with attributes.

> 
> To make this feature generally available beyond this specific warning I
> would suggest to enhance the pretty printer to make it possible to also
> include attributes in a declaration.  E.g., by interpreting the pound ('#')
> flag as a request to do so ("%#qE").
> 
> $ cat b.c && gcc -S -Wall -Wextra -Wpedantic -xc++ b.c
> extern "C" int sprintf (char*, ...);
> 
> b.c:1:16: warning: declaration of ‘int sprintf(char*, ...)’ conflicts with
> built-in declaration ‘int sprintf(char*, const char*, ...)’
> [-Wbuiltin-declaration-mismatch]
>  extern "C" int sprintf (char*, ...);
> ^~~

[Bug c++/78632] Produce warning when a derived class shadows a field of the base class with `-Wshadow`

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-22
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
(In reply to Vittorio Romeo from comment #0)
> struct Base { int a; };
> struct Derived : Base  { int a; };
> int main() { }
> 
> The code snippet above produces no warnings with `-Wshadow` enabled. 
> This seems like an unusual situation that could lead to unexpected behavior.
> 
> I suggest producing a warning when `-Wshadow` is enabled, to alert that
> `Derived::a` is shadowing `Base::a`.
> 
> Related SO question:
> https://stackoverflow.com/questions/40908402

Confirmed that no warnings are produced.

(In reply to Vittorio Romeo from comment #1)
> Forgot to set an appropriate importance level, and I can't seem to edit it.
> Sorry.

That's okay, leaving it as the default is probably better.

[Bug c++/4898] adding an option to verify exception specifications

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Dynamic exception specifications are no longer part of the C++ language anyway.

[Bug go/81926] go/parse.o differs between stage2 and stage3 for gcc 7.2.0

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  ---
> the ELF section header table seems
>  to be in a slightly different place between the two files :
> 
> d$ elfdump -delv stage2-gcc/go/parse.o
> 
> ELF Header
>   ei_magic:   { 0x7f, E, L, F }
>   ei_class:   ELFCLASS64  ei_data:   ELFDATA2MSB
>   ei_osabi:   ELFOSABI_NONE   ei_abiversion: 0
>   e_machine:  EM_SPARCV9  e_version: EV_CURRENT
>   e_type: ET_REL
>   e_flags:[ EF_SPARCV9_TSO ]
>   e_entry: 0  e_ehsize: 64  e_shstrndx:  1
>   e_shoff:  0x3b7cd8  e_shentsize:  64  e_shnum: 86
>   e_phoff: 0  e_phentsize:   0  e_phnum: 0
> 
> d$ elfdump -delv stage3-gcc/go/parse.o
> 
> ELF Header
>   ei_magic:   { 0x7f, E, L, F }
>   ei_class:   ELFCLASS64  ei_data:   ELFDATA2MSB
>   ei_osabi:   ELFOSABI_NONE   ei_abiversion: 0
>   e_machine:  EM_SPARCV9  e_version: EV_CURRENT
>   e_type: ET_REL
>   e_flags:[ EF_SPARCV9_TSO ]
>   e_entry: 0  e_ehsize: 64  e_shstrndx:  1
>   e_shoff:  0x3b7cd0  e_shentsize:  64  e_shnum: 86
>   e_phoff: 0  e_phentsize:   0  e_phnum: 0
> d$
> 
> So there I see 0x3b7cd8 in stage2 and 0x3b7cd0 in stage3. 

Sure, but we need to find where this difference comes from, i.e. which section
of the executable has a different size.  elfdump can probably dump this info.

> At first glance there appears to be only an 8 byte difference in the
> size of the file but looking down through the various sections in the
> ELF data for both files I see the same data represented in very similar
> places but yet, slightly different.  For example the ELF header offset
> is 0x3b7cd0 in one of them and 0x3b7cd8 in the other.  Is this a valid
> functional difference at all?

Maybe not, but the comparison process is very strict.  In any case, 2 identical
compilers should produce identical object files (modulo timestamp).

[Bug c++/81431] add warning for missing initializers in constructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
   Last reconfirmed||2017-08-22
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=16166
 Resolution|DUPLICATE   |---
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
I would prefer to see -Weffc++ deprecated and removed, so tying this valid
request to -Weffc++ might see it die.

[Bug c++/81930] New: [meta-bug] Issues with -Weffc++

[egallager at gcc dot gnu.org]

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

Bug ID: 81930
   Summary: [meta-bug] Issues with -Weffc++
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic, meta-bug
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egallager at gcc dot gnu.org
Depends on: 16166, 16168, 22395, 22406, 25814, 55836, 55837,
56879, 57854, 58407, 68391, 77984
  Target Milestone: ---

This is to help organize all the bugs related to -Weffc++.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16166
[Bug 16166] -Weffc++ finer granularity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16168
[Bug 16168] -Weffc++ item 14 improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22395
[Bug 22395] -Weffc++ shouldn't warn about non-virtual dtor of private
subclasses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22406
[Bug 22406] -Weffc++ warns about missing op= and copy ctor, even when base
classes have already disabled these
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25814
[Bug 25814] Request for warning for parser ambiguity of function declarations
and variable declarations with initializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55836
[Bug 55836] Weffc++: warning: base class 'class std::list' has a non-virtual destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55837
[Bug 55837] [C++11] -Weffc++: warning: 'xxx:yyy' should be initialized in the
member initialization list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56879
[Bug 56879] -Weffc++ warns about non-virtual base class destructor even if it
is protected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57854
[Bug 57854] Would like to have a warning for virtual overrides without C++11
"override" keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58407
[Bug 58407] [C++11] Should warn about deprecated implicit generation of copy
constructor/assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68391
[Bug 68391] -Wsuggest-override does not work on Item 12 of Effective Modern C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77984
[Bug 77984] Invalid warning on templated operator= with -Weffc++

[Bug c++/16166] -Weffc++ finer granularity

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu.org

--- Comment #11 from Eric Gallager  ---
*** Bug 81431 has been marked as a duplicate of this bug. ***

[Bug c++/81431] add warning for missing initializers in constructor

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Eric Gallager  ---
(In reply to Tom Tromey from comment #0)
> I would like gcc to emit a warning when a constructor does not
> initialize a POD member; and in particular I'd like this not to
> be tied to -Wuninitialized.
> 
> Having a warning like this is good for robustness -- it avoids
> situations where one forgets to initialize a scalar or the like.
> 
> I realize -Wuninitialized will do this, but that can be a difficult
> warning to enable for an existing code base, due to false positives.
> 
> Something along the lines of
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972#c9
> would be nice.
> 
> -Weffc++ does warn about this, but it is too broad, as it includes
> members that have a constructor.

-Weffc++ being too broad is bug 16166.

> 
> Here's a simple example:
> 
> struct X
> {
>   int a,b;
> 
>   X() : a(5) { }
> };
> 
> X x;

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

[Bug target/80210] ICE in in extract_insn, at recog.c:2311 on ppc64 for with __builtin_pow

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #13 from Peter Bergner  ---
Closing as fixed.

[Bug go/81926] go/parse.o differs between stage2 and stage3 for gcc 7.2.0

[dclarke at blastwave dot org]

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

--- Comment #2 from Dennis Clarke  ---
the ELF section header table seems
 to be in a slightly different place between the two files :

d$ elfdump -delv stage2-gcc/go/parse.o

ELF Header
  ei_magic:   { 0x7f, E, L, F }
  ei_class:   ELFCLASS64  ei_data:   ELFDATA2MSB
  ei_osabi:   ELFOSABI_NONE   ei_abiversion: 0
  e_machine:  EM_SPARCV9  e_version: EV_CURRENT
  e_type: ET_REL
  e_flags:[ EF_SPARCV9_TSO ]
  e_entry: 0  e_ehsize: 64  e_shstrndx:  1
  e_shoff:  0x3b7cd8  e_shentsize:  64  e_shnum: 86
  e_phoff: 0  e_phentsize:   0  e_phnum: 0

d$ elfdump -delv stage3-gcc/go/parse.o

ELF Header
  ei_magic:   { 0x7f, E, L, F }
  ei_class:   ELFCLASS64  ei_data:   ELFDATA2MSB
  ei_osabi:   ELFOSABI_NONE   ei_abiversion: 0
  e_machine:  EM_SPARCV9  e_version: EV_CURRENT
  e_type: ET_REL
  e_flags:[ EF_SPARCV9_TSO ]
  e_entry: 0  e_ehsize: 64  e_shstrndx:  1
  e_shoff:  0x3b7cd0  e_shentsize:  64  e_shnum: 86
  e_phoff: 0  e_phentsize:   0  e_phnum: 0
d$

So there I see 0x3b7cd8 in stage2 and 0x3b7cd0 in stage3. 


At first glance there appears to be only an 8 byte difference in the
size of the file but looking down through the various sections in the
ELF data for both files I see the same data represented in very similar
places but yet, slightly different.  For example the ELF header offset
is 0x3b7cd0 in one of them and 0x3b7cd8 in the other.  Is this a valid
functional difference at all?  Perhaps a bug lay inside the linker which
created the actual object file? Looking at both files and the ELF data
between them I see the exact same data in both and yet in different
addresses :

stage 2 :

Section Header[44]:  sh_name: .bss
sh_addr:  0   sh_flags:   [ SHF_WRITE SHF_ALLOC ]
sh_size:  0x11sh_type:[ SHT_NOBITS ]
sh_offset:0x204458sh_entsize: 0
sh_link:  0   sh_info:0
sh_addralign: 0x4

stage 3 :

Section Header[44]:  sh_name: .bss
sh_addr:  0   sh_flags:   [ SHF_WRITE SHF_ALLOC ]
sh_size:  0x11sh_type:[ SHT_NOBITS ]
sh_offset:0x204450sh_entsize: 0
sh_link:  0   sh_info:0
sh_addralign: 0x4

That sort of difference lay between the two files in many many places.
Slightly different by 8 bytes again however nm tells me that the symbol
listing is identical between the two files. Perhaps there is no actual
"functional" difference between the files at all.

[Bug tree-optimization/81292] [8 regression] ICE in zero_length_string, at tree-ssa-strlen.c:822

[LpSolit at netscape dot net]

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

--- Comment #10 from Dmitry G. Dyachenko  ---
r249961 PASS for me

[Bug c++/4898] adding an option to verify exception specifications

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
(In reply to luc.maisonobe from comment #0)
> C++ allows to specify exceptions in the function declaration
> but do not enforces it. When lots of classes and methods are
> involved, maintaining up-to-date specifications is very
> difficult, and every missed exception create runtime
> problems (unexpected exception -> abort -> core dumped). For
> the moment the lack of support tools prevents developers
> from using these specifications effectively.
> 
> It would be very helpful to have a switch on the compiler
> to get warnings if a function do not declare the exceptions
> that can be thrown by itself and its callee and that are
> either not caught or that are rethrown. This could be an
> extension to the existing -Weffc++ flag.
> 

Which item from the Effective C++ book says to do this? (I don't actually own
the book myself...)

> As an example, one can look at Java that enforces the proper
> declarations, this is nice.
> 
> Release:
> gcc-3.0
> 
> Environment:
> All

[Bug bootstrap/81710] build fail with glibc 2.26 due to removing ucontext/sigaltstack struct tags

[LpSolit at netscape dot net]

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

Petr Ovtchenkov  changed:

   What|Removed |Added

  Attachment #41921|0   |1
   is patch||
  Attachment #41921|application/mbox|text/plain
  mime type||

--- Comment #3 from Jakub Jelinek  ---
The fix was r249957.

[Bug libstdc++/81891] [5/6/7 Regression] heap-use-after-free if inserting element in std::unordered_map(InputIt, InputIt) throws

[LpSolit at netscape dot net]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/80772] GCC ignores default template argument declaration in the template definition

[LpSolit at netscape dot net]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
dup

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

[Bug tree-optimization/80519] if(p)free(p) with -Os

[LpSolit at netscape dot net]

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

--- Comment #7 from Richard Biener  ---
*** Bug 81892 has been marked as a duplicate of this bug. ***

[Bug target/80210] ICE in in extract_insn, at recog.c:2311 on ppc64 for with __builtin_pow

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #12 from Peter Bergner  ---
Fixes now back ported to all open GCC branches (GCC 7, GCC 6 and GCC 5).

[Bug target/80210] ICE in in extract_insn, at recog.c:2311 on ppc64 for with __builtin_pow

[bergner at gcc dot gnu.org]

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

--- Comment #11 from Peter Bergner  ---
Author: bergner
Date: Tue Aug 22 20:13:11 2017
New Revision: 251293

URL: https://gcc.gnu.org/viewcvs?rev=251293=gcc=rev
Log:
gcc/
Backport from mainline
2017-08-17  Peter Bergner  

PR target/80210
* config/rs6000/rs6000.c (rs6000_activate_target_options): New
function.
(rs6000_set_current_function): Rewrite function to use it.

gcc/testsuite/
Backport from mainline
2017-08-17  Peter Bergner  

PR target/80210
* gcc.target/powerpc/pr80210.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr80210.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/rs6000/rs6000.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug target/80210] ICE in in extract_insn, at recog.c:2311 on ppc64 for with __builtin_pow

[bergner at gcc dot gnu.org]

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

--- Comment #10 from Peter Bergner  ---
Author: bergner
Date: Tue Aug 22 20:10:58 2017
New Revision: 251292

URL: https://gcc.gnu.org/viewcvs?rev=251292=gcc=rev
Log:
gcc/
Backport from mainline
2017-08-17  Peter Bergner  

PR target/80210
* config/rs6000/rs6000.c (rs6000_activate_target_options): New
function.
(rs6000_set_current_function): Rewrite function to use it.

gcc/testsuite/
Backport from mainline
2017-08-17  Peter Bergner  

PR target/80210
* gcc.target/powerpc/pr80210.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr80210.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/rs6000.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/80210] ICE in in extract_insn, at recog.c:2311 on ppc64 for with __builtin_pow

[bergner at gcc dot gnu.org]

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

--- Comment #9 from Peter Bergner  ---
Author: bergner
Date: Tue Aug 22 20:08:51 2017
New Revision: 251291

URL: https://gcc.gnu.org/viewcvs?rev=251291=gcc=rev
Log:
gcc/
Backport from mainline
2017-08-17  Peter Bergner  

PR target/80210
* config/rs6000/rs6000.c (rs6000_activate_target_options): New
function.
(rs6000_set_current_function): Rewrite function to use it.

gcc/testsuite/
Backport from mainline
2017-08-17  Peter Bergner  

PR target/80210
* gcc.target/powerpc/pr80210.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/pr80210.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/rs6000/rs6000.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c++/77984] Invalid warning on templated operator= with -Weffc++

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-22
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Eric Gallager  ---
(In reply to Victor Paléologue from comment #0)
> Created attachment 39810 [details]
> Stand-alone C++ code reproducing a false warning
> 
> In the code attached, Thing::operator= is defined as following:
> 
> struct Thing
> {
>   template
>   Thing& operator=(const T&)
>   {
> return *this;
>   }
> };
> 
> Compiling it, I get a warning that does not seem legitimate:
> 
> $ g++ false_warning.cpp -Weffc++
> false_warning.cpp: In member function ‘Thing& Thing::operator=(const T&)’:
> false_warning.cpp:6:13: warning: ‘operator=’ should return a reference to
> ‘*this’ [-Weffc++]
>  return *this;
>  ^~~~
> 

Confirmed.

(In reply to Jonathan Wakely from comment #4)
> No, but IMHO it should be (unless somebody fixes it, see PR 16166 and PR
> 16168 and PR 55837 and others).

I'd rather see it fixed; I might give it a try myself once I learn enough c++
to know what I'm doing. In the meantime I'll make a meta-bug to gather all the
-Weffc++ bugs together.

[Bug c++/60342] -Wsign-conversion ignores explicit conversion

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||yaghmour.shafik at gmail dot 
com

--- Comment #2 from Eric Gallager  ---
*** Bug 66170 has been marked as a duplicate of this bug. ***

[Bug c++/66170] Bogus warning with -Wsign-conversion when using static_cast on an int

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Eric Gallager  ---
Looks like bug 60342 to me.

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

[Bug middle-end/81908] [8 Regression] FAIL: gfortran.dg/alloc_comp_auto_array_2.f90 -O3 -g -m32

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Below is a small test case that attempts to illustrate the point from comment
#3 about the same logic as for -Walloc-size-larger-than perhaps not applying
quite as well to -Wstringop-overflow.

The odds are minuscule that the argument value is valid (only zero is), and
when it is, the memcpy call is dead, so the warning is helpful for code written
by a human: the call shouldn't be made to begin with.  But the warning is not
helpful to the user when the code is generated by GCC from valid source code.

$ cat a.c && gcc -O2 -S -Wall a.c
void f (char *d, const char *s, __SIZE_TYPE__ n)
{
  if (n > 0 && n <= __SIZE_MAX__ / 2)
n = 0;

  __builtin_memcpy (d, s, n);
}
a.c: In function ‘f’:
a.c:6:3: warning: ‘__builtin_memcpy’ specified size between 9223372036854775808
and 18446744073709551615 exceeds maximum object size 9223372036854775807
[-Wstringop-overflow=]
   __builtin_memcpy (d, s, n);
   ^~

[Bug c++/68391] -Wsuggest-override does not work on Item 12 of Effective Modern C++

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-22
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
(In reply to rhalbersma from comment #0)
> Item 12 of Effective Modern C++ contains this example:
> 
> class Base {
> public:
> virtual void mf1() const;
> virtual void mf2(int x);
> virtual void mf3() &;
> void mf4() const;
> };
> 
> class Derived: public Base {
> public:
> virtual void mf1();
> virtual void mf2(unsigned int x);
> virtual void mf3() &&;
> void mf4() const;
> };
> 
> int main(){}
> 
> gcc -Wsuggest-override does not yield a single warning (-Wall -Wextra
> -pedantic don't help either).

I get these warnings:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic -Wsuggest-override
-Woverloaded-virtual -Weffc++ 68391.cc
68391.cc:1:7: warning: ‘class Base’ has virtual functions and accessible
non-virtual destructor [-Wnon-virtual-dtor]
 class Base {
   ^~~~
68391.cc:9:7: warning: base class ‘class Base’ has accessible non-virtual
destructor [-Wnon-virtual-dtor]
 class Derived: public Base {
   ^~~
68391.cc:9:7: warning: ‘class Derived’ has virtual functions and accessible
non-virtual destructor [-Wnon-virtual-dtor]
68391.cc:3:18: warning: ‘virtual void Base::mf1() const’ was hidden
[-Woverloaded-virtual]
 virtual void mf1() const;
  ^~~
68391.cc:11:18: warning:   by ‘virtual void Derived::mf1()’
[-Woverloaded-virtual]
 virtual void mf1();
  ^~~
68391.cc:4:18: warning: ‘virtual void Base::mf2(int)’ was hidden
[-Woverloaded-virtual]
 virtual void mf2(int x);
  ^~~
68391.cc:12:18: warning:   by ‘virtual void Derived::mf2(unsigned int)’
[-Woverloaded-virtual]
 virtual void mf2(unsigned int x);
  ^~~
68391.cc:5:18: warning: ‘virtual void Base::mf3() &’ was hidden
[-Woverloaded-virtual]
 virtual void mf3() &;
  ^~~
68391.cc:13:18: warning:   by ‘virtual void Derived::mf3() &&’
[-Woverloaded-virtual]
 virtual void mf3() &&;
  ^~~
$

Sure, none of them are -Wsuggest-override specifically, but could they still be
what you were looking for?

[Bug c++/59840] -Wconversion produces incorrect warning when value is shifted by 0

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #1 from Eric Gallager  ---
gcc8 doesn't warn. Probably FIXED, but I'm not sure exactly, could be just a
fluke, so I'll say WORKSFORME.

[Bug c++/70808] Spurious -Wzero-as-null-pointer-constant for nullptr_t

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-22
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Confirmed for both examples.

[Bug c++/81929] New: exponential slowdown in undefined behavior sanitizer for streaming

[patrick.a.moran at gmail dot com]

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

Bug ID: 81929
   Summary: exponential slowdown in undefined behavior sanitizer
for streaming
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick.a.moran at gmail dot com
  Target Milestone: ---

Created attachment 42028
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42028=edit
A reproduction of the issue described

I've attached a reproduction. The trigger for the behavior we identified is:

 * To stream a number of ints (or other numeric types) into a
std::ostringstream
 * To call .str() on that std::ostringstream
 * To do all of the above in a single expression
 * Build with -fsanitize=undefined

It seems that all the above conditions are necessary - the problem vanishes if
you:
 * Split the same logic into multiple logical lines of code
 * Call some member function other than .str() (like .rdbuf())
 * Stream string literals instead of numeric types
 * Compile without -fsanitize=undefined

The behavior we see is a compile-time that seems to grow as roughly 4^n, where
n is the number of ints being streamed in. On my box

10 numbers =   0.671s
11 numbers =   1.608s
12 numbers =   5.356s
13 numbers =  20.250s
14 numbers =  80.163s
15 numbers = 318.994s

Salient output from perf record / perf report:

# Overhead  Command   Shared Object  Symbol
#     . 

#
59.95%  cc1plus   cc1plus[.]
walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
23.54%  cc1plus   cc1plus[.]
replace_placeholders_r(tree_node**, int*, void*)
14.87%  cc1plus   cc1plus[.]
cp_walk_subtrees(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*)
 0.07%  cc1plus   cc1plus[.]
push_to_top_level()
 0.06%  cc1plus   [kernel.kallsyms]  [k] clear_page_c_e
 0.04%  cc1plus   cc1plus[.]
lookup_name_real(tree_node*, int, int, bool, int, int)

[Bug c++/81928] New: if(!this) optimization leads to possible errors without warnings

[matthieu.brucher at gmail dot com]

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

Bug ID: 81928
   Summary: if(!this) optimization leads to possible errors
without warnings
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matthieu.brucher at gmail dot com
  Target Milestone: ---

The constructs if(!this) in a method raises a warning about comparison with
NULL, as it should.
We agree that this is an undefined behavior at its worst. The issue is that the
behavior of this condition is not the same between debug and optimized where
the call is considered at compile time.
Even if there is an existing warning on this undefined behavior, this should be
an error (or a warning no matter what) as there is a different behavior between
debug and optimized (even if they both make sense).

[Bug ada/81919] type derived from instantiation of Ada.Iterator_Interfaces wrongly rejected

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-22
 CC||ebotcazou at gcc dot gnu.org
Summary|Compiler refuses to compile |type derived from
   |valid code  |instantiation of
   ||Ada.Iterator_Interfaces
   ||wrongly rejected
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
> We think that the refusal to compile it is a compiler bug.
> 
> Note that if I remove "type Iterated_Object is access all Integer;" and
> replace "type Cursor is new Iterated_Object;" with "type Cursor is access
> all Integer;" then the compiler does not complaint.

Yes, the behaviour is rather inconsistent.

[Bug go/81926] go/parse.o differs between stage2 and stage3 for gcc 7.2.0

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-22
 CC||ebotcazou at gcc dot gnu.org,
   ||ro at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
> The compiler to be used for the initial stage of bootstrap is gcc 6.4.0 thus
> :
> 
> d$ /usr/local/gcc6/bin/gcc --version 
> gcc (genunix Wed Jul 26 02:41:24 GMT 2017) 6.4.0
> Copyright (C) 2017 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> That had reasonable test results previously : 
> https://gcc.gnu.org/ml/gcc-testresults/2017-07/msg02881.html

But Go wasn't enabled for it, was it?

> There seems to be only an 8 byte size difference : 
> 
> d$ ls -lo ./stage2-gcc/go/parse.o ./stage3-gcc/go/parse.o
> -rw-r--r--   1 dclarke  3904088 Aug 22 04:00 ./stage2-gcc/go/parse.o
> -rw-r--r--   1 dclarke  3904080 Aug 22 04:57 ./stage3-gcc/go/parse.o
> 
> Also the various symbols in these object files are identical but the
> location of data inside the ELF files is slightly different : 

Can you find out (with objdump for example) which section differs in size?

Rainer, do you test Go in this configuration (system as + ld)?

[Bug target/71958] x86_64-w64-mingw32, ICE when '-mx32' is used

[dansan at gcc dot gnu.org]

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

--- Comment #3 from dansan at gcc dot gnu.org ---
Author: dansan
Date: Tue Aug 22 17:59:24 2017
New Revision: 251287

URL: https://gcc.gnu.org/viewcvs?rev=251287=gcc=rev
Log:
PR target/71958: Error on -mx32 with -mabi=ms

gcc/ChangeLog:
2017-08-11  Daniel Santos  

* config/i386/i386.c (ix86_option_override_internal): Error when
-mx32 is combined with -mabi=ms.
(ix86_function_type_abi): Limit errors for mixing -mx32 with
attribute ms_abi.

gcc/testsuite/ChangeLog:
2017-08-11  Daniel Santos  

* gcc.target/i386/pr71958.c: New test to verify error on -mx32
and -mabi=ms
* gcc.target/i386/pr64409.c: Modify to only run on x32.
* gcc.target/i386/pr46470.c: Modify to skip x32 target.
* gcc.target/i386/pr66275.c: Likewise.
* gcc.target/i386/pr68018.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr71958.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr46470.c
trunk/gcc/testsuite/gcc.target/i386/pr64409.c
trunk/gcc/testsuite/gcc.target/i386/pr66275.c
trunk/gcc/testsuite/gcc.target/i386/pr68018.c

[Bug tree-optimization/81488] [8 Regression] gcc goes off the limits allocating memory in gimple-ssa-strength-reduction.c

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #8 from Bill Schmidt  ---
Fixed.

[Bug tree-optimization/81488] [8 Regression] gcc goes off the limits allocating memory in gimple-ssa-strength-reduction.c

[wschmidt at gcc dot gnu.org]

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

--- Comment #7 from Bill Schmidt  ---
Author: wschmidt
Date: Tue Aug 22 17:32:26 2017
New Revision: 251286

URL: https://gcc.gnu.org/viewcvs?rev=251286=gcc=rev
Log:
2017-08-22  Bill Schmidt  

PR tree-optimization/81488
* gimple-ssa-strength-reduction (struct slsr_cand_d): Add visited
and cached_basis fields.
(MAX_SPREAD): New constant.
(alloc_cand_and_find_basis): Initialize new fields.
(clear_visited): New function.
(create_phi_basis_1): Rename from create_phi_basis, set visited
and cached_basis fields.
(create_phi_basis): New wrapper function.
(phi_add_costs_1): Rename from phi_add_costs, add spread
parameter, set visited field, short-circuit when limits reached.
(phi_add_costs): New wrapper function.
(record_phi_increments_1): Rename from record_phi_increments, set
visited field.
(record_phi_increments): New wrapper function.
(phi_incr_cost_1): Rename from phi_incr_cost, set visited field.
(phi_incr_cost): New wrapper function.
(all_phi_incrs_profitable_1): Rename from
all_phi_incrs_profitable, set visited field.
(all_phi_incrs_profitable): New wrapper function.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-strength-reduction.c

[Bug other/81927] [8 regression] Many, many test case failures starting with r251220

[rguenther at suse dot de]

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

--- Comment #2 from rguenther at suse dot de  ---
On August 22, 2017 6:11:56 PM GMT+02:00, "seurer at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81927
>
>seurer at gcc dot gnu.org changed:
>
>   What|Removed |Added
>
>Target||powerpc64-unknown-linux-gnu
>CC||rguenth at gcc dot gnu.org,
>  ||wschmidt at gcc dot gnu.org
>  Host||powerpc64-unknown-linux-gnu
> Build||powerpc64-unknown-linux-gnu
>
>--- Comment #1 from seurer at gcc dot gnu.org ---
>Note that this was on powerpc64 BE only.  LE works fine.

Should be fixed by the last liberty change,thus a duplicate.

[Bug other/81927] [8 regression] Many, many test case failures starting with r251220

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 Target||powerpc64-unknown-linux-gnu
 CC||rguenth at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
   Host||powerpc64-unknown-linux-gnu
  Build||powerpc64-unknown-linux-gnu

--- Comment #1 from seurer at gcc dot gnu.org ---
Note that this was on powerpc64 BE only.  LE works fine.

[Bug other/81927] New: [8 regression] Many, many test case failures starting with r251220

[seurer at gcc dot gnu.org]

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

Bug ID: 81927
   Summary: [8 regression] Many, many test case failures starting
with r251220
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Here's one in detail:

spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/asan/alloca_big_alignment.c
-B/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libsanitizer/
-B/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libsanitizer/asan/
-L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libsanitizer/asan/.libs
-fsanitize=address -g
-I/home/seurer/gcc/gcc-test/gcc/testsuite/../../libsanitizer/include
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -flto
-fno-use-linker-plugin -flto-partition=none -lm -o ./alloca_big_alignment.exe
/tmp/ccS0sV4idebugobjtem: file not recognized: Bad value
collect2: error: ld returned 1 exit status
lto-wrapper: fatal error: /home/seurer/gcc/build/gcc-test/gcc/xgcc returned 1
exit status
compilation terminated.
collect2: fatal error: lto-wrapper returned 1 exit status
compilation terminated.
compiler exited with status 1
output is:
/tmp/ccS0sV4idebugobjtem: file not recognized: Bad value
collect2: error: ld returned 1 exit status
lto-wrapper: fatal error: /home/seurer/gcc/build/gcc-test/gcc/xgcc returned 1
exit status
compilation terminated.
collect2: fatal error: lto-wrapper returned 1 exit status
compilation terminated.

FAIL: c-c++-common/asan/alloca_big_alignment.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  (test for excess errors)
Excess errors:
/tmp/ccS0sV4idebugobjtem: file not recognized: Bad value
lto-wrapper: fatal error: /home/seurer/gcc/build/gcc-test/gcc/xgcc returned 1
exit status
compilation terminated.
collect2: fatal error: lto-wrapper returned 1 exit status
compilation terminated.



Here's the output of the compilation command with -v:

Reading specs from /home/seurer/gcc/build/gcc-test/gcc/specs
COLLECT_GCC=/home/seurer/gcc/build/gcc-test/gcc/xgcc
COLLECT_LTO_WRAPPER=/home/seurer/gcc/build/gcc-test/gcc/lto-wrapper
Target: powerpc64-unknown-linux-gnu
Configured with: /home/seurer/gcc/gcc-test/configure
--prefix=/home/seurer/gcc/install/gcc-test --enable-languages=c,fortran,c++
--with-cpu=power8 --disable-bootstrap
--with-as=/home/seurer/binutils/install/bin/as
--with-ld=/home/seurer/binutils/install/bin/ld
Thread model: posix
gcc version 8.0.0 20170821 (experimental) [trunk revision 251220] (GCC) 
COLLECT_GCC_OPTIONS='-fdiagnostics-color=never' '-v' '-B'
'/home/seurer/gcc/build/gcc-test/gcc/' '-B'
'/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libsanitizer/'
'-B'
'/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libsanitizer/asan/'
'-L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libsanitizer/asan/.libs'
'-fsanitize=address' '-g' '-I'
'/home/seurer/gcc/gcc-test/gcc/testsuite/../../libsanitizer/include'
'-fno-diagnostics-show-caret' '-O2' '-flto' '-fno-use-linker-plugin'
'-flto-partition=none' '-o' './alloca_big_alignment.exe' '-mcpu=power8'
 /home/seurer/gcc/build/gcc-test/gcc/cc1 -quiet -v -I
/home/seurer/gcc/gcc-test/gcc/testsuite/../../libsanitizer/include -iprefix
/home/seurer/gcc/build/gcc-test/gcc/../lib/gcc/powerpc64-unknown-linux-gnu/8.0.0/
-isystem /home/seurer/gcc/build/gcc-test/gcc/include -isystem
/home/seurer/gcc/build/gcc-test/gcc/include-fixed -D__unix__ -D__gnu_linux__
-D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux -Asystem=unix
-Asystem=posix
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/asan/alloca_big_alignment.c
-quiet -dumpbase alloca_big_alignment.c -mcpu=power8 -auxbase
alloca_big_alignment -g -O2 -version -fdiagnostics-color=never
-fsanitize=address -fno-diagnostics-show-caret -flto -fno-use-linker-plugin
-flto-partition=none -o /tmp/ccBq2zds.s
GNU C11 (GCC) version 8.0.0 20170821 (experimental) [trunk revision 251220]
(powerpc64-unknown-linux-gnu)
compiled by GNU C version 7.1.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/home/seurer/gcc/build/gcc-test/gcc/../lib/gcc/powerpc64-unknown-linux-gnu/8.0.0/include"
ignoring nonexistent directory
"/home/seurer/gcc/build/gcc-test/gcc/../lib/gcc/powerpc64-unknown-linux-gnu/8.0.0/include-fixed"
ignoring nonexistent directory
"/home/seurer/gcc/build/gcc-test/gcc/../lib/gcc/powerpc64-unknown-linux-gnu/8.0.0/../../../../powerpc64-unknown-linux-gnu/include"
ignoring nonexistent directory

[Bug c++/77777] Use rich location to mark correct expression for "invalid use of non-static member function"

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-22
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug c++/64875] -Winline does not report C++ methods

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-08-22
 CC||egallager at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |daniel.gutson at intel 
dot com
 Ever confirmed|0   |1

--- Comment #3 from Eric Gallager  ---
(In reply to Daniel Gutson from comment #0)
> The following code misses the warning:
> 
> #include 
> 
> struct PP
> {
>   inline void m();
> };
> 
> int main()
> {
>   PP pp;
>   pp.m();
> }
> 
> inline void PP::m()
> {
>   std::cout << "hola" << std::endl;
> }
> 
> Invoke:
>   g++ -Wall -Wextra -pedantic -ggdb3 -std=c++11 -Winline winline.cpp
> No warnings emitted.
> 
> However:
> 
> objdump -dC ./a.out |grep "PP"
>   40086c: e8 59 00 00 00  callq  4008ca 
> 004008ca :
> 
> If no one is available, assign this to me (though I'm not sure when I will
> have time to address this).

OK.

(In reply to Daniel Gutson from comment #2)
> inline is as useful in c++ as in C regardless of ODR or any other reason but
> its original purpose: performance. I want to know when my hint is not honored
> which is the exact intent of this warning.

If you use an optimization flag the 'inline' is honored:

$ /usr/local/bin/g++ -Wall -Wextra -pedantic -ggdb3 -std=c++11 -Winline -o
64975_O0.exe 64975.cc
$ objdump -dC ./64975_O0.exe | grep "PP"
1e88:   e8 b3 11 00 00  call   3040 <_ZN2PP1mEv$stub>
1f0e :
3040 <_ZN2PP1mEv$stub>:
$ /usr/local/bin/g++ -Wall -Wextra -pedantic -ggdb3 -std=c++11 -Winline -O1 -o
64975_O1.exe 64975.cc
$ objdump -dC ./64975_O1.exe | grep "PP"

So maybe mention optimizing in the warning if you add one.

[Bug c++/77502] -Wzero-as-null-pointer-constant : misleading/imprecise messages

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-22
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Confirmed that the location info ought to be improved.

[Bug c++/77370] missing -Wignored-qualiifiers on a bogus const reference

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-22
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
(In reply to Martin Sebor from comment #0)
> GCC rejects the program below because it tries to initialize the non-const
> reference object cr with a temporary, but it doesn't diagnose the
> declaration of the reference type CR where it disregards the const
> qualifier.  In contrast, Clang diagnoses both.  GCC could be improved by
> doing the same.
> 
> $ (set -x && cat z.C && /build/gcc-trunk-svn/gcc/xgcc -B
> /build/gcc-trunk-svn/gcc -Wall -Wextra -Wpedantic z.C;
> /build/llvm-trunk/bin/clang -S -Wall z.C)
> + cat z.C
> typedef char& R;
> typedef const R CR;
> 
> char c;
> R r = c;
> CR cr = 'b';
> + /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -Wall -Wextra
> -Wpedantic z.C
> z.C:6:9: error: cannot bind non-const lvalue reference of type ‘CR {aka
> char&}’ to an rvalue of type ‘char’
>  CR cr = 'b';
>  ^~~
> + /build/llvm-trunk/bin/clang -S -Wall z.C
> z.C:2:9: warning: 'const' qualifier on reference type 'R' (aka 'char &') has
> no
>   effect [-Wignored-qualifiers]
> typedef const R CR;
> ^~
> z.C:6:4: error: non-const lvalue reference to type 'char' cannot bind to a
>   temporary of type 'char'
> CR cr = 'b';
>^~~~
> 1 warning and 1 error generated.

My version of clang only prints the one error, but then again my version of
clang is old (because my computer is old). Confirmed anyways that it'd still be
a nice additional warning to have.

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 77370.cc
77370.cc:6:9: error: cannot bind non-const lvalue reference of type ‘CR {aka
char&}’ to an rvalue of type ‘char’
 CR cr = 'b';
 ^~~
$ /sw/opt/llvm-3.1/bin/clang++ -c -S -Wall -Wextra -pedantic 77370.cc
77370.cc:6:4: error: non-const lvalue reference to type 'char' cannot bind to a
temporary of type 'char'
CR cr = 'b';
   ^~~~
1 error generated.
$

[Bug tree-optimization/81741] Misoptimisation : replacing a constant field read access by a function call

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #6 from Jeffrey A. Law  ---
Should be fixed on the trunk now.

[Bug tree-optimization/81741] Misoptimisation : replacing a constant field read access by a function call

[law at gcc dot gnu.org]

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

--- Comment #5 from Jeffrey A. Law  ---
Author: law
Date: Tue Aug 22 15:13:09 2017
New Revision: 251279

URL: https://gcc.gnu.org/viewcvs?rev=251279=gcc=rev
Log:
PR tree-optimization/81741
PR tree-optimization/71947
* tree-ssa-dom.c: Include tree-inline.h.
(record_temporary_equivalences): Only record SSA_NAME = SSA_NAME
equivalences if one is more expensive to compute than the other.
* tree-ssa-scopedtables.h (class const_or_copies): Make
record_const_or_copy_raw method private.
(class avail_exprs_stack): New method simplify_binary_operation.
* tree-ssa-scopedtables.c (avail_exprs_stack::lookup_avail_expr): Call
avail_exprs_stack::simplify_binary_operation as needed.
(avail_exprs_stack::simplify_binary_operation): New function.

PR tree-optimization/81741
PR tree-optimization/71947
* gcc.dg/tree-ssa/pr81741.c: New test.
* gcc.dg/tree-ssa/pr71947-7.c: New test.
* gcc.dg/tree-ssa/pr71947-8.c: New test.
* gcc.dg/tree-ssa/pr71947-9.c: New test.
* gcc.dg/tree-ssa/pr71941-1.c: Tweak expected output.
* gcc.dg/tree-ssa/pr71941-2.c: Tweak expected output.
* gcc.dg/tree-ssa/pr71941-3.c: Tweak expected output.
* gcc.dg/tree-ssa/20030922-2.c: xfail.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71947-7.c
  - copied, changed from r251276,
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71947-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71947-8.c
  - copied, changed from r251276,
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71947-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71947-9.c
  - copied, changed from r251276,
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71947-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr81741.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/20030922-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71947-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71947-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71947-3.c
trunk/gcc/tree-ssa-dom.c
trunk/gcc/tree-ssa-scopedtables.c
trunk/gcc/tree-ssa-scopedtables.h

[Bug tree-optimization/71947] [6 Regression] x ^ y not folded to 0 if x == y by DOM

[law at gcc dot gnu.org]

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

--- Comment #16 from Jeffrey A. Law  ---
Author: law
Date: Tue Aug 22 15:13:09 2017
New Revision: 251279

URL: https://gcc.gnu.org/viewcvs?rev=251279=gcc=rev
Log:
PR tree-optimization/81741
PR tree-optimization/71947
* tree-ssa-dom.c: Include tree-inline.h.
(record_temporary_equivalences): Only record SSA_NAME = SSA_NAME
equivalences if one is more expensive to compute than the other.
* tree-ssa-scopedtables.h (class const_or_copies): Make
record_const_or_copy_raw method private.
(class avail_exprs_stack): New method simplify_binary_operation.
* tree-ssa-scopedtables.c (avail_exprs_stack::lookup_avail_expr): Call
avail_exprs_stack::simplify_binary_operation as needed.
(avail_exprs_stack::simplify_binary_operation): New function.

PR tree-optimization/81741
PR tree-optimization/71947
* gcc.dg/tree-ssa/pr81741.c: New test.
* gcc.dg/tree-ssa/pr71947-7.c: New test.
* gcc.dg/tree-ssa/pr71947-8.c: New test.
* gcc.dg/tree-ssa/pr71947-9.c: New test.
* gcc.dg/tree-ssa/pr71941-1.c: Tweak expected output.
* gcc.dg/tree-ssa/pr71941-2.c: Tweak expected output.
* gcc.dg/tree-ssa/pr71941-3.c: Tweak expected output.
* gcc.dg/tree-ssa/20030922-2.c: xfail.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71947-7.c
  - copied, changed from r251276,
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71947-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71947-8.c
  - copied, changed from r251276,
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71947-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71947-9.c
  - copied, changed from r251276,
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71947-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr81741.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/20030922-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71947-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71947-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71947-3.c
trunk/gcc/tree-ssa-dom.c
trunk/gcc/tree-ssa-scopedtables.c
trunk/gcc/tree-ssa-scopedtables.h

[Bug c++/72789] add -Wunused-private-field

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-22
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Eric Gallager  ---
Confirming as an enhancement.

[Bug go/81926] New: go/parse.o differs between stage2 and stage3 for gcc 7.2.0

[dclarke at blastwave dot org]

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

Bug ID: 81926
   Summary: go/parse.o differs between stage2 and stage3 for gcc
7.2.0
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: dclarke at blastwave dot org
CC: cmang at google dot com
  Target Milestone: ---

configure ran thus : 

$ ../gcc-7.2.0/configure --build=sparc64-sun-solaris2.10 \
--target=sparc64-sun-solaris2.10 \
--host=sparc64-sun-solaris2.10 \
--prefix=/usr/local/gcc7 \
--without-gnu-as --without-gnu-ld \
--with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/sparcv9/ld \
--disable-nls --enable-threads=posix --enable-shared \
--with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local \
--with-isl=/usr/local \
--with-build-time-tools=/usr/local/bin --with-cpu=v9 \
--enable-bootstrap \
--enable-languages=ada,c,c++,fortran,go,objc,obj-c++ \
--with-pkgversion=genunix Tue Aug 22 00:36:56 GMT 2017

This resulted in : 

checking build system type... sparc64-sun-solaris2.10
checking host system type... sparc64-sun-solaris2.10
checking target system type... sparc64-sun-solaris2.10
checking for a BSD-compatible install... ../gcc-7.2.0/install-sh -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for a sed that does not truncate output... /usr/local/bin/sed
checking for gawk... /usr/local/bin/gawk
checking for libatomic support... yes
checking for libcilkrts support... yes
checking for libitm support... yes
checking for libsanitizer support... no
checking for libvtv support... no
checking for libmpx support... no
checking for libhsail-rt support... no
checking for sparc64-sun-solaris2.10-gcc... sparc64-sun-solaris2.10-gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether sparc64-sun-solaris2.10-gcc accepts -g... yes
checking for sparc64-sun-solaris2.10-gcc option to accept ISO C89... none
needed
checking for sparc64-sun-solaris2.10-g++... sparc64-sun-solaris2.10-g++
checking whether we are using the GNU C++ compiler... yes
checking whether sparc64-sun-solaris2.10-g++ accepts -g... yes
checking whether g++ accepts -static-libstdc++ -static-libgcc... yes
checking for sparc64-sun-solaris2.10-gnatbind... no
checking for gnatbind... gnatbind
checking for sparc64-sun-solaris2.10-gnatmake... no
checking for gnatmake... gnatmake
checking whether compiler driver understands Ada... yes
checking how to compare bootstrapped objects... cmp $$f1 $$f2 16 16
checking for objdir... .libs
checking for the correct version of gmp.h... yes
checking for the correct version of mpfr.h... yes
checking for the correct version of mpc.h... yes
checking for the correct version of the gmp/mpfr/mpc libraries... yes
checking for isl 0.15 or later... yes
The following languages will be built: c,ada,c++,fortran,go,lto,objc,obj-c++
*** This configuration is not supported in the following subdirectories:
 target-libsanitizer target-libvtv target-libmpx target-libhsail-rt
target-liboffloadmic
(Any other directories should still work fine.)
checking for default BUILD_CONFIG... 
checking for --enable-vtable-verify... no
checking for bison... bison -y
checking for bison... bison
checking for gm4... /usr/local/bin/m4
checking for flex... flex
checking for flex... flex
checking for makeinfo... makeinfo
checking for expect... expect
checking for runtest... runtest
checking for ar... (cached) /usr/xpg4/bin/ar
checking for sparc64-sun-solaris2.10-ar... (cached) /usr/xpg4/bin/ar
checking for as... (cached) /usr/ccs/bin/as
checking for sparc64-sun-solaris2.10-as... (cached) /usr/ccs/bin/as
checking for sparc64-sun-solaris2.10-dlltool... no
checking for dlltool... no
checking for ld... (cached) /usr/ccs/bin/ld
checking for sparc64-sun-solaris2.10-ld... (cached) /usr/ccs/bin/ld
checking for sparc64-sun-solaris2.10-lipo... no
checking for lipo... no
checking for nm... (cached) /usr/ccs/bin/sparcv9/nm -p
checking for sparc64-sun-solaris2.10-nm... (cached) /usr/ccs/bin/sparcv9/nm -p
checking for ranlib... (cached) /usr/ccs/bin/ranlib
checking for sparc64-sun-solaris2.10-ranlib... (cached) /usr/ccs/bin/ranlib
checking for strip... (cached) /usr/ccs/bin/strip
checking for sparc64-sun-solaris2.10-strip... (cached) /usr/ccs/bin/strip
checking for sparc64-sun-solaris2.10-windres... no
checking for windres... no
checking for sparc64-sun-solaris2.10-windmc... no
checking for windmc... no
checking for sparc64-sun-solaris2.10-objcopy... no
checking for objcopy... no
checking for sparc64-sun-solaris2.10-objdump... no
checking for objdump... no
checking for sparc64-sun-solaris2.10-readelf... no

[Bug lto/81925] early lto debug link failure on aarch64_be

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Tue Aug 22 13:54:01 2017
New Revision: 251276

URL: https://gcc.gnu.org/viewcvs?rev=251276=gcc=rev
Log:
2017-08-22  Richard Biener  

PR lto/81925
* simple-object-elf.c (simple_object_elf_write_shdr): Adjust
type of sh_addralign and sh_entsize and properly write
sh_entsize as Elf_Addr.
(simple_object_elf_write_to_file): Read sh_entsize as Elf_Addr.

Modified:
trunk/libiberty/ChangeLog
trunk/libiberty/simple-object-elf.c

[Bug target/81910] [avr] ICE with "address" attribute on type

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

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

[Bug lto/81925] early lto debug link failure on aarch64_be

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[romain.services at mm dot st]

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

Romain  changed:

   What|Removed |Added

 CC||romain.services at mm dot st

--- Comment #6 from Romain  ---
Hi, 

> It might be an interesting exercise to encrypt the APFS volume and see if that
throws just enough additional filesystem overhead in to make the problem go
latent.

I'm also trying to compile gcc-7.2.0 on macOS 10.13, and I'm using encrypted
APFS, but it does not make this bug disappear.

Regards,
Romain

[Bug c++/58950] Missing "statement has no effect"

[nightstrike at gmail dot com]

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

--- Comment #24 from nightstrike  ---
Ah.. I missed Comment #13, the PR is still open because of a slightly different
test.  In any case, if it worked in 4.8, it should be a regression.

[Bug c++/58950] Missing "statement has no effect"

[nightstrike at gmail dot com]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #23 from nightstrike  ---
Given that Comment #1 clearly shows g++ 4.8 working, I think this should
qualify as a regression.  Moreover, g++ 6.2 works correctly, so this was fixed
at some point between 4.9 and 6.2:

$ cat > a.cc
void f() {
  int i __attribute__((vector_size(2*sizeof(int={2,3};
  __builtin_shuffle(i,i);
}

$ g++ -c a.cc -Wunused-value
a.cc: In function 'void f()':
a.cc:3:3: warning: value computed is not used [-Wunused-value]
   __builtin_shuffle(i,i);
   ^

[Bug testsuite/81920] Improve timing-sensitive libgomp.oacc testcases

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries  ---
Created attachment 42027
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42027=edit
Updated patch

prints lines to be matched into a separate file, allowing using scan-file. When
timings are failing, show this in libgomp.sum:
...
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/lib-81.c
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0   scan-file actual time 3 <
0.11: ok
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/lib-81.c
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2   scan-file actual time 3 <
0.11: ok
...

[Bug lto/81925] early lto debug link failure on aarch64_be

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-08-22
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I have a afix.

[Bug testsuite/81920] Improve timing-sensitive libgomp.oacc testcases

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
Created attachment 42026
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42026=edit
tentative patch for lib-81.c

The only problem: error reporting has not improved a lot.

When I hand-edit the test-case to make the matching fail:
...
- /* { dg-output ".*actual time 3 < 0.10: ok"  } */
+ /* { dg-output ".*actual time 3 < 0.11: ok"  } */
...

We just get:
...
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/lib-81.c
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2  output pattern test
...
so, no line saying: this individual dg-output line failed.

In libgomp.log, things are not too readable either:
...
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/lib-81.c
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2  output pattern test
Output was:
actual time 1: 528.946960, delay time: 500.00
actual time 1 >= delay time: ok
actual time 2: 0.073856
actual time 2 < 0.10: ok
actual time 3: 0.022368
actual time 3 < 0.10: ok

Should match:
actual time 1 >= delay time: ok.*actual time 2 < 0.10: ok.*actual time 3 <
0.11: ok
...

[Bug c++/59324] C++11: -Wsequence-point

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Eric Gallager  ---
(In reply to Mathieu Malaterre from comment #0)
> It would be nice to remove the following warning about UB when compiling in
> C++11 mode:
> 

To REMOVE it? Just turn off the warning flag controlling it.

(In reply to Manuel López-Ibáñez from comment #1)
> Clang also thinks this is UB:
> 
> warning: multiple unsequenced modifications to 'b' [-Wunsequenced]

Since clang agrees, that's further evidence the warning is correct. I'm gonna
close this as INVALID since the warning is correct and easily avoidable.

[Bug lto/81925] New: early lto debug link failure on aarch64_be

[nsz at gcc dot gnu.org]

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

Bug ID: 81925
   Summary: early lto debug link failure on aarch64_be
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 42025
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42025=edit
save-temps and other output files

following works without -g, with -g linking fails,
readelf reports errors on linker input, files are
attached in a tar:

$ ./aarch64_be-none-elf-gcc -flto -specs=rdimon.specs -g a.c -v -save-temps
Using built-in specs.
Reading specs from
/home/szabolcs/w/b/build-aarch64_be-none-elf/install/lib/gcc/aarch64_be-none-elf/8.0.0/../../../../aarch64_be-none-elf/lib/rdimon.specs
rename spec lib to libc
COLLECT_GCC=./aarch64_be-none-elf-gcc
COLLECT_LTO_WRAPPER=/home/szabolcs/w/b/build-aarch64_be-none-elf/install/libexec/gcc/aarch64_be-none-elf/8.0.0/lto-wrapper
Target: aarch64_be-none-elf
Configured with: /home/szabolcs/w/b/src/gcc/configure
--target=aarch64_be-none-elf
--prefix=/home/szabolcs/w/b/build-aarch64_be-none-elf/install
--with-gmp=/home/szabolcs/w/b/build-aarch64_be-none-elf/host-tools
--with-mpfr=/home/szabolcs/w/b/build-aarch64_be-none-elf/host-tools
--with-mpc=/home/szabolcs/w/b/build-aarch64_be-none-elf/host-tools
--with-isl=/home/szabolcs/w/b/build-aarch64_be-none-elf/host-tools
--with-pkgversion=unknown --disable-shared --disable-nls --disable-threads
--disable-tls --enable-checking=yes --enable-languages=c,c++,fortran
--with-newlib : (reconfigured) 
Thread model: single
gcc version 8.0.0 20170821 (experimental) (unknown) 
COLLECT_GCC_OPTIONS='-flto' '-specs=rdimon.specs' '-g' '-v' '-save-temps'
'-mbig-endian' '-mabi=lp64'

/home/szabolcs/w/b/build-aarch64_be-none-elf/install/libexec/gcc/aarch64_be-none-elf/8.0.0/cc1
-E -quiet -v a.c -mbig-endian -mabi=lp64 -flto -g -fworking-directory
-fpch-preprocess -o a.i
ignoring nonexistent directory
"/home/szabolcs/w/b/build-aarch64_be-none-elf/install/lib/gcc/aarch64_be-none-elf/8.0.0/../../../../aarch64_be-none-elf/sys-include"
#include "..." search starts here:
#include <...> search starts here:

/home/szabolcs/w/b/build-aarch64_be-none-elf/install/lib/gcc/aarch64_be-none-elf/8.0.0/include

/home/szabolcs/w/b/build-aarch64_be-none-elf/install/lib/gcc/aarch64_be-none-elf/8.0.0/include-fixed

/home/szabolcs/w/b/build-aarch64_be-none-elf/install/lib/gcc/aarch64_be-none-elf/8.0.0/../../../../aarch64_be-none-elf/include
End of search list.
COLLECT_GCC_OPTIONS='-flto' '-specs=rdimon.specs' '-g' '-v' '-save-temps'
'-mbig-endian' '-mabi=lp64'

/home/szabolcs/w/b/build-aarch64_be-none-elf/install/libexec/gcc/aarch64_be-none-elf/8.0.0/cc1
-fpreprocessed a.i -quiet -dumpbase a.c -mbig-endian -mabi=lp64 -auxbase a -g
-version -flto -o a.s
GNU C11 (unknown) version 8.0.0 20170821 (experimental) (aarch64_be-none-elf)
compiled by GNU C version 6.3.0 20170406, GMP version 4.3.2, MPFR
version 3.0.0, MPC version 0.8.2, isl version isl-0.15-2-g00f2e0ca-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C11 (unknown) version 8.0.0 20170821 (experimental) (aarch64_be-none-elf)
compiled by GNU C version 6.3.0 20170406, GMP version 4.3.2, MPFR
version 3.0.0, MPC version 0.8.2, isl version isl-0.15-2-g00f2e0ca-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: c56b6c42715c65bbcbf1872ac0fefbbe
COLLECT_GCC_OPTIONS='-flto' '-specs=rdimon.specs' '-g' '-v' '-save-temps'
'-mbig-endian' '-mabi=lp64'

/home/szabolcs/w/b/build-aarch64_be-none-elf/install/lib/gcc/aarch64_be-none-elf/8.0.0/../../../../aarch64_be-none-elf/bin/as
-EB -mabi=lp64 -o a.o a.s
COMPILER_PATH=/home/szabolcs/w/b/build-aarch64_be-none-elf/install/libexec/gcc/aarch64_be-none-elf/8.0.0/:/home/szabolcs/w/b/build-aarch64_be-none-elf/install/libexec/gcc/aarch64_be-none-elf/8.0.0/:/home/szabolcs/w/b/build-aarch64_be-none-elf/install/libexec/gcc/aarch64_be-none-elf/:/home/szabolcs/w/b/build-aarch64_be-none-elf/install/lib/gcc/aarch64_be-none-elf/8.0.0/:/home/szabolcs/w/b/build-aarch64_be-none-elf/install/lib/gcc/aarch64_be-none-elf/:/home/szabolcs/w/b/build-aarch64_be-none-elf/install/lib/gcc/aarch64_be-none-elf/8.0.0/../../../../aarch64_be-none-elf/bin/
LIBRARY_PATH=/home/szabolcs/w/b/build-aarch64_be-none-elf/install/lib/gcc/aarch64_be-none-elf/8.0.0/:/home/szabolcs/w/b/build-aarch64_be-none-elf/install/lib/gcc/aarch64_be-none-elf/8.0.0/../../../../aarch64_be-none-elf/lib/
COLLECT_GCC_OPTIONS='-flto' '-specs=rdimon.specs' '-g' '-v' '-save-temps'
'-mbig-endian' '-mabi=lp64'

/home/szabolcs/w/b/build-aarch64_be-none-elf/install/libexec/gcc/aarch64_be-none-elf/8.0.0/collect2
-plugin

[Bug target/81924] [5 Regression] ICE: in simplify_binary_operation_1, at simplify-rtx.c:3678 on powerpc64le-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Priority|P3  |P2
  Known to work||4.8.5
   Target Milestone|--- |5.5

[Bug c++/52961] Make -Wempty-body less noisy and enable it with -Wall

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-22
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |minor

--- Comment #11 from Eric Gallager  ---
(In reply to Paolo Carlini from comment #9)
> Uhm, I was under the impression that the other 2 used to give problems and
> that's why we don't warn anymore by default. Bah. All in all, given that we
> have the warning anyway, I don't think this is really an high priority
> issue, if you see what I mean ;)

ok, changing importance from "normal" to "minor" then (and confirming)

[Bug c++/62126] -Wshadow for typedef and template parm

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #1 from Eric Gallager  ---
gcc8 prints a shadowing warning for me:

$ /usr/local/bin/g++ -c -Wall -Wextra -Wshadow -pedantic -D_GNU_SOURCE
-mtune=generic -march=i386 -fstack-protector -Wformat=2 -Wformat-security
62126.cc
62126.cc: In static member function ‘static void Base::hello()’:
62126.cc:25:16: warning: declaration of ‘type_t’ shadows a previous local
[-Wshadow]
typedef int type_t; // <<< shadowing type_t
^~
62126.cc:23:16: note: shadowed declaration is here
   typedef type type_t;
^~
$

So it looks like it was probably FIXED, but I don't have the computing
resources to bisect to find out what version exactly, so I'll just say
WORKSFORME.

[Bug c++/54052] g++ takes excessive time in opt and generate phase; can lead to Segmentation Fault when not enough memory available

[egallager at gcc dot gnu.org]

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

--- Comment #8 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Eric Gallager from comment #6)
> > Doesn't ICE for me, just takes an inordinately long time to compile (once I
> > add -fpermissive):
> 
> You should have used -m32 not -fpermissive, the preprocessed source was
> created on i686-pc-cygwin i.e. an ILP32 target. That's why you got those
> warnings on x86_64.
> 

I'm actually on a 32-bit target myself (i386-apple-darwin9.8.0) so -m32 is
already the default for me

[Bug target/81924] New: [5 Regression] ICE: in simplify_binary_operation_1, at simplify-rtx.c:3678 on powerpc64le-linux-gnu

[doko at gcc dot gnu.org]

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

Bug ID: 81924
   Summary: [5 Regression] ICE: in simplify_binary_operation_1, at
simplify-rtx.c:3678 on powerpc64le-linux-gnu
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen with the gcc-5 branch on  powerpc64le-linux-gnu, works on 4.8, 6 and 7,
worked around with -O1:

$ gcc-5 -c -g -O2 foo.cfoo.c: In function ‘fn1’:
foo.c:19:1: internal compiler error: in simplify_binary_operation_1, at
simplify-rtx.c:3678
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.

(gdb) bt
#0  0x10d12b64 in fancy_abort(char const*, int, char const*) ()
#1  0x1066d4dc in ?? ()
#2  0x102c2048 in ?? ()
#3  0x102c2f70 in cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*,
int, rtx_def* (*)(rtx_def*, bitmap_head*, int, void*), void*) ()
#4  0x10913938 in ?? ()
#5  0x102c1ef4 in ?? ()
#6  0x102c1bb8 in ?? ()
#7  0x102c2f70 in cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*,
int, rtx_def* (*)(rtx_def*, bitmap_head*, int, void*), void*) ()
#8  0x10913938 in ?? ()
#9  0x102c1ef4 in ?? ()
#10 0x102c2f70 in cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*,
int, rtx_def* (*)(rtx_def*, bitmap_head*, int, void*), void*) ()
#11 0x10912508 in emit_note_insn_var_location(variable_def**,
emit_note_data_def*) ()
#12 0x10914654 in ?? ()
#13 0x10919428 in ?? ()
#14 0x1091bbd8 in ?? ()
#15 0x105b5c10 in execute_one_pass(opt_pass*) ()
#16 0x105b6124 in ?? ()
#17 0x105b613c in ?? ()
#18 0x105b613c in ?? ()
#19 0x105b61c4 in execute_pass_list(function*, opt_pass*) ()
#20 0x102b0bac in cgraph_node::expand() ()
#21 0x102b25d8 in ?? ()
#22 0x102b40a8 in symbol_table::finalize_compilation_unit() ()
#23 0x10176be8 in c_write_global_declarations() ()
#24 0x106903fc in ?? ()
#25 0x101588d8 in toplev::main(int, char**) ()
#26 0x10159348 in main ()

$ cat foo.c
typedef __uint128_t vint128_t __attribute__((vector_size(16)));
vint128_t z;
int x, y;

void fn2(void);

void fn1(void)
{
vint128_t c;
y = 1000;
for (; y; y--) {
c = c ^ x;
z -= c;
z ^= x;
c = c ^ x;
}

fn2();
}

[Bug c++/80287] C++ crash with __attribute((may_alias))

[yroux at gcc dot gnu.org]

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

--- Comment #10 from Yvan Roux  ---
Author: yroux
Date: Tue Aug 22 10:51:52 2017
New Revision: 251273

URL: https://gcc.gnu.org/viewcvs?rev=251273=gcc=rev
Log:
2017-08-22  Yvan Roux  

Backport from mainline
2017-08-22  Yvan Roux  

PR c++/80287
* g++.dg/pr80287.C: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/pr80287.C
Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug sanitizer/81923] New: [ASAN] gcc emites wrong odr asan instrumentation for glibc

[d.khalikov at partner dot samsung.com]

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

Bug ID: 81923
   Summary: [ASAN] gcc emites wrong odr asan instrumentation for
glibc
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d.khalikov at partner dot samsung.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: ---

Hello,
I'm currently working on enabling the build of glibc with ASan instrumentation
and facing this type of error:

/tmp/ccKWa1tS.s: Assembler messages:
/tmp/ccKWa1tS.s:20: Error: junk at end of line, first unrecognized character is
`*'
/tmp/ccKWa1tS.s:21: Error: junk at end of line, first unrecognized character is
`*'
/tmp/ccKWa1tS.s:23: Error: unrecognized symbol type ""
/tmp/ccKWa1tS.s:23: Error: junk at end of line, first unrecognized character is
`*'
/tmp/ccKWa1tS.s:24: Error: expected comma after name `__odr_asan.' in .size
directive
/tmp/ccKWa1tS.s:25: Error: invalid character '*' in mnemonic
/tmp/ccKWa1tS.s:53: Error: invalid operands (*UND* and .rodata sections) for
`*'

As far as I understood, the KASAN disables this type of instrumentation:

2567 static bool
2568 asan_needs_odr_indicator_p (tree decl)
2569 {
2570   /* Don't emit ODR indicators for kernel because:
2571  a) Kernel is written in C thus doesn't need ODR indicators.
2572  b) Some kernel code may have assumptions about symbols containing
specific
2573 patterns in their names.  Since ODR indicators contain original
names
2574 of symbols they are emitted for, these assumptions would be broken
for
2575 ODR indicator symbols.  */
2576   return (!(flag_sanitize & SANITIZE_KERNEL_ADDRESS)
2577   && !DECL_ARTIFICIAL (decl)
2578   && !DECL_WEAK (decl)
2579   && TREE_PUBLIC (decl));
2580 }

Could it be some solution for glibc ? Or may be "compile time" flag.
Thanks.

[Bug lto/81487] [mingw32] ld.exe: error: asprintf failed

[gjl at gcc dot gnu.org]

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

--- Comment #7 from Georg-Johann Lay  ---
Author: gjl
Date: Tue Aug 22 10:32:36 2017
New Revision: 251272

URL: https://gcc.gnu.org/viewcvs?rev=251272=gcc=rev
Log:
lto-plugin/
Backport from 2017-07-26 gcc-7-branch r250562.
PR lto/81487
* lto-plugin.c (claim_file_handler): Use xasprintf instead of
asprintf.
[hi!=0]: Swap hi and lo arguments supplied to xasprintf.
gcc/
Backport from 2017-07-26 gcc-7-branch r250562.
PR 81487
* tree-ssa-structalias.c (alias_get_name): Use xasprintf instead
of asprintf.

Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/tree-ssa-structalias.c
branches/gcc-5-branch/lto-plugin/ChangeLog
branches/gcc-5-branch/lto-plugin/lto-plugin.c

[Bug target/81907] memset called when it does not need to be; -mtune=cortex-a9

[rearnsha at gcc dot gnu.org]

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

--- Comment #14 from Richard Earnshaw  ---
(In reply to dongkyun.s from comment #13)
> > Confirmed the call on 6.4.1 but GCC 7 and trunk don't generate the call for 
> > -mcpu=cortex-a9 .
> 
> I also verified memset call is not generated with GCC 7.1 + "-mcpu=cortex-a9
> or -mtune=cortex-a9" or lower.
> 
> It seems interesting that 
> in GCC6,
> - don't generate the memset call for -mcpu=cortex-a12 or higer(e.g,
> cortex-a15, V7 big.LITTLE)
> - always generate the memset call for -mcpu=cortex-a9 or lower(e.g,
> cortex-a7, cotex-a5)
> 
> in GCC7.1
> - always don't generate the memset call (even with V3 Architecture
> Processors. e.g, -mcpu=arm7)

There's nothing in the compiler that explicitly says: use memset for these
cores and not for others.  The choice will be down to available instructions
and their relative costs.

[Bug rtl-optimization/75964] insn combiner removes comparison after ABS

[gjl at gcc dot gnu.org]

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

--- Comment #11 from Georg-Johann Lay  ---
Author: gjl
Date: Tue Aug 22 10:07:51 2017
New Revision: 251271

URL: https://gcc.gnu.org/viewcvs?rev=251271=gcc=rev
Log:
gcc/
Backport from 2017-05-06 trunk r247719.
PR rtl-optimization/75964
* simplify-rtx.c (simplify_const_relational_operation): Remove
invalid handling of comparisons of integer ABS.
gcc/testsuite/
Backport from 2017-05-06 trunk r247719.
PR rtl-optimization/75964
* gcc.dg/torture/pr75964.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr75964.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/simplify-rtx.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/81305] [avr] avrtiny uses LDS for SREG in ISR routines which is out of range of LDS.

[gjl at gcc dot gnu.org]

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

--- Comment #7 from Georg-Johann Lay  ---
Author: gjl
Date: Tue Aug 22 10:01:38 2017
New Revision: 251270

URL: https://gcc.gnu.org/viewcvs?rev=251270=gcc=rev
Log:
gcc/
Backport from 2017-07-05 trunk r249995.
PR target/81305
* config/avr/avr.c (avr_out_movhi_mr_r_xmega) [CONSTANT_ADDRESS_P]:
Don't depend on "optimize > 0".
(out_movhi_r_mr, out_movqi_mr_r): Same.
(out_movhi_mr_r, out_movqi_r_mr): Same.
(avr_address_cost) [CONSTANT_ADDRESS_P]: Don't depend cost for
io_address_operand on "optimize > 0".
gcc/testsuite/
Backport from 2017-07-05 trunk r249995, r249996.
PR target/81305
* gcc.target/avr/isr-test.h: New file.
* gcc.target/avr/torture/isr-01-simple.c: New test.
* gcc.target/avr/torture/isr-02-call.c: New test.
* gcc.target/avr/torture/isr-03-fixed.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/avr/isr-test.h
branches/gcc-5-branch/gcc/testsuite/gcc.target/avr/torture/isr-01-simple.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/avr/torture/isr-02-call.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/avr/torture/isr-03-fixed.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/avr/avr.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c++/81922] New: ICE in output_constructor_regular_field, at varasm.c:5030

[rguenth at gcc dot gnu.org]

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

Bug ID: 81922
   Summary: ICE in output_constructor_regular_field, at
varasm.c:5030
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-*-*

Created attachment 42024
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42024=edit
unincluded unreduced testcase

> g++-7 -std=gnu++1z -S floc.cc 
floc.cc:187:1: internal compiler error: in output_constructor_regular_field, at
varasm.c:5030
continue;
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

same ICE with gcc 6 and trunk.