[Bug c++/69775] thread_local extern variable causes linkage error

[felix.esch.42+dev at gmail dot com]

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

felix.esch.42+dev at gmail dot com  changed:

   What|Removed |Added

 CC||felix.esch.42+dev at gmail dot 
com

--- Comment #1 from felix.esch.42+dev at gmail dot com  ---
Created attachment 38241
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38241=edit
minimal example with --save-tems

Run with: g++ -std=c++14 tls-error.cpp tls-main.cpp -o tls-error
d
This is a minimal example. The extra header / cpp unit is necesary and
compiling all in one compilation unit does not trigger this error.
Using -std=c++11 does not change the behaviour.

Running the command above yields no executable file and the following output:

/tmp/ccyxWUc5.o: In function `TLS wrapper function for A::var':
tls-main.cpp:(.text._ZTWN1A3varE[_ZTWN1A3varE]+0x5): undefined reference to
`TLS init function for A::var'
collect2: error: ld returned 1 exit status

I use gcc v 5.3 on 64 bit arch linux:

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc-5-20160209/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-multilib --disable-werror
--enable-checking=release
Thread model: posix
gcc version 5.3.0 (GCC)

[Bug c++/70617] internal compiler error: Segmentation fault

[jan.sm...@alcatel-lucent.com]

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

--- Comment #5 from Jan Smets <jan.sm...@alcatel-lucent.com> ---
Reduced test case by creduce

struct UINT;
typedef struct { UINT TYPES } eType;
fn1(eType) {


gcc version 5.3.1 20160411 (GCC) 
 = gcc-5-branch @ 0efe1cc72d37ff1173b52cf6bc3f17bd0ccb59f3
target = x86_64-unknown-linux-gnu

compile with : -xc++ -c testcase.best  -o /dev/null  -m32 -w

[Bug c++/70635] New: ICE on (and rejects) valid code on x86_64-linux-gnu: Segmentation fault (program cc1plus)

[su at cs dot ucdavis.edu]

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

Bug ID: 70635
   Summary: ICE on (and rejects) valid code on x86_64-linux-gnu:
Segmentation fault (program cc1plus)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current GCC trunk (and
4.9.x and later) on x86_64-linux-gnu in both 32-bit and 64-bit modes.  

The code does not cause an ICE for 4.8.x (and earlier), but is rejected. It
looks valid and is accepted by clang.


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20160411 (experimental) [trunk revision 234874] (GCC) 
$ 
$ g++-trunk -c small.cpp
small.cpp:11:37: error: declaration of ‘typedef typename A::B::type>::type A::B::type’ -fpermissive]
   typedef typename A < type >::type type;
 ^~~~
small.cpp:5:28: error: changes meaning of ‘type’ from ‘typedef typename
A::B::type A::type’ [-fpermissive]
   typedef typename B::type type;
^~~~
g++-trunk: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 
$ g++-4.8 -c small.cpp
small.cpp:11:37: error: declaration of ‘typedef typename A::B::type>::type A::B::type’ [-fpermissive]
   typedef typename A < type >::type type;
 ^
small.cpp:5:28: error: changes meaning of ‘type’ from ‘typedef typename
A::B::type A::type’ [-fpermissive]
   typedef typename B::type type;
^
$ 
$ clang++-trunk -c small.cpp -Weverything
$ 





template < typename T > 
struct A
{
  struct B;
  typedef typename B::type type;
};

template < typename T > 
struct A < T >::B
{
  typedef typename A < type >::type type;
  type Foo ();
};

template < typename T > 
typename A < T >::B::type
A < T >::B::Foo ()
{
  return 0;
}

[Bug rtl-optimization/70625] [4.9/5 Regression] Memory exhaustion when building specific snippet at -O2

[asolokha at gmx dot com]

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

--- Comment #4 from Arseny Solokha  ---
1. % armv7a-hardfloat-linux-gnueabihf-gcc-4.9.3 -v  
Using built-in specs.
COLLECT_GCC=armv7a-hardfloat-linux-gnueabihf-gcc-4.9.3
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv7a-hardfloat-linux-gnueabihf/4.9.3/lto-wrapper
Target: armv7a-hardfloat-linux-gnueabihf
Configured with:
/var/tmp/portage/cross-armv7a-hardfloat-linux-gnueabihf/gcc-4.9.3/work/gcc-4.9.3/configure
--host=x86_64-pc-linux-gnu --target=armv7a-hardfloat-linux-gnueabihf
--build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/armv7a-hardfloat-linux-gnueabihf/gcc-bin/4.9.3
--includedir=/usr/lib/gcc/armv7a-hardfloat-linux-gnueabihf/4.9.3/include
--datadir=/usr/share/gcc-data/armv7a-hardfloat-linux-gnueabihf/4.9.3
--mandir=/usr/share/gcc-data/armv7a-hardfloat-linux-gnueabihf/4.9.3/man
--infodir=/usr/share/gcc-data/armv7a-hardfloat-linux-gnueabihf/4.9.3/info
--with-gxx-include-dir=/usr/lib/gcc/armv7a-hardfloat-linux-gnueabihf/4.9.3/include/g++-v4
--with-python-dir=/share/gcc-data/armv7a-hardfloat-linux-gnueabihf/4.9.3/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --disable-nls --enable-checking=release --enable-esp
--enable-libstdcxx-time --enable-poison-system-directories
--with-sysroot=/usr/armv7a-hardfloat-linux-gnueabihf --disable-bootstrap
--enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-altivec
--disable-fixed-point --with-float=hard --with-arch=armv7-a --with-float=hard
--with-fpu=vfpv3-d16 --disable-libgcj --enable-libgomp --disable-libmudflap
--disable-libssp --disable-libcilkrts --disable-libquadmath --enable-lto
--with-cloog --disable-isl-version-check --enable-libsanitizer
Thread model: posix
gcc version 4.9.3

Memory hog.

2. % armv7m-softfloat-eabi-gcc-5.3.0 -v
Using built-in specs.
COLLECT_GCC=armv7m-softfloat-eabi-gcc-5.3.0
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv7m-softfloat-eabi/5.3.0/lto-wrapper
Target: armv7m-softfloat-eabi
Configured with:
/var/tmp/portage/cross-armv7m-softfloat-eabi/gcc-5.3.0/work/gcc-5.3.0/configure
--host=x86_64-pc-linux-gnu --target=armv7m-softfloat-eabi
--build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/armv7m-softfloat-eabi/gcc-bin/5.3.0
--includedir=/usr/lib/gcc/armv7m-softfloat-eabi/5.3.0/include
--datadir=/usr/share/gcc-data/armv7m-softfloat-eabi/5.3.0
--mandir=/usr/share/gcc-data/armv7m-softfloat-eabi/5.3.0/man
--infodir=/usr/share/gcc-data/armv7m-softfloat-eabi/5.3.0/info
--with-gxx-include-dir=/usr/lib/gcc/armv7m-softfloat-eabi/5.3.0/include/g++-v5
--with-python-dir=/share/gcc-data/armv7m-softfloat-eabi/5.3.0/python
--enable-languages=c --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --disable-nls --enable-checking=release
--enable-poison-system-directories --disable-shared --disable-libatomic
--disable-threads --without-headers --disable-bootstrap --with-newlib
--enable-multilib --disable-altivec --disable-fixed-point --with-float=soft
--with-arch=armv7-m --with-mode=thumb --disable-libgcj --disable-libgomp
--disable-libmudflap --disable-libssp --disable-libcilkrts
--disable-libquadmath --enable-lto --with-isl --disable-isl-version-check
--disable-libsanitizer
Thread model: single
gcc version 5.3.0

Successful compilation.

[Bug tree-optimization/70357] [openacc][gomp4] ICE on reduction (+:sum) private (sum)

[cesar at gcc dot gnu.org]

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

cesar at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from cesar at gcc dot gnu.org ---
This issue has been resolved in r234889. Note that private reductions are now
reported as errors.

[Bug tree-optimization/70357] [openacc][gomp4] ICE on reduction (+:sum) private (sum)

[cesar at gcc dot gnu.org]

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

--- Comment #2 from cesar at gcc dot gnu.org ---
Author: cesar
Date: Mon Apr 11 23:21:28 2016
New Revision: 234889

URL: https://gcc.gnu.org/viewcvs?rev=234889=gcc=rev
Log:
gcc/
PR tree-optimization/70357
* gimplify.c (gimplify_scan_omp_clauses): Remove stale acc reduction
code.
(gimplify_adjust_omp_clauses): Add or adjust data clauses for acc
parallel reductions as necessary.  Error on those that are private.
(localize_reductions_r): Delete.
(localize_reductions): Delete.
(gimplify_omp_for): Don't call localize_reductions.
(gimplify_omp_workshare): Likewise.
* omp-low.c (build_outer_var_ref): Remove stale reduction-specific
corner cases.
(fixup_remapped_decl): Likewise.
(scan_sharing_clauses):  Don't install variables which are used in
acc parallel reductions.
(check_omp_nesting_restrictions): Remove stale reduction-specific
corner cases.
(scan_omp_1_stmt): Clean up whitespace.
(lower_rec_input_clauses): Remove stale reduction-specific corner
cases.
(lower_oacc_reductions): Update it to handle parallel, reference and
nested reductions.
(lower_omp_target): Don't remap variables appearing in acc parallel
reductions.
* tree-core.h (enum omp_clause_code): Remove stale comments about
the fifth reduction clause operand.
* tree.c (omp_clause_num_ops): Set the number of reduction clause
operands to 5.
(walk_tree_1): Update error checking for the reduction clause.
* tree.h (OMP_CLAUSE_MAP_IN_REDUCTION): New macro.


