date:20151129

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

--- Comment #6 from David Edelsohn  ---
Author: dje
Date: Sun Nov 29 18:11:54 2015
New Revision: 231045

URL: https://gcc.gnu.org/viewcvs?rev=231045=gcc=rev
Log:
PR target/28115
* config/rs6000/rs6000.c (rs6000_adjust_cost): Correct
recog_memoized test for insn and check recog_memoized for dep_insn.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c

[Bug c++/67581] [6 Regression] ICE on transparent union with -g enabled on x86_64-linux-gnu (verify_type failed)

2015-11-29 Thread hubicka at gcc dot gnu.org

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

--- Comment #3 from Jan Hubicka  ---
Author: hubicka
Date: Sun Nov 29 19:48:45 2015
New Revision: 231048

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

PR c/67581
* g++.dg/torture/pr67581.C: New testcase.
* c-family/c-common.c (handle_transparent_union_attribute): Update
also type variants.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr67581.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/testsuite/ChangeLog

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

2015-11-29 Thread ebotcazou at gcc dot gnu.org

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #3 from Eric Botcazou  ---
The regression is that for:

(gdb) p debug_generic_expr(rci->high_bound)
(integer) ((struct loop_optimization19__obj_t *) s1)->length

(gdb) p debug_generic_expr(gnu_high)
(integer) ((struct loop_optimization19__obj_t *) s1)->length

calling fold_binary (LE_EXPR, boolean_type_node, op0 , op1) yields:

(gdb) p debug_generic_expr(high_ok)
SAVE_EXPR <(integer) ((struct loop_optimization19__obj_t *) s1)->length>;, 1

instead of just 1 before, which is really annoying because SAVE_EXPR has
TREE_SIDE_EFFECTS set on it so the whole COMPOUND_EXPR has it too.

Can't we be move clever here and avoid pessimizing folding in this case?

[Bug bootstrap/68540] 6.0 build process broken on Linux Mint, potential include ordering problem

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

David Edelsohn  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #7 from David Edelsohn  ---
GCC Development often requires newer versions of packages than those shipped
with Linux distributions.  GCC now requires ISL 0.14 or 0.15 (possibly 0.13,
but no one has confirmed).

Also, as referenced in comment #6, earlier versions of ISL have flaws and
should not be used.

There are multiple reasons that ISL 0.12 should not be supported.  GCC Graphite
can compile and operate correctly with ISL 0.15.  Please upgrade to a newer
release of ISL.

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

2015-11-29 Thread tkoenig at gcc dot gnu.org

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

--- Comment #3 from Thomas Koenig  ---
Created attachment 36868
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36868=edit
Modified benchmark (really this time)

Hi Dominique,

I think you are seeing the effects of inefficiencies of assumed-shape arrays.

If you want to use matmul on very small matrix sizes, it is best to
use fixed-size explicit arrays.

Below the results of the modified benchmark (some changes to keep
the optimizer honest, such as a call to a dummy subroutine) on my
rather dated home box:

 Size Loops  Matmul   dgemm Matmul  Matmul
  fixed explicitassumed  variable
explicit

=
220  11.948   0.072   0.142   0.411
420   1.711   0.417   0.534   0.861
820   2.314   0.953   0.858   1.076
   1620   1.745   1.276   0.918   1.000
   3220   1.459   1.456   1.371   1.436
   64 30757   1.501   1.440   1.360   1.393
  128  3829   1.586   1.544   1.557   1.529
  256   477   1.531   1.519   1.544   1.507
  51259   1.315   1.290   1.263   1.231
 1024 7   1.110   1.081   1.069   1.053
 2048 1   1.095   1.086   1.081   1.058

[Bug c++/67436] [C++14] Generic lambda capture fails for thread_local variables

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Markus Trippelsdorf  ---
Fixed.

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

2015-11-29 Thread jvdelisle at gcc dot gnu.org

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #4 from Jerry DeLisle  ---
Created attachment 36869
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36869=edit
Thomas program with a modified dgemm.

The dgemm in this example is a stripped out version of an "optimized for cache"
version from netlib.org.  I stripped out a lot of the unused code.

Results show better performance for larger arrays.  Maybe we could model the
library routines after this and invoke for larger arrays.

 Size Loops  Matmul   dgemm Matmul  Matmul
  fixed explicitassumed  variable
explicit
 ==
220   1.752   0.042   0.124   0.295
420   2.172   0.314   0.434   0.704
820   2.293   1.071   0.721   1.127
   1620   2.826   1.533   0.972   1.468
   3220   2.707   1.666   1.184   2.154
   64 30757   2.726   1.853   1.192   2.299
  128  3829   2.641   1.965   1.379   2.542
  256   477   2.661   2.001   1.384   2.594
  51259   1.740   2.011   1.147   1.746
 1024 7   1.344   2.024   1.070   1.355
 2048 1   1.305   2.026   1.088   1.312

