[Bug tree-optimization/69989] [6 Regression] ICE on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes (in verify_loop_structure, at cfgloop.c:1639)

[chengniansun at gmail dot com]

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

Chengnian Sun  changed:

   What|Removed |Added

 CC||chengniansun at gmail dot com

--- Comment #6 from Chengnian Sun  ---
Another example with a similar stack trace. 

$: gcc-trunk -w -O3 small.c
small.c: In function ‘fn1’:
small.c:5:6: error: loop verification on loop tree that needs fixup
 void fn1() {
  ^~~
small.c:5:6: internal compiler error: in verify_loop_structure, at
cfgloop.c:1639
0x72f9f7 verify_loop_structure()
../../gcc-source-trunk/gcc/cfgloop.c:1639
0xca037f checking_verify_loop_structure
../../gcc-source-trunk/gcc/cfgloop.h:324
0xca037f tree_transform_and_unroll_loop(loop*, unsigned int, edge_def*,
tree_niter_desc*, void (*)(loop*, void*), void*)
../../gcc-source-trunk/gcc/tree-ssa-loop-manip.c:1362
0xc07819 tree_predictive_commoning_loop
../../gcc-source-trunk/gcc/tree-predcom.c:2530
0xc07819 tree_predictive_commoning()
../../gcc-source-trunk/gcc/tree-predcom.c:2565
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$: 
$: cat small.c
int a, b, d;
short c[] = {4073709551611, 1, 4, 4}

;
void fn1() {
  if (a)
goto LABEL_vhvhP;
  for (;;) {
for (; b; b++)
  d = c[b + 3] | c[b];
  LABEL_vhvhP:
if (d)
  break;
  }
}

int main() { return 0; }

[Bug tree-optimization/69989] [6 Regression] ICE on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes (in verify_loop_structure, at cfgloop.c:1639)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #5 from Jeffrey A. Law  ---
r233754 was reverted.

[Bug libgcc/69998] New: GCC5.3.0 _Unwind_ForcedUnwind Always Abort While pthread_exit

[tcliuqiang at msn dot com]

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

Bug ID: 69998
   Summary: GCC5.3.0 _Unwind_ForcedUnwind Always Abort While
pthread_exit
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tcliuqiang at msn dot com
  Target Milestone: ---

Hello GCC team.

I build the cross toolchain for c,c++ myself (for multiple architectures like
x86, arm, powerpc, mips).  One thing really confuse me for several weeks.
The pthreads can not exit normally instead of abort and the whole program
terminated by the abort.

the example Python3 code:
import threading
def xx():print("hello,world")

th=threading.Thread(target=xx)
th.start()

And the result of running this code in python3 interactive mode:
~ # python3
Python 3.3.5 (default, Feb 27 2016, 19:04:46) 
[GCC 5.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import threading
>>> def xx():print("hello,world")
... 
>>> th=threading.Thread(target=xx)
>>> th.start()
hello,world
>>> Aborted
~ # 
~ # 
And then I get the backtrace from gdb:

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x761a8700 (LWP 133)]
0x76cdd348 in raise () from /lib/libc.so.6
(gdb) bt
#0  0x76cdd348 in raise () from /lib/libc.so.6
#1  0x76cde7ca in abort () from /lib/libc.so.6
#2  0x757a2a57 in uw_init_context_1
(context=context@entry=0x761a7cc0, 
outer_cfa=outer_cfa@entry=0x761a7ef0, outer_ra=0x77766c10
<__pthread_unwind+64>)
at /develop/build/toolchain/src/gcc-5.3.0/libgcc/unwind-dw2.c:1563
#3  0x757a3046 in _Unwind_ForcedUnwind (exc=0x761a8d70,
stop=0x77766a90 , 
stop_argument=0x761a7f70) at
/develop/build/toolchain/src/gcc-5.3.0/libgcc/unwind.inc:201
#4  0x77766c10 in __pthread_unwind () from /lib/libpthread.so.0
#5  0x7775f525 in pthread_exit () from /lib/libpthread.so.0
#6  0x77aa614f in PyThread_exit_thread () at
Python/thread_pthread.h:266
#7  0x77aaa766 in t_bootstrap (boot_raw=0x700380) at
./Modules/_threadmodule.c:1023
#8  0x7775e3e4 in start_thread () from /lib/libpthread.so.0
#9  0x76d9179d in clone () from /lib/libc.so.6

I check the libgcc code, and can not find anything useful.

THE SAME THING happened for GCC4.9.2/4.9.3 WHICH I TESTED.

uw_init_context_1 (struct _Unwind_Context *context,
   void *outer_cfa, void *outer_ra)
{
  void *ra = __builtin_extract_return_addr (__builtin_return_address (0));
  _Unwind_FrameState fs;
  _Unwind_SpTmp sp_slot;
  _Unwind_Reason_Code code;

  memset (context, 0, sizeof (struct _Unwind_Context));
  context->ra = ra;
  if (!ASSUME_EXTENDED_UNWIND_CONTEXT)
context->flags = EXTENDED_CONTEXT_BIT;

  code = uw_frame_state_for (context, );  
  gcc_assert (code == _URC_NO_REASON);


The followed is cross compiler info:
work:Project$ x86_64-linux-gcc -v -save-temps test.c -o /develop/tmp/test/test
使用内建 specs。
COLLECT_GCC=x86_64-linux-gcc
COLLECT_LTO_WRAPPER=/develop/build/toolchain/release/x86_64_gcc5.3.0_glibc2.23/libexec/gcc/x86_64-ltriangle-linux-gnu/5.3.0/lto-wrapper
目标：x86_64-ltriangle-linux-gnu
配置为：/develop/build/toolchain/src/gcc-5.3.0/configure
--target=x86_64-ltriangle-linux-gnu
--prefix=/develop/build/toolchain/release/x86_64_gcc5.3.0_glibc2.23 CFLAGS=-O2
CXXFLAGS=-O2 --enable-languages=c,c++ --disable-multilib
--with-bugurl=tcliuqi...@gmail.com --enable-__cxa_atexit --enable-threads=posix
--enable-nls --enable-c99 --with-gnu-as --with-gnu-ld --enable-shared
--enable-checking=release --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-tune=generic --with-arch_32=i686
线程模型：posix
gcc 版本 5.3.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' '/develop/tmp/test/test'
'-mtune=generic' '-march=x86-64'

/develop/build/toolchain/release/x86_64_gcc5.3.0_glibc2.23/libexec/gcc/x86_64-ltriangle-linux-gnu/5.3.0/cc1
-E -quiet -v test.c -mtune=generic -march=x86-64 -fpch-preprocess -o test.i
忽略不存在的目录“/develop/build/toolchain/release/x86_64_gcc5.3.0_glibc2.23/lib/gcc/x86_64-ltriangle-linux-gnu/5.3.0/../../../../x86_64-ltriangle-linux-gnu/sys-include”
#include "..." 搜索从这里开始：
#include <...> 搜索从这里开始：

/develop/build/toolchain/release/x86_64_gcc5.3.0_glibc2.23/lib/gcc/x86_64-ltriangle-linux-gnu/5.3.0/include

/develop/build/toolchain/release/x86_64_gcc5.3.0_glibc2.23/lib/gcc/x86_64-ltriangle-linux-gnu/5.3.0/include-fixed

/develop/build/toolchain/release/x86_64_gcc5.3.0_glibc2.23/lib/gcc/x86_64-ltriangle-linux-gnu/5.3.0/../../../../x86_64-ltriangle-linux-gnu/include
搜索列表结束。
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' '/develop/tmp/test/test'
'-mtune=generic' '-march=x86-64'

[Bug libgcc/69997] New: GCC5.3.0 _Unwind_ForcedUnwind Always Abort While pthread_exit

[tcliuqiang at msn dot com]

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

Bug ID: 69997
   Summary: GCC5.3.0 _Unwind_ForcedUnwind Always Abort While
pthread_exit
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tcliuqiang at msn dot com
  Target Milestone: ---

Hello the GCC team.

I build the cross toolchain for c,c++ myself (for multiple architectures like
x86, arm, powerpc, mips).  One thing really confuse me for several weeks.
The pthreads can not exit normally instead of abort and the whole program
terminated by the abort.

the example Python3 code:
import threading
def xx():print("hello,world")

th=threading.Thread(target=xx)
th.start()

And the result of running this code in python3 interactive mode:
~ # python3
Python 3.3.5 (default, Feb 27 2016, 19:04:46) 
[GCC 5.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import threading
>>> def xx():print("hello,world")
... 
>>> th=threading.Thread(target=xx)
>>> th.start()
hello,world
>>> Aborted
~ # 
~ # 
And then I get the backtrace from gdb:

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x761a8700 (LWP 133)]
0x76cdd348 in raise () from /lib/libc.so.6
(gdb) bt
#0  0x76cdd348 in raise () from /lib/libc.so.6
#1  0x76cde7ca in abort () from /lib/libc.so.6
#2  0x757a2a57 in uw_init_context_1
(context=context@entry=0x761a7cc0, 
outer_cfa=outer_cfa@entry=0x761a7ef0, outer_ra=0x77766c10
<__pthread_unwind+64>)
at /develop/build/toolchain/src/gcc-5.3.0/libgcc/unwind-dw2.c:1563
#3  0x757a3046 in _Unwind_ForcedUnwind (exc=0x761a8d70,
stop=0x77766a90 , 
stop_argument=0x761a7f70) at
/develop/build/toolchain/src/gcc-5.3.0/libgcc/unwind.inc:201
#4  0x77766c10 in __pthread_unwind () from /lib/libpthread.so.0
#5  0x7775f525 in pthread_exit () from /lib/libpthread.so.0
#6  0x77aa614f in PyThread_exit_thread () at
Python/thread_pthread.h:266
#7  0x77aaa766 in t_bootstrap (boot_raw=0x700380) at
./Modules/_threadmodule.c:1023
#8  0x7775e3e4 in start_thread () from /lib/libpthread.so.0
#9  0x76d9179d in clone () from /lib/libc.so.6