Modified:
branches/gomp-4_0-branch/gcc/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/gimplify.c
branches/gomp-4_0-branch/gcc/omp-low.c
branches/gomp-4_0-branch/gcc/tree-core.h
branches/gomp-4_0-branch/gcc/tree.c
branches/gomp-4_0-branch/gcc/tree.h

[Bug c++/70634] New: ICE on valid code on x86_64-linux-gnu: Segmentation fault (program cc1plus)

[su at cs dot ucdavis.edu]

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

Bug ID: 70634
   Summary: ICE on valid code on x86_64-linux-gnu: Segmentation
fault (program cc1plus)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current GCC trunk on
x86_64-linux-gnu in both 32-bit and 64-bit modes.  

This is a regression from 5.3.x.


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20160411 (experimental) [trunk revision 234874] (GCC) 
$ 
$ g++-5.3 -c small.cpp
$ clang++ -c small.cpp
$ 
$ g++-trunk -c small.cpp
g++-trunk: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 


-


template < typename T > 
bool foo ()
{
  const int i = sizeof (i) > 1 ? sizeof (T) : 0;
  return i > 0;
}

[Bug target/70630] [6 regression] sparc bootstrap failure: sparc.c:4919:6: error: suggest explicit braces to avoid ambiguous 'else'

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
> At least from the code indentation it seems the right fix is to add braces
> that will match the formatting, but it needs to be tested.

Right, the code is effectively a no-op since all global registers are
call-used, so fixing it won't change anything for code generation in the end.

> The bug has been introduced in r174897 it seems.

Ouch.

[Bug c++/70594] [6 Regression] -fcompare-debug failure

[nathan at gcc dot gnu.org]

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