[Bug ada/68564] Ada fails to bootstrap on sparc64-linux-gnu

2015-11-29 Thread doko at gcc dot gnu.org

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

--- Comment #12 from Matthias Klose  ---
Author: doko
Date: Sun Nov 29 22:41:00 2015
New Revision: 231051

URL: https://gcc.gnu.org/viewcvs?rev=231051=gcc=rev
Log:
2015-11-29  Matthias Klose  

PR ada/68564
* gcc-interface/Makefile.in: Fix powerpc/powerpc64* and
mipsel/mips64el bitness detection. 
Merge the mipsel/mips64el definitions into one.

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/Makefile.in

[Bug c++/68607] Internal compiler error with generic lambda and constexpr

2015-11-29 Thread Casey at Carter dot net

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

Casey Carter  changed:

   What|Removed |Added

 CC||Casey at Carter dot net

--- Comment #1 from Casey Carter  ---
4.9.2 and 6 compile this program correctly; 5.1 and 5.2 don't. This is a
regression in the version 5 series.

[Bug target/28115] possible bug in recog_memoized usage in rs6000.c??

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

David Edelsohn  changed:

   What|Removed |Added

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

--- Comment #7 from David Edelsohn  ---
Fixed.

[Bug c/67106] [6 Regression] ICE: verify_type failed: type variant differs by TYPE_PACKED. with -g -fpack-struct

2015-11-29 Thread hubicka at gcc dot gnu.org

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

--- Comment #4 from Jan Hubicka  ---
Author: hubicka
Date: Sun Nov 29 19:50:04 2015
New Revision: 231049

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

PR c/67106
* gcc.c-torture/compile/pr67106.c: New testcase.
* c-decl.c: Set TYPE_PACKED in variants.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr67106.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug ada/68564] Ada fails to bootstrap on sparc64-linux-gnu

2015-11-29 Thread doko at gcc dot gnu.org

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

--- Comment #14 from Matthias Klose  ---
Author: doko
Date: Sun Nov 29 22:42:25 2015
New Revision: 231053

URL: https://gcc.gnu.org/viewcvs?rev=231053=gcc=rev
Log:
2015-11-29  Matthias Klose  

PR ada/68564
* gcc-interface/Makefile.in: Fix powerpc/powerpc64* and
mipsel/mips64el bitness detection. 
Merge the mipsel/mips64el definitions into one.

Modified:
branches/gcc-4_9-branch/gcc/ada/ChangeLog
branches/gcc-4_9-branch/gcc/ada/gcc-interface/Makefile.in

[Bug ada/68564] Ada fails to bootstrap on sparc64-linux-gnu

2015-11-29 Thread doko at gcc dot gnu.org

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

--- Comment #13 from Matthias Klose  ---
Author: doko
Date: Sun Nov 29 22:41:48 2015
New Revision: 231052

URL: https://gcc.gnu.org/viewcvs?rev=231052=gcc=rev
Log:
2015-11-29  Matthias Klose  

PR ada/68564
* gcc-interface/Makefile.in: Fix powerpc/powerpc64* and
mipsel/mips64el bitness detection. 
Merge the mipsel/mips64el definitions into one.

Modified:
branches/gcc-5-branch/gcc/ada/ChangeLog
branches/gcc-5-branch/gcc/ada/gcc-interface/Makefile.in

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

2015-11-29 Thread redi at gcc dot gnu.org

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-29
 Ever confirmed|0   |1

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

2015-11-29 Thread milan.plzik at gmail dot com

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

milan.plzik at gmail dot com changed:

   What|Removed |Added

 CC||milan.plzik at gmail dot com

--- Comment #17 from milan.plzik at gmail dot com ---
with gcc 5.2.0, I still get this error when e.g. compiling ChibiOS example:
$ make
Linking build/ch.elf
lto1: internal compiler error: in add_symbol_to_partition_1, at
lto/lto-partition.c:158
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: fatal error: arm-none-eabi-gcc returned 1 exit status
compilation terminated.
/usr/lib/gcc/arm-none-eabi/5.2.0/../../../../arm-none-eabi/bin/ld: lto-wrapper
failed
collect2: error: ld returned 1 exit status
../../../os/common/ports/ARMCMx/compilers/GCC/rules.mk:238: recipe for target
'build/ch.elf' failed
make: *** [build/ch.elf] Error 1