I check the libgcc code, and can not find anything useful.

THE SAME THING happened for GCC4.9.2/4.9.3 WHICH I TESTED.

uw_init_context_1 (struct _Unwind_Context *context,
   void *outer_cfa, void *outer_ra)
{
  void *ra = __builtin_extract_return_addr (__builtin_return_address (0));
  _Unwind_FrameState fs;
  _Unwind_SpTmp sp_slot;
  _Unwind_Reason_Code code;

  memset (context, 0, sizeof (struct _Unwind_Context));
  context->ra = ra;
  if (!ASSUME_EXTENDED_UNWIND_CONTEXT)
context->flags = EXTENDED_CONTEXT_BIT;

  code = uw_frame_state_for (context, );  
  gcc_assert (code == _URC_NO_REASON);


The followed is cross compiler info:
work:Project$ x86_64-linux-gcc -v -save-temps test.c -o /develop/tmp/test/test
使用内建 specs。
COLLECT_GCC=x86_64-linux-gcc
COLLECT_LTO_WRAPPER=/develop/build/toolchain/release/x86_64_gcc5.3.0_glibc2.23/libexec/gcc/x86_64-ltriangle-linux-gnu/5.3.0/lto-wrapper
目标：x86_64-ltriangle-linux-gnu
配置为：/develop/build/toolchain/src/gcc-5.3.0/configure
--target=x86_64-ltriangle-linux-gnu
--prefix=/develop/build/toolchain/release/x86_64_gcc5.3.0_glibc2.23 CFLAGS=-O2
CXXFLAGS=-O2 --enable-languages=c,c++ --disable-multilib
--with-bugurl=tcliuqi...@gmail.com --enable-__cxa_atexit --enable-threads=posix
--enable-nls --enable-c99 --with-gnu-as --with-gnu-ld --enable-shared
--enable-checking=release --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-tune=generic --with-arch_32=i686
线程模型：posix
gcc 版本 5.3.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' '/develop/tmp/test/test'
'-mtune=generic' '-march=x86-64'

/develop/build/toolchain/release/x86_64_gcc5.3.0_glibc2.23/libexec/gcc/x86_64-ltriangle-linux-gnu/5.3.0/cc1
-E -quiet -v test.c -mtune=generic -march=x86-64 -fpch-preprocess -o test.i
忽略不存在的目录“/develop/build/toolchain/release/x86_64_gcc5.3.0_glibc2.23/lib/gcc/x86_64-ltriangle-linux-gnu/5.3.0/../../../../x86_64-ltriangle-linux-gnu/sys-include”
#include "..." 搜索从这里开始：
#include <...> 搜索从这里开始：

/develop/build/toolchain/release/x86_64_gcc5.3.0_glibc2.23/lib/gcc/x86_64-ltriangle-linux-gnu/5.3.0/include

/develop/build/toolchain/release/x86_64_gcc5.3.0_glibc2.23/lib/gcc/x86_64-ltriangle-linux-gnu/5.3.0/include-fixed

/develop/build/toolchain/release/x86_64_gcc5.3.0_glibc2.23/lib/gcc/x86_64-ltriangle-linux-gnu/5.3.0/../../../../x86_64-ltriangle-linux-gnu/include
搜索列表结束。
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' '/develop/tmp/test/test'
'-mtune=generic' '-march=x86-64'

[Bug fortran/61156] [4.9/5/6 Regression] Internal compiler error for Fortran files when specifying a file instead of an include directory with -I

[jvdelisle at gcc dot gnu.org]

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

--- Comment #11 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Feb 28 06:50:27 2016
New Revision: 233789

URL: https://gcc.gnu.org/viewcvs?rev=233789=gcc=rev
Log:
2016-02-27  Jerry DeLisle  

Backported from mainline
PR fortran/61156
* scanner.c (add_path_to_list): If include path is not a directory,
issue a fatal error.

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

Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/scanner.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/include_6.f90

[Bug tree-optimization/69740] [5/6 Regression] gcc ICE at -O2 and above on valid code on x86_64-linux-gnu in "verify_loop_structure"

[law at gcc dot gnu.org]

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

--- Comment #11 from Jeffrey A. Law  ---
Author: law
Date: Sun Feb 28 06:43:07 2016
New Revision: 233788

URL: https://gcc.gnu.org/viewcvs?rev=233788=gcc=rev
Log:


Revert
2016-02-26  Richard Biener  
Jeff Law  

Backport from mainline
2016-02-26  Richard Biener  
Jeff Law  

PR tree-optimization/69740
* cfghooks.c (remove_edge): Request loop fixups if we delete
an edge that might turn an irreducible loop into a natural
loop.


Revert
2016-02-26  Richard Biener  
Jeff Law  

Backport from mainline
2016-02-26  Richard Biener  
Jeff Law  

PR tree-optimization/69740
* gcc.c-torture/compile/pr69740-1.c: New test.
* gcc.c-torture/compile/pr69740-2.c: New test.

2016-02-26  Richard Biener  

Removed:
branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/compile/pr69740-1.c
branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/compile/pr69740-2.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/cfghooks.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/69740] [5/6 Regression] gcc ICE at -O2 and above on valid code on x86_64-linux-gnu in "verify_loop_structure"

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=69989
 Resolution|FIXED   |---
Summary|[5 Regression] gcc ICE at   |[5/6 Regression] gcc ICE at
   |-O2 and above on valid code |-O2 and above on valid code
   |on x86_64-linux-gnu in  |on x86_64-linux-gnu in
   |"verify_loop_structure" |"verify_loop_structure"

--- Comment #10 from Jeffrey A. Law  ---
Patch reverted from trunk and gcc-5 branch, re-opened.

[Bug tree-optimization/69740] [5 Regression] gcc ICE at -O2 and above on valid code on x86_64-linux-gnu in "verify_loop_structure"

[law at gcc dot gnu.org]

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

--- Comment #9 from Jeffrey A. Law  ---
Author: law
Date: Sun Feb 28 06:34:20 2016
New Revision: 233787

URL: https://gcc.gnu.org/viewcvs?rev=233787=gcc=rev
Log:
Revert
2016-02-26  Richard Biener  
Jeff Law  

PR tree-optimization/69740
* cfghooks.c (remove_edge): Request loop fixups if we delete
an edge that might turn an irreducible loop into a natural
loop.

Revert
2016-02-26  Richard Biener  
Jeff Law  