--- Comment #19 from Nathan Sidwell  ---
(In reply to Jason Merrill from comment #17)
> I still don't understand why/how this is causing problems, if
> -fcompare-debug only cares about the order of decls.  The copied decls
> shouldn't appear anywhere in the output, and other decls should still have
> the same order.

DECL_UID escapes into the emitted names, as the fragment Jakub's just pointed
to shows.  We perturb the DECL_UID's allocated, as I describe in comment 7. 
Hope that helps.

[Bug c++/70610] [6 regression] error: invalid initialization of non-const reference of type

[ppalka at gcc dot gnu.org]

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

--- Comment #6 from Patrick Palka  ---
uhhh... here: https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00482.html

[Bug c++/70610] [6 regression] error: invalid initialization of non-const reference of type

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-04-11
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Patrick Palka  ---
Patch

[Bug c++/70627] [6 Regression] internal compiler error: verify_type failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Reduced testcase (-O2 -g):
struct D;
struct A
{
  D *operator->();
};
struct B
{
  template  void foo (T &&...) {}
};
typedef unsigned char G;
enum class H : G;
struct C
{
};
struct D : C
{
  B foo () const { B a; a.foo (d); }
  H d;
};
struct F : C
{
  void foo ();
  A f;
};
enum class H : unsigned char;
void F::foo () { B b = f->foo (); }

[Bug c++/70594] [6 Regression] -fcompare-debug failure

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  ---
For the testcases in this PR probably:
--- gcc/tree-sra.c  2016-04-09 13:21:06.111510703 +0200
+++ gcc/tree-sra.c  2016-04-11 23:11:41.253126047 +0200
@@ -1537,17 +1537,12 @@ compare_access_positions (const void *a,
 static void
 make_fancy_decl_name (tree decl)
 {
-  char buffer[32];
-
   tree name = DECL_NAME (decl);
   if (name)
 obstack_grow (_obstack, IDENTIFIER_POINTER (name),
  IDENTIFIER_LENGTH (name));
   else
-{
-  sprintf (buffer, "D%u", DECL_UID (decl));
-  obstack_grow (_obstack, buffer, strlen (buffer));
-}
+obstack_grow (_obstack, "D", 5);
 }

 /* Helper for make_fancy_name.  */

or something similar would be enough (or do that only for flag_dump_final_insns
!= NULL?).  But the #c0 report suggests this affects more than that, but only
Tobias has the reproducer that.

[Bug c++/70594] [6 Regression] -fcompare-debug failure

[jason at gcc dot gnu.org]

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

--- Comment #17 from Jason Merrill  ---
I still don't understand why/how this is causing problems, if -fcompare-debug
only cares about the order of decls.  The copied decls shouldn't appear
anywhere in the output, and other decls should still have the same order.

[Bug c/70633] New: ICE on valid code at -Os (in 32-bit mode) on x86_64-linux-gnu: output_operand: invalid expression as operand

[su at cs dot ucdavis.edu]

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

Bug ID: 70633
   Summary: ICE on valid code at -Os (in 32-bit mode) on
x86_64-linux-gnu: output_operand: invalid expression
as operand
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current GCC trunk (and
5.x) at -Os on x86_64-linux-gnu in the 32-bit mode. 

This is a regression from 4.9.x. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20160411 (experimental) [trunk revision 234874] (GCC)
$
$ gcc-trunk -m32 -O0 small.c
$ gcc-4.9 -m32 -Os small.c
$
$ gcc-trunk -m32 -Os small.c
small.c: In function ‘main’:
small.c:10:1: internal compiler error: output_operand: invalid expression as
operand
 }
 ^
0x8610c3 output_operand_lossage(char const*, ...)
../../gcc-source-trunk/gcc/final.c:3409
0x861a0d output_addr_const(_IO_FILE*, rtx_def*)
../../gcc-source-trunk/gcc/final.c:3998
0xe5291e assemble_integer_with_op(char const*, rtx_def*)
../../gcc-source-trunk/gcc/varasm.c:2668
0xe52975 default_assemble_integer(rtx_def*, unsigned int, int)
../../gcc-source-trunk/gcc/varasm.c:2684
0xe529fa assemble_integer(rtx_def*, unsigned int, unsigned int, int)
../../gcc-source-trunk/gcc/varasm.c:2700
0xe59339 output_constant
../../gcc-source-trunk/gcc/varasm.c:4749
0xe5b3ed output_constant
../../gcc-source-trunk/gcc/varasm.c:5003
0xe5b3ed output_constructor_regular_field
../../gcc-source-trunk/gcc/varasm.c:5006
0xe5b3ed output_constructor
../../gcc-source-trunk/gcc/varasm.c:5276
0xe59be0 assemble_constant_contents
../../gcc-source-trunk/gcc/varasm.c:3381
0xe624e4 output_constant_def_contents
../../gcc-source-trunk/gcc/varasm.c:3426
0xe62768 mark_constants_in_pattern
../../gcc-source-trunk/gcc/varasm.c:3951
0xe628db mark_constants
../../gcc-source-trunk/gcc/varasm.c:3983
0xe628db mark_constant_pool
../../gcc-source-trunk/gcc/varasm.c:3999
0xe628db output_constant_pool
../../gcc-source-trunk/gcc/varasm.c:4040
0xe628db assemble_start_function(tree_node*, char const*)
../../gcc-source-trunk/gcc/varasm.c:1726
0x864909 rest_of_handle_final
../../gcc-source-trunk/gcc/final.c:4439
0x864909 execute
../../gcc-source-trunk/gcc/final.c:4516
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$





int a;

int main ()
{ 
  int __attribute__ ((vector_size (4 * sizeof (int b =
{ (int) main, 0, 0, 0 };
  if ( + a)
__builtin_abort ();
  return 0;
}

[Bug target/70630] [6 regression] sparc bootstrap failure: sparc.c:4919:6: error: suggest explicit braces to avoid ambiguous 'else'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-11
 CC||ebotcazou at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
That is because the warning is new (well, old-new, it existed for C a decade
ago or so).
At least from the code indentation it seems the right fix is to add braces that
will match the formatting, but it needs to be tested.
The bug has been introduced in r174897 it seems.

[Bug c++/70632] New: Wrong function name resolution using variadic template and additional template parameters

[grumpy76 at web dot de]

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

Bug ID: 70632
   Summary: Wrong function name resolution using variadic template
and additional template parameters
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: grumpy76 at web dot de
  Target Milestone: ---

GCC Version

g++ (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6) - devtoolset 3
g++ (GCC) 5.2.1 20150902 (Red Hat 5.2.1-2) - devtoolset 4


System
--
CentOS Linux release 7.2.1511 (Core)


Command line to compile
---
g++ -std=c++11 -Wall -Wextra -pedantic


Minimal code to reproduce
-
#include 
#include 
#include 

template
std::ostringstream& appendToStream(std::ostringstream& stream, const T&
value) {
stream << value;
return stream;
}

template
std::ostringstream& appendToStream(std::ostringstream& stream, const T&
value, Args... args) {
stream << value;
return appendToStream(stream, args...);
}

template
std::string createMessage(Args... args) {
std::ostringstream x;
appendToStream(x, args...);
return x.str(); 
}

template
std::string foo(int, Args... args) {
return std::string("foo with int: " + createMessage(args...));
}

template
std::string foo(Args... args) {
return std::string("foo without int: " +
createMessage(args...));
}

template
std::string bar(int, Args... args) {
return std::string("bar with int: " + createMessage(args...));
}

template
std::string bar(Args... args) {
return std::string("bar without int: " +
createMessage(args...));
}

int main(int, char**) {
int i(-1);
std::cout << foo(i, "Hello ", "world") << std::endl;
std::cout << foo("Hello ", "world") << std::endl;
std::cout << bar(i, "Hello ", "world") << std::endl;
std::cout << bar("Hello ", "world") << std::endl;
}


Output is
-
foo with int: Hello world
foo without int: Hello world
bar without int: -1Hello world
bar without int: Hello world


Output expected
---
foo with int: Hello world
foo without int: Hello world
bar with int: Hello world
bar without int: Hello world


Comments

Code works as expected with 
- g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-4)
- clang version 3.4.2 (tags/RELEASE_34/dot2-final)
- clang version 3.8.0 (tags/RELEASE_380/final)
- msvc-14.0 (19.00.23918)

[Bug target/70381] On powerpc, -mfloat128 is on by default for all VSX systems

[meissner at gcc dot gnu.org]

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

--- Comment #7 from Michael Meissner  ---
Author: meissner
Date: Mon Apr 11 19:45:35 2016
New Revision: 234884

URL: https://gcc.gnu.org/viewcvs?rev=234884=gcc=rev
Log:
[gcc]
2016-04-11  Michael Meissner  

PR target/70381
* config/rs6000/rs6000.c (rs6000_opt_masks): Disable using the
target attribute and pragma from changing the -mfloat128
and -mfloat128-hardware options.

* doc/extend.texi (Additional Floating Types): Document PowerPC
__float128 restrictions.

[libgcc]
2016-04-11  Michael Meissner  

PR target/70381
* configure.ac (powerpc*-*-linux*): Rework tests to build
__float128 emulation routines to not depend on using #pragma GCC
target to enable -mfloat128.
* configure: Regnerate.

[gcc/testsuite]
2016-04-11  Michael Meissner  

PR target/70381
* gcc.target/powerpc/float128-1.c: New tests to make sure the
__float128 emulator is built and runs.
* gcc.target/powerpc/float128-1.c: Likewise.

* lib/target-supports.exp (check_ppc_float128_sw_available):
Rework tests for __float128 software and hardware
availability. Fix exit condition to return 0 on success.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/float128-1.c
trunk/gcc/testsuite/gcc.target/powerpc/float128-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/doc/extend.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/target-supports.exp
trunk/libgcc/ChangeLog
trunk/libgcc/configure
trunk/libgcc/configure.ac

[Bug c++/70631] New: Warn about redundant comparisons with -Wlogical-op

[vittorio.romeo at outlook dot com]

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

Bug ID: 70631
   Summary: Warn about redundant comparisons with -Wlogical-op
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vittorio.romeo at outlook dot com
  Target Milestone: ---

https://godbolt.org/g/Tt8hfe

int main()
{
int x = 0;

// warning: logical 'or' of collectively exhaustive tests is always true
[-Wlogical-op]
if(x != 5 || x != 6) { } 

// warning: logical 'and' of mutually exclusive tests is always false
[-Wlogical-op]
if(x == 5 && x == 6) { } 

// no warnings
if(true || x == 10) { }
if(false && x == 10) { }

// no warnings
if(x == 5 || x != 6) { } // x==5 is redundant
if(x == 5 && x != 6) { } // x!=6 is redundant
}

I think gcc should warn about the redundant comparisons with -Wlogical-op.

More information:
https://www.reddit.com/r/cpp/comments/4e9kf1/logical_expressions_in_cc_mistakes_made_by/

[Bug target/70630] New: [6 regression] sparc bootstrap failure: sparc.c:4919:6: error: suggest explicit braces to avoid ambiguous 'else'

[mikpelinux at gmail dot com]

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

Bug ID: 70630
   Summary: [6 regression] sparc bootstrap failure:
sparc.c:4919:6: error: suggest explicit braces to
avoid ambiguous 'else'
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikpelinux at gmail dot com
  Target Milestone: ---

Attempting to bootstrap gcc-6-20160410 on sparc-linux fails with:

/mnt/scratch/gcc-6-20160410/gcc/config/sparc/sparc.c: In function 'long long
int sparc_compute_frame_size(long long int, int)':
/mnt/scratch/gcc-6-20160410/gcc/config/sparc/sparc.c:4919:6: error: suggest
explicit braces to avoid ambiguous 'else' [-Werror=parentheses]
   if (TARGET_ARCH64)
  ^
cc1plus: all warnings being treated as errors
make[3]: *** [sparc.o] Error 1
make[3]: *** Waiting for unfinished jobs
make[3]: Leaving directory `/mnt/scratch/objdir6/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/mnt/scratch/objdir6'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/mnt/scratch/objdir6'
make: *** [bootstrap] Error 2

What it's complaining about is:

if (TARGET_ARCH64)
for (i = 0; i < 8; i++)
  if (save_global_or_fp_reg_p (i, 0))
n_global_fp_regs += 2;
  else
for (i = 0; i < 8; i += 2)
  if (save_global_or_fp_reg_p (i, 0) || save_global_or_fp_reg_p (i + 1, 0))
n_global_fp_regs += 2;

which seems highly dubious to me (the else should probably go with the outer
not the inner if).
gcc-6-20160403 bootstrapped fine.  Strangely enough, it contains the exact same
code here, so I don't know why gcc didn't complain before.

Configured as:
/mnt/scratch/gcc-6-20160410/configure --prefix=/mnt/scratch/install6
--with-gmp=/home/mikpe/pkgs/linux-sparc64/gmp-6.1.0
--with-mpfr=/home/mikpe/pkgs/linux-sparc64/mpfr-3.1.4
--with-mpc=/home/mikpe/pkgs/linux-sparc64/mpc-1.0.3 --enable-multilib
--disable-plugin --disable-lto --disable-nls --enable-threads=posix
--enable-checking=release --disable-libmudflap --enable-languages=c,ada,c++
--build=sparc-unknown-linux --target=sparc-unknown-linux --with-cpu=ultrasparc
--enable-targets=all

[Bug c++/70613] -fabi-version docs don't match implementation

[wilson at gcc dot gnu.org]

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

--- Comment #1 from Jim Wilson  ---
I see that the patch for bug 65945 was back ported to the gcc-5 branch, which
required a partial backport of the patch for bug 44282, which added abi version
9.  The original patch for 44282 is missing the doc change.

The missing doc change was then added here
https://gcc.gnu.org/viewcvs/gcc?view=revision=228017
which has the invoke.texi hunk we need, but is missing a ChangeLog entry for
it.  So it appears all we need is a partial backport of this invoke.texi hunk. 
This is mostly documenting a change to -Wabi, so we only need parts of two
hunks that document -fabi-version=9 and mention gcc-5.2.

[Bug c/69197] Can't compile older

[prathamesh3492 at gcc dot gnu.org]

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

prathamesh3492 at gcc dot gnu.org changed:

   What|Removed |Added

 CC||prathamesh3492 at gcc dot 
gnu.org

--- Comment #7 from prathamesh3492 at gcc dot gnu.org ---
*** Bug 70629 has been marked as a duplicate of this bug. ***

[Bug lto/70629] 176.gcc fails to build with -O0 -flto with undefined reference to is_reserved_word

[prathamesh3492 at gcc dot gnu.org]

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

prathamesh3492 at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from prathamesh3492 at gcc dot gnu.org ---
oops this also failed to build with only -O0 (i tried -O0 -flto and -O2 -flto),
This was totally irrelevant to LTO. Sorry for the noise.

Thanks,
Prathamesh

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

[Bug lto/70629] 176.gcc fails to build with -O0 -flto with undefined reference to is_reserved_word

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #3 from prathamesh3492 at gcc dot gnu.org ---
Compiling with -std=gnu89 worked, thanks!

Regards,
Prathamesh

[Bug c++/70620] possible wrong code at -Os on x86_64-linux-gnu for C++ code with multiple inheritance and casting

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
FYI, the change in behavior is that ipa-devirt or what changes the destructor
call into __builtin_unreachable () and anything can happen then.

[Bug c++/70620] possible wrong code at -Os on x86_64-linux-gnu for C++ code with multiple inheritance and casting

[su at cs dot ucdavis.edu]

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

--- Comment #3 from Zhendong Su  ---
(In reply to Jonathan Wakely from comment #2)
> Your code is equivalent to:
> 
>   delete reinterpret_cast(static_cast(new E));
> 
> which means the conversion is not done safely, and you get a D* that doesn't
> point to the D subobject.
> 
> Compare:
> 
>   E* e = new E;
>   std::cout << (D*)e << '\n' << (B1*)e << '\n' << (D*)(B1*)e << '\n';
> 
> The expression (D*)(B1*)e is not the same as (D*)e, i.e. it does not produce
> the address of the D subobject.

Thanks Jonathan. That's what I had thought, but the change in behavior caused
me to wonder.

[Bug sanitizer/65479] sanitizer stack trace missing frames past #0 on powerpc64

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-11
 Ever confirmed|0   |1

--- Comment #16 from Bill Schmidt  ---
Unfortunately, that does not appear to be sufficient to solve any of the extant
ASAN failures.  I'm suspicious that fast unwinding is still being disabled
somewhere.  In any case, we need the backport; but we seem to need something
else as well.

Confirmed, in any case.

[Bug debug/70628] [5/6 regression] ICE in get_reg_rtx, at emit-rtl.c:1025

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
   Target Milestone|--- |5.4

--- Comment #5 from Andrew Pinski  ---
(In reply to Andreas Schwab from comment #2)
> a714a09ad18ee606064bbaac690ab1c8121dcc31 is the first bad commit
> commit a714a09ad18ee606064bbaac690ab1c8121dcc31
> Author: mkuvyrkov 
> Date:   Fri Oct 24 08:22:12 2014 +
> 
> git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@216620
> 138bc75d-0d04-0410-961f-82ee72b054a4

Since that is just a scheduler change, it exposes the latent bug.  Now the
problem is most likely related to Pmode != ptrmode (this is correct here but
the var-tracking code does not do the correct thing).

[Bug lto/70629] 176.gcc fails to build with -O0 -flto with undefined reference to is_reserved_word

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-04-11
 Ever confirmed|0   |1

[Bug lto/70629] 176.gcc fails to build with -O0 -flto with undefined reference to is_reserved_word

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69197#c4 also.

[Bug lto/70629] 176.gcc fails to build with -O0 -flto with undefined reference to is_reserved_word

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Are you compiling 176.gcc with -std=gnu89 also?

[Bug lto/70629] New: 176.gcc fails to build with -O0 -flto with undefined reference to is_reserved_word

[prathamesh3492 at gcc dot gnu.org]

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

Bug ID: 70629
   Summary: 176.gcc fails to build with -O0 -flto with undefined
reference to is_reserved_word
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prathamesh3492 at gcc dot gnu.org
  Target Milestone: ---

Hi,
176.gcc from SPEC2000 fails to build with trunk using -O0 -flto
for arm-linux-gnueabihf with many undefined references to is_reserved_word().
Also observed with system gcc-5.2.1 for x86_64.
However works with -O2/-O3 -flto
I am not sure if this qualifies to be a valid bug report.
Is -flto meant to work even for -O0 ?

Thanks,
Prathamesh

[Bug tree-optimization/68756] [6 Regression] ICE w/ -O1 -floop-nest-optimize and isl 0.15: isl-0.15/isl_id.c:213: unable to find id

[vries at gcc dot gnu.org]

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

--- Comment #8 from vries at gcc dot gnu.org ---
Created attachment 38240
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38240=edit
tentative patch for second snippet

[Bug tree-optimization/68756] [6 Regression] ICE w/ -O1 -floop-nest-optimize and isl 0.15: isl-0.15/isl_id.c:213: unable to find id

[vries at gcc dot gnu.org]

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

--- Comment #7 from vries at gcc dot gnu.org ---
(In reply to Arseny Solokha from comment #6)
> (In reply to vries from comment #5)
> > Failure no longer reproducible after r232812, "new scop schedule for
> > isl-0.15"
> 
> There are four snippets in this PR. All except the first one (snippet 1 from
> #c0) are still reproducible w/ gcc-6.0.0-alpha20160403.

Sorry for being sloppy in formulation.

So, the first snippet is no longer reproducible.

The second snippet still reproduces with the same symptom and backtrace.

The third and fourth longer reproduce as before, but look like duplicates of PR
69728 - '[6 Regression] internal compiler error: in outer_projection_mupa, at
graphite-sese-to-poly.c:1175'

[Bug sanitizer/70624] [6 Regression] Several hundred asan failures with 6.0 on x86_64-apple-darwin10.8

[howarth.at.gcc at gmail dot com]

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

Jack Howarth  changed:

   What|Removed |Added

 CC||howarth.at.gcc at gmail dot com

--- Comment #4 from Jack Howarth  ---
This issue goes back to http://reviews.llvm.org/D11719

[Bug debug/70628] [5/6 regression] ICE in get_reg_rtx, at emit-rtl.c:1025

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-11
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||5.3.1, 6.0

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Confirmed on 5.3 and trunk.
The reduced testcase for me is:
struct mntent
{
  char mnt_fsname;
  char mnt_opts;
} * a;

void gp_port_info_set_type ();

char *strstr ();

int *setmntent ();

struct mntent *getmntent ();

void
gp_port_library_list_mntent_1 (int p1)
{
  int *b = setmntent ();
  while (a = getmntent (b))
if (strstr ("") || strstr () || strstr ("fuse") || strstr ("nfs")
|| strstr ("autofs") || strstr ("devtmpfs") || strstr ("devpts")
|| strstr ("sysfs") || strstr ("gphotofs")
|| strstr (gp_port_library_list_mntent_1, "autofs")
|| strstr (gp_port_library_list_mntent_1, "nfs") || a->mnt_opts)
  if (strstr (>mnt_fsname))
gp_port_info_set_type (p1);
  getmntent (b);
  if (strstr ("") || strstr ("fuse") || strstr ("nfs") || strstr ("autofs")
  || strstr () || strstr ("devtmpfs") || strstr ("devpts")
  || strstr ("sysfs") || strstr ("gphotofs") || strstr (a, "autofs", ""))
gp_port_info_set_type ();
}

ICEs with -O2 -g -S -mabi=ilp32.

Funnily enough this reduced testcase ICEs on 4.9 as well but in a completely
different way in tree_ssa_dse.

[Bug tree-optimization/70545] [openacc] gfortran.dg/goacc/kernels-loop-n.f95 not parallelized

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-11
 CC||tschwinge at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug debug/70628] [5/6 regression] ICE in get_reg_rtx, at emit-rtl.c:1025

[sch...@linux-m68k.org]

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

--- Comment #3 from Andreas Schwab  ---
Created attachment 38239
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38239=edit
auto-host.h

[Bug debug/70628] [5/6 regression] ICE in get_reg_rtx, at emit-rtl.c:1025

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 CC||mkuvyrkov at gcc dot gnu.org

--- Comment #2 from Andreas Schwab  ---
a714a09ad18ee606064bbaac690ab1c8121dcc31 is the first bad commit
commit a714a09ad18ee606064bbaac690ab1c8121dcc31
Author: mkuvyrkov 
Date:   Fri Oct 24 08:22:12 2014 +

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

[Bug debug/70628] [5/6 regression] ICE in get_reg_rtx, at emit-rtl.c:1025

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Can't reproduce with a current trunk's cross, can you attach your auto-host.h ?

[Bug middle-end/70626] bogus results in 'acc parallel loop' reductions

[cesar at gcc dot gnu.org]

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

--- Comment #2 from cesar at gcc dot gnu.org ---
Created attachment 38238
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38238=edit
counter example

I looked at the standard again, and it says that the reduction clause should be
associated with the acc loop. That does make sense because if it were
duplicated, then as my counter example shows, the final reduction value would
be num_gangs times larger than it would be if there were only one reduction
clause.

I'll see what the acc technical committee says about this.

[Bug testsuite/70150] Additonal test failures with --enable-default-pie

[psturm at computervoice dot com]

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

--- Comment #13 from psturm at computervoice dot com ---
(In reply to H.J. Lu from comment #12)
> Patches are posted at
> 
> https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00929.html
> https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00995.html

https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00929.html patch does not apply
because it appears it conflicts with another change made for HPPA:

In weekly snapshot 6-20160410: gcc/testsuite/gcc.dg/uninit-19.c

/* { dg-warning "may be used uninitialized" "" { target { { nonpic } || {
hppa*64*-*-* } } } 13 } */
/* { dg-warning "may be used uninitialized" "" { target { ! { { nonpic } || {
hppa*64*-*-* } } } } 22 } */

patch is looking for:
-/* { dg-warning "may be used uninitialized" "" { target nonpic } 13 } */
-/* { dg-warning "may be used uninitialized" "" { target { ! nonpic } } 22 } */

[Bug c++/70620] possible wrong code at -Os on x86_64-linux-gnu for C++ code with multiple inheritance and casting

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Your code is equivalent to:

  delete reinterpret_cast(static_cast(new E));

which means the conversion is not done safely, and you get a D* that doesn't
point to the D subobject.

Compare:

  E* e = new E;
  std::cout << (D*)e << '\n' << (B1*)e << '\n' << (D*)(B1*)e << '\n';

The expression (D*)(B1*)e is not the same as (D*)e, i.e. it does not produce
the address of the D subobject.

[Bug debug/70628] New: [5/6 regression] ICE in get_reg_rtx, at emit-rtl.c:1025

[sch...@linux-m68k.org]

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

Bug ID: 70628
   Summary: [5/6 regression] ICE in get_reg_rtx, at
emit-rtl.c:1025
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
  Target Milestone: ---
Target: aarch64-*-*

Created attachment 38237
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38237=edit
Preprocessed source

$ gcc/xgcc -B gcc/ -O2 -g -S -mabi=ilp32 disk.i
disk/disk.c: In function ‘gp_port_library_list’:
disk/disk.c:305:1: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1025
0x7f30d3 gen_reg_rtx(machine_mode)
../../gcc/emit-rtl.c:1025
0x8297b3 convert_modes(machine_mode, machine_mode, rtx_def*, int)
../../gcc/expr.c:723
0x777a5b cselib_expand_value_rtx_1
../../gcc/cselib.c:1832
0x779acb cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc/cselib.c:1540
0xdfa043 vt_expand_var_loc_chain
../../gcc/var-tracking.c:8329
0xdfa043 vt_expand_loc_callback
../../gcc/var-tracking.c:8492
0x77790b cselib_expand_value_rtx_1
../../gcc/cselib.c:1693
0x779acb cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc/cselib.c:1540
0xdf9cbf vt_expand_loc_callback
../../gcc/var-tracking.c:8426
0x47 cselib_expand_value_rtx_1
../../gcc/cselib.c:1658
0x779acb cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc/cselib.c:1540
0xdfa043 vt_expand_var_loc_chain
../../gcc/var-tracking.c:8329
0xdfa043 vt_expand_loc_callback
../../gcc/var-tracking.c:8492
0x77790b cselib_expand_value_rtx_1
../../gcc/cselib.c:1693
0x777973 cselib_expand_value_rtx_1
../../gcc/cselib.c:1731
0x779acb cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc/cselib.c:1540
0xdfa043 vt_expand_var_loc_chain
../../gcc/var-tracking.c:8329
0xdfa043 vt_expand_loc_callback
../../gcc/var-tracking.c:8492
0x77790b cselib_expand_value_rtx_1
../../gcc/cselib.c:1693
0x779acb cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc/cselib.c:1540

Needs -O >= 2, -g >= 2 and -mabi=ilp32.

[Bug lto/65950] Loop is not vectorized with lto.

[gcp at sjeng dot org]

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

Gian-Carlo Pascutto  changed:

   What|Removed |Added

 CC||gcp at sjeng dot org

--- Comment #6 from Gian-Carlo Pascutto  ---
I'm seeing similar behavior in gcc-4.9.2 (debian stable) and gcc-5.3.1 (Ubuntu
16.04 prelease).

Adding -flto causes certain loops not to get vectorized, adding -fno-lto to
affected files fixes it.

Unfortunately producing a reduced testcase is not so easy, but program source
is available to gcc devs on request.

[Bug c++/70627] [6 Regression] internal compiler error: verify_type failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-11
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|internal compiler error:|[6 Regression] internal
   |verify_type failed  |compiler error: verify_type
   ||failed
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
Started with r222991.  Maybe related to PR70029.

[Bug middle-end/70626] bogus results in 'acc parallel loop' reductions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Guess it depends on what the standard says about that.

[Bug c++/70627] [6 Regression] internal compiler error: verify_type failed

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Reducing now (at 4.5MB right now).

[Bug target/69841] Wrong template instantiation in C++11 on armv7l

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
(In reply to James Greenhalgh from comment #5)
> I don't know enough about the C++ standard to know whether this patch is
> reasonable to backport to GCC 5. Jason, do you have an opinion?

I'd be pretty nervous about packporting that patch, as changes to that behavior
tend to have unexpected side-effects.  And it seems likely to have just made
this bug latent, rather than actually fixed it.

[Bug sanitizer/65479] sanitizer stack trace missing frames past #0 on powerpc64

[wschmidt at gcc dot gnu.org]

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

--- Comment #15 from Bill Schmidt  ---
Yes, it seems likely that this is due to this patch being missing from GCC 5.3:

http://reviews.llvm.org/D11552

The fix is present in trunk, so this should be fixed with a backport.

[Bug c++/70627] internal compiler error: verify_type failed

[jseward at acm dot org]

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

--- Comment #2 from jseward at acm dot org ---
Created attachment 38236
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38236=edit
Unified_cpp_dom_animation0.ii.bz2

Testcase .ii.bz2, compressed so as to get it under the 1MB limit :-(

[Bug c++/70627] internal compiler error: verify_type failed

[jseward at acm dot org]

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

--- Comment #1 from jseward at acm dot org ---
sewardj@dundee[6X]:~/MOZ$ c++ -c Unified_cpp_dom_animation0.ii -Wall
-Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual
-Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings
-Wc++14-compat -Wno-invalid-offsetof -Wno-error=maybe-uninitialized
-Wno-error=deprecated-declarations -Wno-error=array-bounds -fno-exceptions
-fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++11
-pthread -pipe -g -g -Og -fno-omit-frame-pointer -Wshadow
In file included from
/home/sewardj/MOZ/MC-MOCHI/ff-Og-linux64/dom/animation/Unified_cpp_dom_animation0.cpp:137:0:
/home/sewardj/MOZ/MC-MOCHI/dom/animation/PendingAnimationTracker.cpp: In
function ‘T&& mozilla::Forward(typename mozilla::RemoveReference::Type&)
[with T = const mozilla::CSSPseudoElementType&]’:
/home/sewardj/MOZ/MC-MOCHI/dom/animation/PendingAnimationTracker.cpp:124:1:
error: type variant has different TREE_TYPE
 } // namespace mozilla
 ^
 
unit size 
align 8 symtab 1270682720 alias set -1 canonical type 0x7fb94bd98540
precision 8 min  max 
pointer_to_this  reference_to_this
>
sizes-gimplified asm_written static unsigned type_5 type_6 QI size
 unit size 
align 8 symtab 1173426976 alias set -1 canonical type 0x7fb946878498
precision 8 min  max 
values 
local bindings <(nil)>>
value 
readonly constant used VOID file
/home/sewardj/MOZ/MC-MOCHI/layout/style/nsCSSPseudoElementList.h line 28 col 1
align 1 context 
initial >
chain 
local bindings <(nil)>> value 
chain 
local bindings <(nil)>> value 
chain 
local bindings <(nil)>> value 
chain 
local bindings <(nil)>> value 
chain  value  chain >> context 
pointer_to_this  reference_to_this
 chain >
/home/sewardj/MOZ/MC-MOCHI/dom/animation/PendingAnimationTracker.cpp:124:1:
error: type variant's TREE_TYPE
  constant 8>
unit size  constant 1>
align 8 symtab 1270682720 alias set -1 canonical type 0x7fb94bd98540
precision 8 min  max 
pointer_to_this  reference_to_this
>
/home/sewardj/MOZ/MC-MOCHI/dom/animation/PendingAnimationTracker.cpp:124:1:
error: type's TREE_TYPE
  constant 8>
unit size  constant 1>
align 8 symtab 1173427056 alias set -1 canonical type 0x7fb94bd98540
precision 8 min  max >
 
unit size 
align 8 symtab 1173427056 alias set -1 canonical type 0x7fb94bd98540
precision 8 min  max >
readonly sizes-gimplified static unsigned type_5 type_6 QI size
 unit size 
align 8 symtab 921920128 alias set -1 canonical type 0x7fb945f193f0
precision 8 min  max 
values 
local bindings <(nil)>>
value 
readonly constant used VOID file
/home/sewardj/MOZ/MC-MOCHI/layout/style/nsCSSPseudoElementList.h line 28 col 1
align 1 context 
initial >
chain 
local bindings <(nil)>> value 
chain 
local bindings <(nil)>> value 
chain 
local bindings <(nil)>> value 
chain 
local bindings <(nil)>> value 
chain  value  chain >> context 
pointer_to_this  reference_to_this
>
/home/sewardj/MOZ/MC-MOCHI/dom/animation/PendingAnimationTracker.cpp:124:1:
internal compiler error: verify_type failed
0xf9f9e2 verify_type(tree_node const*)
../../gcc-6-20160410/gcc/tree.c:13908
0x9a1dd4 gen_type_die_with_usage
../../gcc-6-20160410/gcc/dwarf2out.c:22703
0x9a2439 gen_type_die_with_usage
../../gcc-6-20160410/gcc/dwarf2out.c:22805
0x9a31b6 gen_type_die
../../gcc-6-20160410/gcc/dwarf2out.c:22901
0x99b17f gen_decl_die
../../gcc-6-20160410/gcc/dwarf2out.c:23454
0x99b90e dwarf2out_decl
../../gcc-6-20160410/gcc/dwarf2out.c:23953
0x9b3078 dwarf2out_early_global_decl
../../gcc-6-20160410/gcc/dwarf2out.c:23626
0x9295ab symbol_table::finalize_compilation_unit()
../../gcc-6-20160410/gcc/cgraphunit.c:2556
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
sewardj@dundee[6X]:~/MOZ$ gcc --version
gcc (GCC) 6.0.0 20160410 (experimental)
Copyright (C) 2016 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.

[Bug libstdc++/70609] std::experimental::filesystem::copy fails if the file size is 0 bytes

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
The problem is due to my lazy approach to copying the file:

  __gnu_cxx::stdio_filebuf sbin(in.fd, std::ios::in);
  __gnu_cxx::stdio_filebuf sbout(out.fd, std::ios::out);
  if ( !(std::ostream() << ) )
{
  ec = std::make_error_code(std::errc::io_error);
  return false;
}

The condition is false when no bytes are copied. We just want to make that code
conditional with:

if (from_st->st_size)

That function should also check the result of ::close(fd), on at least the
target file.

[Bug middle-end/70626] New: bogus results in 'acc parallel loop' reductions

[cesar at gcc dot gnu.org]

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

Bug ID: 70626
   Summary: bogus results in 'acc parallel loop' reductions
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: cesar at gcc dot gnu.org
  Reporter: cesar at gcc dot gnu.org
CC: tschwinge at gcc dot gnu.org
  Target Milestone: ---

Created attachment 38233
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38233=edit
test case

Currently, given a combined acc parallel loop of the form

  #pragma acc parallel loop reduction(+:var)

all of the front ends will split that loop as

  #pragma acc parallel
  #pragma acc loop reduction(+:var)

This is bad because the gimplifier will not assign an implicit present_or_copy
clause for the reduction variable 'var', instead 'var' gets transferred via
firstprivate. One solution here is to teach the front ends to attach the
reduction clause to both directives, instead of just the split acc loop.

[Bug c++/70627] New: internal compiler error: verify_type failed

[jseward at acm dot org]

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

Bug ID: 70627
   Summary: internal compiler error: verify_type failed
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jseward at acm dot org
  Target Milestone: ---

This is with gcc (GCC) 6.0.0 20160410 (experimental) building part of Firefox
on x86_64-linux, on Fedora 21.

[Bug target/70117] ppc long double isinf() is wrong?

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

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

--- Comment #20 from Alan Modra  ---
Fixed

[Bug rtl-optimization/70625] [4.9/5 Regression] Memory exhaustion when building specific snippet at -O2

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
(In reply to Arseny Solokha from comment #2)
> (In reply to ktkachov from comment #1)
> > I see the PR70623 ICE with 4.9 and 5 at -O2 on arm-none-eabi.
> > Do you have any other relevant gcc configure options that trigger this?
> 
> Talking about this particular PR, I can't even reproduce it w/ all the
> targets I have: it works well w/o ICE for powerpc-e300c3-linux-gnu, for
> example.
> 
> As of PR70623, for me it started triggering ICE somewhere between
> 6.0.0-alpha20160110 and 6.0.0-alpha20160403 for both
> powerpc-e500v2-linus-gnuspe and x86_64-pc-linux-gnu. I failed to reproduce
> it w/ 4.9.3 and 5.3.0 configured for all four targets mentioned by me here.
> Given your comment, I'll certainly try it in the days ahead w/ the flavor of
> arm-none-eabi that I have.
> 
> In case I've got you wrong, what configure options do you want me to make
> specific?

I tried compiling it for an arm-none-eabi target and I get the ICE rather than
seeing the memory-hog behaviour.
By configure options I mean the output of gcc -v.
For arm targets, the --with-arch,--with-cpu,--with-fpu,--with-float-abi
configure switches can result in different compiler paths being taken, which
may expose or hide the bug.

[Bug rtl-optimization/70625] [4.9/5 Regression] Memory exhaustion when building specific snippet at -O2

[asolokha at gmx dot com]

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

--- Comment #2 from Arseny Solokha  ---
(In reply to ktkachov from comment #1)
> I see the PR70623 ICE with 4.9 and 5 at -O2 on arm-none-eabi.
> Do you have any other relevant gcc configure options that trigger this?

Talking about this particular PR, I can't even reproduce it w/ all the targets
I have: it works well w/o ICE for powerpc-e300c3-linux-gnu, for example.

As of PR70623, for me it started triggering ICE somewhere between
6.0.0-alpha20160110 and 6.0.0-alpha20160403 for both
powerpc-e500v2-linus-gnuspe and x86_64-pc-linux-gnu. I failed to reproduce it
w/ 4.9.3 and 5.3.0 configured for all four targets mentioned by me here. Given
your comment, I'll certainly try it in the days ahead w/ the flavor of
arm-none-eabi that I have.

In case I've got you wrong, what configure options do you want me to make
specific?

[Bug target/70117] ppc long double isinf() is wrong?

[amodra at gcc dot gnu.org]

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

--- Comment #19 from Alan Modra  ---
Author: amodra
Date: Mon Apr 11 13:47:40 2016
New Revision: 234881

URL: https://gcc.gnu.org/viewcvs?rev=234881=gcc=rev
Log:
PR70117, ppc long double isinf

gcc/
PR target/70117
* builtins.c (fold_builtin_classify): For IBM extended precision,
look at just the high-order double to test for NaN.
(fold_builtin_interclass_mathfn): Similarly for Inf.  For isnormal
test just the high double for Inf but both doubles for subnormal
limit.
gcc/testsuite/
* gcc.target/powerpc/pr70117.c: New.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/powerpc/pr70117.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/builtins.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug target/70117] ppc long double isinf() is wrong?

[amodra at gcc dot gnu.org]

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

--- Comment #18 from Alan Modra  ---
Author: amodra
Date: Mon Apr 11 13:46:51 2016
New Revision: 234880

URL: https://gcc.gnu.org/viewcvs?rev=234880=gcc=rev
Log:
PR70117, ppc long double isinf

gcc/
PR target/70117
* builtins.c (fold_builtin_classify): For IBM extended precision,
look at just the high-order double to test for NaN.
(fold_builtin_interclass_mathfn): Similarly for Inf.  For isnormal
test just the high double for Inf but both doubles for subnormal
limit.
gcc/testsuite/
* gcc.target/powerpc/pr70117.c: New.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/pr70117.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/builtins.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[rogero at howzatt dot demon.co.uk]

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

--- Comment #57 from Roger Orr  ---
Created attachment 38232
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38232=edit
Stripped down intermediate file

I've managed to reproduce the problem without including any proprietary code -
code replaced with blank lines between the "#" lines (and a slight change in
the number of includes) now provokes the diagnostic.

/var/tmp/gcc-trunk-234481/install/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/cc1plus
-fpreprocessed pr69650.ii -quiet -dumpbase pr69650.ii -mtune=generic
-march=x86-64 -auxbase-strip /var/tmp/pr69650.o -O3 -Werror -std=c++14 -o
/tmp/ccNlrUZ8.s

In file included from
/opt/reactor-buildkit/B2BH-BK2GIT44-1/poco/include/Poco/Net/IPAddress.h:346:0,
 from
/home/rorr/linuxdev109ws_9119/rorr_linuxdev109ws_9119/Reactor5/project/prj-lcc-device-longer-name/reactor/src/base/messaging/messaging/rsHintServerBase.hxx:19,
 from
/home/rorr/linuxdev109ws_9119/rorr_linuxdev109ws_9119/Reactor5/project/prj-lcc-device-longer-name/reactor/src/base/messaging/src/rsMessaging.cxx:16:
/home/rorr/linuxdev109ws_9119/rorr_linuxdev109ws_9119/Reactor5/project/prj-lcc-device-longer-name/reactor/src/base/hxx/rsEnumMnemonic.hxx:10:165:
error: file
"/home/rorr/linuxdev109ws_9119/rorr_linuxdev109ws_9119/Reactor5/project/prj-lcc-device-longer-name/reactor/src/base/messaging/messaging/rsHintServerBase.hxx"
linemarker ignored due to incorrect nesting [-Werror]
/home/rorr/linuxdev109ws_9119/rorr_linuxdev109ws_9119/Reactor5/project/prj-lcc-device-longer-name/reactor/src/base/hxx/rsEnumMnemonic.hxx:12:154:
error: file
"/home/rorr/linuxdev109ws_9119/rorr_linuxdev109ws_9119/Reactor5/project/prj-lcc-device-longer-name/reactor/src/base/messaging/src/rsMessaging.cxx"
linemarker ignored due to incorrect nesting [-Werror]
cc1plus: all warnings being treated as errors

(234480 compiles cleanly)

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #56 from Bernd Schmidt  ---
Ok, thanks for the effort in identifying the problem. I should reopen this so
it gets tracked as a regression. I'll put your patch through a test cycle.

[Bug rtl-optimization/70398] [6 Regression] gcc.dg/vect/slp-multitypes-9.c FAILs with -fno-tree-loop-optimize -fno-tree-ter

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/70614] [4.9/5/6 Regression] GCC gets stuck with -O

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||spop at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Even on the following testcase at -O2 we end up with over 200
analyze_scalar_evolution calls (while that finishes within a second and half,
it still looks very much excessive to me).  Perhaps we should have similar
param like we have for max-ssa-name-query-depth (certainly not as tight) and
simply give up if we recurse more than that during computation of SCEV?

struct S
{
  int *s;
};
int a, b, c, d, e, f, *g, *h;
void
foo (struct S *t)
{
  int *i;
lab1:
  switch (0)
{
case 0:
  switch (0)
{
case 0:
case 1:
  if (((struct S *) t)->s)
goto lab4;
}
}
  f = 0;
lab2:
  if (i)
goto lab3;
  if (h)
g = 0;
  goto lab4;
lab3:
  if ((int) i)
{
  i = i;
  goto lab2;
}
lab4:
lab5:
  switch (a)
{
case 1:
  if (0)
goto lab8;
  switch (1)
{
case 1:
  if ((int) ((struct S *) t)->s)
switch (0)
  {
  case 0:
switch (e)
  {
  case 0:
switch (c)
  {
  case 0:
if (((struct S *) t)->s)
lab6:
  switch (d)
{
case 0:
  if ((int) ((struct S *) t)->s & 1)
goto lab8;
lab7:
  if (i)
i = 0;
}
  }
  }
  }
case 0:
  goto lab8;
}
case 0:
  if (a)
goto lab5;
}
lab8:
lab9:
  if (a)
goto lab9;
  switch ((int) g)
{
case 0:
  switch (b)
{
case 0:
  if (((struct S *) t)->s)
switch (e)
  {
  case 0:
if ((int) ((struct S *) t)->s)
  i = 1;
  }
}
}
lab10:
  if (h)
goto lab10;
  switch ((int) i)
{
case 0:
  goto lab1;
}
}

[Bug libstdc++/70609] std::experimental::filesystem::copy fails if the file size is 0 bytes

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-04-11
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug libstdc++/70607] The return type of std::conj must be std::complex

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Target|GNU/Linux x86_64|
   Host|GNU/Linux x86_64|

--- Comment #4 from Jonathan Wakely  ---
Not target-specific.

[Bug libstdc++/70607] The return type of std::conj must be std::complex

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
I think Marc's point is that GCC is doing what DR 1137 says ... but it looks as
though the DR resolution never made it into C++11.

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[rogero at howzatt dot demon.co.uk]

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

--- Comment #55 from Roger Orr  ---
Note - I should have added that I am not at all sure the fix above is
*correct*, simply that it prevents accessing the freed entry.

I don't know enough about how the code works to know whether the value obtained
by re-loading via:

maps = LINEMAPS_LAST_ORDINARY_MAP (pfile->line_table);

is reading the the value that _actually_ needs to be verified in the subsequent
code: the logical entry referred to by "LINEMAPS_LAST_ORDINARY_MAP" might have
changed from the one obtained at the start of the function.

[Bug target/70133] AArch64 -mtune=native generates improperly formatted -march parameters

[davidwillmore at gmail dot com]

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

--- Comment #13 from davidwillmore at gmail dot com ---
Thank you very much!

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[rogero at howzatt dot demon.co.uk]

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

--- Comment #54 from Roger Orr  ---
Unfortunately the patch does not help: the cached 'from' pointer is a pointer
into the old maps entry -- the one which has now been deallocated.

The first test, main_file_p, now (correctly) fails.

The second test, 

(new_file
 && from != NULL
 && filename_cmp (ORDINARY_MAP_FILE_NAME (from), new_file) != 0)

now SEGVs as the memory area 'from' refers has been freed, so
ORDINARY_MAP_FILE_NAME returns a pointer value read from this freed memory,
which now contains 0x5a.

The call stack of the re-allocation is:

#0  __memset_x86_64 () at ../sysdeps/x86_64/memset.S:1229
#1  0x00b1d595 in ggc_free (p=0x718b2000) at
../../gcc/ggc-page.c:1611
#2  0x00d5019d in ggc_realloc (x=0x718b2000, size=524288) at
../../gcc/ggc-common.c:162
#3  0x010ce764 in realloc_for_line_map (ptr=0x718b2000, len=524288)
at ../../gcc/toplev.c:939
#4  0x01b223aa in new_linemap (set=0x77ffc000, reason=LC_RENAME) at
../../libcpp/line-map.c:427
#5  0x01b2264b in linemap_add (set=0x77ffc000, reason=LC_RENAME,
sysp=2,
to_file=0x2c9ba00
"/opt/reactor-buildkit/B2BH-BK2GIT44-1/poco/include/Poco/Net/IPAddress.h",
to_line=344) at ../../libcpp/line-map.c:500
#6  0x01b22d2d in linemap_line_start (set=0x77ffc000, to_line=344,
max_column_hint=256) at ../../libcpp/line-map.c:748
#7  0x01b22f1a in linemap_position_for_column (set=0x77ffc000,
to_column=162) at ../../libcpp/line-map.c:809
#8  0x01b2066f in _cpp_lex_direct (pfile=0x2b20310) at
../../libcpp/lex.c:2730
#9  0x01b1f0f2 in _cpp_lex_token (pfile=0x2b20310) at
../../libcpp/lex.c:2202
#10 0x01b29956 in cpp_get_token_1 (pfile=0x2b20310, location=0x0) at
../../libcpp/macro.c:2439
#11 0x01b29d9b in cpp_get_token (pfile=0x2b20310) at
../../libcpp/macro.c:2581
#12 0x01b0cec6 in do_linemarker (pfile=0x2b20310) at
../../libcpp/directives.c:1009
#13 0x01b0bf65 in _cpp_handle_directive (pfile=0x2b20310, indented=0)
at ../../libcpp/directives.c:510
#14 0x01b1f142 in _cpp_lex_token (pfile=0x2b20310) at
../../libcpp/lex.c:2214
#15 0x01b29956 in cpp_get_token_1 (pfile=0x2b20310,
location=0x7fffd144) at ../../libcpp/macro.c:2439
#16 0x01b29dc0 in cpp_get_token_with_location (pfile=0x2b20310,
loc=0x7fffd144) at ../../libcpp/macro.c:2625
#17 0x00ae8d90 in c_lex_with_flags (value=0x7fffd148,
loc=0x7fffd144, cpp_flags=0x7fffd142 "@▒▒S▒\034", lex_flags=2)
at ../../gcc/c-family/c-lex.c:391
#18 0x0099 in cp_lexer_get_preprocessor_token
(lexer=0x71f2b480, token=0x7fffd140) at ../../gcc/cp/parser.c:792
#19 0x008ffcb4 in cp_lexer_new_main () at ../../gcc/cp/parser.c:656
#20 0x0090349b in cp_parser_new () at ../../gcc/cp/parser.c:3689
#21 0x00952055 in c_parse_file () at ../../gcc/cp/parser.c:37405
#22 0x00af45f8 in c_common_parse_file () at
../../gcc/c-family/c-opts.c:1064
#23 0x010cdb41 in compile_file () at ../../gcc/toplev.c:465
#24 0x010d00e9 in do_compile () at ../../gcc/toplev.c:1988
#25 0x010d036e in toplev::main (this=0x7fffd260, argc=16,
argv=0x7fffd368) at ../../gcc/toplev.c:2096
#26 0x01ae22ce in main (argc=16, argv=0x7fffd368) at
../../gcc/main.c:39

and the arguments to memset() are:
void *s = 0x718b2000
int c = 0xa5a
size_t n = 131782

In frame 12, from = 0x718d0c20, which is within this range and so the
contents are set to 0x5a.

I've tried out this patch, re-reading the potentially changed maps value from
pfile->line_table, and it seems to work for me:

*** ../../gcc-trunk-234481-original/libcpp/directives.c 2016-04-07
12:46:40.0 +0100
--- directives.c2016-04-11 11:54:18.0 +0100
*** do_linemarker (cpp_reader *pfile)
*** 1048,1053 
--- 1048,1056 

if (reason == LC_LEAVE)
  {
+   // reload map in case re-allocation has occurred
+   const line_map_ordinary *map = LINEMAPS_LAST_ORDINARY_MAP
(pfile->line_table);
+
const line_map_ordinary *from;
if (MAIN_FILE_P (map)
  || (new_file

[Bug rtl-optimization/70625] [4.9/5 Regression] Memory exhaustion when building specific snippet at -O2

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
I see the PR70623 ICE with 4.9 and 5 at -O2 on arm-none-eabi.
Do you have any other relevant gcc configure options that trigger this?

[Bug rtl-optimization/70625] New: [4.9/5 Regression] Memory exhaustion when building specific snippet at -O2

[asolokha at gmx dot com]

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

Bug ID: 70625
   Summary: [4.9/5 Regression] Memory exhaustion when building
specific snippet at -O2
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Keywords: memory-hog
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: armv7a-hardfloat-linux-gnueabihf, x86_64-pc-linux-gnu

armv7a-hardfloat-linux-gnueabihf-4.9.3 and x86_64-pc-linux-gnu-5.3.0 exhaust
all available memory when compiling the following snippet at -O2:

int b8, il, rc, nm;

void
h9(void)
{
  int *av = 

 is:
  for (;;) {
int vj, wk;
int *m9 = 

if (*m9 == *av) {
  if (il == 0)
goto is;

di:
  continue;
  for (vj = 0; vj < 1; ++vj) {
goto di;
  kz:
;
  }
}

for (rc = 0; rc < 2; ++rc) {
  int bc = rc ? rc : nm;
  int ud = bc ? (*av ? 0 : rc) : 1;

  if (ud != 0)
if (*av != 0)
  goto kz;
}

for (wk = 0; wk < 3; ++wk)
  ++(*av);
av = 0;
  }
}

Mostly vec- and bitmap-related calls show up in perf top:

   1.93%  cc1 [.] bitmap_bit_p
   1.41%  cc1 [.] pool_alloc
   1.36%  cc1 [.] bitmap_set_bit
   1.18%  cc1 [.] bitmap_and_compl
   1.15%  cc1 [.] VN_INFO
   1.05%  cc1 [.] bitmap_clear
   0.78%  cc1 [.] bitmap_copy
   0.72%  cc1 [.] vec::iterate
   0.67%  cc1 [.] vec::operator[]
   0.67%  cc1 [.] vec_safe_length
   0.67%  cc1 [.] vec::operator[]
   0.65%  cc1 [.] vec::quick_push
   0.64%  cc1 [.] vec::length
   0.59%  cc1 [.] bitmap_equal_p
   0.49%  cc1 [.] vec::operator[]
   0.49%  cc1 [.] bitmap_count_bits
   0.47%  cc1 [.] vec::reserve
   0.47%  cc1 [.] vec::iterate
   0.47%  cc1 [.] vec::operator[]
   0.46%  cc1 [.] iterative_hash_host_wide_int
   0.44%  cc1 [.] value_id_constant_p
   0.42%  cc1 [.] va_heap::reserve
   0.40%  cc1 [.] vec::space
   0.39%  cc1 [.] vec::space
   0.37%  cc1 [.] vec::embedded_init
   0.37%  cc1 [.] bitmap_and_into
   0.33%  cc1 [.] vec::operator[]
   0.31%  cc1 [.] vec::operator[]
   0.30%  cc1 [.] bitmap_empty_p
   0.28%  cc1 [.] vec::safe_push
   0.23%  cc1 [.] va_heap::release
   0.23%  cc1 [.] bitmap_clear_bit
   0.22%  cc1 [.] vec::operator[]
   0.21%  cc1 [.] xrealloc
   0.20%  cc1 [.] vec::release
   0.18%  cc1 [.] vec_prefix::calculate_allocation
   0.18%  cc1 [.] vec::iterate
   0.17%  cc1 [.] vec::quick_push

This snippet was reduced from the same source as the one from PR70623.

[Bug c++/70621] [6 Regression] ICE on invalid code at -O1 and above on x86_64-linux-gnu in record_reference, at cgraphbuild.c:64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
It is unfortunate that due to the Cilk+ bug it is hard to bisect this properly.
Anyway, looking at what 5.x does I see a major difference of r229018, we used
to modify the initializer (apparently in-place), but we no longer do and the
PTRMEM_CST remains in the IL until the ME.

[Bug c++/70615] [6 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu in add_expr, at tree.c:7870

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
This is another case of PTRMEM_CST leaking from the FE to the gimplifier (the
other is PR70621, but in this case it is not even during error-recovery).

[Bug target/69841] Wrong template instantiation in C++11 on armv7l

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 CC||jason at redhat dot com

--- Comment #6 from James Greenhalgh  ---
*ping*

[Bug target/70133] AArch64 -mtune=native generates improperly formatted -march parameters

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

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

--- Comment #12 from James Greenhalgh  ---
Fixed on trunk with r234875 r234876 and r234877 . You'll need to contact Linaro
through their support/bug channels if you think these fixes should be ported to
the Linaro releases.

[Bug target/70133] AArch64 -mtune=native generates improperly formatted -march parameters

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #11 from James Greenhalgh  ---
Author: jgreenhalgh
Date: Mon Apr 11 10:16:26 2016
New Revision: 234877

URL: https://gcc.gnu.org/viewcvs?rev=234877=gcc=rev
Log:
[Patch AArch64 3/3] Fix up for pr70133

gcc/

PR target/70133
* config/aarch64/driver-aarch64.c
(aarch64_get_extension_string_for_isa_flags): New.
(arch_extension): Rename to...
(aarch64_arch_extension): ...This.
(ext_to_feat_string): Rename to...
(aarch64_extensions): ...This.
(aarch64_core_data): Keep track of architecture extension flags.
(cpu_data): Rename to...
(aarch64_cpu_data): ...This.
(aarch64_arch_driver_info): Keep track of architecture extension
flags.
(get_arch_name_from_id): Rename to...
(get_arch_from_id): ...This, change return type.
(host_detect_local_cpu): Update and reformat for renames, handle
extensions through common infrastructure.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/driver-aarch64.c

[Bug target/70133] AArch64 -mtune=native generates improperly formatted -march parameters

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #10 from James Greenhalgh  ---
Author: jgreenhalgh
Date: Mon Apr 11 10:14:59 2016
New Revision: 234876

URL: https://gcc.gnu.org/viewcvs?rev=234876=gcc=rev
Log:
[Patch AArch64 2/3] Rework the code to print extension strings (pr70133)

gcc/

PR target/70133
* config/aarch64/aarch64-common.c (aarch64_option_extension): Keep
track of a canonical flag name.
(all_extensions): Likewise.
(arch_to_arch_name): Also track extension flags enabled by the arch.
(all_architectures): Likewise.
(aarch64_parse_extension): Move to here.
(aarch64_get_extension_string_for_isa_flags): Take a new argument,
rework.
(aarch64_rewrite_selected_cpu): Update for above change.
* config/aarch64/aarch64-option-extensions.def: Rework the way flags
are handled, such that the single explicit value enabled by an
extension is kept seperate from the implicit values it also enables.
* config/aarch64/aarch64-protos.h (aarch64_parse_opt_result): Move
to here.
(aarch64_parse_extension): New.
* config/aarch64/aarch64.c (aarch64_parse_opt_result): Move from
here to config/aarch64/aarch64-protos.h.
(aarch64_parse_extension): Move from here to
common/config/aarch64/aarch64-common.c.
(aarch64_option_print): Update.
(aarch64_declare_function_name): Likewise.
(aarch64_start_file): Likewise.
* config/aarch64/driver-aarch64.c (arch_extension): Keep track of
the canonical flag for extensions.
* config.gcc (aarch64*-*-*): Extend regex for capturing extension
flags.

gcc/testsuite/

PR target/70133
* gcc.target/aarch64/mgeneral-regs_4.c: Fix expected output.
* gcc.target/aarch64/target_attr_15.c: Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/common/config/aarch64/aarch64-common.c
trunk/gcc/config.gcc
trunk/gcc/config/aarch64/aarch64-option-extensions.def
trunk/gcc/config/aarch64/aarch64-protos.h
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/config/aarch64/driver-aarch64.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/aarch64/mgeneral-regs_4.c
trunk/gcc/testsuite/gcc.target/aarch64/target_attr_15.c

[Bug sanitizer/70624] [6 Regression] Several hundred asan failures with 6.0 on x86_64-apple-darwin10.8

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-11
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
> Darwin 10.8 seems to be quite an old system (June 23, 2011),

Indeed.

> perhaps it's dynamic linker (dyld) just haven't dyldVersionNumber symbol?

It's my understanding.

> Anyway, this is a library issue and perhaps it should go to sanitizer bugzilla
> (https://github.com/google/sanitizers/issues).

Done, #669.

[Bug sanitizer/70624] [6 Regression] Several hundred asan failures with 6.0 on x86_64-apple-darwin10.8

[m.ostapenko at samsung dot com]

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

Maxim Ostapenko  changed:

   What|Removed |Added

 CC||m.ostapenko at samsung dot com

--- Comment #2 from Maxim Ostapenko  ---
Darwin 10.8 seems to be quite an old system (June 23, 2011), perhaps it's
dynamic linker (dyld) just haven't dyldVersionNumber symbol? Anyway, this is a
library issue and perhaps it should go to sanitizer bugzilla
(https://github.com/google/sanitizers/issues).

[Bug sanitizer/70624] [6 Regression] Several hundred asan failures with 6.0 on x86_64-apple-darwin10.8

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
That is not very recent change.  Has Darwin itself changed incompatibly?

[Bug c++/70610] [6 regression] error: invalid initialization of non-const reference of type

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
#c3 changed behavior (started to be rejected) with r181174.

[Bug tree-optimization/70614] [4.9/5/6 Regression] GCC gets stuck with -O

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |4.9.4
Summary|GCC gets stuck with -O  |[4.9/5/6 Regression] GCC
   ||gets stuck with -O

--- Comment #2 from Jakub Jelinek  ---
Most likely started with r191232 (r191230 works, r191243 already spends lots of
time in SCEV).

[Bug sanitizer/70624] New: [6 Regression] Several hundred asan failures with 6.0 on x86_64-apple-darwin10.8

[dominiq at lps dot ens.fr]

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

Bug ID: 70624
   Summary: [6 Regression] Several hundred asan failures with 6.0
on x86_64-apple-darwin10.8
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: chefmax at gcc dot gnu.org, dodji at gcc dot gnu.org,
dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org,
kcc at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin10.8
Target: x86_64-apple-darwin10.8
 Build: x86_64-apple-darwin10.8

On x86_64-apple-darwin10.8 I get several hundred asan failures with 6.0 (see
https://gcc.gnu.org/ml/gcc-testresults/2016-04/msg01013.html). Most (if not
all) of them are of the kind

dyld: Symbol not found: _dyldVersionNumber
  Referenced from:
/opt/gcc/build_c/x86_64-apple-darwin10.8.0/i386/libsanitizer/asan/.libs/libasan.3.dylib
  Expected in: flat namespace
 in
/opt/gcc/build_c/x86_64-apple-darwin10.8.0/i386/libsanitizer/asan/.libs/libasan.3.dylib

AFAICT they are related to revision r229111

+bool DyldNeedsEnvVariable() {
+  // If running on OS X 10.11+ or iOS 9.0+, dyld will interpose even if
+  // DYLD_INSERT_LIBRARIES is not set. However, checking OS version via
+  // GetMacosVersion() doesn't work for the simulator. Let's instead check
+  // `dyldVersionNumber`, which is exported by dyld, against a known version
+  // number from the first OS release where this appeared.
+  return dyldVersionNumber < kMinDyldVersionWithAutoInterposition;
+}
+

[Bug tree-optimization/70577] [6 regression] tree-ssa/prefetch-5.c scan-tree-dump-times aprefetch failures

[kyukhin at gcc dot gnu.org]

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

Kirill Yukhin  changed:

   What|Removed |Added

 CC||kyukhin at gcc dot gnu.org

--- Comment #8 from Kirill Yukhin  ---
This commit caused miscompare of spec2000/178.galgel on -march=skylake-avx512
(-Ofast -flto -funroll-loops):
   Newton iteration #  0Maximal derivative = 0.1526E-07
   Newton iteration #  0Maximal derivative = 0.3901E-07

[Bug tree-optimization/70577] [6 regression] tree-ssa/prefetch-5.c scan-tree-dump-times aprefetch failures

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #6)
> I think -1 is the right answer, these are flexible array-like arrays, 
> where one could e.g.
> struct tail0 *p = malloc (sizeof (struct tail0) + 131072 * sizeof (int));
> initialize (p);
> loop0 (131072, p);
> and similarly for tail1/loop1.

Ah, you are right, thanks for explanation.

[Bug c++/70615] [6 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu in add_expr, at tree.c:7870

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-11
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|ICE on valid code at -O1|[6 Regression] ICE on valid
   |and above on|code at -O1 and above on
   |x86_64-linux-gnu in |x86_64-linux-gnu in
   |add_expr, at tree.c:7870|add_expr, at tree.c:7870
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r231197.

[Bug c++/70616] [4.9/5/6 Regression] ICE on valid code on x86_64-linux-gnu in build_base_path, at cp/class.c:303

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-11
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |4.9.4
Summary|ICE on valid code on|[4.9/5/6 Regression] ICE on
   |x86_64-linux-gnu in |valid code on
   |build_base_path, at |x86_64-linux-gnu in
   |cp/class.c:303  |build_base_path, at
   ||cp/class.c:303
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r185945.

[Bug c++/70620] possible wrong code at -Os on x86_64-linux-gnu for C++ code with multiple inheritance and casting

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
This changed behavior with r215569.  I'd be really surprised if this is not UB,
but in C++ nothing can really surprise me.

[Bug c++/70621] [6 Regression] ICE on invalid code at -O1 and above on x86_64-linux-gnu in record_reference, at cgraphbuild.c:64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Keywords||error-recovery
   Last reconfirmed||2016-04-11
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ICE on invalid code at -O1  |[6 Regression] ICE on
   |and above on|invalid code at -O1 and
   |x86_64-linux-gnu in |above on x86_64-linux-gnu
   |record_reference, at|in record_reference, at
   |cgraphbuild.c:64|cgraphbuild.c:64
   Target Milestone|--- |6.0

--- Comment #1 from Jakub Jelinek  ---
Started with my r232278 aka PR68511 and PR69213 fix.

[Bug c++/70622] [6 Regression] auto specifier don't deduce value type and its pointer type within single declaration.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|auto specifier don't deduce |[6 Regression] auto
   |value type and its pointer  |specifier don't deduce
   |type within single  |value type and its pointer
   |declaration.|type within single
   ||declaration.

--- Comment #1 from Jakub Jelinek  ---
Started with r231349 aka PR68597 fix.

[Bug tree-optimization/70623] [6 Regression] ICE in compute_antic at -O2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-11
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r226801.

[Bug bootstrap/70173] make distclean: leaves stage_final and libcc1/compiler-name.h

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
Author: segher
Date: Mon Apr 11 07:26:36 2016
New Revision: 234874

URL: https://gcc.gnu.org/viewcvs?rev=234874=gcc=rev
Log:
libcc1: Clean compiler-name.h (PR70173)

Since the file is generated from a Makefile fragment, it needs to be
added to MOSTLYCLEANFILES.  The directory itself is still not deleted
(just like the gnattools and gotools directories).


2016-04-11  Segher Boessenkool  

libcc1/
PR bootstrap/70173
* Makefile.am (MOSTLYCLEANFILES): New, add compiler-name.h .
(compiler-name.h): Shorten recipe so that it fits the line.
* Makefile.in: Regenerate.

Modified:
trunk/libcc1/ChangeLog
trunk/libcc1/Makefile.am
trunk/libcc1/Makefile.in