[Bug rtl-optimization/67778] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in maybe_record_trace_start, at dwarf2cfi.c:2297

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
Shrink-wrapping should not put the prologue in the middle of a loop.
It can take a BB inside a loop as the block to put the prologue on,
but in that case (as in any other case) it duplicates all blocks
that can be entered both with and without the prologue.

This error is almost always a target problem.  It means there are
multiple paths to the same BB that have conflicting CFI information.
It really shouldn't just assert but instead print out what conflicts,
via what paths.

[Bug tree-optimization/68599] [6 Regression] gcc.dg/tree-ssa/pr45122.c and tree-vrp.c

[law at redhat dot com]

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

--- Comment #3 from Jeffrey A. Law  ---
Yea, this is a latent issue in the RTL loop optimizer.  Essentially
-funsafe-loop-optimizations is getting too aggressive.  We've essentially got
the same situation in RTL-land as we had in tree land for pr45122.

I'm looking at a similar solution, namely limiting aggressiveness when the loop
has multiple exits.

[Bug ipa/68331] [meta-bug] fipa-pta issues

[vries at gcc dot gnu.org]

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

--- Comment #7 from vries at gcc dot gnu.org ---
(In reply to vries from comment #6)
> (In reply to vries from comment #5)
> > libstdc++.sum:FAIL: experimental/filesystem/path/concat/strings.cc execution
> 
> The test doesn't pass when compiled from the command line with -fno-ipa-pta.

Conversly, the test doesn't fail with -fipa-pta for a build with -fno-ipa-pta
as default. So it looks indeed like a library miscompilation.

[Bug target/68577] [6 Regression] ICE: in expand_direct_optab_fn, at internal-fn.c:2171

[rsandifo at gcc dot gnu.org]

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Tue Dec  1 21:01:35 2015
New Revision: 231131

URL: https://gcc.gnu.org/viewcvs?rev=231131=gcc=rev
Log:
PR68577: Handle narrowing for vector popcount, etc.

This patch adds support for simple cases where a vector
internal function returns wider results than the scalar
equivalent.  It punts on other cases.

Tested on powerpc64-linux-gnu and x86_64-linux-gnu.

gcc/
PR tree-optimization/68577
* tree-vect-stmts.c (simple_integer_narrowing): New function.
(vectorizable_call): Restrict internal function handling
to NONE and NARROW cases, using simple_integer_narrowing
to test for the latter.  Add cost of narrowing operation
and insert it where necessary.

gcc/testsuite/
PR tree-optimization/68577
* gcc.dg/vect/pr68577.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr68577.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-stmts.c

[Bug target/68577] [6 Regression] ICE: in expand_direct_optab_fn, at internal-fn.c:2171

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
Patch applied.

[Bug c++/68642] New: GCC crashes on deep std::make_index_sequence

[wmhkebe at gmail dot com]

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

Bug ID: 68642
   Summary: GCC crashes on deep std::make_index_sequence
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wmhkebe at gmail dot com
  Target Milestone: ---

Created attachment 36884
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36884=edit
Preprocessed file that will crash the compiler.

Compiling code containing std::make_index_sequence with moderately large N
(~100k) will crash g++. This is illustrated by the following code snippet,
which should be compiled with g++ -std=c++14 -ftemplate-depth=20 (a
preprocessed file is also attached):

#include 

int main() {
  std::make_index_sequence<10> a;
  return 0;
}

Compiler output:
g++-5: internal compiler error: Segmentation fault: 11 (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Output from g++ -v:
Using built-in specs.
COLLECT_GCC=gcc-5
COLLECT_LTO_WRAPPER=/Users/menghui/homebrew/Cellar/gcc5/5.2.0/libexec/gcc/x86_64-apple-darwin14.5.0/5.2.0/lto-wrapper
Target: x86_64-apple-darwin14.5.0
Configured with: ../configure --build=x86_64-apple-darwin14.5.0
--prefix=/Users/menghui/homebrew/Cellar/gcc5/5.2.0
--libdir=/Users/menghui/homebrew/Cellar/gcc5/5.2.0/lib/gcc/5
--enable-languages=c,c++,objc,obj-c++ --program-suffix=-5
--with-gmp=/Users/menghui/homebrew/opt/gmp
--with-mpfr=/Users/menghui/homebrew/opt/mpfr
--with-mpc=/Users/menghui/homebrew/opt/libmpc
--with-isl=/Users/menghui/homebrew/opt/isl014 --with-system-zlib
--enable-libstdcxx-time=yes --enable-stage1-checking --enable-checking=release
--enable-lto --disable-werror --with-pkgversion='Homebrew gcc5 5.2.0'
--with-bugurl=https://github.com/Homebrew/homebrew-versions/issues
--enable-plugin --disable-nls --enable-multilib
Thread model: posix
gcc version 5.2.0 (Homebrew gcc5 5.2.0)

[Bug libffi/65726] [5/6 Regression] libffi fails to build when not bootstrapping: configure: error: C++ preprocessor "/lib/cpp" fails sanity check

[andreast at gcc dot gnu.org]

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

--- Comment #10 from Andreas Tobler  ---
I will wait until gcc5 opens again and then I back-port this patch to gcc5 and
gcc49.

[Bug lto/65380] [5 Regression][ICF] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158

[milan.plzik at gmail dot com]

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

--- Comment #19 from milan.plzik at gmail dot com ---
Created attachment 36886
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36886=edit
Shell script, which compiles ChibiOS and indeed triggers gcc failure

Attached script should trigger the problem when compiling ChibiOS sources.

[Bug libffi/65726] [5/6 Regression] libffi fails to build when not bootstrapping: configure: error: C++ preprocessor "/lib/cpp" fails sanity check

[andreast at gcc dot gnu.org]

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

--- Comment #9 from Andreas Tobler  ---
Author: andreast
Date: Tue Dec  1 20:15:35 2015
New Revision: 231128

URL: https://gcc.gnu.org/viewcvs?rev=231128=gcc=rev
Log:
2015-12-01  Andreas Tobler  

PR libffi/65726
* Makefile.def (lang_env_dependencies): Make libffi depend
on cxx.
* Makefile.in: Regenerate.

Modified:
trunk/ChangeLog
trunk/Makefile.def
trunk/Makefile.in

[Bug ipa/68331] [meta-bug] fipa-pta issues

[vries at gcc dot gnu.org]

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

--- Comment #6 from vries at gcc dot gnu.org ---
(In reply to vries from comment #5)
> libstdc++.sum:FAIL: experimental/filesystem/path/concat/strings.cc execution

The test doesn't pass when compiled from the command line with -fno-ipa-pta.

Failure backtrace (for -O0 -g):
...
Program received signal SIGSEGV, Segmentation fault.
0x00404811 in
std::vector::~vector (this=0x4f, __in_chrg=)
at x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_vector.h:426
426   { std::_Destroy(this->_M_impl._M_start, this->_M_impl._M_finish,
(gdb) bt
#0  0x00404811 in
std::vector::~vector (this=0x4f, __in_chrg=)
at x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_vector.h:426
#1  0x0040373e in
std::experimental::filesystem::v1::__cxx11::path::~path (this=0x2f,
__in_chrg=)
at x86_64-pc-linux-gnu/libstdc++-v3/include/experimental/bits/fs_path.h:190
#2  0x004075ec in
std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts() ()
#3  0x00407fd7 in
std::experimental::filesystem::v1::__cxx11::path::parent_path() const ()
#4  0x004042bf in test01 ()
at libstdc++-v3/testsuite/experimental/filesystem/path/concat/strings.cc:45
#5  0x0040465a in main ()
at libstdc++-v3/testsuite/experimental/filesystem/path/concat/strings.cc:54
...

[Bug middle-end/68641] New: undefined variables implicitly considered to be zero

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 68641
   Summary: undefined variables implicitly considered to be zero
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch
  Target Milestone: ---

This is an enhancement request. Using -O1 and higher, undefined variables are
considered equal to 0 in optimization. This leads to code compiling at -O1 but
failing to compile at -O0, for example :

> cat test.f90
  INTEGER :: i
  INTEGER, POINTER :: foo
  IF (i/=0) CALL link_error
  IF (ASSOCIATED(foo)) CALL link_error
END

another disadvantage is that e.g. using valgrind, the above program will not
fail when compiled at -O1. Only at -O0 these cases will be found (leading to
much longer testing times).

Using -Wmaybe-uninitialized is not a real solution, there are just too many
false positives (I'm not aware of a -Wmust-be-uninitialized, which would be
valuable).

So, ideally no optimization is done based on an assumed value.

[Bug ipa/68331] [meta-bug] fipa-pta issues

[vries at gcc dot gnu.org]

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

--- Comment #5 from vries at gcc dot gnu.org ---
Created attachment 36885
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36885=edit
Abort solve_graph after num_edge passes threshold

This patch aborts solve_graph after stats.num_edges passes 4.000.000.

Using this patch, in combination with a -fipa-pta on-by-by-default patch, I'm
able to do a no-bootstrap build and reg-test.

Test failures:
...
libstdc++.sum:FAIL: experimental/filesystem/path/concat/strings.cc execution
test
libstdc++.sum:FAIL: experimental/filesystem/path/construct/locale.cc execution
test
...

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[sje at gcc dot gnu.org]

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

--- Comment #8 from Steve Ellcey  ---
Where in CC1 do you segfault?  Can you show me the error message you get when
compiling the test program using the latest gcc-5-branch sources.

[Bug libstdc++/66059] make_integer_sequence should use a log(N) implementation

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||wmhkebe at gmail dot com

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

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[sje at gcc dot gnu.org]

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

--- Comment #6 from Steve Ellcey  ---
I still haven't been able to reproduce this.  I have been trying to do so with
the gcc-5-branch.  Aurelien, what host GCC version are you using when you build
a cross compiler?  I am building on Ubuntu 12.04 with GCC 4.6.3 and am building
the cross compiler as a 64 bit executable.

[Bug c/68612] Const-compatibility in C

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  ---
I'd consider this a reasonable extension (not suitable for adding while 
trunk is in bug-fixing mode, of course) for default (non-pedantic) mode, 
similar to the extension to use C++-like rules for arrays of qualified 
type.  Similar to that, it requires a lot of care to make sure it doesn't 
cause valid code to be rejected, as well as thorough testcases.

(To be clear, the C++ rule is not symmetric between const and other 
qualifiers; it allows adding arbitrary qualifiers in certain places if 
const is present at all levels of indirection beyond those where any 
qualifiers are added.  For this purpose, in C, _Atomic should not be 
considered a qualifier, and you'd need to think about how address space 
qualifiers are involved.)

[Bug c++/68642] GCC crashes on deep std::make_index_sequence

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
That is one of the secondary uses of it, so that's fair enough!

The new implementation scales well to 100k, but won't be available until after
the 5.3 release, sorry.

[Bug c++/68642] GCC crashes on deep std::make_index_sequence

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
It ran out of memory. This has already been fixed on trunk, and will be
backported to the branch after 5.3 is released.

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

[Bug rtl-optimization/67778] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in maybe_record_trace_start, at dwarf2cfi.c:2297

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #8 from Segher Boessenkool  ---
I'll take it.

[Bug c++/68642] GCC crashes on deep std::make_index_sequence

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
N.B. 100k is not "moderately large" it's far larger than any real parameter
pack is ever likely to be, and the primary purpose of index_sequence is to
index into parameter packs.

[Bug c++/68642] GCC crashes on deep std::make_index_sequence

[wmhkebe at gmail dot com]

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

--- Comment #3 from wmhkebe at gmail dot com ---
(In reply to Jonathan Wakely from comment #2)
> N.B. 100k is not "moderately large" it's far larger than any real parameter
> pack is ever likely to be, and the primary purpose of index_sequence is to
> index into parameter packs.

Thanks for the prompt reply Jonathan!

Just a little background about my use case. I want to initialize a constexpr
std::array with a constexpr function f, with a[i]=f(i), without
needing to repeat my code for 100k times like a = {f(0), f(1), f(2), ...}. 100k
is a reasonable size for an int array, so I expected it also to be feasible for
std::make_index_sequence, provided that clang can handle it pretty efficiently.
Thanks again!

[Bug middle-end/68146] [6 Regression] ice in gimple_stmt_nonnegative_warnv_p with -O2

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
*** Bug 68521 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/68521] [6 regression] ICE on valid code

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
Just to confirm this is a dup of PR68146.  Testing a fix now.

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

[Bug middle-end/68146] [6 Regression] ice in gimple_stmt_nonnegative_warnv_p with -O2

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Testing a fix.

[Bug rtl-optimization/67778] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in maybe_record_trace_start, at dwarf2cfi.c:2297

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
But it is shrink-wrapping that inserts the prologue into the loop.
Before pro_and_epilogue we have cfg like:

 ENTRY
   |
  bb2
 /   \
v v<+
   bb3bb4\
|  \  \
v<+ \  \
   bb5 \ \  \
  /  \  \ \  \
 v<+  v  \ \  \
bb6|  bb7 | \  \
 | |  / \ | |  |
 +-+  | +-+ |  |
  v |  |
 bb8|  |
  | v  |
  +---> bb9|
/ \|
   v   +---+
  bb10
   |
   v
  EXIT

and the only bb that needs prologue is bb10.
The changes that pro_and_epilogue pass does are:
1) the bb4 -> bb9 edge, previously DFS_BACK,IRREDUCIBLE_LOOP, looses both of
those flags
2) prologue is inserted at the beginning of bb9
3) epilogue (ending with (simple_return) is inserted at the end of bb10
4) a barrier is inserted after that (simple_return)
I don't see any other changes.  Please have a look at the dumps.

Multiple paths to the same bb having different CFI info are a direct
consequence of this bug, because bb9 is then reachable from the CFI info at the
beginning of function (when reached from bb8 or bb2->bb4) and CFI info after
prologue (when reached from bb9->bb4).  What code in the shrink-wrapping bb
discovery rewrite is supposed to make sure that the prologue is not put into
the middle of a loop?

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[aurelien at aurel32 dot net]

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

--- Comment #7 from Aurelien Jarno  ---
I am using gcc 5.2 from Debian unstable to build the cross compiler. Please
also note that I have the same issue when using the native GCC 5.2 compiler on
a mips or mipsel system.

How can I help debugging that? Is there any output I can provide that might
help?

[Bug tree-optimization/68644] New: FAIL: gcc.dg/tree-ssa/ivopts-lt-2.c scan-tree-dump-times ivopts "PHI <p_" 1

[danglin at gcc dot gnu.org]

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

Bug ID: 68644
   Summary: FAIL: gcc.dg/tree-ssa/ivopts-lt-2.c
scan-tree-dump-times ivopts "PHI 

[Bug testsuite/68643] New: FAIL: gcc.dg/tree-prof/cold_partition_label.c scan-assembler foo[._]+cold[._]+0

[danglin at gcc dot gnu.org]

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

Bug ID: 68643
   Summary: FAIL: gcc.dg/tree-prof/cold_partition_label.c
scan-assembler foo[._]+cold[._]+0
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/objdi
r/gcc/
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-prof/cold_partition_labe
l.c -fno-diagnostics-show-caret -fdiagnostics-color=never   -O2
-freorder-bl
ocks-and-partition -save-temps -fprofile-use -D_PROFILE_USE  -lm  -o
/home/dave/
gnu/gcc/objdir/gcc/testsuite/gcc/cold_partition_label.x02(timeout = 300)
spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/obj
dir/gcc/
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-prof/cold_partition_la
bel.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O2
-freorder-blocks
-and-partition -save-temps -fprofile-use -D_PROFILE_USE -lm -o
/home/dave/gnu/gc
c/objdir/gcc/testsuite/gcc/cold_partition_label.x02
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-prof/cold_partition_label.c:1:0
: note: -freorder-blocks-and-partition does not work on this architecture
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-prof/cold_partition_label.c:1:0
: note: -freorder-blocks-and-partition does not work on this architecture
output is:
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-prof/cold_partition_label.c:1:0:
note: -freorder-blocks-and-partition does not work on this architecture
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-prof/cold_partition_label.c:1:0:
note: -freorder-blocks-and-partition does not work on this architecture

PASS: gcc.dg/tree-prof/cold_partition_label.c compilation,  -fprofile-use
-D_PROFILE_USE
Setting LD_LIBRARY_PATH to
:/home/dave/gnu/gcc/objdir/gcc:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libatomic/.libs::/home/dave/gnu/gcc/objdir/gcc:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libatomic/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libssp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libgomp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libatomic/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home/dave/gnu/gcc/objdir/./prev-gcc:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libssp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libgomp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libatomic/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home/dave/gnu/gcc/objdir/./prev-gcc
spawn [open ...]
PASS: gcc.dg/tree-prof/cold_partition_label.c execution,-fprofile-use
-D_PROFILE_USE
FAIL: gcc.dg/tree-prof/cold_partition_label.c scan-assembler foo[._]+cold[._]+0
FAIL: gcc.dg/tree-prof/cold_partition_label.c scan-assembler size[
\ta-zA-Z0-0]+foo[._]+cold[._]+0

[Bug c++/68645] New: FAIL: c-c++-common/attr-simd-3.c -std=gnu++11 (test for excess errors)

[danglin at gcc dot gnu.org]

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

Bug ID: 68645
   Summary: FAIL: c-c++-common/attr-simd-3.c  -std=gnu++11 (test
for excess errors)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++
-B/h
ome/dave/gnu/gcc/objdir/gcc/testsuite/g++/../../
/home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/attr-simd-3.c
-fno-diagnostics-show-caret -fdiagnostics-color
=never -nostdinc++
-I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/inclu
de/hppa-linux-gnu
-I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++11 -fcilkplus -S -o
attr-simd-3.s/home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/attr-simd-3.c:5:48:
warning: '__simd__' attribute does not apply to types [-Wattributes]output
is:/home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/attr-simd-3.c:5:48:
warning: '__simd__' attribute does not apply to types [-Wattributes]
XFAIL: c-c++-common/attr-simd-3.c  -std=gnu++11 PR68158 (test for errors, line
5)FAIL: c-c++-common/attr-simd-3.c  -std=gnu++11 (test for excess errors)
Excess
errors:/home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/attr-simd-3.c:5:48:
warning: '__simd__' attribute does not apply to types [-Wattributes]

[Bug go/65717] 64-bit runtime FAILs with 32-bit compiler

[ian at gcc dot gnu.org]

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

--- Comment #5 from ian at gcc dot gnu.org  ---
Author: ian
Date: Wed Dec  2 01:28:26 2015
New Revision: 231142

URL: https://gcc.gnu.org/viewcvs?rev=231142=gcc=rev
Log:
PR go/65717
compiler: Fix array reflection when len doesn't fit in unsigned long.

This comes up when using a 32-bit host and a 64-bit target.

Fixes https://gcc.gnu.org/PR65717.

Reviewed-on: https://go-review.googlesource.com/17330

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/gcc/go/gofrontend/types.cc

[Bug lto/68646] New: FAIL: g++.dg/lto/20081118 cp_lto_20081118_0.o-cp_lto_20081118_1.o link

[danglin at gcc dot gnu.org]

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

Bug ID: 68646
   Summary: FAIL: g++.dg/lto/20081118
cp_lto_20081118_0.o-cp_lto_20081118_1.o link
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++
-B/home/dave/gnu/gcc/objdir/gcc/testsuite/g++/../../ cp_lto_20081118_0.o
cp_lto_20081118_1.o -fno-diagnostics-show-caret -fdiagnostics-color=never
-nostdinc++
-I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu
-I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward
 -I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -fPIC
-flto -flto-partition=1to1 -r -nostdlib
-L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libstdc++-v3/src/.libs
-B/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libstdc++-v3/src/.libs -o
g++-dg-lto-20081118-01.exelto1: error: comdat-local symbol referred to by
_ZTV6object outside its comdat_ZN6objectD0Ev.localalias.3/47
(_ZN6objectD0Ev.localalias.3) @0xfd56d1b0  Type: function definition analyzed
alias  Visibility: comdat_group:_ZN6objectD5Ev virtual
  Same comdat group as: _ZN6objectD0Ev/3  Address is taken.
  References: _ZN6objectD0Ev/3 (alias)
  Referring: _ZTV6object/10 (addr)
  Availability: available
  First run: 0
  Function flags:
  Called by: 
  Calls: 
lto1: internal compiler error: verify_cgraph_node failed
0x213e57 cgraph_node::verify_node()
../../gcc/gcc/cgraph.c:3160
0x20728f symtab_node::verify()
../../gcc/gcc/symtab.c:1078
0x20752b symtab_node::verify_symtab_nodes()
../../gcc/gcc/symtab.c:1098
0x464d23 symtab_node::checking_verify_symtab_nodes()
../../gcc/gcc/cgraph.h:566
0x464d23 symbol_table::remove_unreachable_nodes(_IO_FILE*)
../../gcc/gcc/ipa.c:672
0x584917 execute_todo
../../gcc/gcc/passes.c:2024
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error:
/home/dave/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++ returned 1 exit status
compilation terminated.
/usr/bin/hppa-linux-gnu-ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
compiler exited with status 1
output is:
lto1: error: comdat-local symbol referred to by _ZTV6object outside its comdat
_ZN6objectD0Ev.localalias.3/47 (_ZN6objectD0Ev.localalias.3) @0xfd56d1b0
  Type: function definition analyzed alias
  Visibility: comdat_group:_ZN6objectD5Ev virtual
  Same comdat group as: _ZN6objectD0Ev/3
  Address is taken.
  References: _ZN6objectD0Ev/3 (alias)
  Referring: _ZTV6object/10 (addr)
  Availability: available
  First run: 0
  Function flags:
  Called by: 
  Calls: 
lto1: internal compiler error: verify_cgraph_node failed
0x213e57 cgraph_node::verify_node()
../../gcc/gcc/cgraph.c:3160
0x20728f symtab_node::verify()
../../gcc/gcc/symtab.c:1078
0x20752b symtab_node::verify_symtab_nodes()
../../gcc/gcc/symtab.c:1098
0x464d23 symtab_node::checking_verify_symtab_nodes()
../../gcc/gcc/cgraph.h:566
0x464d23 symbol_table::remove_unreachable_nodes(_IO_FILE*)
../../gcc/gcc/ipa.c:672
0x584917 execute_todo
../../gcc/gcc/passes.c:2024
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error:
/home/dave/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++ returned 1 exit status
compilation terminated.
/usr/bin/hppa-linux-gnu-ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

FAIL: g++.dg/lto/20081118 cp_lto_20081118_0.o-cp_lto_20081118_1.o link, -fPIC
-flto -flto-partition=1to1 -r -nostdlib (internal compiler error)
UNRESOLVED: g++.dg/lto/20081118 cp_lto_20081118_0.o-cp_lto_20081118_1.o execute
-fPIC -flto -flto-partition=1to1 -r -nostdlib

Similar fail:

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++
-B/home/dave/gnu/gcc/objdir/gcc/testsuite/g++/../../ cp_lto_20081204-1_0.o
cp_lto_20081204-1_1.o -fno-diagnostics-show-caret -fdiagnostics-color=never
-nostdinc++
-I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu
-I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include
-I/home/dave/gnu/g
cc/gcc/libstdc++-v3/libsupc++

[Bug rtl-optimization/67778] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in maybe_record_trace_start, at dwarf2cfi.c:2297

[segher at gcc dot gnu.org]

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

--- Comment #9 from Segher Boessenkool  ---
I cannot reproduce the problem, #c2, not with any flags I tried,
not with a 20151122 compiler either.  Help?

[Bug go/65717] 64-bit runtime FAILs with 32-bit compiler

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #6 from Ian Lance Taylor  ---
Fixed on trunk.

[Bug tree-optimization/68521] [6 regression] ICE on valid code

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Sounds similar to PR68146.

[Bug middle-end/66685] [6 Regression] conftest.c:16:1: internal compiler error: in as_a, at is-a.h:192

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #10 from rsandifo at gcc dot gnu.org  
---
Patch committed.

[Bug tree-optimization/66558] Missed vectorization of loop with control flow

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Patch applied.

[Bug target/28126] gcc moves an expensive (tls) instruction outside of a conditional

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

[Bug tree-optimization/68640] New: foo restrict propagated to foo._omp_fn.0

[vries at gcc dot gnu.org]

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

Bug ID: 68640
   Summary: foo restrict propagated to foo._omp_fn.0
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

I.

Consider parallel-alias.c:
...
#define N 1024

int
foo (int *__restrict__ ap, int *__restrict__ bp)
{
#pragma omp parallel for
  for (unsigned int idx = 0; idx < N; idx++)
ap[idx] = bp[idx];
}
...

compile with:
...
$ gcc parallel-alias.c -O2 -fopenmp -S
...

At ealias in foo._omp_fn.0, we have:
...
ap_9 = { PARM_NOALIAS(10) }
_24 = { PARM_NOALIAS(10) }
bp_8 = { PARM_NOALIAS(12) }
_27 = { PARM_NOALIAS(12) }
...

resulting in:
...
  # VUSE <.MEM_4>
  _28 = MEM[(intD.6 *)_27 clique 1 base 3];

  # .MEM_29 = VDEF <.MEM_4>
  MEM[(intD.6 *)_24 clique 1 base 2] = _28;
...

So the restrict in foo had an effect in foo._omp_fn.0.

While doing omp-lower, we enter install_var_field with a var with restrict
type:
...
Breakpoint 1, install_var_field (var=0x761b2080, by_ref=false, mask=3,
ctx=0x2aad910)
at src/gcc/omp-low.c:1374
1374  tree field, type, sfield = NULL_TREE;
(gdb) call debug_generic_expr (var)
bp
(gdb) call debug_generic_expr (var.typed.type)
int * restrict
...

And declare the field with the same type:
...
1389  type = TREE_TYPE (var);
   ...
1400  field = build_decl (DECL_SOURCE_LOCATION (var),
1401  FIELD_DECL, DECL_NAME (var), type);
...


II.

Now we rewrite the example a bit to introduce aliasing between ap and bp:
...
#define N 1024

int
foo (int *__restrict__ ap)
{
  int *bp = ap;
#pragma omp parallel for
  for (unsigned int idx = 0; idx < N; idx++)
ap[idx] = bp[idx];
}
...

at ealias, we have:
...
ap_9 = { PARM_NOALIAS(10) }
_24 = { PARM_NOALIAS(10) }
bp_8 = { NONLOCAL }
_27 = { NONLOCAL }
...

Resulting in:
...
  # VUSE <.MEM_4>
  _28 = *_27;

  # .MEM_29 = VDEF <.MEM_4>
  MEM[(intD.6 *)_24 clique 1 base 2] = _28;
...

So, atm I cannot find an example where we generate wrong code (but that might
happen when we make compute_dependence_clique more aggressive).

But I do wonder whether the usage of the restrict of foo in foo._omp_fn.0 is
intentional or accidental.

[Bug rtl-optimization/68432] [6 Regression] internal compiler error: in expand_insn, at optabs.c:6947

[rsandifo at gcc dot gnu.org]

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

--- Comment #14 from rsandifo at gcc dot gnu.org  
---
(In reply to Tobias Burnus from comment #13)
> (In reply to rsand...@gcc.gnu.org from comment #10)
> > Series finally posted here:
> >   https://gcc.gnu.org/ml/gcc-patches/2015-11/msg03020.html
> 
> Part 05's gcc/genattrtab.c changes do not apply. (All other parts and the
> chunks for other files in Part 05 do with some line-offset fuzzy.)
> 
> That's a bit surprising as git lists r229184 of 2015-10-22 as latest change
> for that file while the patch set was posted on 2015-11-25. - Six of the
> gcc/genattrtab.c chunks do not apply and none of them looks trivial.
> 
> 
> For instance, the patch changes:
> @@ -4770,6 +4804,7 @@ gen_insn_reserv (md_rtx_info *info)
>memset (, 0, sizeof (attr));
>attr.name = DEF_ATTR_STRING (XSTR (def, 0));
>attr.loc = info->loc;
> +  attr.type = AT_INSN;
> 
>decl->name= DEF_ATTR_STRING (XSTR (def, 0));
>decl->default_latency = XINT (def, 1);
> 
> 
> But in the trunk, I only see:
>   4753  gen_insn_reserv (md_rtx_info *info)
>   4754  {
>   4755struct insn_reserv *decl = oballoc (struct insn_reserv);
>   4756rtx def = info->def;
>   4757
>   4758decl->name= DEF_ATTR_STRING (XSTR (def, 0));
>   4759decl->default_latency = XINT (def, 1);

Sorry, this was because I'd based it on top of r231103.

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[josephpattara at gmail dot com]

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

--- Comment #6 from Joseph John  ---
Frank, Any pointers you could give me on this how you solved the first issue
coming because of native LD? That could help me a lot. 

I believe you still compiled with native LD but how did you progress the
"relocation PCREL21B" error?

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[josephpattara at gmail dot com]

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

--- Comment #7 from Joseph John  ---
MY LD version is below:
-bash-4.3$ ld -V
ld: 92453-07 linker ld HP Itanium(R) B.12.60  IPF/IPF

Are you using the same version?

[Bug c/68637] Wrong -Wattributes on array of function pointers

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

Summary|[6 Regression] Wrong|Wrong -Wattributes on array
   |-Wattributes on array of|of function pointers
   |function pointers   |

--- Comment #2 from H.J. Lu  ---
(In reply to H.J. Lu from comment #1)
> GCC 5 doesn't warn
> 
> typedef void (*func) (int, int) __attribute__ ((regparm (2)));
> 
> and GCC 6 does.

Never mind. Pilot error.

[Bug rtl-optimization/68432] [6 Regression] internal compiler error: in expand_insn, at optabs.c:6947

[rsandifo at gcc dot gnu.org]

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

--- Comment #15 from rsandifo at gcc dot gnu.org  
---
Created attachment 36882
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36882=edit
proposed patch

Here's an alternative to the 22-patch series, testing now.

[Bug tree-optimization/68474] [6 Regression] ICE: in get_no_error_domain, at tree-call-cdce.c:699 with -funsafe-math-optimizations

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Patch committed.

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[rsandifo at gcc dot gnu.org]

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

Bug 66558 Summary: Missed vectorization of loop with control flow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66558

   What|Removed |Added

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

[Bug target/38595] gcc.target/mips/mips16e-extends.c fails for -mlong64

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Unfortunately I no longer have the patch mentioned in comment #1.

[Bug middle-end/68291] [6 regression] ICE in emit_move_insn, at expr.c:3540

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  ---
This comes from -ftree-coalesce-vars in expand_function_start:

  /* If we may coalesce this result, make sure it has the expected mode.  */
  if (flag_tree_coalesce_vars && is_gimple_reg (res))
{
  tree def = ssa_default_def (cfun, res);
  gcc_assert (def);
  machine_mode mode = promote_ssa_mode (def, NULL);
  set_parm_rtl (res, gen_reg_rtx (mode));
}

(gdb) p debug_tree(def)
 
unit size 
align 32 symtab 0 alias set 1 canonical type 0x76c4d3f0
precision 32
pointer_to_this >
BLK
size 
unit size 
align 128 symtab 0 alias set -1 canonical type 0x76d09540
attributes > nunits 4
context >
var def_stmt GIMPLE_NOP

version 10>

so we end up creating a REG with BLKmode:

(gdb) p debug_tree(res)
 
unit size 
align 32 symtab 0 alias set 1 canonical type 0x76c4d3f0
precision 32
pointer_to_this >
BLK
size 
unit size 
align 128 symtab 0 alias set -1 canonical type 0x76d09540
attributes > nunits 4
context >
ignored BLK file pr39928-1.c line 8 col 1 size  unit size 
align 128 context 
(reg:BLK 109 [  ])>

instead of the expected:

 
unit size 
align 32 symtab 0 alias set 1 canonical type 0x76c4d3f0
precision 32
pointer_to_this >
BLK
size 
unit size 
align 128 symtab 0 alias set -1 canonical type 0x76d09540
attributes > nunits 4
context >
ignored BLK file pr39928-1.c line 8 col 1 size  unit size 
align 128 context 
(parallel:BLK [
(expr_list:REG_DEP_TRUE (reg:DI 109 [  ])
(const_int 0 [0]))
(expr_list:REG_DEP_TRUE (reg:DI 110 [ +8 ])
(const_int 8 [0x8]))
])>

and this later confuses expand_function_end.

[Bug middle-end/68292] [6 regression] ICE in copy_blkmode_to_reg, at expr.c:2277

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  ---
It's another failure mode of the underlying issue of PR middle-end/68291.

[Bug fortran/38312] Unexpected STATEMENT FUNCTION statement

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #8 from Joost VandeVondele  
---
The current error message has changed :

test.f90:7:6:

   co(i,j)=t1(i,k)*t2(j,k)
  1

Error: The function result on the lhs of the assignment at (1) must have the
pointer attribute.

now the location gives a hint.

[Bug middle-end/68291] [6 regression] ICE in emit_move_insn, at expr.c:3540

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #6 from Eric Botcazou  ---
So it seems to me that -ftree-coalesce-vars expects every GIMPLE register to be
mapped onto an RTL register if the type is returned in registers by the target,
but that's not true with BLKmode vector types on SPARC 64-bit.  We may be able
to work around this during expand if there is an integer mode with the same
size as the vector type, but then we would need to add a new mode (OImode) for
SPARC.

Alexandre, any hint on the best course of action here?

[Bug fortran/38312] Unexpected STATEMENT FUNCTION statement

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  ---
> The current error message has changed :
>
> test.f90:7:6:
>
>   co(i,j)=t1(i,k)*t2(j,k)
>  1
>
> Error: The function result on the lhs of the assignment at (1) must have
> the pointer attribute.
>
> now the location gives a hint.

Confirmed. The change occurred between revisions r227754 (2015-09-14, old
error) and r228407 (2015-10-02, new error), likely r228222 (pr63921).

How do you prefer to resolve this PR: as FIXED or WONTFIX?

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

[josephpattara at gmail dot com]

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

--- Comment #15 from Joseph John  ---
Hi John,
What is the LD version you have in the system.

MY LD version is below:
-bash-4.3$ ld -V
ld: 92453-07 linker ld HP Itanium(R) B.12.60  IPF/IPF

The reason for my question is if I use default configure and make commands I
was originally hitting an issue as below:
.
ld: The value 0xfdf68820 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x102 in section index 74 of file
libbackend.a[function.o]
ld: The value 0xfdee13b0 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x102 in section index 79 of file
libbackend.a[functiono]
..

which points to some issue on Native LD.

[Bug c/68533] bogus location for "warning: ‘struct s3’ declared inside parameter list will not be visible outside of this definition or declaration"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-12-01
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 36883
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36883=edit
gcc6-pr68533.patch

Untested fix.

[Bug rtl-optimization/67778] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in maybe_record_trace_start, at dwarf2cfi.c:2297

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #10)
> (In reply to Segher Boessenkool from comment #9)
> > I cannot reproduce the problem, #c2, not with any flags I tried,
> > not with a 20151122 compiler either.  Help?
> 
> #c2 testcase, x86_64-linux compiler, -m32 -O2, reproduces this for me
> reliably.
> Say with -mtune=generic -march=i386 (or -march=x86_64, or -march=i686).
> -m32 -O3 too.  r231142 reproduces it too.
> -m32 -O2 -fno-shrink-wrap does not ICE.  Are you using a cross-compiler from
> some other target?

But it reproduces on #c2 also with -m64 -O2 and -m64 -O3.
In all cases it is
Block 10 needs the prologue.
After wrapping required blocks, PRO is now 10
Avoiding non-duplicatable blocks, PRO is now 10
Bumping back to anticipatable blocks, PRO is now 9
Performing shrink-wrapping.
on main, where bb10 is not in any loop, but bb9 is part of a loop.

[Bug sanitizer/68650] Firefox compilation fails with Address Sanitizer (error: undefined reference to 'dlerror')

[gk at torproject dot org]

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

--- Comment #1 from Georg Koppen  ---
To give a bit more context the flags used for compilation are:

export CFLAGS="-fsanitize=address -Dxmalloc=myxmalloc"
export CXXFLAGS="-fsanitize=address -Dxmalloc=myxmalloc"
export LDFLAGS="-fsanitize=address"

(and there are some Firefox specific configure switches involved like

ac_add_options --enable-address-sanitizer
ac_add_options --disable-jemalloc
ac_add_options --disable-elf-hack
)

[Bug driver/68029] Strange behavior of -fdiagnostics-color option

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #13 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug driver/68029] Strange behavior of -fdiagnostics-color option

[law at gcc dot gnu.org]

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

--- Comment #12 from Jeffrey A. Law  ---
Author: law
Date: Wed Dec  2 07:42:58 2015
New Revision: 231150

URL: https://gcc.gnu.org/viewcvs?rev=231150=gcc=rev
Log:
[PATCH] Fix PR68029

PR driver/68029
* opts-common.c (prune_options): Don't ignore -fdiagnostics-color
if it is the first parameter.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/opts-common.c

[Bug bootstrap/66022] 4.8.4 build fails with stage 2 and 3 comparison error

[norm.jacobs at oracle dot com]

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

Norm Jacobs  changed:

   What|Removed |Added

 CC||norm.jacobs at oracle dot com

--- Comment #2 from Norm Jacobs  ---
I have run into something similar building GCC 4.8.2 on a Solaris 12
development build.

silence-ld04% uname -a
SunOS silence-ld04 5.12 s12_87 sun4v sparc sun4v

I have a Sparc Solaris 12 system with Binutils 2.25.1.  When I try to build GCC
4.8.2 (yes, I know it's old) I get failures in the stage2/stage3 comparison.

[snip]
libiberty/strsignal.o differs
libiberty/dwarfnames.o differs
libiberty/physmem.o differs
libiberty/obstack.o differs
libiberty/choose-temp.o differs
libiberty/strerror.o differs
libiberty/safe-ctype.o differs
zlib/libz_a-uncompr.o differs
zlib/libz_a-gzwrite.o differs
zlib/libz_a-inffast.o differs
zlib/libz_a-compress.o differs
zlib/libz_a-zutil.o differs
make[3]: *** [compare] Error 1

It seems to build fine with Binutils 2.23.1 installed and seems to build fine
on x86.  A little digging and I found that configure is deciding set
BUILD_CONFIG to bootstrap-debug with Binutils 2.25.1 installed on SPARC, but
not otherwise.  Doing this adds "-gtoggle" to the compilation line in stage2,
which wouldn't be a problem since the comparison should have switched to
contrib/compare-debug which strips out unwanted ELF sections prior to
comparison.  In my case, the problem seems to be that the ELF sections are
re-ordered as a result of adding '-gtoggle' to the compilation.  Since the
sections are re-ordered, the comparison fails even after being stripped.

silence-ld04% /usr/gnu/bin/objdump --headers libz_a-zutil.o*

libz_a-zutil.o: file format elf32-sparc-sol2

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
  0 .text 0114      0120  2**2
  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .rodata   00c6      0238  2**3
  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
  2 .debug_frame  009c      0300  2**2
  CONTENTS, RELOC, READONLY, DEBUGGING
  3 .debug_info   02aa      039c  2**0
  CONTENTS, RELOC, READONLY, DEBUGGING
  4 .debug_abbrev 00fd      0646  2**0
  CONTENTS, READONLY, DEBUGGING
  5 .debug_loc00a0      0743  2**0
  CONTENTS, READONLY, DEBUGGING
  6 .debug_aranges 0020      07e3  2**0
  CONTENTS, RELOC, READONLY, DEBUGGING
  7 .debug_line   0122      0803  2**0
  CONTENTS, RELOC, READONLY, DEBUGGING
  8 .debug_str      0925  2**0
  CONTENTS, READONLY, DEBUGGING
  9 .comment  004e      0e00  2**0
  CONTENTS, READONLY

libz_a-zutil.o.gtoggle: file format elf32-sparc-sol2

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
  0 .rodata   00c6      0080  2**3
  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
  1 .text 0114      0148  2**2
  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  2 .comment  004e      0430  2**0
  CONTENTS, READONLY
silence-ld04%

Note that the ordering of .rodata and .text differ.  I can workaround this for
now using "--with-build-config=no" when I configure, but it seems odd that my
ELF sections are getting re-ordered.  I haven't yet tried to build the trunk on
this system.

[Bug fortran/68649] [6 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |fortran

--- Comment #2 from Andrew Pinski  ---
This smells like a fortran front-end issue where _gfortran_reshape_r8's decl is
created twice with two different argument types.

[Bug sanitizer/68650] Firefox compilation fails with Address Sanitizer (error: undefined reference to 'dlerror')

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
This smells like -ldl is not being added to the link line when it should be and
that overriding of LDFLAGS causing that.

[Bug sanitizer/68650] Firefox compilation fails with Address Sanitizer (error: undefined reference to 'dlerror')

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
The question is how is the binary linked.
If it uses -static-libasan or not.  If it links dynamically against -lasan,
libasan.so.* should have DT_NEEDED and this shouldn't be an issue.
If it is linking static libasan.a in, then we have libsanitizer.spec for that
to handle it, which has:
*link_libasan: -lrt -lrt -lpthread -ldl -lm
Unless the binary is linked with -nostdlib or something similar, then of course
it would be responsible for handling everything itself.

[Bug target/68648] New: [5/6][ARM] ICE: fail to generate BIC(immediate) instruction

[cctsai57 at gmail dot com]

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

Bug ID: 68648
   Summary: [5/6][ARM] ICE: fail to generate BIC(immediate)
instruction
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cctsai57 at gmail dot com
  Target Milestone: ---

/* ICE if "arm-linux-gnueabihf-gcc -O1". */
extern void abort (void);

int __attribute__((noinline))
foo() { return 123; }

int __attribute__((noinline))
bar()
{
  int c = 1;
  c |= 4294967295 ^ (foo() | 4073709551608);
  return c;
}

int main()
{
  if (bar() != 0x83fd4005) abort();
}


Compiler version: 5.x, 6.0.0


ICE message:
--
$ arm-linux-gnueabihf-gcc -O1 test.c
test.c: In function 'bar':
test.c:13:1: error: unrecognizable insn:
 }
 ^
(insn 27 26 11 2 (set (reg:SI 0 r0 [orig:121 D.4254 ] [121])
(and:SI (not:SI (const_int 1 [0x1]))
(reg:SI 0 r0 [orig:121 D.4254 ] [121]))) test.c:12 -1
 (nil))
test.c:13:1: internal compiler error: in extract_insn, at recog.c:2343
0x8e52e3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/rtl-error.c:110
0x8e5319 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/rtl-error.c:118
0x8b9e19 extract_insn(rtx_insn*)
../../gcc/recog.c:2343
0x8b9e81 extract_insn_cached(rtx_insn*)
../../gcc/recog.c:2234
0x6f6a19 cleanup_subreg_operands(rtx_insn*)
../../gcc/final.c:3137
0x8b82cc split_insn
../../gcc/recog.c:2957
0x8bc191 split_all_insns()
../../gcc/recog.c:3011
0x8bc252 rest_of_handle_split_after_reload
../../gcc/recog.c:3958
0x8bc252 execute
../../gcc/recog.c:3987
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
--


Description:

I think the above (insn 27 ...) should match arm.md:andsi_notsi_si
define_insn pattern but fail because (match_operand 2 ...) does not
accept (const_int 1).

The following patch may fix this problem and generate "bic r0, r0, #0"
successfully.

diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index b380763..0eff5ae 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -2786,7 +2786,7 @@

 (define_insn "andsi_notsi_si"
   [(set (match_operand:SI 0 "s_register_operand" "=r")
-   (and:SI (not:SI (match_operand:SI 2 "s_register_operand" "r"))
+   (and:SI (not:SI (match_operand:SI 2 "reg_or_int_operand" "rI"))
(match_operand:SI 1 "s_register_operand" "r")))]
   "TARGET_32BIT"
   "bic%?\\t%0, %1, %2"

[Bug middle-end/68649] New: note: code may be misoptimized unless -fno-strict-aliasing is used

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 68649
   Summary: note: code may be misoptimized unless
-fno-strict-aliasing is used
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch
  Target Milestone: ---

Today's trunk produces a lot of warnings / notes all referring to functions
from libgfortran, when compiling CP2K with LTO. I'm looking at generating a
reduced testcase, but the first obvious tries didn't work.

/data/vjoost/gnu/cp2k/cp2k/makefiles/../src/dbcsr_lib/dbcsr_block_access_c.F:709:0:
note: ‘_gfortran_reshape_c4’ was previously declared here
  data_block%p(:,:) = RESHAPE (block, (/row_size, col_size/))


/data/vjoost/gnu/cp2k/cp2k/makefiles/../src/dbcsr_lib/dbcsr_block_access_c.F:709:0:
note: code may be misoptimized unless -fno-strict-aliasing is used
/data/vjoost/gnu/cp2k/cp2k/makefiles/../src/helium_methods.F:1071:0: warning:
type of ‘_gfortran_unpack1’ does not match original declaration
[-Wlto-type-mismatch]
 helium%pos(:,:,:) = UNPACK(message(offset+1:offset+msglen), MASK=m,
FIELD=f )


/data/vjoost/gnu/cp2k/cp2k/makefiles/../src/helium_methods.F:1699:0: warning:
type of ‘_gfortran_unpack1’ does not match original declaration
[-Wlto-type-mismatch]
 helium%rho_rstr(:,:,:,:) = UNPACK(message(1:msglen), MASK=m, FIELD=f)


/data/vjoost/gnu/cp2k/cp2k/makefiles/../src/helium_methods.F:1547:0: note:
‘_gfortran_unpack1’ was previously declared here
   ig(:,:) = UNPACK(message(offset+33:offset+38), MASK=m, FIELD=f )


/data/vjoost/gnu/cp2k/cp2k/makefiles/../src/helium_methods.F:1547:0: note: code
may be misoptimized unless -fno-strict-aliasing is used
/data/vjoost/gnu/cp2k/cp2k/makefiles/../src/dbcsr_lib/dbcsr_block_access_s.F:709:0:
warning: type of ‘_gfortran_reshape_r4’ does not match original declaration
[-Wlto-type-mismatch]
  data_block%p(:,:) = RESHAPE (block, (/row_size, col_size/))


/data/vjoost/gnu/cp2k/cp2k/makefiles/../src/dbcsr_lib/dbcsr_block_access_s.F:709:0:
warning: type of ‘_gfortran_reshape_r4’ does not match original declaration
[-Wlto-type-mismatch]

[Bug middle-end/68649] [6 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||Joost.VandeVondele at mat dot 
ethz
   ||.ch
Summary|note: code may be   |[6 Regression] note: code
   |misoptimized unless |may be misoptimized unless
   |-fno-strict-aliasing is |-fno-strict-aliasing is
   |used|used

--- Comment #1 from Joost VandeVondele  
---
testcase

> cat foo.f90 
SUBROUTINE s8(a8,b8)
 REAL*8 :: a8(16),b8(4,4)
 a8=RESHAPE(b8,(/16/))
 b8=RESHAPE(a8,(/4,4/))
END SUBROUTINE
 REAL*8 :: a8(16),b8(4,4)
 CALL RANDOM_NUMBER(b8)
 CALL s8(a8,b8)
 WRITE(6,*) MAXVAL(a8),MAXVAL(b8)
END

> gfortran  -flto -O3 foo.f90 
foo.f90:3:0: warning: type of ‘_gfortran_reshape_r8’ does not match original
declaration [-Wlto-type-mismatch]
  a8=RESHAPE(b8,(/16/))


foo.f90:4:0: note: ‘_gfortran_reshape_r8’ was previously declared here
  b8=RESHAPE(a8,(/4,4/))


foo.f90:4:0: note: code may be misoptimized unless -fno-strict-aliasing is used

[Bug sanitizer/68650] New: Firefox compilation fails with Address Sanitizer (error: undefined reference to 'dlerror')

[gk at torproject dot org]

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

Bug ID: 68650
   Summary: Firefox compilation fails with Address Sanitizer
(error: undefined reference to 'dlerror')
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gk at torproject dot org
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
  Target Milestone: ---

Beginning with r215527 building Firefox with Address Sanitizer enabled fails
with errors like

error: undefined reference to 'dlerror'
error: undefined reference to 'dlsym'

Testing with a clang (e.g. 3.6) including the upstream revision 218156 is
working fine for me.

[Bug ada/68169] s-osinte-rtems.ads is out of synch with type definitions of current newlib

[law at gcc dot gnu.org]

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

--- Comment #1 from Jeffrey A. Law  ---
Author: law
Date: Wed Dec  2 07:09:41 2015
New Revision: 231145

URL: https://gcc.gnu.org/viewcvs?rev=231145=gcc=rev
Log:
[PATCH] Fix declaration of pthread-structs in s-osinte-rtems.ads (ada/68169)

PR ada/68169
* s-oscons-tmplt.c: Generate pthread constants for RTEMS
* s-osinte-rtems.ads: Declare pthread structs as opaque types in Ada

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/s-oscons-tmplt.c
trunk/gcc/ada/s-osinte-rtems.ads

[Bug rtl-optimization/67778] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in maybe_record_trace_start, at dwarf2cfi.c:2297

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
(In reply to Segher Boessenkool from comment #9)
> I cannot reproduce the problem, #c2, not with any flags I tried,
> not with a 20151122 compiler either.  Help?

#c2 testcase, x86_64-linux compiler, -m32 -O2, reproduces this for me reliably.
Say with -mtune=generic -march=i386 (or -march=x86_64, or -march=i686).
-m32 -O3 too.  r231142 reproduces it too.
-m32 -O2 -fno-shrink-wrap does not ICE.  Are you using a cross-compiler from
some other target?

[Bug gcov-profile/68603] [6 Regression] FAIL: g++.dg/gcov/gcov-1.C

[krebbel at gcc dot gnu.org]

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

--- Comment #3 from Andreas Krebbel  ---
Author: krebbel
Date: Wed Dec  2 07:26:30 2015
New Revision: 231146

URL: https://gcc.gnu.org/viewcvs?rev=231146=gcc=rev
Log:
[PR68603] Associate conditional C++ loop's back-jump with start, not body

SVN commit r230979 always associates a loop's back-jump with the start
of the loop body.  This caused a regression for gcov with conditional
loops, because then the loop body appears to be covered twice per
iteration.

2015-12-02  Andreas Arnez  

PR gcov-profile/68603
* cp-gimplify.c (genericize_cp_loop): For the back-jump's location
use the start of the loop body only if the loop is unconditional.


Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c

[Bug c/68533] bogus location for "warning: ‘struct s3’ declared inside parameter list will not be visible outside of this definition or declaration"

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Wed Dec  2 07:33:06 2015
New Revision: 231147

URL: https://gcc.gnu.org/viewcvs?rev=231147=gcc=rev
Log:
PR c/68533
* c-decl.c (get_parm_info): Use b->locus instead of input_location
for diagnostics.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr68533.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/68649] [6 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #3 from Joost VandeVondele  
---
Grepping the list of 'note:' in our build process, it triggers for at least
these functions:

_gfortran_matmul_r8
_gfortran_reshape_4
_gfortran_reshape_c4
_gfortran_reshape_c8
_gfortran_reshape_r4
_gfortran_reshape_r8
_gfortran_unpack1

so it is somewhat general.

[Bug fortran/68600] Inlined MATMUL is too slow.

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
Created attachment 36887
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36887=edit
A faster version

I took the example code found in
http://wiki.cs.utexas.edu/rvdg/HowToOptimizeGemm/ where the register based
vector computations are explicitly called via the SSE registers and converted
it to use the builtin gcc vector extensions.  I had to experiment a little to
get some of the equivalent operations of the original code.

With only -O2 and march=native I am getting good results. I need to roll this
into the other test program yet to confirm the gflops are being computed
correctly.  The diff value is comparing to the reference naive results to check
the computation is correct.

MY_MMult = [
Size: 40, Gflops: 1.828571e+00, Diff: 2.664535e-15 
Size: 80, Gflops: 3.696751e+00, Diff: 7.105427e-15 
Size: 120, Gflops: 4.051583e+00, Diff: 1.065814e-14 
Size: 160, Gflops: 4.015686e+00, Diff: 1.421085e-14 
Size: 200, Gflops: 4.029212e+00, Diff: 2.131628e-14 
Size: 240, Gflops: 3.972414e+00, Diff: 2.486900e-14 
Size: 280, Gflops: 3.881188e+00, Diff: 2.842171e-14 
Size: 320, Gflops: 3.872371e+00, Diff: 3.552714e-14 
Size: 360, Gflops: 3.887676e+00, Diff: 4.973799e-14 
Size: 400, Gflops: 3.862052e+00, Diff: 4.973799e-14 
Size: 440, Gflops: 3.886575e+00, Diff: 4.973799e-14 
Size: 480, Gflops: 3.910124e+00, Diff: 6.039613e-14 
Size: 520, Gflops: 3.863706e+00, Diff: 6.394885e-14 
Size: 560, Gflops: 3.976947e+00, Diff: 6.750156e-14 
Size: 600, Gflops: 4.002631e+00, Diff: 7.460699e-14 
Size: 640, Gflops: 3.992507e+00, Diff: 8.171241e-14 
Size: 680, Gflops: 3.964570e+00, Diff: 9.237056e-14 
Size: 720, Gflops: 3.973661e+00, Diff: 1.101341e-13 
Size: 760, Gflops: 3.982346e+00, Diff: 1.065814e-13 
Size: 800, Gflops: 3.869291e+00, Diff: 8.881784e-14 
Size: 840, Gflops: 3.936271e+00, Diff: 1.065814e-13 
Size: 880, Gflops: 3.931259e+00, Diff: 1.030287e-13 
Size: 920, Gflops: 3.912907e+00, Diff: 1.207923e-13 
Size: 960, Gflops: 3.938391e+00, Diff: 1.278977e-13 
Size: 1000, Gflops: 3.945754e+00, Diff: 1.421085e-13

[Bug target/68647] New: __builtin_popcountll doesn't generate popcnt instructions when targeting -mpopcnt on x86_32

[jamrial at gmail dot com]

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

Bug ID: 68647
   Summary: __builtin_popcountll doesn't generate popcnt
instructions when targeting -mpopcnt on x86_32
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamrial at gmail dot com
  Target Milestone: ---

#include 
int fn (uint64_t a) {
return __builtin_popcountll(a);
}


gcc -O2 -mpopcnt
xor eax, eax
popcnt  rax, rdi
ret


clang -O2 -mpopcnt
popcnt  rax, rdi
ret


gcc -O2 -m32 -mpopcnt
sub esp, 20
pushDWORD PTR [esp+28]
pushDWORD PTR [esp+28]
call__popcountdi2
add esp, 28
ret


clang -O2 -m32 -mpopcnt
popcnt  ecx, dword ptr [esp + 8]
popcnt  eax, dword ptr [esp + 4]
add eax, ecx
ret


Unrelated to this ticket, but GCC should also consider doing like clang and
make the builtins inline the relevant code when the target hardware lacks
support for the popcnt instruction.
I know of at least two projects that provide their own popcount functions
instead of using the builtins when popcnt is not available because the calls to
__popcount[sd]i2 are slow.

[Bug ipa/65654] [6 Regression] 447.dealII in SPEC CPU 2006 failed to build with LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #6 from Jan Hubicka  ---
Hmm, I did not manage to get in the conversion to sreal this stage1 either.  I
may still try for stage3, but this is not very critical.  Since this is just
heuristic bookeeping bug and we do not ICE I would suggest not considering it
as P1.

[Bug c++/68184] [4.9/5/6 Regression] Exception from a virtual function does not get caught

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka  ---
Will take a look. This is ipa-pure-const bug.  We have:

{anonymous}::FooBar::_ZThn8_N12_GLOBAL__N_16FooBar3fooEv (_3);

(i.e. we now devirtualize to call to thunk) and consequently we mark:

Function found to be nothrow: virtual void
{anonymous}::FooBar::_ZThn8_N12_GLOBAL__N_16FooBar3fooEv()

I suppose ipa-pure-const is confused about same body alias wich is used to call
the virtual method.

[Bug other/49401] Warning regression for 'uninitialized' variable on non-existant code path (in mep-pragma.c)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2012-03-05 00:00:00 |2015-12-01
 CC||msebor at gcc dot gnu.org
  Known to work||4.5.3
 Ever confirmed|0   |1
  Known to fail||4.7.0, 4.8.5, 4.9.3, 5.1.0,
   ||6.0

--- Comment #2 from Martin Sebor  ---
Warning confirmed with GCC 4.8.5, 4.9.3, 5.1.0, and the latest trunk on both
x86_64 and powerpc64le (i.e., it's most likely not architecture specific).

GCC 4.5.3 doesn't complain.

The return type of foo() matters, as does the goto statement.

$ cat pr49401.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc
-O2 -S -Wall -Werror -Wextra pr49401.c
extern int foo (void);

int mep_pragma_coprocessor_subclass (int *a)
{
  if (!a)
goto error;

  int rclass;

  int c = foo ();

  if (c >= 0 && c <= 1)
switch (c)
  {
  case 0:
rclass = 0;
break;
  case 1:
rclass = 1;
break;
  }
  else
return 0;

  return a [rclass];

error:
  return 2;
}

[Bug c++/68184] [4.9/5/6 Regression] Exception from a virtual function does not get caught

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #4 from Jan Hubicka  ---
Will take a look

[Bug tree-optimization/68599] [6 Regression] gcc.dg/tree-ssa/pr45122.c and tree-vrp.c

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #2 from Jeffrey A. Law  ---
At first glance this looks like a latent issue in the RTL optimizers.  
Everything looks good coming out of the SSA optimizers.  I wouldn't be
surprised at all to find that this is ultimately -funsafe-loop-optimizations
doing something uber-stupid.

[Bug fortran/38312] Unexpected STATEMENT FUNCTION statement

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

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

--- Comment #10 from Joost VandeVondele  
---
let's go for fixed.

[Bug ada/68590] [6 Regression] FAIL: gnat.dg/loop_optimization19.adb scan-tree-dump-not optimized "Index_Check"

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
(In reply to Eric Botcazou from comment #10)
> > So the original compliant was that if we do that we pessimize code-gen
> > because we un-CSE a possibly large sub-expression.
> 
> Then maybe the "possibly large sub-expression" should be taken into account.
> We already try by means of skip_simple_arithmetic, but it's too simple.
> 
> > So you say that any tree-shared expr is only expanded once (as if it were 
> > wrapped in a save-expr)?
> 
> No, it will be reexpanded if it has no TREE_SIDE_EFFECTS.  What I'm saying
> is that you control it by means of TREE_SIDE_EFFECTS.
> 
> > Oh, so fold is performing CSE here?  Shouldn't _that_ folding not set
> > TREE_SIDE_EFFECTS on the SAVE_EXPR?  Instead of forcing it on every user...
> 
> It's not just fold, it's the way SAVE_EXPR works in GENERIC.  You need to be
> able to control when the variable is initialized at run time, otherwise it's
> a recipe for disaster.

Btw, removing TREE_SIDE_EFFECTS passes bootstrap for all languages but causes
(not double-checked whether they are really caused by the change but they
are new to my eyes):

=== acats tests ===
FAIL:   c64107a
FAIL:   cc3007b

=== g++ tests ===
FAIL: g++.dg/ext/vla9.C  -std=gnu++11 execution test
FAIL: g++.dg/ext/vla9.C  -std=gnu++14 execution test
FAIL: g++.dg/ext/vla9.C  -std=gnu++98 execution test
FAIL: g++.dg/pr58950.C  -std=gnu++11  (test for warnings, line 6)
FAIL: g++.dg/pr58950.C  -std=gnu++11 (test for excess errors)
FAIL: g++.dg/pr58950.C  -std=gnu++14  (test for warnings, line 6)
FAIL: g++.dg/pr58950.C  -std=gnu++14 (test for excess errors)
FAIL: g++.dg/pr58950.C  -std=gnu++98  (test for warnings, line 6)
FAIL: g++.dg/pr58950.C  -std=gnu++98 (test for excess errors)
FAIL: c-c++-common/ubsan/save-expr-3.c   -O0  (test for excess errors)
FAIL: c-c++-common/ubsan/save-expr-3.c   -O1  (test for excess errors)
FAIL: c-c++-common/ubsan/save-expr-3.c   -O2  (test for excess errors)
FAIL: c-c++-common/ubsan/save-expr-3.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
FAIL: c-c++-common/ubsan/save-expr-3.c   -O3 -g  (test for excess errors)
FAIL: c-c++-common/ubsan/save-expr-3.c   -Os  (test for excess errors)
FAIL: c-c++-common/ubsan/save-expr-4.c   -O0  (test for excess errors)
FAIL: c-c++-common/ubsan/save-expr-4.c   -O1  (test for excess errors)
FAIL: c-c++-common/ubsan/save-expr-4.c   -O2  (test for excess errors)
FAIL: c-c++-common/ubsan/save-expr-4.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
FAIL: c-c++-common/ubsan/save-expr-4.c   -O3 -g  (test for excess errors)
FAIL: c-c++-common/ubsan/save-expr-4.c   -Os  (test for excess errors)

=== gcc tests ===
FAIL: gcc.dg/c99-bool-1.c execution test
FAIL: c-c++-common/gomp/atomic-12.c (test for excess errors)
FAIL: c-c++-common/gomp/atomic-13.c (test for excess errors)
FAIL: c-c++-common/ubsan/save-expr-3.c   -O0  (test for excess errors)
FAIL: c-c++-common/ubsan/save-expr-3.c   -O1  (test for excess errors)
FAIL: c-c++-common/ubsan/save-expr-3.c   -O2  (test for excess errors)
FAIL: c-c++-common/ubsan/save-expr-3.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
FAIL: c-c++-common/ubsan/save-expr-3.c   -O3 -g  (test for excess errors)
FAIL: c-c++-common/ubsan/save-expr-3.c   -Os  (test for excess errors)
FAIL: c-c++-common/ubsan/save-expr-4.c   -O0  (test for excess errors)
FAIL: c-c++-common/ubsan/save-expr-4.c   -O1  (test for excess errors)
FAIL: c-c++-common/ubsan/save-expr-4.c   -O2  (test for excess errors)
FAIL: c-c++-common/ubsan/save-expr-4.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
FAIL: c-c++-common/ubsan/save-expr-4.c   -O3 -g  (test for excess errors)
FAIL: c-c++-common/ubsan/save-expr-4.c   -Os  (test for excess errors)

[Bug ada/68590] [6 Regression] FAIL: gnat.dg/loop_optimization19.adb scan-tree-dump-not optimized "Index_Check"

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
Author: rguenth
Date: Tue Dec  1 08:52:58 2015
New Revision: 231100

URL: https://gcc.gnu.org/viewcvs?rev=231100=gcc=rev
Log:
2015-12-01  Richard Biener  

PR middle-end/68590
* match.pd: Merge (eq @0 @0) and (ge/le @0 @0) patterns.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd

[Bug ada/68590] [6 Regression] FAIL: gnat.dg/loop_optimization19.adb scan-tree-dump-not optimized "Index_Check"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/68194] [4.9/5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  ---
*** Bug 68189 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/68189] [4.9/5/6 Regression] wrong code at -Os and above on x86_64-linux-gnu by RTL if-conversion

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #10 from Jakub Jelinek  ---
Dup.

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

[Bug testsuite/68629] New: FAIL: c-c++-common/attr-simd-3.c

[thopre01 at gcc dot gnu.org]

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

Bug ID: 68629
   Summary: FAIL: c-c++-common/attr-simd-3.c
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thopre01 at gcc dot gnu.org
  Target Milestone: ---
Target: arm-none-eabi

Hi,

When cross-compiling forarm-none-eabi targets with current trunk, attr-simd-3.c
fails with:

xgcc: error: unrecognized command line option '-pthread'

The test would not have been run if it was with the other cilk-plus tests in
c-c++-common/cilk-plus where it would be controlled by cilk-plus.exp instead of
dg.exp.

[Bug c++/68630] New: [concepts] internal compiler error: in add_expr, at tree.c:7828

[lucdanton at free dot fr]

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

Bug ID: 68630
   Summary: [concepts] internal compiler error: in add_expr, at
tree.c:7828
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lucdanton at free dot fr
  Target Milestone: ---

Created attachment 36877
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36877=edit
Reduced testcase

Using 6.0.0 20151201 (experimental). The testcase was reduced mechanically,
must be compiled with any level of optimization above -O0 e.g.:

$ g++-trunk -std=c++1z -Og prepro.ii

The stack trace produced is noticeably similar to the one for PR 68116, but not
identical either:

prepro.ii:59:22: internal compiler error: in add_expr, at tree.c:7828
  (l, ::get)(), "", l.i, "");
  ^

0xcb5d5d inchash::add_expr(tree_node const*, inchash::hash&)
../../gcc/gcc/tree.c:7828
0xcb5894 inchash::add_expr(tree_node const*, inchash::hash&)
../../gcc/gcc/tree.c:7801
0x8cf1de iterative_hash_expr
../../gcc/gcc/tree.h:4737
0x8cf1de gimplify_hasher::hash(gimple_temp_hash_elt const*)
../../gcc/gcc/gimplify.c:11535
0x8cf1de hash_table<gimplify_hasher,
xcallocator>::find_slot(gimple_temp_hash_elt* const&, insert_option)
../../gcc/gcc/hash-table.h:408
0x8cf1de lookup_tmp_var
../../gcc/gcc/gimplify.c:523
0x8cf1de internal_get_tmp_var
../../gcc/gcc/gimplify.c:558
0x8cabdc gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:10982
0x8d1e1a gimplify_modify_expr
../../gcc/gcc/gimplify.c:4687
0x8cb2da gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:10057
0x8cb379 gimplify_target_expr
../../gcc/gcc/gimplify.c:5525
0x8cb379 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:10426
0x8cb685 gimplify_addr_expr
../../gcc/gcc/gimplify.c:5053
0x8cb685 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:10103
0x8d05d8 gimplify_call_expr
../../gcc/gcc/gimplify.c:2506
0x8cb86d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:10028
0x8d1e1a gimplify_modify_expr
../../gcc/gcc/gimplify.c:4687
0x8cb2da gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:10057
0x8cb379 gimplify_target_expr
../../gcc/gcc/gimplify.c:5525
0x8cb379 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:10426

[Bug c++/68631] -lstdc++fs switch not working on gcc 5.3.0-RC-20151130

[marqin.pl+gcc at gmail dot com]

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

--- Comment #1 from Hubert Jarosz  ---
Created attachment 36879
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36879=edit
.cpp test file

[Bug c++/68631] New: -lstdc++fs switch not working on gcc 5.3.0-RC-20151130

[marqin.pl+gcc at gmail dot com]

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

Bug ID: 68631
   Summary: -lstdc++fs switch not working on gcc 5.3.0-RC-20151130
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marqin.pl+gcc at gmail dot com
  Target Milestone: ---

Created attachment 36878
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36878=edit
GCC output with -v

-lstdc++fs switch not working on gcc 5.3.0-RC-20151130

I've tried building code example from here:
http://en.cppreference.com/w/cpp/experimental/fs/directory_iterator

with this command line:
/opt/gcc53/bin/g++ -v -std=c++1z  -lstdc++fs -L/opt/gcc53/lib64 test.cpp

And I'm getting errors that are in attached output.txt

Using nm on libstdc++fs.a show that those symbols are there, so it looks like
gcc problem.

[Bug c++/68631] -lstdc++fs switch not working on gcc 5.3.0-RC-20151130

[marqin.pl+gcc at gmail dot com]

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

--- Comment #2 from Hubert Jarosz  ---
This GCC was built with 3 stage bootstraping from tarball posted by Richard
Biener on GCC maillist: https://gcc.gnu.org/ml/gcc/2015-11/msg00210.html

[Bug testsuite/68632] New: FAIL: gcc.target/arm/lto/pr65837 c_lto_pr65837_0.o assemble, -flto -mfpu=neon

[thopre01 at gcc dot gnu.org]

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

Bug ID: 68632
   Summary: FAIL: gcc.target/arm/lto/pr65837 c_lto_pr65837_0.o
assemble, -flto -mfpu=neon
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thopre01 at gcc dot gnu.org
  Target Milestone: ---
Target: arm-none-eabi

Hi,

The patch fixing this PR65837 added a new test in
gcc.target/arm/lto/pr65837_0.c. This test adds -mfpu=neon option but doesn't
require an arm_neon_ok effective target which makes the test fail on ARMv7-M
arm-none-eabi targets.

[Bug tree-optimization/68625] [6 Regression] Segmentation fault in useless_type_conversion_p

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-12-01
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
#1  0x00fccbcd in may_propagate_copy (dest=, 
orig=)
at /space/rguenther/src/svn/trunk3/gcc/tree-ssa-propagate.c:1418
1418  if (!useless_type_conversion_p (type_d, type_o))
(gdb) p debug_tree (orig)
 
$2 = void

after copyprop.  I will have a looksee.

[Bug tree-optimization/68624] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (in 64-bit mode)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-01
   Target Milestone|--- |6.0
Summary|wrong code at -O2 and -O3   |[6 Regression] wrong code
   |on x86_64-linux-gnu (in |at -O2 and -O3 on
   |64-bit mode)|x86_64-linux-gnu (in 64-bit
   ||mode)
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug c++/68631] -lstdc++fs switch not working on gcc 5.3.0-RC-20151130

[marqin.pl+gcc at gmail dot com]

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

--- Comment #3 from Hubert Jarosz  ---
I forgot to mention, it was configured with this option:
../configure --prefix=/opt/gcc53 --enable-languages=c,c++

And here is sha sum, so it's from correct tarball:
c3e2b79419024867df0788a91ef67b758f546e51d17861ca123b874e85cb0952c3faad590b4e7d3a8034258c0cd1dae4b33248ba6278d9ec2df61c87dde20187
 gcc-5.3.0-RC-20151130.tar.gz

[Bug rtl-optimization/67778] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in maybe_record_trace_start, at dwarf2cfi.c:2297

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Seems like shrink-wrapping bug.  On the #c2 -m32 -Os, we have one bb that needs
prologue (the dominator of the exit block with the printf call, bb10).
Infinite loop in BB 6.
Infinite loop in BB 6.
starting the processing of deferred insns
ending the processing of deferred insns
df_analyze called
Attempting shrink-wrapping optimization.
Block 10 needs the prologue.
After wrapping required blocks, PRO is now 10
Avoiding non-duplicatable blocks, PRO is now 10
Bumping back to anticipatable blocks, PRO is now 9
Performing shrink-wrapping.

but, bb9 is part of an irreducible loop, and by moving the prologue into the
bb9, we end up with the prologue in the middle of a loop, which dwarf2cfi is
obviously strongly unhappy about.

So, the
  basic_block last_ok = pro;
  while (pro != entry)
{
  basic_block pre = get_immediate_dominator (CDI_DOMINATORS, pro);
  if (!dominated_by_p (CDI_POST_DOMINATORS, pre, pro))
break;

  pro = pre;
  if (can_get_prologue (pro, prologue_clobbered))
last_ok = pro;
}
  pro = last_ok;
conditions are not sufficient, shall we also test whether pre is not inside of
some loop (loops are freed at this point though)?  Shall it be in this loop, or
in can_get_prologue?

[Bug c++/68631] -lstdc++fs switch not working on gcc 5.3.0-RC-20151130

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
It works for me.

[Bug tree-optimization/68624] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (in 64-bit mode)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Started with r231003.

[Bug c++/68631] -lstdc++fs switch not working on gcc 5.3.0-RC-20151130

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
You may want to use -Wl,--verbose to check which libstdc++fs the linker ends up
using.

[Bug c++/68631] -lstdc++fs switch not working on gcc 5.3.0-RC-20151130

[glisse at gcc dot gnu.org]

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

--- Comment #6 from Marc Glisse  ---
Did you try putting things in the right order on the command line (i.e. -l
flags at the end)?

[Bug tree-optimization/68552] [5/6 Regression]: ICE in in expand_expr_real_2 with -O2 -ftree-vectorize

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug fortran/68598] Ponter Function as LValue

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
Without the requested information, this PR can only be resolved as INVALID.

[Bug c++/68628] New: [concepts] ICE: segmentation fault in crash_signal, toplev.c:334

[lucdanton at free dot fr]

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

Bug ID: 68628
   Summary: [concepts] ICE: segmentation fault in crash_signal,
toplev.c:334
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lucdanton at free dot fr
  Target Milestone: ---

The source program was mechanically reduced.

$ g++-trunk --version
g++-trunk (GCC) 6.0.0 20151130 (experimental)
Copyright (C) 2015 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.

$ cat prepro.ii
template  struct is_convertible;
auto functor = [] {};
void forward();
namespace internal {
template  Type constant;
struct A {
  template  static auto impl();
};
template  struct B : A {
  template 
  auto operator()(F, Args... args) requires
  is_convertible::value;
};
}
using internal::constant;
namespace functors {
using internal::B;
}
template  auto invoke_as = constant;
template  bool Invokable{invoke_as(forward)};
static_assert ( Invokable < decltype ( functor ), int >
$ g++-trunk -std=c++1z prepro.ii
prepro.ii: In instantiation of 'bool Invokable<, int>':
prepro.ii:21:17:   required from here
prepro.ii:12:40: internal compiler error: Segmentation fault
   is_convertible::value;
^

0xab2e5f crash_signal
../../gcc/gcc/toplev.c:334
0x5a61ee resolve_args
../../gcc/gcc/cp/call.c:3956
0x5b0eeb build_new_method_call_1
../../gcc/gcc/cp/call.c:8161
0x5b0eeb build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc/gcc/cp/call.c:8445
0x692ee0 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2360
0x5e9117 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:16451
0x5e9ba8 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:13379
0x5f1d0a tsubst_template_args
../../gcc/gcc/cp/pt.c:11077
0x5f220f tsubst_aggr_type
../../gcc/gcc/cp/pt.c:11274
0x5ea0f3 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:12743
0x5e6774 tsubst_qualified_id
../../gcc/gcc/cp/pt.c:13573
0x5e7531 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:16028
0x5e2b07 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15620
0x6ea5ba satisfy_predicate_constraint
../../gcc/gcc/cp/constraint.cc:1794
0x6ea5ba satisfy_constraint_1
../../gcc/gcc/cp/constraint.cc:1998
0x6eaa86 satisfy_constraint
../../gcc/gcc/cp/constraint.cc:2049
0x6eab67 constraints_satisfied_p(tree_node*)
../../gcc/gcc/cp/constraint.cc:2156
0x5aff95 add_function_candidate
../../gcc/gcc/cp/call.c:1994
0x5b061c add_template_candidate_real
../../gcc/gcc/cp/call.c:3118
0x5b0a23 add_template_candidate
../../gcc/gcc/cp/call.c:3160
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.