PR tree-optimization/69740
* gcc.c-torture/compile/pr69740-1.c: New test.
* gcc.c-torture/compile/pr69740-2.c: New test.

Removed:
trunk/gcc/testsuite/gcc.c-torture/compile/pr69740-1.c
trunk/gcc/testsuite/gcc.c-torture/compile/pr69740-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfghooks.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/69989] [6 Regression] ICE on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes (in verify_loop_structure, at cfgloop.c:1639)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #4 from Jeffrey A. Law  ---
*** Bug 69987 has been marked as a duplicate of this bug. ***

[Bug middle-end/69987] [6 Regression] internal compiler error: in verify_loop_structure, at cfgloop.c:1639

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #3 from Jeffrey A. Law  ---
Essentially a duplicate of 69989, loop optimizer deletes an edge in an
irreducible region, we schedule loop fixups, and we hit an explicit call to
verify_loop_structure before fixing up the loops.

This one hits from a different part of the loop optimizer, but it's essentially
the same bug as 69989.

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

[Bug fortran/69456] Namelist value with trailing sign is ignored without error

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #9 from Jerry DeLisle  ---
Fixed on trunk. Closing

[Bug fortran/56744] [meta-bug] Namelist bugs

[jvdelisle at gcc dot gnu.org]

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

Bug 69456 Summary: Namelist value with trailing sign is ignored without error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69456

   What|Removed |Added

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

[Bug fortran/69910] ICE with NEWUNIT

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #8 from Jerry DeLisle  ---
Fixed on trunk. Closing

[Bug tree-optimization/69989] [6 Regression] ICE on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes (in verify_loop_structure, at cfgloop.c:1639)

[law at redhat dot com]

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

--- Comment #3 from Jeffrey A. Law  ---
WRT fallout and reverting on the gcc-5 branch.  Based on what I'm seeing, that
may make sense.

The problem in this particular case is we've marked loops for fixup, then loop
distribution is explicitly calling checking_verify_loop_structure.

checking_verify_loop_structure will assert that loops do not need fixup, and of
course, that assertion fails.  There's at least a half-dozen of these explicit
calls that can fail in a similar manner.

I'm going to poke a bit, but my inclination is to pull the patch from the trunk
and the branch.

[Bug tree-optimization/69989] [6 Regression] ICE on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes (in verify_loop_structure, at cfgloop.c:1639)

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #2 from H.J. Lu  ---
*** Bug 69996 has been marked as a duplicate of this bug. ***

[Bug middle-end/69996] [6 Regression] 186.crafty in SPEC CPU 2000 failed to build

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #2 from H.J. Lu  ---
Dup.

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

[Bug middle-end/69996] [6 Regression] 186.crafty in SPEC CPU 2000 failed to build

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-28
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
This may be a dup of PR 69989.

[Bug middle-end/69996] New: [6 Regression] 186.crafty in SPEC CPU 2006 failed to build

[hjl.tools at gmail dot com]

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

Bug ID: 69996
   Summary: [6 Regression] 186.crafty in SPEC CPU 2006 failed to
build
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: law at gcc dot gnu.org
  Target Milestone: ---

On x86, r233754 caused that 186.crafty in SPEC CPU 2006 failed to build:

gcc -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver
-fuse-linker-plugin -DSPEC_CPU2000_LP64 searchr.o search.o repeat.o next.o
nextr.o history.o nexte.o quiesce.o evaluate.o movgen.o make.o unmake.o
lookup.o store.o attacks.o swap.o boolean.o draw.o utility.o valid.o drawn.o
edit.o enprise.o init.o input.o interupt.o iterate.o main.o option.o output.o
phase.o ponder.o preeval.o root.o setboard.o time.o validate.o   -lm  -o crafty
option.c: In function 'Option':
option.c:2772:7: warning: implicit declaration of function 'gets'
[-Wimplicit-function-declaration]
   gets(buffer);
   ^~~~
make[4]: warning: jobserver unavailable: using -j1.  Add '+' to parent make
rule.
main.c: In function 'main':
main.c:1881:5: error: loop verification on loop tree that needs fixup
 int main(int argc, char **argv)
 ^
main.c:1881:5: internal compiler error: in verify_loop_structure, at
cfgloop.c:1639
0x64c97f verify_loop_structure()
../../src-trunk/gcc/cfgloop.c:1639
0xad8b0e checking_verify_loop_structure
../../src-trunk/gcc/cfgloop.h:324
0xad8b0e execute
../../src-trunk/gcc/tree-loop-distribution.c:1818
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[4]: *** [/tmp/ccmCWG8m.ltrans4.ltrans.o] Error 1
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/local/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
specmake[3]: *** [crafty] Error 1

[Bug libstdc++/69081] forward_list::splice_after does not handle the case of first<=last properly

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
No response, closing because the example is not expected to work.

[Bug c++/69995] New: [C++14] Invalid result when evaluating constexpr function

[ldionne.2 at gmail dot com]

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

Bug ID: 69995
   Summary: [C++14] Invalid result when evaluating constexpr
function
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ldionne.2 at gmail dot com
  Target Milestone: ---

The following code triggers a runtime assertion:

--
#include 

#define CONSTEXPR constexpr

template 
struct array {
T elems_[Size];

constexpr T const& operator[](unsigned long n) const
{ return elems_[n]; }

constexpr T& operator[](unsigned long n)
{ return elems_[n]; }
};

template 
CONSTEXPR void my_swap(T& a, T& b) {
T tmp = a;
a = b;
b = tmp;
}

CONSTEXPR auto rotate2() {
array, 2> result{};
array a{{0, 1}};

result[0] = a;
my_swap(a[0], a[1]);
result[1] = a;

return result;
}

int main() {
CONSTEXPR auto indices = rotate2();
assert(indices[0][0] == 0);
assert(indices[0][1] == 1);
assert(indices[1][0] == 1);
assert(indices[1][1] == 0);
}
--

The fun thing is that #defining CONSTEXPR to nothing makes the code work again.
So GCC's constexpr evaluation seems to be broken in this case, in a way that
can lead to _runtime_ errors.

Live example: http://melpon.org/wandbox/permlink/PPpwDHbk5tYVlNWI

[Bug fortran/69910] ICE with NEWUNIT

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sat Feb 27 19:07:13 2016
New Revision: 233782

URL: https://gcc.gnu.org/viewcvs?rev=233782=gcc=rev
Log:
2016-02-27  Jerry DeLisle  
Steven G. Kargl  

PR fortran/69910
* io.c (gfc_match_open): Check that open status is an expression
constant before comparing string to 'scratch' with NEWUNIT.

* gfortran.dg/newunit_4.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/newunit_4.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/io.c
trunk/gcc/testsuite/ChangeLog

[Bug target/69988] libgo.so: undefined reference to `__unorddf2'

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #4 from John Paul Adrian Glaubitz  ---
Hmm, the symbol is present in the glibc I used:

root@atlantis:/srv/sid-powerpcspe-sbuild/lib/powerpc-linux-gnuspe# objdump -T
libgcc_s.so.1 |grep unorddf2
00010a78 gDF .text  0088  GCC_3.3.4   __unorddf2
root@atlantis:/srv/sid-powerpcspe-sbuild/lib/powerpc-linux-gnuspe#

[Bug target/69988] libgo.so: undefined reference to `__unorddf2'

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #3 from John Paul Adrian Glaubitz  ---
Looking at the source code, I found this:

ppc_fp_compat=
case ${ppc_fp_type} in
soft|e500v1|e500v2)
  if test $glibc_version_major -gt 2 \
|| ( test $glibc_version_major -eq 2 \
&& test $glibc_version_minor -ge 19 ); then
ppc_fp_compat="t-softfp-compat"
  fi
  ;;
esac
;;
esac

Which apparently originates here:

> https://patchwork.ozlabs.org/patch/405072/

So, it seems that gcc-5 is relying on glibc for providing the softfloat
functions and those are particularly not present in static libgcc.

The chroot I used for building gcc-5 uses glibc_2.19, so that should be recent
enough. Will try disabling the above code and see what happens.