$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-none-eabi/5.2.0/lto-wrapper
Target: arm-none-eabi
Configured with: /build/arm-none-eabi-gcc/src/gcc-5.2.0/configure
--target=arm-none-eabi --prefix=/usr --with-sysroot=/usr/arm-none-eabi
--with-native-system-header-dir=/include --libexecdir=/usr/lib
--enable-languages=c,c++ --enable-plugins --disable-decimal-float
--disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath
--disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared
--disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-system-zlib
--with-newlib --with-headers=/usr/arm-none-eabi/include
--with-python-dir=share/gcc-arm-none-eabi --with-gmp --with-mpfr --with-mpc
--with-isl --with-libelf --enable-gnu-indirect-function
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-pkgversion='Arch Repository' --with-bugurl=https://bugs.archlinux.org/
--with-multilib-list=armv6-m,armv7-m,armv7e-m,armv7-r
Thread model: single
gcc version 5.2.0 (Arch Repository)

[Bug c++/68607] Internal compiler error with generic lambda and constexpr

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Markus Trippelsdorf  ---
Already fixed on gcc-5 branch.

[Bug target/68365] gfortran test case showing performance loss with vectorization

2015-11-29 Thread n8tm at aol dot com

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

--- Comment #5 from n8tm at aol dot com ---
Sorry, will attach that source file.

Sent via the ASUS PadFone X mini, an AT 4G LTE smartphone

 Original Message 
From:"dominiq at lps dot ens.fr" 
Sent:Sun, 15 Nov 2015 14:37:23 -0500
To:tpri...@computer.org
Subject:[Bug fortran/68365] gfortran test case showing performance loss with
vectorization

>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68365
>
>Dominique d'Humieres  changed:
>
>   What|Removed |Added
>
> Status|UNCONFIRMED |WAITING
>   Last reconfirmed||2015-11-15
> Ever confirmed|0   |1
>
>--- Comment #1 from Dominique d'Humieres  ---
>make: *** No rule to make target 'lcdmod.o', needed by 'lcd_mod.mod'.  Stop.
>
>or
>
>Fatal Error: Can't open module file 'lcd_mod.mod' for reading at (1): No such
>file or directory
>
>What should be done for non cygwin platform?
>
>-- 
>You are receiving this mail because:
>You are on the CC list for the bug.
>You reported the bug.

[Bug c++/66921] [4.9/5/6 Regression] failure to determine size of static constexpr array that is nested within a templated class

2015-11-29 Thread jim at meyering dot net

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

jim at meyering dot net changed:

   What|Removed |Added

 CC||jim at meyering dot net

--- Comment #3 from jim at meyering dot net ---
I too have just found my upgrade to 4.9.x blocked by many instances of this
problem. Any fix in gcc would be most welcome.

[Bug c++/68607] New: Internal compiler error with generic lambda and constexpr

2015-11-29 Thread paulourio at gmail dot com

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

Bug ID: 68607
   Summary: Internal compiler error with generic lambda and
constexpr
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: paulourio at gmail dot com
  Target Milestone: ---

The following C++14 file produces an internal compiler error.

int main() {
  constexpr int k = 0;

  auto f = [&](auto param) {
if (param == k) {
}
  };

  f(0);
  return 0;
}