[Bug target/69988] libgo.so: undefined reference to `__unorddf2'

[glaubitz at physik dot fu-berlin.de]

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

John Paul Adrian Glaubitz  changed:

   What|Removed |Added

Version|5.2.1   |5.3.1

--- Comment #2 from John Paul Adrian Glaubitz  ---
I have now verified the problem affects 5.3.1 (SVN rr233687) as well.

/bin/bash ./libtool --tag=GCJ   --mode=compile /«PKGBUILDDIR»/build/./gcc/gcj
-B/«PKGBUILDDIR»/build/powerpc-linux-gnuspe/libjava/
-B/«PKGBUILDDIR»/build/./gcc/
 -B/usr/powerpc-linux-gnuspe/bin/ -B/usr/powerpc-linux-gnuspe/lib/ -isystem
/usr/powerpc-linux-gnuspe/include -isystem
/usr/powerpc-linux-gnuspe/sys-include -isystem /«PKGBUILDDIR»/build/sys-include
   -fclasspath= -fbootclasspath=../../../src/libjava/classpath/lib
--encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2  -c -o
gnu/javax/crypto/key/srp6.lo
-fsource-filename=/«PKGBUILDDIR»/build/powerpc-linux-gnuspe/libjava/classpath/lib/classes
-MT gnu/javax/crypto/key/srp6.lo -MD -MP -MF gnu/javax/crypto/key/srp6.deps
@gnu/javax/crypto/key/srp6.list
libtool: compile:  /«PKGBUILDDIR»/build/./gcc/gcj
-B/«PKGBUILDDIR»/build/powerpc-linux-gnuspe/libjava/
-B/«PKGBUILDDIR»/build/./gcc/ -B/usr/powerpc-linux-gnuspe/bin/
-B/usr/powerpc-linux-gnuspe/lib/ -isystem /usr/powerpc-linux-gnuspe/include
-isystem /usr/powerpc-linux-gnuspe/sys-include -isystem
/«PKGBUILDDIR»/build/sys-include -fclasspath=
-fbootclasspath=../../../src/libjava/classpath/lib --encoding=UTF-8
-Wno-deprecated -fbootstrap-classes -g -O2 -c
-fsource-filename=/«PKGBUILDDIR»/build/powerpc-linux-gnuspe/libjava/classpath/lib/classes
-MT gnu/javax/crypto/key/srp6.lo -MD -MP -MF gnu/javax/crypto/key/srp6.deps
@gnu/javax/crypto/key/srp6.list  -fPIC -o gnu/javax/crypto/key/.libs/srp6.o
../powerpc-linux-gnuspe/libgo/.libs/libgo.so: undefined reference to
`__unorddf2'
collect2: error: ld returned 1 exit status
Makefile:629: recipe for target 'gofmt' failed
make[4]: *** [gofmt] Error 1

I assume that libgcc/soft-fp/unorddf2.c is not included in libgcc, so most
likely just an issue with the Makefile, I guess.

[Bug tree-optimization/69110] [4.9/5/6 Regression] execution failure in gcc.c-torture/execute/doloop-{1,2}.c with -ftree-parallelize-loops=2

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #24 from Jerry DeLisle  ---
(In reply to Jerry DeLisle from comment #23)
> Author: jvdelisle
> Date: Sat Feb 27 19:07:13 2016
> New Revision: 233782
> 
> URL: https://gcc.gnu.org/viewcvs?rev=233782=gcc=rev
> Log:
> 2016-02-27  Jerry DeLisle  
>   Steven G. Kargl  
> 
>   PR fortran/69110
>   * io.c (gfc_match_open): Check that open status is an expression
>   constant before comparing string to 'scratch' with NEWUNIT.
> 
>   * gfortran.dg/newunit_4.f90: New test.
> 
> Added:
> trunk/gcc/testsuite/gfortran.dg/newunit_4.f90
> Modified:
> trunk/gcc/fortran/ChangeLog
> trunk/gcc/fortran/io.c
> trunk/gcc/testsuite/ChangeLog

Should have been PR69910

[Bug target/69994] New: [6 regression] test case gfortran.dg/reassoc_6.f fails starting with r233669

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 69994
   Summary: [6 regression] test case gfortran.dg/reassoc_6.f fails
starting with r233669
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

FAIL: gfortran.dg/reassoc_6.f   -O   scan-tree-dump-not optimized "~"

=== gfortran Summary ===

# of expected passes1
# of unexpected failures1
/home/seurer/gcc/build/gcc-test3/gcc/testsuite/gfortran/../../gfortran  version
6.0.0 20160224 (experimental) [trunk revision 233669] (GCC) 

This fails on both BE and LE.

This does not fail on x86.

[Bug c++/67164] ICE: tree check: expected class ‘expression’, have ‘exceptional’ (argument_pack_select) in tree_operand_check, at tree.h:3356

[ldionne.2 at gmail dot com]

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

--- Comment #6 from Louis Dionne  ---
The code I posted above does not seem to trigger the bug anymore on GCC trunk. 
However, the following code still produces an ICE on trunk:

> ~/code/gcc/prefix/bin/g++ --version
> g++ (GCC) 6.0.0 20160226 (experimental)

--
#include 

namespace detail {
template 
struct fast_and
: std::is_same>
{ };
}

template 
struct tuple {
tuple() { }

template ::value...>::value
>::type>
tuple(Yn&& ...yn) { }

template ::value...>::value
>::type>
tuple(tuple const& other) { }
};

tuple> t{};
tuple> copy = t;
--

[Bug c/69993] Misleading wording for -Wmisleading-indentation

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
(In reply to David Malcolm from comment #1)
> which suggests reversing the order of the messages, so that they appear in
> source order.

That seems a nice property. What about?

sslKeyExchange.c:629:4: warning: this 'if' clause does not guard...
[-Wmisleading-indentation]
 if ((err = SSLHashSHA1.update(, )) != 0)
 ^~
 sslKeyExchange.c:631:8: note: ...this statement, but indentation suggests
otherwise
 goto fail;
 ^~~~

[Bug tree-optimization/69110] [4.9/5/6 Regression] execution failure in gcc.c-torture/execute/doloop-{1,2}.c with -ftree-parallelize-loops=2

[jvdelisle at gcc dot gnu.org]

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

--- Comment #23 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sat Feb 27 19:07:13 2016
New Revision: 233782

URL: https://gcc.gnu.org/viewcvs?rev=233782=gcc=rev
Log:
2016-02-27  Jerry DeLisle  
Steven G. Kargl  

PR fortran/69110
* io.c (gfc_match_open): Check that open status is an expression
constant before comparing string to 'scratch' with NEWUNIT.

* gfortran.dg/newunit_4.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/newunit_4.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/io.c
trunk/gcc/testsuite/ChangeLog

[Bug c/69985] [6 Regression] ICE: in linemap_position_for_loc_and_offset, at libcpp/line-map.c:924

[manu at gcc dot gnu.org]

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

--- Comment #11 from Manuel López-Ibáñez  ---
(In reply to Markus Trippelsdorf from comment #6)
> Bingo! With both files present I can even reproduce it on my x86_64 machine.

Unfortunately, I cannot reproduce it with r230753, so it seems quite a recent
regression. (something is broken in the machine of the compile farm that I use
for development and I cannot build a more recent GCC).

If you want to investigate further, add a breakpoint just before calling 
linemap_position_for_loc_and_offset(), figure out if the arguments passed make
sense and if they do, why the corresponding assert is triggering.

The assert triggering is one of these two:

  if (linemap_assert_fails (r <= set->highest_location)
  || linemap_assert_fails (map == linemap_lookup (set, r)))

This may be because the line-tables are somehow messed up, the offset we passed
was larger than it should be or because we think that r should be encoded in
map "map", but somehow this is wrong. The function tries to account for these
cases, but perhaps I missed some corner-case.

It should also be possible to minimize the original .c file by removing headers
and stuff, but probably the bug depends a lot on the line-table structure,
which is quite sensitive to the locations of what is parsed. Nonetheless, some
automatic tool may be able to produce another smaller reproducer
(https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction).

In any case, this should only happen with checking enabled, since the assert is
disabled otherwise. (The assert is there mostly to catch QOI issues, thus it is
harmless to disable it in release builds).

BTW, this code should not even be reached with "-w", since that disables all
warnings, and this code is only used to print precise columns numbers in
warnings. Does not using -Wall at all trigger the bug also?

[Bug c/69985] [6 Regression] ICE: in linemap_position_for_loc_and_offset, at libcpp/line-map.c:924

[manu at gcc dot gnu.org]

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

--- Comment #10 from Manuel López-Ibáñez  ---
(In reply to Jakub Jelinek from comment #8)
> Note that this first started to ICE with r223470, which is also the first
> revision where it starts opening cmds-check.c (which also premature to me,
> because no warning is actually emitted; I'd think that it should do that
> only if the warning is actually going to be emitted and needs it, otherwise
> it is an unnecessary compile time slowdown); that ICE got later fixed in
> r224236, but later reappeared (in r230331).

I also don't think this is the same ICE that Marek fixed. It is likely that
David's changes altered something in the way the line-table is constructed and
this uncovered a different latent bug.

[Bug c/69985] [6 Regression] ICE: in linemap_position_for_loc_and_offset, at libcpp/line-map.c:924

[manu at gcc dot gnu.org]

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

--- Comment #9 from Manuel López-Ibáñez  ---
(In reply to Jakub Jelinek from comment #8)
> Note that this first started to ICE with r223470, which is also the first
> revision where it starts opening cmds-check.c (which also premature to me,
> because no warning is actually emitted; I'd think that it should do that
> only if the warning is actually going to be emitted and needs it, otherwise
> it is an unnecessary compile time slowdown); that ICE got later fixed in
> r224236, but later reappeared (in r230331).

I added the linemap_assert_fails to catch QOI issues with this function, that
is, cases where we should return the correct offset but we don't for some
reason. This is why it is not enabled in release mode. Since nobody seems to
have time or interest to fix these QOI issues, a better approach than removing
the asserts completely would be to replace linemap_assert_fails with some
equivalent macro which only enables the asserts if explicitly requested. This
way, if someone someday decides to improve the offsets, they could re-enable
the asserts and see which of the cases where we give up because something went
wrong is the one triggering.

Most code in c-format.c is only necessary if -Wformat is enabled, but it is run
nevertheless. Note also that -w only disables printing the warning text quite
late in the diagnostics machinery, it doesn't change the value of any warning
option.

[Bug c/69993] Misleading wording for -Wmisleading-indentation

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
There's an alternate suggestion here:
https://www.reddit.com/r/programming/comments/47pejg/gcc_6_wmisleadingindentation_vs_goto_fail/d0eqyih

> This is just passive voice, there is nothing tricky about it.
> What I find more confusing -- and what your fix preserves -- is the
> reversed order of offending lines of code in the source file and the message.
> 
> I'd rather go with something like this:
> sslKeyExchange.c:629:4: warning: indentation of a statement below this 'if' 
> clause... [-Wmisleading-indentation]
> if ((err = SSLHashSHA1.update(, )) != 0)
> ^~
> sslKeyExchange.c:631:8: note: ...suggests it is guarded by the 'if' clause, 
> but it's not
> goto fail;
> ^~~~
> You can even see how the indentation is wrong in the very error message.

which suggests reversing the order of the messages, so that they appear in
source order.

[Bug c/69985] [6 Regression] ICE: in linemap_position_for_loc_and_offset, at libcpp/line-map.c:924

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Note that this first started to ICE with r223470, which is also the first
revision where it starts opening cmds-check.c (which also premature to me,
because no warning is actually emitted; I'd think that it should do that only
if the warning is actually going to be emitted and needs it, otherwise it is an
unnecessary compile time slowdown); that ICE got later fixed in r224236, but
later reappeared (in r230331).

[Bug c/69993] New: Misleading wording for -Wmisleading-indentation

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 69993
   Summary: Misleading wording for -Wmisleading-indentation
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Reddit user "sysop073" observed here:

https://www.reddit.com/r/programming/comments/47pejg/gcc_6_wmisleadingindentation_vs_goto_fail/d0eonwd

that the wording of -Wmisleading-indentation is rather confusing:

> The way they split up the warning looks designed to trick you.
> sslKeyExchange.c:631:8: warning: statement is indented as if it were guarded 
> by... [-Wmisleading-indentation]
> goto fail;
> ^~~~
> sslKeyExchange.c:629:4: note: ...this 'if' clause, but it is not
> if ((err = SSLHashSHA1.update(, )) != 0)
> ^~
> You read the first half and it sounds like goto fail; is guarding something. 
> Why would it not be:
> sslKeyExchange.c:631:8: warning: statement is wrongly indented... 
> [-Wmisleading-indentation]
> goto fail;
> ^~~~
> sslKeyExchange.c:629:4: note: ...as if it were guarded by this 'if' clause
> if ((err = SSLHashSHA1.update(, )) != 0)
> ^~

I agree that the current wording is suboptimal.

I think the wording would be much clearer if the wording of the "warning" only
spoke about the statement in question, and the "note"/inform should then talk
about the not-really-guarding guard.

I think my preferred wording would be:

sslKeyExchange.c:631:8: warning: statement is misleadingly indented...
[-Wmisleading-indentation]
goto fail;
^~~~
sslKeyExchange.c:629:4: note: ...as if it were guarded by this 'if' clause, but
it is not
if ((err = SSLHashSHA1.update(, )) != 0)
^~

[Bug c/69985] [6 Regression] ICE: in linemap_position_for_loc_and_offset, at libcpp/line-map.c:924

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||dmalcolm at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #7 from Jakub Jelinek  ---
Started with r230331.

[Bug middle-end/69987] [6 Regression] internal compiler error: in verify_loop_structure, at cfgloop.c:1639

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Indeed, started with r233754.

[Bug tree-optimization/69989] [6 Regression] ICE on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes (in verify_loop_structure, at cfgloop.c:1639)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-27
 CC||jakub at gcc dot gnu.org,
   ||law at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|ICE on x86_64-linux-gnu at  |[6 Regression] ICE on
   |-O3 in both 32-bit and  |x86_64-linux-gnu at -O3 in
   |64-bit modes (in|both 32-bit and 64-bit
   |verify_loop_structure, at   |modes (in
   |cfgloop.c:1639) |verify_loop_structure, at
   ||cfgloop.c:1639)
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r233754.  Perhaps the backport to 5 branch should be reverted
until the fallout is settled on the trunk?

[Bug c/69985] [6 Regression] ICE: in linemap_position_for_loc_and_offset, at libcpp/line-map.c:924

[trippels at gcc dot gnu.org]

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

--- Comment #6 from Markus Trippelsdorf  ---
Created attachment 37813
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37813=edit
c file

(In reply to Manuel López-Ibáñez from comment #4)
> (In reply to Markus Trippelsdorf from comment #0)
> > If I move the cmds-check.i file to a different directory gcc no longer ICEs,
> > so reducing is impossible.
> 
> One idea. Do you still have cmds-check.c in that subdir?
> location_from_offset will try to re-open the file to find the visual column
> because GCC's internal representation does not capture this info.

Bingo! With both files present I can even reproduce it on my x86_64 machine.

markus@x4 tmp % gcc -w -c -Wall cmds-check.i

cmds-check.c: In function ‘check_chunk_refs’:
cmds-check.c:7849:6: internal compiler error: in
linemap_position_for_loc_and_offset, at libcpp/line-map.c:924
  block_group_rec->flags);
  ^~~
0x12b30ca linemap_position_for_loc_and_offset(line_maps*, unsigned int,
unsigned int)
../../gcc/libcpp/line-map.c:924
0x593a2f location_from_offset
../../gcc/gcc/c-family/c-format.c:139
0x593b7a format_type_warning
../../gcc/gcc/c-family/c-format.c:2672
0x698f32 check_format_types
../../gcc/gcc/c-family/c-format.c:2616
0x698f32 check_format_info_main
../../gcc/gcc/c-family/c-format.c:2424
0x698f32 check_format_arg
../../gcc/gcc/c-family/c-format.c:1688
0x6960b7 check_format_info
../../gcc/gcc/c-family/c-format.c:1423
0x6960b7 check_function_format(tree_node*, int, tree_node**)
../../gcc/gcc/c-family/c-format.c:1093
0x6874c6 check_function_arguments(unsigned int, tree_node const*, int,
tree_node**)
../../gcc/gcc/c-family/c-common.c:9695
0x6061d4 build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*)
../../gcc/gcc/c/c-typeck.c:3051
0x625f0d c_parser_postfix_expression_after_primary
../../gcc/gcc/c/c-parser.c:8262
0x61ca09 c_parser_postfix_expression
../../gcc/gcc/c/c-parser.c:8075
0x61f74a c_parser_unary_expression
../../gcc/gcc/c/c-parser.c:6893
0x620547 c_parser_cast_expression
../../gcc/gcc/c/c-parser.c:6722
0x620762 c_parser_binary_expression
../../gcc/gcc/c/c-parser.c:6531
0x621425 c_parser_conditional_expression
../../gcc/gcc/c/c-parser.c:6302
0x621ac0 c_parser_expr_no_commas
../../gcc/gcc/c/c-parser.c:6219
0x62 c_parser_expression
../../gcc/gcc/c/c-parser.c:8404
0x622c69 c_parser_expression_conv
../../gcc/gcc/c/c-parser.c:8437
0x63c441 c_parser_statement_after_labels
../../gcc/gcc/c/c-parser.c:5275

[Bug target/69992] New: test case gcc.dg/sms-4.c fails

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 69992
   Summary: test case gcc.dg/sms-4.c fails
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

PASS: gcc.dg/sms-4.c (test for excess errors)
PASS: gcc.dg/sms-4.c execution test
FAIL: gcc.dg/sms-4.c scan-rtl-dump-times sms "SMS succeeded" 1

This fails on powerpc with gcc 5 and gcc 6 from trunk and it succeeds with gcc
4.9 but I am not sure if it is a regression.  I tried out several older
revisions going back over 6 months and they all fail.  It fails with both big
and little endian.  This test works on x86.

[Bug c/69985] [6 Regression] ICE: in linemap_position_for_loc_and_offset, at libcpp/line-map.c:924

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---



(gdb) bt
#0  0x110c60d8 in linemap_position_for_loc_and_offset
(set=0x3fffb7f7, loc=, offset=) at
../../gcc/libcpp/line-map.c:925
#1  0x101051b4 in location_from_offset (loc=,
offset=) at ../../gcc/gcc/c-family/c-format.c:139
#2  0x101053f0 in format_type_warning (loc=2147495432,
type=0x3fffc398, wanted_type=0x3fffaf3809d8, arg_type=0x3fffaf6c13b0)
at ../../gcc/gcc/c-family/c-format.c:2672
#3  0x1010631c in check_format_types (loc=2147495432,
types=0x3fffc398) at ../../gcc/gcc/c-family/c-format.c:2616
#4  0x1026ccdc in check_format_info_main (info=0x3fffc770,
info=0x3fffc770, fwt_pool=..., arg_num=,
params=0x3fffab29fca8, 
format_length=, 
format_chars=0x3fffaf79d75e ", %u, %llu]: length(%llu), offset(%llu),
type(%llu) mismatch with block group[%llu, %u, %llu]: offset(%llu),
objectid(%llu), flags(%llu)\n",4
#5  check_format_arg (ctx=, format_tree=,
arg_num=) at ../../gcc/gcc/c-family/c-format.c:1688
#6  0x10255a40 in check_function_arguments_recurse (callback=0x1026af00
, ctx=0x3fffc758,
param=0x3fffab2ac0a0, 
param_num=2) at ../../gcc/gcc/c-family/c-common.c:9783
#7  0x10269cd8 in check_format_info (params=0x3fffab29fcd0,
info=) at ../../gcc/gcc/c-family/c-format.c:1423
#8  check_function_format (attrs=, nargs=14, argarray=) at ../../gcc/gcc/c-family/c-format.c:1093
#9  0x10256378 in check_function_arguments (loc=,
fntype=0x3fffaf5952b0, nargs=, argarray=0x3fffad294ad8)
at ../../gcc/gcc/c-family/c-common.c:9695
#10 0x101b8210 in build_function_call_vec (loc=,
arg_loc=..., function=0x3fffab2ac260, params=,
origtypes=0x3fffad295df0)
at ../../gcc/gcc/c/c-typeck.c:3051
#11 0x101e0290 in c_parser_postfix_expression_after_primary
(parser=0x3fffaf58, expr_loc=162929382, expr=...) at
../../gcc/gcc/c/c-parser.c:8263
#12 0x101d490c in c_parser_postfix_expression (parser=0x3fffaf58)
at ../../gcc/gcc/c/c-parser.c:8075
#13 0x101d7a6c in c_parser_unary_expression (parser=0x3fffaf58) at
../../gcc/gcc/c/c-parser.c:6893
#14 0x101d8abc in c_parser_cast_expression (parser=0x3fffaf58,
after=0x0) at ../../gcc/gcc/c/c-parser.c:6722
#15 0x101d8d68 in c_parser_binary_expression (parser=0x3fffaf58,
after=, omp_atomic_lhs=0x0) at ../../gcc/gcc/c/c-parser.c:6531
#16 0x101d9980 in c_parser_conditional_expression
(parser=0x3fffaf58, after=, omp_atomic_lhs=)
at ../../gcc/gcc/c/c-parser.c:6302
#17 0x101da138 in c_parser_expr_no_commas (parser=0x3fffaf58,
after=0x0, omp_atomic_lhs=0x0) at ../../gcc/gcc/c/c-parser.c:6219
#18 0x101daad0 in c_parser_expression (parser=0x3fffaf58) at
../../gcc/gcc/c/c-parser.c:8404
#19 0x101db7d8 in c_parser_expression_conv (parser=0x3fffaf58) at
../../gcc/gcc/c/c-parser.c:8437
#20 0x101f698c in c_parser_statement_after_labels
(parser=0x3fffaf58, chain=0x0) at ../../gcc/gcc/c/c-parser.c:5275
#21 0x101f7224 in c_parser_if_body (if_tinfo=..., if_p=, parser=0x3fffaf58) at ../../gcc/gcc/c/c-parser.c:5369
#22 c_parser_if_statement (chain=0x0, parser=0x3fffaf58) at
../../gcc/gcc/c/c-parser.c:5445
#23 c_parser_statement_after_labels (parser=0x3fffaf58, chain=0x0) at
../../gcc/gcc/c/c-parser.c:5129
#24 0x101f8a7c in c_parser_compound_statement_nostart
(parser=0x3fffaf58) at ../../gcc/gcc/c/c-parser.c:4859
#25 0x101f946c in c_parser_compound_statement (parser=0x3fffaf58)
at ../../gcc/gcc/c/c-parser.c:4695
#26 0x101f74f4 in c_parser_if_body (if_tinfo=..., if_p=, parser=0x3fffaf58) at ../../gcc/gcc/c/c-parser.c:5367
#27 c_parser_if_statement (chain=0x0, parser=0x3fffaf58) at
../../gcc/gcc/c/c-parser.c:5445
#28 c_parser_statement_after_labels (parser=0x3fffaf58, chain=0x0) at
../../gcc/gcc/c/c-parser.c:5129
#29 0x101f8a7c in c_parser_compound_statement_nostart
(parser=0x3fffaf58) at ../../gcc/gcc/c/c-parser.c:4859
#30 0x101f946c in c_parser_compound_statement (parser=0x3fffaf58)
at ../../gcc/gcc/c/c-parser.c:4695
#31 0x101f74f4 in c_parser_if_body (if_tinfo=..., if_p=, parser=0x3fffaf58) at ../../gcc/gcc/c/c-parser.c:5367
#32 c_parser_if_statement (chain=0x0, parser=0x3fffaf58) at
../../gcc/gcc/c/c-parser.c:5445
#33 c_parser_statement_after_labels (parser=0x3fffaf58, chain=0x0) at
../../gcc/gcc/c/c-parser.c:5129
#34 0x101f8a7c in c_parser_compound_statement_nostart
(parser=0x3fffaf58) at ../../gcc/gcc/c/c-parser.c:4859
#35 0x101f946c in c_parser_compound_statement (parser=0x3fffaf58)
at ../../gcc/gcc/c/c-parser.c:4695
#36 0x101faa4c in c_parser_declaration_or_fndef (parser=0x3fffaf58,
fndef_ok=, static_assert_ok=true, empty_ok=true, nested=false, 
start_attr_ok=true, 