icp.cpp: In instantiation of ‘main():: [with auto:1 = int]’:
icp.cpp:10:6:   required from here
icp.cpp:2:5: internal compiler error: in tsubst_decl, at cp/pt.c:10836
 int main() {
 ^

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

[Bug tree-optimization/68576] scev failed for loop auto parallelize

2015-11-29 Thread amker.cheng at gmail dot com

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

--- Comment #5 from bin.cheng  ---
The type conversion comses from lim, below code:
  /* In case this is a stmt that is not unconditionally executed
 when the target loop header is executed and the stmt may
 invoke undefined integer or pointer overflow rewrite it to
 unsigned arithmetic.  */
  if (is_gimple_assign (stmt)
  && INTEGRAL_TYPE_P (TREE_TYPE (gimple_assign_lhs (stmt)))
  && TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (gimple_assign_lhs (stmt)))
  && arith_code_with_undefined_signed_overflow
   (gimple_assign_rhs_code (stmt))
  && (!ALWAYS_EXECUTED_IN (bb)
  || !(ALWAYS_EXECUTED_IN (bb) == level
   || flow_loop_nested_p (ALWAYS_EXECUTED_IN (bb), level
gsi_insert_seq_on_edge (e, rewrite_to_defined_overflow (stmt));

Once it's introduced, SCEV can't resolve it but assume possible overflow.

By mannually disabling lim pass, SCEV works as expected and now outer loop can
be parallelized.

[Bug c++/68608] New: [concepts] ICE with with explicit class instantiation

2015-11-29 Thread ryan.burn at gmail dot com

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

Bug ID: 68608
   Summary: [concepts] ICE with with explicit class instantiation
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.burn at gmail dot com
  Target Milestone: ---

The below code causes this ICE when compiled with

rnburn@localhost ~/test/explicit_concept $ g++17 --version
g++ (GCC) 6.0.0 20151123 (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.

main.cpp:13:23: error: Two symbols with same comdat_group are not linked by the
same_comdat_group list.
 template struct A;
   ^

_ZN1AIiE1fEv/2 (int A::f() requires predicate(!(C)) [with T = int])
@0x7f63087cf2e0
  Type: function definition analyzed
  Visibility: forced_by_abi public weak comdat_group:_ZN1AIiE1fEv one_only
  previous sharing asm name: 1
  References: 
  Referring: 
  First run: 0
  Function flags: body
  Called by: 
  Calls: 
_ZN1AIiE1fEv/1 (int A::f() requires predicate( C) [with T = int])
@0x7f63087cf170
  Type: function definition analyzed
  Visibility: forced_by_abi public weak comdat_group:_ZN1AIiE1fEv one_only
  next sharing asm name: 2
  References: 
  Referring: 
  First run: 0
  Function flags: body
  Called by: 
  Calls: 
main.cpp:13:23: internal compiler error: symtab_node::verify failed
0x934e59 symtab_node::verify_symtab_nodes()
../../src-fix/gcc/symtab.c:1120
0x94823b symtab_node::checking_verify_symtab_nodes()
../../src-fix/gcc/cgraph.h:566
0x94823b symbol_table::compile()
../../src-fix/gcc/cgraphunit.c:2358
0x94a952 symbol_table::compile()
../../src-fix/gcc/cgraphunit.c:2514
0x94a952 symbol_table::finalize_compilation_unit()
../../src-fix/gcc/cgraphunit.c:2540
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


///
template  concept constexpr bool C = true;

template 
struct A {
  int f() requires C { return 1; }
  int f() requires !C { return 2; }
};

int main() {
  return 0;
}

template struct A;
///

[Bug tree-optimization/68576] scev failed for loop auto parallelize

2015-11-29 Thread amker.cheng at gmail dot com

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

--- Comment #6 from bin.cheng  ---
Hmm, at least for this case, lim should be aware that lim candidate doesn't
invoke undefined overflow when it is not executed after entering target loop. 
Thus we don't need to rewrite it in unsigned arithmetic.

[Bug other/68605] Add -mno-crt0 to disable automatic crt0 injection

2015-11-29 Thread rdiezmail-gcc at yahoo dot de

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

--- Comment #2 from R. Diez  ---
Option -nostartfiles breaks other start-up things like _init and
__libc_init_array:

/home/rdiez/rdiez/arduino/toolchain-bin-08/lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/libstdc++.a(system_error.o):
In function `__static_initialization_and_destruction_0':
/home/rdiez/rdiez/arduino/JtagDue/Toolchain/Tmp/gcc-4.9.3/libstdc++-v3/src/c++11/system_error.cc:66:
undefined reference to `__dso_handle'
/home/rdiez/rdiez/arduino/toolchain-bin-08/lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/libg.a(lib_a-init.o):
In function `__libc_init_array':
/home/rdiez/rdiez/arduino/JtagDue/Toolchain/Tmp/newlib-2.2.0.20150423/newlib/libc/misc/init.c:37:
undefined reference to `_init'
/home/rdiez/rdiez/arduino/toolchain-bin-08/lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld:
jtagdue.elf: hidden symbol `__dso_handle' isn't defined
/home/rdiez/rdiez/arduino/toolchain-bin-08/lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld:
final link failed: Bad value

[Bug tree-optimization/68576] scev failed for loop auto parallelize

2015-11-29 Thread majun4950646 at 163 dot com

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

--- Comment #7 from majun  ---
(In reply to bin.cheng from comment #5)
> The type conversion comses from lim, below code:
>   /* In case this is a stmt that is not unconditionally executed
>  when the target loop header is executed and the stmt may
>invoke undefined integer or pointer overflow rewrite it to
>unsigned arithmetic.  */
>   if (is_gimple_assign (stmt)
> && INTEGRAL_TYPE_P (TREE_TYPE (gimple_assign_lhs (stmt)))
> && TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (gimple_assign_lhs (stmt)))
> && arith_code_with_undefined_signed_overflow
>  (gimple_assign_rhs_code (stmt))
> && (!ALWAYS_EXECUTED_IN (bb)
> || !(ALWAYS_EXECUTED_IN (bb) == level
>  || flow_loop_nested_p (ALWAYS_EXECUTED_IN (bb), level
>   gsi_insert_seq_on_edge (e, rewrite_to_defined_overflow (stmt));
> 
> Once it's introduced, SCEV can't resolve it but assume possible overflow.
> 
> By mannually disabling lim pass, SCEV works as expected and now outer loop
> can be parallelized.

so,it seems better to avoid integer(kind=8) --> unsigned long -->
integer(kind=8) instead of changing scev.

and thanks for digging into this problem!

compiling with "-flto -fuse-linker-plugin" gives libtool error

2015-11-29 Thread john . frankish

Compiling some packages with "-flto -fuse-linker-plugin" gives a libtool
error during "make". Compiling the same package without "-flto
-fuse-linker-plugin" allows "make" to complete without errors.

Using gcc-4.9.1/binutils-2.24.51 or gcc-5.2.0/binutils-2.25.1

The problem seems to occur with a few 10's of packages (eg cogl-1.20.0), but
not with others (eg gnome-music-3.16.2).

Using cogl-1.20.0 as an example:

CC="gcc -flto -fuse-linker-plugin -mtune=generic -Os -pipe" CXX="g++ -flto
-fuse-linker-plugin -mtune=generic -Os -pipe -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local --disable-static --localstatedir=/var
--enable-gles1 --enable-gles2 --enable-cogl-gst=yes

find . -name Makefile -type f -exec sed -i 's/-g -O2//g' {} \;

make
...
CC   cogl-enum-types.lo
CCLD libcogl.la
../libtool: eval: line 1: syntax error: unexpected "|"
Makefile:1507: recipe for target 'libcogl.la' failed
make[4]: *** [libcogl.la] Error 2

This can be fixed by using NM="gcc-nm", but as binutils was compiled with lto 
enabled, it shouldn't be required?

[Bug libstdc++/68606] New: Reduce or disable the static emergency pool for C++ exceptions

2015-11-29 Thread rdiezmail-gcc at yahoo dot de

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

Bug ID: 68606
Summary: Reduce or disable the static emergency pool for C++
exceptions
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rdiezmail-gcc at yahoo dot de
Target Milestone: ---

I am writing embedded firmware in C++ for small ARM Cortex-M3 microcontrollers
running on a 'bare metal' environment. One of the CPUs has just 16 KiB of SRAM.
Nevertheless, I have found that the only way to report sensible error messages
is by using C++ exceptions. And this is working fine, even with such tight
resources.

When you have 16 KiB SRAM, you do look carefully where your memory is going. It
took me while to realise that libstdc++ was reserving full 2 KiB for some
undocumented emergency memory pool in connection with C++ exceptions.

Acceptance of C++ exceptions has been slow over the years, not least due to
implementation deficiencies. In order to fix this one, I would like to see that
memory pool documented, and an option to reduce or disable it.

Embedded systems tend to be designed to never use all available memory. In many
such systems, a failing malloc() can only be caused by a bug, and if it does
happen, the system will panic and automatically reboot.

In my project, I have disabled the pool with this patch:

https://github.com/rdiez/JtagDue/blob/master/Toolchain/GccDisableCppExceptionEmergencyBuffer.patch

[Bug tree-optimization/68576] scev failed for loop auto parallelize

2015-11-29 Thread amker.cheng at gmail dot com

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

bin.cheng  changed:

   What|Removed |Added

 CC||amker.cheng at gmail dot com

--- Comment #4 from bin.cheng  ---
Before parloops, the related dump code is as below:

  _469 = (unsigned long) stride.90_24;
  _468 = (unsigned long) _368;
  _467 = _469 * _468;
  //...
  _466 = _470 + _467;
  _370 = (integer(kind=8)) _466;
  //...
  _373 = _370 + _372;
  //...
  # i1_1 = PHI <1(16), i1_159(24)>
  _75 = (integer(kind=8)) i1_1;
  _76 = _75 + _373;
  *g3_77(D)[_76] = 0.0;

When analyzing scev for _370, GCC needs to handle type conversion as:
(integer(kind=8)){(unsigned long) stride.90_24 + _470, (unsigned long)
stride.90_24}

Currently GCC don't know if below scev overflows or not:
{(integer(kind=8))(unsigned long) stride.90_24 + _470,
(integer(kind=8))(unsigned long) stride.90_24}

This no-overflow information may be provided by source code declaration:
real*8 g1(f4,f3,f2,f1),g2(f4,f4,f3,f2,f1),g3(f4,f3,f2,f1)

Because the stride comes from memory layout of array "g3".  But I don't see how
to compute this information and use it in SCEV.

This leads to another problem: we may be able to avoid this type conversion
here integer(kind=8) --> unsigned long --> integer(kind=8).
They are first introduced by lim2, I will investigate why.

[Bug other/68605] Add -mno-crt0 to disable automatic crt0 injection

2015-11-29 Thread sch...@linux-m68k.org

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

--- Comment #1 from Andreas Schwab  ---
What about -nostartfiles?

[Bug other/68605] New: Add -mno-crt0 to disable automatic crt0 injection

2015-11-29 Thread rdiezmail-gcc at yahoo dot de

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

Bug ID: 68605
   Summary: Add -mno-crt0 to disable automatic crt0 injection
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rdiezmail-gcc at yahoo dot de
  Target Milestone: ---

I am developing embedded software on an ARM Cortex-M3 CPU without an OS ('bare
metal') using newlib. I am not using libgloss, sometimes because the boards
need custom start-up code, partly because they have 2 firmware versions (normal
and emergency). On other scenarios, libgloss is just not worth the trouble.

GCC insists on adding crt0.o to the list of objects to link, which libgloss
tends to provide. I haven't got such a file, and I do not need one, as
everything is provided somewhere else. Due to limitations in the autotools, I
have to provide an empty crt0 on every makefile. An example is here, just
search for "crt0" on the following page:

https://github.com/rdiez/JtagDue/blob/master/Project/JtagFirmware/Makefile.am

I am not the only one hitting this problem, search the Internet for [gcc crt0]
and you'll find many hits. Working around this issue has made enough people
waste enough time.

I guess quietly and forcibly adding an object file to the list of things to
link is still there for historical reasons, but it does not make it any less of
a bad practice.

Some GCC targets have flag -mno-crt0 to alleviate the problem, others allow you
to change the name from crt0 to something else. I would welcome a flag like
-mno-crt0 for all architectures, or at least for ARM, which is what is bugging
me at the moment.

I have seen that some ARM toolchain patches GCC to remove the crt0 injection,
but I like building the GCC toolchain myself, and patching this every time is
unnecessary work.

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

2015-11-29 Thread hjl.tools at gmail dot com

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-29
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

[Bug target/68602] i386: -mtune/arch options not all output by -v --help

2015-11-29 Thread hjl.tools at gmail dot com

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #1 from H.J. Lu  ---
(In reply to Andi Kleen from comment #0)
> gcc -v --help does not output all the possible options for -mtune=/-march=
> 
> For example corei7-avx is missing for arch, which is Sandy Bridge. tune is
> also mising all cpu names
> 
> 
> 
>   -march=CPU[,+EXTENSION...]
>   generate code for CPU and EXTENSION, CPU is one of:
>generic32, generic64, i386, i486, i586, i686,
>pentium, pentiumpro, pentiumii, pentiumiii,
> pentium4,
>prescott, nocona, core, core2, corei7, l1om, k1om,
>k6, k6_2, athlon, opteron, k8, amdfam10, bdver1,
>bdver2, bdver3, bdver4, btver1, btver2
>   EXTENSION is combination of:
>8087, 287, 387, no87, mmx, nommx, sse, sse2, sse3,
>ssse3, sse4.1, sse4.2, sse4, nosse, avx, avx2,
>avx512f, avx512cd, avx512er, avx512pf, avx512dq,
>avx512bw, avx512vl, noavx, vmx, vmfunc, smx,
> xsave,
>xsaveopt, xsavec, xsaves, aes, pclmul, fsgsbase,
>rdrnd, f16c, bmi2, fma, fma4, xop, lwp, movbe,
> cx16,
>ept, lzcnt, hle, rtm, invpcid, clflush, nop,
> syscall,
>rdtscp, 3dnow, 3dnowa, padlock, svme, sse4a, abm,
>bmi, tbm, adx, rdseed, prfchw, smap, mpx, sha,
>clflushopt, prefetchwt1, se1, clwb, pcommit,
>avx512ifma, avx512vbmi
>   -mtune=CPU  optimize for CPU, CPU is one of:
>generic32, generic64, i8086, i186, i286, i386,
> i486,
>i586, i686, pentium, pentiumpro, pentiumii,
>pentiumiii, pentium4, prescott, nocona, core,
> core2,
>corei7, l1om, k1om, k6, k6_2, athlon, opteron, k8,
>amdfam10, bdver1, bdver2, bdver3, bdver4, btver1,
>btver2

This comes from assembler, not GCC, whose -march/-mtune are different from
GCC.

[Bug rtl-optimization/68601] GCC miscompiles LLVM on Windows

2015-11-29 Thread amonakov at gcc dot gnu.org

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

Alexander Monakov  changed:

   What|Removed |Added

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

--- Comment #7 from Alexander Monakov  ---
I have filed this issue previously as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655 (unfixed, has minimized
repro). A workaround on gcc side is -fno-ipa-ra.

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

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

2015-11-29 Thread amonakov at gcc dot gnu.org

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||kfischer at college dot 
harvard.ed
   ||u

--- Comment #2 from Alexander Monakov  ---
*** Bug 68601 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/68601] GCC miscompiles LLVM on Windows

2015-11-29 Thread kfischer at college dot harvard.edu

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

--- Comment #8 from Keno Fischer  ---
Great, thank you, I was having quite a bit of trouble trying to reduce this
one.

[Bug c/16895] incorrect warning when const parameter passed from non-const argument

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #8 from Andrew Pinski  ---
Mark as a dup of bug 17654 because it references the might be changing in C but
that did not happen.

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

[Bug c/17654] Pointless warning on incompatible pointer types

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||Brian.Inglis at SystematicSw 
dot a
   ||b.ca

--- Comment #10 from Andrew Pinski  ---
*** Bug 16895 has been marked as a duplicate of this bug. ***

[Bug c/68612] Const-compatibility in C

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

--- Comment #2 from Andrew Pinski  ---
Really PR 16895.

[Bug c/16895] incorrect warning when const parameter passed from non-const argument

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||mrolnik at gmail dot com

--- Comment #7 from Andrew Pinski  ---
*** Bug 62037 has been marked as a duplicate of this bug. ***

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

2015-11-29 Thread andi-gcc at firstfloor dot org

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

Andi Kleen  changed:

   What|Removed |Added

 CC||andi-gcc at firstfloor dot org

--- Comment #14 from Andi Kleen  ---
I'm building a current Linux kernel with allyesconfig, and this new warning
causes
1383(!) new warnings in the build.

I think this should be revisited and the warning be turned off again.

[Bug target/66019] Corrupt libstdc++ on AIX 6.1

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||dje at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |5.0

--- Comment #1 from David Edelsohn  ---
GCC 4.9 makes extensive use of aliases and AIX XCOFF semantics are different
than Linux ELF semantics.  This was re-written in GCC 5.  The fix is too
extensive to backport to GCC 4.9.

[Bug c/68612] Const-compatibility in C

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

--- Comment #1 from Andrew Pinski  ---
PR 62037 .

[Bug c/62037] cannot pass 'int **' as a 'int const* const*' parameter

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|CLOSED  |RESOLVED
 Resolution|INVALID |DUPLICATE

--- Comment #5 from Andrew Pinski  ---
Marking as a dup of bug 16895.

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

[Bug target/68609] New: PowerPC reciprocal estimate missed opportunities

2015-11-29 Thread anton at samba dot org

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

Bug ID: 68609
   Summary: PowerPC reciprocal estimate missed opportunities
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anton at samba dot org
  Target Milestone: ---

gcc.target/i386/recip-sqrtf.c shows some missed opportunities for the
reciprocal estimate instructions. One example:

float t3(float a)
{
  return sqrtf(a);
}

On x86 (and PowerPC clang), we use the square root reciprocal estimate
instructions, but PowerPC gcc does not.

[Bug other/68610] New: configure failure in libssp

2015-11-29 Thread gccbugzilla at limegreensocks dot com

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

Bug ID: 68610
   Summary: configure failure in libssp
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gccbugzilla at limegreensocks dot com
  Target Milestone: ---

I was trying to figure out why I was getting this warning from ssp.c in libssp
when building gcc on i386:

  warning: visibility attribute not supported in this configuration; ignored

Configure checks to see if this attribute is supported and sets a #define, so I
was puzzled why that wasn't working.  After looking thru the configure script,
it appears that the configure check is failing because compiling the test code
throws a 'warning' instead of an error:

  conftest.c:12:1: warning: visibility attribute not supported in this
configuration; ignored [-Wattributes]

And the reason it does seems to be that ac_c_werror_flag is assumed to contain
the switch to turn the warning into an error (-Werror), when in fact it is
undefined.  Setting this to -Werror causes the configure check to correctly
detect that visibility isn't supported, and the warning from ssp.c disappears.

A lot of gcc's configure scripts use ac_c_werror_flag, but I'm not sure it ever
gets set to -Werror.  Sometimes it gets set to "yes", but that can't be right.

[Bug c/68611] New: Recommendation for 'cleanup' variable attribute

2015-11-29 Thread alexreg at gmail dot com

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

Bug ID: 68611
   Summary: Recommendation for 'cleanup' variable attribute
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexreg at gmail dot com
  Target Milestone: ---

Presently, the `cleanup_function` parameter to the `cleanup` variable attribute
"must take one parameter, a pointer to a type compatible with the variable".
(see
).
It would be helpful to allow to the function to be compatible more generally –
that is, as far as implicit casts are allowed, when calling a function. For
example, if a `cleanup` attribute is applied to a variable of type `int * *`
and the cleanup function has parameter type `int const * const`, this should be
acceptable, as it is an implicit cast in C.

[Bug c/68612] New: Const-compatibility in C

2015-11-29 Thread alexreg at gmail dot com

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

Bug ID: 68612
   Summary: Const-compatibility in C
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexreg at gmail dot com
  Target Milestone: ---

There is a widely-known deficiency in C involving the passing of arguments to
'more' const-qualified parameters. e.g.

```
void func (int const * const * foo)
{
if (foo)
;
}

int main ()
{
int * * foo = 0;
func (foo);
}
```

fails with

warning: passing argument 1 of 'func' from incompatible pointer type
[-Wincompatible-pointer-types]
note: expected 'const int **' but argument is of type 'int **'

as per the C99 specification. C++ is more liberal in this respect, but no less
safe, since the above will compile without warnings. (Note that if the
parameter type for `func` in the above example is instead `int const * *`,
there exist slightly obscure ways for code to modify `**foo` without warnings
or errors being generated, thus violating const-correctness. This is not the
case as long as the parameter type is `int const * const *`.)

Would it possible to enable a feature on the C compiler and GCC driver for
const-compatibility to work as it does for C++, in the more liberal manner? As
a point of annoyance for many C programmers (in my experience), this would at
least allow those of us who don't care about standards compliance so much to
circumvent this design deficiency.

[Bug c/68612] Const-compatibility in C

2015-11-29 Thread alexreg at gmail dot com

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

Alexander Regueiro  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c/68612] Const-compatibility in C

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

--- Comment #3 from Andrew Pinski  ---
From https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17654#c7 :
That way at present is to use the C++ compiler, if you want the C++ 
const-correctness rules.  Such a change was proposed for C99 in 
.  I do not know 
why it was not adopted although the impression I get is that it was 
proposed too late in the process and there wasn't enough time at the 
relevant meeting.  I would suggest it might be worth proposing such a 
change again when features for C1x are under consideration in some years' 
time; C++ provides the prior art.


So there are two points in this bug report.  One add the extension to GCC and
the other is fix the C standard.

We are not going to accept it as an extension I don't think though.  So you
should see what is going on the C standard side of things.

[Bug tree-optimization/68379] [6 Regression] BB vectorization: definition in block 13 follows the use for SSA_NAME

2015-11-29 Thread su at cs dot ucdavis.edu

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

--- Comment #5 from Zhendong Su  ---
(In reply to Markus Trippelsdorf from comment #4)
> *** Bug 68614 has been marked as a duplicate of this bug. ***

Sorry for the duplicate report, but hope the new C test case will be of use
nonetheless.

[Bug tree-optimization/68614] New: ICE at -O3 on x86_64-linux-gnu (verify_ssa failed)

2015-11-29 Thread su at cs dot ucdavis.edu

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

Bug ID: 68614
   Summary: ICE at -O3 on x86_64-linux-gnu (verify_ssa failed)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

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

It is a regression from 5.2.x. 

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20151128 (experimental) [trunk revision 231032] (GCC) 
$ 
$ gcc-trunk -O2 -c small.c
$ gcc-5.2 -O3 -c small.c
$ 
$ gcc-trunk -O3 -c small.c
small.c: In function ‘fn1’:
small.c:4:1: error: definition in block 2 follows the use
 fn1 ()
 ^~~

for SSA_NAME: _18 in statement:
vectp.19_36 = [_18];
small.c:4:1: internal compiler error: verify_ssa failed
0xcf9adc verify_ssa(bool, bool)
../../gcc-trunk/gcc/tree-ssa.c:1039
0xa28f8d execute_function_todo
../../gcc-trunk/gcc/passes.c:1965
0xa2982b execute_todo
../../gcc-trunk/gcc/passes.c:2010
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 


---


int a, b[3], c[3][5];

void
fn1 ()
{
  int e;
  for (a = 2; a >= 0; a--)
for (e = 0; e < 4; e++)
  c[a][e] = b[a];
}

[Bug tree-optimization/68379] [6 Regression] BB vectorization: definition in block 13 follows the use for SSA_NAME

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #6 from Markus Trippelsdorf  ---
(In reply to Zhendong Su from comment #5)
> (In reply to Markus Trippelsdorf from comment #4)
> > *** Bug 68614 has been marked as a duplicate of this bug. ***
> 
> Sorry for the duplicate report, but hope the new C test case will be of use
> nonetheless.

No need to apologize. Your testcase is most welcome.

[Bug tree-optimization/68379] [6 Regression] BB vectorization: definition in block 13 follows the use for SSA_NAME

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||su at cs dot ucdavis.edu

--- Comment #4 from Markus Trippelsdorf  ---
*** Bug 68614 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/68614] ICE at -O3 on x86_64-linux-gnu (verify_ssa failed)