[Bug tree-optimization/69991] New: missed tail merge optimization

[vries at gcc dot gnu.org]

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

Bug ID: 69991
   Summary: missed tail merge optimization
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider testcase test.c:
...
void
foo (int c, int d, int *z, int *y)
{
  int res = 0;
  if (c)
{
  *y = 0;
  if (d)
{
  *z = 1;
  res = *y;
}
}
  else
{
  *z = 1;
  res = *y;
}
}
...

When compiled with -O2 -fno-tree-dce, tail-merge fails, due to this check in
find_duplicate:
...
  /* If the incoming vuses are not the same, and the vuse escaped into an
 SSA_OP_DEF, then merging the 2 blocks will change the value of the def,
 which potentially means the semantics of one of the blocks will be
changed.
 TODO: make this check more precise.  */
  if (vuse_escaped && vuse1 != vuse2)
return;
...

Removing the check allows the testcase to be tail-merged, and the testcase
belonging the check (pr52734.c) still passes.  This is due to the fix for
PR62167. With a less conservative fix for PR62167, we'd still need this check
for pr52734.c. So it's not necessarily a good idea to remove the check now.

A quick fix would be to ignore defs with no uses in
gsi_advance_bw_nondebug_nonlocal, in the same way we ignore stmts with zero
operands. But the usability of such a fix would be limited.

Another option is to consider the TODO mentioned in the comment. The test-case
pr52734.c can actually safely be tail-merged, as long as the right bb is
chosen. If we can model the incoming vuse as a dependency for one bb, we should
be able to choose the right bb (the empty one with no depencencies).

[Bug c/69985] [6 Regression] ICE: in linemap_position_for_loc_and_offset, at libcpp/line-map.c:924

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Markus Trippelsdorf from comment #0)
> If I move the cmds-check.i file to a different directory gcc no longer ICEs,
> so reducing is impossible.

One idea. Do you still have cmds-check.c in that subdir? location_from_offset
will try to re-open the file to find the visual column because GCC's internal
representation does not capture this info.

[Bug c/69985] [6 Regression] ICE: in linemap_position_for_loc_and_offset, at libcpp/line-map.c:924

[manu at gcc dot gnu.org]

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

--- Comment #3 from Manuel López-Ibáñez  ---
(In reply to Markus Trippelsdorf from comment #0)
> If I move the cmds-check.i file to a different directory gcc no longer ICEs,
> so reducing is impossible.

What is the complete path to cmds-check.i ?

[Bug c/69985] [6 Regression] ICE: in linemap_position_for_loc_and_offset, at libcpp/line-map.c:924

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
Can you get a backtrace? Does it happen with --enable-checking=release?

Dumping the line-table might also be useful to understand what happened. 

> If I move the cmds-check.i file to a different directory gcc no longer ICEs,
> so reducing is impossible.

That is weird. Filenames should be encoded already in the *.i file, so moving
it should make no difference.

[Bug rtl-optimization/69886] ICE: in process_insert_insn, at gcse.c:1976 with --param=gcse-unrestricted-cost=0 @ aarch64

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Sat Feb 27 13:31:39 2016
New Revision: 233781

URL: https://gcc.gnu.org/viewcvs?rev=233781=gcc=rev
Log:
PR target/69613
PR rtl-optimization/69886
* gcc.dg/torture/pr69886.c: Add -w -Wno-psabi to dg-options.
* gcc.dg/torture/pr69613.c: Likewise.  Guard -mavx with avx_runtime
target.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/torture/pr69613.c
trunk/gcc/testsuite/gcc.dg/torture/pr69886.c

[Bug target/69613] [6 Regression] wrong code with -O and simple 128bit arithmetics and vectors @ aarch64

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Author: jakub
Date: Sat Feb 27 13:31:39 2016
New Revision: 233781

URL: https://gcc.gnu.org/viewcvs?rev=233781=gcc=rev
Log:
PR target/69613
PR rtl-optimization/69886
* gcc.dg/torture/pr69886.c: Add -w -Wno-psabi to dg-options.
* gcc.dg/torture/pr69613.c: Likewise.  Guard -mavx with avx_runtime
target.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/torture/pr69613.c
trunk/gcc/testsuite/gcc.dg/torture/pr69886.c

[Bug c++/69889] [6 Regression] ICE: in assign_temp, at function.c:961

[bbannier+gcc_bugs at gmail dot com]

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

--- Comment #7 from Benjamin Bannier  ---
Thanks for taking care of this so quickly. I currently do not observe any more
ICEs from that codebase.

[Bug tree-optimization/69990] New: decl alignment not respected

[amodra at gmail dot com]

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

Bug ID: 69990
   Summary: decl alignment not respected
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amodra at gmail dot com
  Target Milestone: ---

The following testcase on powerpc64le-linux results in
/usr/local/powerpc64le-linux/bin/ld: pack.o: In function `main':
pack.c:(.text.startup+0x10): error: R_PPC64_TOC16_LO_DS not a multiple of 4
/usr/local/powerpc64le-linux/bin/ld: final link failed: Bad value


/* -O2 -fsection-anchors -ftree-loop-vectorize */

#pragma pack(1)
struct S0 {
  volatile int f0:12;
} static a[] = {{15}}, c[] = {{15}};

struct S0 b[] = {{7}};
int d;

int main(void)
{
  struct S0 *f[] = { c, (struct S0 *) };
  return __builtin_printf ("%x %x %x\n", a[0].f0, b[0].f0, f[0]->f0);
}


Breakpoint 1, offsettable_ok_by_alignment (mode=DImode, offset=0,
op=0x76db39a8) at /src/gcc.git/gcc/config/rs6000/rs6000.c:7109
(gdb) p debug_rtx(op)
(symbol_ref:DI ("a") [flags 0x2] )
$1 = void
(gdb) p debug_tree(decl)
 
unit size 
align 8 symtab 0 alias set 1 canonical type 0x76da3c78 fields
 context 
pointer_to_this  chain >
HI size  unit size 
align 8 symtab 0 alias set 1 canonical type 0x76da3150
domain 
DI
size 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x76d7a1f8
precision 64 min  max >
pointer_to_this >
readonly used static HI file /src/tmp/ds_mem.c line 6 col 10 size
 unit size 
user align 128 context 
(mem/u/c:HI (symbol_ref:DI ("a") [flags 0x2] )
[1 a+0 S2 A128]) chain >
$2 = void

So the alignment of "a" is reported as 128 bits, but in fact "a" is only 16 bit
aligned as seen below in extract from assembly file.

.comm   d,4,4
.globl b
.seta,c
.section".data"
.align 4
.set.LANCHOR0,. + 0
.type   b, @object
.size   b, 2
b:
.byte   7
.byte   0
.type   c, @object
.size   c, 2
c:
.byte   15
.byte   0

[Bug c++/69564] [5/6 Regression] lto and/or C++ make scimark2 LU slower

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
(In reply to Artem S. Tashkinov from comment #15)
> Is this the same bug?
> 
> https://www.phoronix.com/scan.php?page=article=ubuntu-1604-
> compilers=2
> 
> In Dense LU Matrix Factorization GCC 5.3.1/6.0 is more than 2 times slower
> than Clang.
> 
> G++ options: -O3 -march=native
> CPU: Xeon E3-1280 v5

Maybe.  Though with -Ofast -march=native -funroll-loops is at least on my box
GCC emitted code faster than clang, without -funroll-loops it is the opposite.

[Bug middle-end/69987] [6 Regression] internal compiler error: in verify_loop_structure, at cfgloop.c:1639

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch, law at gcc dot gnu.org

--- Comment #1 from Joost VandeVondele  
---
> cat bug.f90 
MODULE cp_lbfgs
  INTEGER, PARAMETER :: dp=8
CONTAINS
  SUBROUTINE mainlb(n, m, x, l, u, nbd, f, g, factr, pgtol, ws, wy, &
   csave, lsave, isave, dsave)
REAL(KIND=dp):: x(n), l(n), u(n)
REAL(KIND=dp) :: f, g(n), factr, pgtol, ws(n, m), wy(n, m), sy(m, m), &
  ss(m, m), wt(m, m), wn(2*m, 2*m), snd(2*m, 2*m), z(n), r(n), d(n), &
  t(n), wa(8*m)
CHARACTER(len=60):: task
IF (task == 'START') THEN
   IF (task(1:5) == 'FG_LN') GOTO 666
ENDIF
222 CONTINUE
DO 40 i = 1, n
   d(i) = z(i) - x(i)
40  ENDDO
666 CONTINUE
IF (info /= 0 .OR. iback >= 20) THEN
   CALL dcopy(n,r,1,g,1)
ENDIF
GOTO 222
  END SUBROUTINE mainlb
END MODULE cp_lbfgs

> gfortran  -c -O3 -fprefetch-loop-arrays bug.f90 
bug.f90:4:0:

   SUBROUTINE mainlb(n, m, x, l, u, nbd, f, g, factr, pgtol, ws, wy, &

Error: loop verification on loop tree that needs fixup
bug.f90:4:0: internal compiler error: in verify_loop_structure, at
cfgloop.c:1639


last known good r233732 , first known bad r233775

[Bug c++/69564] [5/6 Regression] lto and/or C++ make scimark2 LU slower

[t.artem at mailcity dot com]

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

--- Comment #15 from Artem S. Tashkinov  ---
Is this the same bug?

https://www.phoronix.com/scan.php?page=article=ubuntu-1604-compilers=2

In Dense LU Matrix Factorization GCC 5.3.1/6.0 is more than 2 times slower than
Clang.

G++ options: -O3 -march=native
CPU: Xeon E3-1280 v5

[Bug tree-optimization/69989] New: ICE on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes (in verify_loop_structure, at cfgloop.c:1639)

[chengniansun at gmail dot com]

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

Bug ID: 69989
   Summary: ICE on x86_64-linux-gnu at -O3 in both 32-bit and
64-bit modes (in verify_loop_structure, at
cfgloop.c:1639)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

The following code crashes the trunk on x86_64-linux-gnu at -O3 in both 32-bit
and 64-bit modes. 

$: 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 20160227 (experimental) [trunk revision 233778] (GCC) 
$: 
$: gcc-trunk -O3 small.c
small.c: In function ‘fn1’:
small.c:3:6: error: loop verification on loop tree that needs fixup
 void fn1() {
  ^~~
small.c:3:6: internal compiler error: in verify_loop_structure, at
cfgloop.c:1639
0x72f9f7 verify_loop_structure()
../../gcc-source-trunk/gcc/cfgloop.c:1639
0xbd54d5 checking_verify_loop_structure
../../gcc-source-trunk/gcc/cfgloop.h:324
0xbd54d5 execute
../../gcc-source-trunk/gcc/tree-loop-distribution.c:1818
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.
$: 
$: cat small.c
int a, b, d;
char c[0];
void fn1() {
  for (;;) {
if (b)
LABEL_T5T5T:
for (; d; d++)
  c[d] = 6;
break;
  }
  a = 1;
  goto LABEL_T5T5T;
}

int main() {}
$:

[Bug target/69988] libgo.so: undefined reference to `__unorddf2'

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #1 from John Paul Adrian Glaubitz  ---
Full build log here:

> https://people.debian.org/~glaubitz/gcc-5_5.2.1-14_powerpcspe-20160226-2238.build

[Bug target/69988] New: libgo.so: undefined reference to `__unorddf2'

[glaubitz at physik dot fu-berlin.de]

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

Bug ID: 69988
   Summary: libgo.so: undefined reference to `__unorddf2'
   Product: gcc
   Version: 5.2.1
   URL: https://people.debian.org/~glaubitz/gcc-5_5.2.1-14_pow
erpcspe-20160226-2238.build
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
CC: doko at debian dot org
  Target Milestone: ---
  Host: powerpc-linux-gnuspe
Target: powerpc-linux-gnuspe
 Build: powerpc-linux-gnuspe

Hello!

I'm currently working on reviving Debian's powerpcspe port. After fixing some
minor issues in Debian's packaging for powerpcspe, I am stumbling over an issue
that I would consider a bug:

/«PKGBUILDDIR»/build/./gcc/gccgo -B/«PKGBUILDDIR»/build/./gcc/ -g -O2
-static-libstdc++ -static-libgcc -Wl,-z,relro -L
../powerpc-linux-gnuspe/libgo -L ../powe
rpc-linux-gnuspe/libgo/.libs -o gofmt
../../src/gotools/../libgo/go/cmd/gofmt/doc.go
../../src/gotools/../libgo/go/cmd/gofmt/gofmt.go ../../src/gotools/../libgo
/go/cmd/gofmt/rewrite.go
../../src/gotools/../libgo/go/cmd/gofmt/simplify.go
../powerpc-linux-gnuspe/libgo/.libs/libgo.so: undefined reference to
`__unorddf2'
collect2: error: ld returned 1 exit status
Makefile:629: recipe for target 'gofmt' failed
make[4]: *** [gofmt] Error 1
make[4]: Leaving directory '/«PKGBUILDDIR»/build/gotools'
Makefile:12509: recipe for target 'all-gotools' failed
make[3]: *** [all-gotools] Error 2

I asssume that unorddf2 is normally present in libgcc, so the linking above
should not fail. But assume the above happens because the unorddf2 symbol might
be undefined since the differentian between "powerpc" and "powerpcspe" is
missing, i.e. the code is compiled as if on a powerpc with an FPU.

But I'm just guessing from experience from seeing similar issues on x86_64 vs.
x32.

PS: I couldn't test anything newer than gcc-5.2.1 yet since the gcc-5.3.x
packages in Debian build-depend on g++-5 itself. gcc-5 has not been built on
powerpcspe yet which is why I wanted to start with an older version first, then
build the current version of the gcc-5 package.

Cheers,

Adrian

[Bug middle-end/69987] New: [6 Regression] internal compiler error: in verify_loop_structure, at cfgloop.c:1639

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 69987
   Summary: [6 Regression]  internal compiler error: in
verify_loop_structure, at cfgloop.c:1639
   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: ---

an overnight regression on trunk, which I'll tr to reduce:

/data/vjoost/gnu/cp2k/cp2k/makefiles/../src/cp_lbfgs.F:242:0:

   SUBROUTINE mainlb(n, m, x, l, u, nbd, f, g, factr, pgtol, ws, wy, &

Error: loop verification on loop tree that needs fixup
/data/vjoost/gnu/cp2k/cp2k/makefiles/../src/cp_lbfgs.F:242:0: internal compiler
error: in verify_loop_structure, at cfgloop.c:1639
0x773ecc verify_loop_structure()
../../gcc/gcc/cfgloop.c:1639
0xd07b50 checking_verify_loop_structure
../../gcc/gcc/cfgloop.h:324
0xd07b50 tree_transform_and_unroll_loop(loop*, unsigned int, edge_def*,
tree_niter_desc*, void (*)(loop*, void*), void*)
../../gcc/gcc/tree-ssa-loop-manip.c:1362
0xd19205 loop_prefetch_arrays
../../gcc/gcc/tree-ssa-loop-prefetch.c:1908
0xd19205 tree_ssa_prefetch_arrays()
../../gcc/gcc/tree-ssa-loop-prefetch.c:1977
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[2]: *** [cp_lbfgs.o] Error 1

First guess would be this is related to the fix of PR69740 (which was also
backported to the 5 branch).

[Bug target/69986] New: smaller code possible with -Os by using push/pop to spill/reload

[peter at cordes dot ca]

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

Bug ID: 69986
   Summary: smaller code possible with -Os by using push/pop to
spill/reload
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: minor
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---
Target: x86-64-*-*

#include 
int f(int a) { close(a); return a; }

 push   rbx
 movebx,edi
 call   400490 
 moveax,ebx
 poprbx
 ret

with gcc 5.3 -Os.

It could be smaller:

 push   rbi
 call   400490 
 poprax
 ret

saving 4 bytes (mov reg,reg is two bytes).

More generally, push/pop are 1 byte each, much smaller than mov [rsp-8], edi or
something.

This might not be a desirable optimization, though, because a round-trip
through memory increases latency.  It's one of those code-size optimizations
that will might often have a negative impact on performance in the case where
the function is already hot in L1 I-cache.

It would be nice if there was a way to optimize a bit for code-size without
making bad performance sacrifices, and also another option to optimize for code
size without much regard for performance.  -Oss vs. -Os?  Or -OS?  I assume
tuning these options is a lot of work.