[Bug fortran/57496] I/O: WRITE(*,*) HUGE(0._10) gives SIGFPE with -ffpe-trap=overflow

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org,
   ||fxcoudert at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |fxcoudert at gcc dot 
gnu.org

--- Comment #6 from Francois-Xavier Coudert  ---
On x86_64-apple-darwin14, I can confirm this occurs on 5.2.0 but appears to
have been fixed on trunk.

Also, I don't understand how Tobias' patch worked, because in libgfortran.h we
have for a long time redefined all the type-generic floating-point macros in
terms of "safe to use" GCC builtins:


/* The C99 classification macros isfinite, isinf, isnan, isnormal
   and signbit are broken or inconsistent on quite a few targets.
   So, we use GCC's builtins instead.

   Another advantage for GCC's builtins for these type-generic macros
   is that it handles floating-point types that the system headers
   may not support (like __float128).  */

#undef isnan
#define isnan(x) __builtin_isnan(x)
#undef isfinite
#define isfinite(x) __builtin_isfinite(x)
#undef isinf
#define isinf(x) __builtin_isinf(x)
#undef isnormal
#define isnormal(x) __builtin_isnormal(x)
#undef signbit
#define signbit(x) __builtin_signbit(x)

[Bug libfortran/57496] I/O: WRITE(*,*) HUGE(0._10) gives SIGFPE with -ffpe-trap=overflow

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

  Component|fortran |libfortran

--- Comment #7 from Francois-Xavier Coudert  ---
(In reply to Francois-Xavier Coudert from comment #6)
> Also, I don't understand how Tobias' patch worked, because in libgfortran.h
> we have for a long time redefined all the type-generic floating-point macros
> in terms of "safe to use" GCC builtins

In fact, I can actually reverse the patch and the testcase does not fail.

Index: io/write_float.def
===
--- io/write_float.def  (revision 226894)
+++ io/write_float.def  (working copy)
@@ -958,33 +958,6 @@ __qmath_(quadmath_snprintf) (buffer, siz
 #endif


-#if defined(GFC_REAL_16_IS_FLOAT128)
-#define ISFINITE2Q(val) finiteq(val)
-#endif
-#define ISFINITE2(val) isfinite(val)
-#define ISFINITE2L(val) isfinite(val)
-
-#define ISFINITE(suff,val) TOKENPASTE(ISFINITE2,suff)(val)
-
-
-#if defined(GFC_REAL_16_IS_FLOAT128)
-#define SIGNBIT2Q(val) signbitq(val)
-#endif
-#define SIGNBIT2(val) signbit(val)
-#define SIGNBIT2L(val) signbit(val)
-
-#define SIGNBIT(suff,val) TOKENPASTE(SIGNBIT2,suff)(val)
-
-
-#if defined(GFC_REAL_16_IS_FLOAT128)
-#define ISNAN2Q(val) isnanq(val)
-#endif
-#define ISNAN2(val) isnan(val)
-#define ISNAN2L(val) isnan(val)
-
-#define ISNAN(suff,val) TOKENPASTE(ISNAN2,suff)(val)
-
-

 /* Generate corresponding I/O format for FMT_G and output.
The rules to translate FMT_G to FMT_E or FMT_F from DEC fortran
@@ -1164,7 +1137,7 @@ OUTPUT_FLOAT_FMT_G(16,L)
 {\
 volatile GFC_REAL_ ## x tmp, one = 1.0;\
 tmp = * (GFC_REAL_ ## x *)source;\
-if (ISFINITE (y,tmp))\
+if (isfinite (tmp))\
   {\
nprinted = DTOA(y,0,tmp);\
int e = atoi (&buffer[4]);\
@@ -1235,10 +1208,10 @@ determine_en_precision (st_parameter_dt 
 {\
GFC_REAL_ ## x tmp;\
tmp = * (GFC_REAL_ ## x *)source;\
-   sign_bit = SIGNBIT (y,tmp);\
-   if (!ISFINITE (y,tmp))\
+   sign_bit = signbit (tmp);\
+   if (!isfinite (tmp))\
  { \
-   write_infnan (dtp, f, ISNAN (y,tmp), sign_bit);\
+   write_infnan (dtp, f, isnan (tmp), sign_bit);\
return;\
  }\
tmp = sign_bit ? -tmp : tmp;\

[Bug target/66648] [4.9/5/6 regression] incorrect memcpy expansion with unrolled_loop strategy at -O2

[uros at gcc dot gnu.org]

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

--- Comment #6 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Aug 16 17:50:20 2015
New Revision: 226925

URL: https://gcc.gnu.org/viewcvs?rev=226925&root=gcc&view=rev
Log:
Backport from mainline:
2015-07-25  Uros Bizjak  

PR target/66648
* config/i386/i386.c (ix86_expand_set_or_movmem): Emit main loop
execution guard when min_size is less than size_needed.

testsuite/ChangeLog:

Backport from mainline:
2015-07-25  Uros Bizjak  

PR target/66648
* gcc.target/i386/pr66648.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr66648.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/i386.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/66648] [4.9/5/6 regression] incorrect memcpy expansion with unrolled_loop strategy at -O2

[uros at gcc dot gnu.org]

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

--- Comment #7 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Aug 16 17:52:51 2015
New Revision: 226926

URL: https://gcc.gnu.org/viewcvs?rev=226926&root=gcc&view=rev
Log:
Backport from mainline:
2015-07-25  Uros Bizjak  

PR target/66648
* config/i386/i386.c (ix86_expand_set_or_movmem): Emit main loop
execution guard when min_size is less than size_needed.

testsuite/ChangeLog:

Backport from mainline:
2015-07-25  Uros Bizjak  

PR target/66648
* gcc.target/i386/pr66648.c: New test.


Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr66648.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/i386/i386.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug target/66648] [4.9/5/6 regression] incorrect memcpy expansion with unrolled_loop strategy at -O2

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target|x86_64-*-linux  |x86
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Uroš Bizjak  ---
Fixed everywhere.

[Bug fortran/52846] [F2008] Support submodules

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #26 from Joost VandeVondele  
---
One more datapoint on the .smod / .mod issue. 

I ran into the first package that fails to build with 6.0 because of this.
libxc (version 2.2.2, Tobias Burnus actually being one of the authors), relies
on a configure macro named ax_cv_f90_modext this macro now leads in the
Makefile to :

[...]
am__untar = $${TAR-tar} xf -
ax_cv_f90_modext = mod
smod
bindir = ${exec_prefix}/bin
[...]

which leads to an obvious:> make -j
Makefile:319: *** missing separator.  Stop.

While arguably this is a bug in the ax_cv_f90_modext macro, it might be
indicative of possible problems 'in the wild'.

However, I do like the idea of having only public info in the .mod, and hence
improving the recompilation cascade problem.

[Bug c++/67240] New: [concepts] Implicit conversion constraints are not respected

[sebi707 at gmail dot com]

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

Bug ID: 67240
   Summary: [concepts] Implicit conversion constraints are not
respected
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebi707 at gmail dot com
  Target Milestone: ---

Using the trailing return type to add constraints does not work in some cases.
The following code should not compile:

int foo(int x)
{
return x;
}

template 
concept bool C1 = requires (T x) {
{foo(x)} -> int&;
};

template 
concept bool C2 = requires (T x) {
{foo(x)} -> void;
};

static_assert( C1 );
static_assert( C2 );

However this compiles just fine with r226884.

[Bug middle-end/67241] New: [6 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test

[hjl.tools at gmail dot com]

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

Bug ID: 67241
   Summary: [6 Regression] FAIL:
23_containers/unordered_set/insert/hash_policy.cc
execution test
   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
  Target Milestone: ---

On Linux/x32, r226814 caused:

FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test

[Bug c++/63887] abi_tag confuses demangler on destructor names

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ian at airs dot com
 Resolution|--- |FIXED

--- Comment #1 from Ian Lance Taylor  ---
Should be fixed by

2015-08-15  Ian Lance Taylor  

* cp-demangle.c (d_abi_tags): Preserve di->last_name across any
ABI tags.

although in practice the fix will have to propagate out to the linker.

[Bug fortran/54656] ICE with software REAL(16) for NORM2

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

   Last reconfirmed|2012-09-21 00:00:00 |2015-8-16
 CC||fxcoudert at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |fxcoudert at gcc dot 
gnu.org

--- Comment #3 from Francois-Xavier Coudert  ---
Index: trans-intrinsic.c
===
--- trans-intrinsic.c   (revision 226924)
+++ trans-intrinsic.c   (working copy)
@@ -676,6 +676,11 @@ gfc_build_intrinsic_lib_fndecls (void)
 #undef DEFINE_MATH_BUILTIN
 #undef DEFINE_MATH_BUILTIN_C

+/* There is one built-in we defined manually, because it gets called
+   with builtin_decl_for_precision() or builtin_decl_for_float_type()
+   even though it is not an OTHER_BUILTIN: it is SQRT.  */
+quad_decls[BUILT_IN_SQRT] = define_quad_builtin ("sqrtq", func_1, true);
+
   }

   /* Add GCC builtin functions.  */

[Bug fortran/54656] ICE with software REAL(16) for NORM2

[fxcoudert at gcc dot gnu.org]

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

--- Comment #4 from Francois-Xavier Coudert  ---
Author: fxcoudert
Date: Sun Aug 16 19:47:02 2015
New Revision: 226929

URL: https://gcc.gnu.org/viewcvs?rev=226929&root=gcc&view=rev
Log:
PR fortran/54656

* trans-intrinsic.c (gfc_build_intrinsic_lib_fndecls): Add decl
for quadruple precision BUILT_IN_SQRT.

* gfortran.dg/norm_4.f90: Rename to...
* gfortran.dg/norm2_4.f90: this.
* gfortran.dg/norm2_5.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/norm2_4.f90
  - copied unchanged from r226894,
trunk/gcc/testsuite/gfortran.dg/norm_4.f90
trunk/gcc/testsuite/gfortran.dg/norm2_5.f90
Removed:
trunk/gcc/testsuite/gfortran.dg/norm_4.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/54656] ICE with software REAL(16) for NORM2

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #5 from Francois-Xavier Coudert  ---
Fixed on trunk. Probably not worth a backport.

[Bug fortran/55548] SYSTEM_CLOCK with integer(8) provides nanosecond resolution, but only microsecond precision (without -lrt)

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

--- Comment #4 from Francois-Xavier Coudert  ---
(In reply to janus from comment #3)
> Leftover to-do item:
> 
> > Using SYSTEM_CLOCK with integer(16) arguments currently results in:
> > sysclock.f90:(.text+0x455): undefined reference to 
> > `_gfortran_system_clock_16'
> 
> ... add an integer(16) version of SYSTEM_CLOCK!

This was one sometime before gfortran 5.0. Closing!

[Bug c/67242] New: Missing optimization with float

[f.boesing at gmx dot de]

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

Bug ID: 67242
   Summary: Missing optimization with float
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: f.boesing at gmx dot de
  Target Milestone: ---

testcase:

int n, dummy;
float dummyfloat;

void bug(void) 
{
 for(n=0; n<1000; n++)
dummy = n;
 for(n=0; n<1000; n++)
dummyfloat = n;
}

the first loop (dummy=) is optimized away with -O2 and -O3
the second (dummyfloat=) NOT.

Tested with 4.9.2 & 4.9.3, targets x86-64, arm-thumb and arm.

commandline: gcc -O2 bug.c -S

[Bug c/67242] Missing optimization with float

[f.boesing at gmx dot de]

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

--- Comment #1 from Frank  ---
works ok with local variables.

[Bug target/66232] -fPIC -fno-plt -mx32 fails to generate indirect branch via GOT

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2015-08-16
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #7 from H.J. Lu  ---
It fails with

# make check-gcc RUNTESTFLAGS="--target_board='unix{-mx32\
-maddress-mode=long}' i386.exp=pr66232-*.c"
...
FAIL: gcc.target/i386/pr66232-1.c scan-assembler jmp[ \t]*.bar@GOTPCREL
FAIL: gcc.target/i386/pr66232-2.c scan-assembler call[ \t]*.bar@GOTPCREL
FAIL: gcc.target/i386/pr66232-3.c scan-assembler jmp[ \t]*.bar@GOTPCREL
FAIL: gcc.target/i386/pr66232-4.c scan-assembler call[ \t]*.bar@GOTPCREL

[Bug c/67242] Missing optimization with float

[f.boesing at gmx dot de]

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

--- Comment #2 from Frank  ---
x86-64:



.file   "bug.c"
.section.text.unlikely,"x"
.LCOLDB0:
.text
.LHOTB0:
.p2align 4,,15
.globl  bug
.defbug;.scl2;  .type   32; .endef
.seh_proc   bug
bug:
.seh_endprologue
movl$999, dummy(%rip)
xorl%eax, %eax
.p2align 4,,10
.L2:
pxor%xmm0, %xmm0
cvtsi2ss%eax, %xmm0
addl$1, %eax
cmpl$1000, %eax
jne .L2
movss   %xmm0, dummyfloat(%rip)
movl$1000, n(%rip)
ret
.seh_endproc
.section.text.unlikely,"x"
.LCOLDE0:
.text
.LHOTE0:
.comm   dummyfloat, 4, 2
.comm   dummy, 4, 2
.comm   n, 4, 2
.ident  "GCC: (tdm64-1) 4.9.2"







arm-thumb, soft float:
.cpu arm7tdmi
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 1
.eabi_attribute 30, 2
.eabi_attribute 34, 0
.eabi_attribute 18, 4
.code   16
.file   "bug.c"
.global __aeabi_i2f
.text
.align  2
.global bug
.code   16
.thumb_func
.type   bug, %function
bug:
push{r3, r4, r5, lr}
mov r5, #250
mov r4, #0
ldr r2, .L5
ldr r3, .L5+4
str r2, [r3]
lsl r5, r5, #2
.L2:
mov r0, r4
add r4, r4, #1
bl  __aeabi_i2f
cmp r4, r5
bne .L2
ldr r3, .L5+8
str r0, [r3]
ldr r3, .L5+12
@ sp needed
str r4, [r3]
pop {r3, r4, r5}
pop {r0}
bx  r0
.L6:
.align  2
.L5:
.word   999
.word   dummy
.word   dummyfloat
.word   n
.size   bug, .-bug
.comm   dummyfloat,4,4
.comm   dummy,4,4
.comm   n,4,4
.ident  "GCC: (GNU Tools for ARM Embedded Processors) 4.9.3 20150529
(release) [ARM/embedded-4_9-branch revision 224288]"

[Bug fortran/51175] Memory Leak with Transfer intrinsic

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||fxcoudert at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |4.7.0

--- Comment #3 from Francois-Xavier Coudert  ---
This was fixed in 4.7 and later.

[Bug other/65794] Building crossback fails: No rule to make target `auto-build.h', needed by `build/genmddeps.o'

[saper at marcincieslak dot com]

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

Marcin Cieślak  changed:

   What|Removed |Added

 CC||saper at marcincieslak dot com

--- Comment #1 from Marcin Cieślak  ---
I have the same problem on solaris 2.9 using GCC:

I am using gcc 4.9.3 (compiled as a 32-bit binary) to compile gcc 4.9.3 as a
64-bit binary:


env \
BOOT_CFLAGS="-m64 -mcpu=ultrasparc3" \
BOOT_CXXFLAGS="-m64 -mcpu=ultrasparc3" \
CFLAGS="-m64 -mcpu=ultrasparc3" \
CXXFLAGS="-m64 -mcpu=ultrasparc3" \
CC=$HOME/sparcv7/bin/gcc \
CXX=$HOME/sparcv7/bin/g++ \
LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${HOME}/sparcv9/lib \
AR="/usr/ccs/bin/ar" \
RANLIB="/usr/ccs/bin/ranlib" \
AS="/usr/ccs/bin/as" \
$HOME/src/gcc-4.9.3/configure \
 --prefix=$HOME/sparcv9\
 --with-gmp=$HOME/sparcv9  \
 --with-mpfr=$HOME/sparcv9 \
 --with-mpc=$HOME/sparcv9  \
 --with-isl=$HOME/sparcv9  \
 --with-cloog=$HOME/sparcv9  \
 --without-gnu-as --without-gnu-ld \
 --enable-languages=c,c++ --enable-obsolete \
 --host=sparc64-sun-solaris2.9 \
 --target=sparc64-sun-solaris2.9 \
 --build=sparc-sun-solaris2.9 \
 --disable-bootstrap


Failure:

make[2]: Entering directory '/home/admini/saper/build/gcc-4.9.3/gcc'
TARGET_CPU_DEFAULT="" \
HEADERS="auto-host.h ansidecl.h" DEFINES="" \
/bin/bash /home/admini/saper/src/gcc-4.9.3/gcc/mkconfig.sh config.h
TARGET_CPU_DEFAULT="TARGET_CPU_v9" \
HEADERS="options.h insn-constants.h config/sparc/default-64.h
config/sparc/biarch64.h config/vxworks-dummy.h config/sparc/sparc.h
config/dbxelf.h config/elfos.h config/sparc/sysv4.h config/sol2.h
config/sparc/sol2.h config/sol2-bi.h config/sparc/tso.h config/initfini-array.h
defaults.h" DEFINES="LIBC_GLIBC=1 LIBC_UCLIBC=2 LIBC_BIONIC=3" \
/bin/bash /home/admini/saper/src/gcc-4.9.3/gcc/mkconfig.sh tm.h
TARGET_CPU_DEFAULT="" \
HEADERS="config/sparc/sparc-protos.h config/sol2-protos.h tm-preds.h"
DEFINES="" \
/bin/bash /home/admini/saper/src/gcc-4.9.3/gcc/mkconfig.sh tm_p.h
TARGET_CPU_DEFAULT="" \
HEADERS="auto-build.h ansidecl.h" DEFINES="" \
/bin/bash /home/admini/saper/src/gcc-4.9.3/gcc/mkconfig.sh bconfig.h
make[2]: *** No rule to make target 'auto-build.h', needed by
'build/genmddeps.o'.  Stop.
make[2]: Leaving directory '/home/admini/saper/build/gcc-4.9.3/gcc'
Makefile:3972: recipe for target 'all-gcc' failed
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory '/home/admini/saper/build/gcc-4.9.3'
Makefile:859: recipe for target 'all' failed
make: *** [all] Error 2

[Bug tree-optimization/67153] [5/6 Regression] integer optimizations 53% slower than std::bitset<>

[ncm at cantrip dot org]

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

--- Comment #13 from ncm at cantrip dot org ---
This is essentially the entire difference between the versions of
puzzlegen-int.cc without, and with, the added "++count;" line 
referenced above (modulo register assignments and branch labels)
that sidesteps the +50% pessimization:

(Asm is from "g++ -fverbose-asm -std=c++14 -O3 -Wall -S $SRC.cc" using
g++ (Debian 5.2.1-15) 5.2.1 20150808, with no instruction-set extensions 
specified.  Output with "-mbmi -mbmi2" has different instructions, but
they do not noticeably affect run time on Haswell i7-4770.)

@@ -793,25 +793,26 @@
 .L141:
movl(%rdi), %esi# MEM[base: _244, offset: 0], word
testl   %r11d, %esi # D.66634, word
jne .L138   #,
xorl%eax, %eax  # tmp419
cmpl%esi, %r12d # word, seven
leaq208(%rsp), %rcx #, tmp574
sete%al #, tmp419
movl%r12d, %edx # seven, seven
leal1(%rax,%rax), %r8d  #, D.66619
.p2align 4,,10
.p2align 3
  .L140:
movl%edx, %eax  # seven, D.66634
negl%eax# D.66634
andl%edx, %eax  # seven, D.66622
testl   %eax, %esi  # D.66622, word
je  .L139   #,
addl%r8d, 24(%rcx)  # D.66619, MEM[base: _207, offset: 24B]
+   addl$1, %ebx#, count
 .L139:
notl%eax# D.66622
subq$4, %rcx#, ivtmp.424
andl%eax, %edx  # D.66622, seven
jne .L140   #,
addq$4, %rdi#, ivtmp.428
cmpq%rdi, %r10  # ivtmp.428, D.66637
jne .L141   #,

I tried a version of the program with a fixed-length loop (over 
'place' in [6..0]) so that branches do not depend on results of
"rest &= ~-rest".  The compiler unrolled the loop, but the program
ran at pessimized speed with or without the "++count" line.

I am very curious whether this has been reproduced on others' Haswells,
and on Ivybridge and Skylake.

[Bug other/65794] Building crossback fails: No rule to make target `auto-build.h', needed by `build/genmddeps.o'

[saper at marcincieslak dot com]

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

--- Comment #2 from Marcin Cieślak  ---
Created attachment 36191
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36191&action=edit
Patch to Makefile to proceed with the build

The attached patch allowed me to continue the build. Probably this patch is not
the correct fix though.

It can be applied to Makefile.in prior to the configure stage. It looks like
"config.status" has no special knowledge of the "auto-build.h" header.

(Basically in my case the generated files - auto-host.h and auto-build.h were
identical, except for the comment in line 1)

[Bug c/67243] New: Wrong Message of -Wvla for Standard ISO C90 However Emitted with -std=c11

[chengniansun at gmail dot com]

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

Bug ID: 67243
   Summary: Wrong Message of -Wvla for Standard ISO C90 However
Emitted with -std=c11
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

When I compile the code "int array[4.3];", in addition to the error, GCC also
emits a -Wvla warning saying that ISO C90 forbids this. However, I specify
-std=c11 in the command line, and IMHO this is at least an inconsistency
between errors and error messages. 

$: cat t.c
int array[4.3];
$: gcc-trunk -c -Wvla -std=c11 -pedantic t.c
t.c:1:5: error: size of array ‘array’ has non-integer type
 int array[4.3];
 ^
t.c:1:1: warning: variably modified ‘array’ at file scope
 int array[4.3];
 ^
t.c:1:1: warning: ISO C90 forbids array ‘array’ whose size can’t be evaluated
[-Wvla]
$: 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
--enable-languages=c,c++,objc,obj-c++,fortran,lto --disable-werror
--with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk
--with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk
--prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 6.0.0 20150815 (experimental) [trunk revision 226911] (GCC) 
$:

[Bug c/67243] Wrong Message of -Wvla for Standard ISO C90 However Emitted with -std=c11

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-16
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
It is also useless to give such warning after such error.

I'm afraid the way GCC reports most extensions is very fragile in this way. It
doesn't affect only Wvla. It would be nice to discuss/design/agree on a
canonical and future-proof way to report:

* Pure GNU extensions, not accepted by any standard.
* Features accepted by some standard but that are extensions for other
standards (like C++ style comments).

The latter requires some future-proof way of reporting:

* Extensions that are forbidden up to a particular standard.

* Extensions that were accepted but are forbidden now (not sure if there is
such case at all).

(It is kind of ironic that Clang is fair more clear pointing out when something
is a "GNU extension". In some way, Clang is doing more promotion of GNU than
GCC!)

[Bug c/67243] Wrong Message of -Wvla for Standard ISO C90 However Emitted with -std=c11

[manu at gcc dot gnu.org]

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

--- Comment #2 from Manuel López-Ibáñez  ---
Moreover, since VLAs are not an extension in C99, the text of Wvla is wrong
always for -std=c99. 

void square(int num) {
  int array[num];
}

With -std=c99 -Wpedantic there is no warning.
With -std=c99 -Wvla, it mentions ISO C90, which is irrelevant.
Clang just says: "variable length array used"

[Bug tree-optimization/67153] [5/6 Regression] integer optimizations 53% slower than std::bitset<>

[ncm at cantrip dot org]

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

--- Comment #14 from ncm at cantrip dot org ---
A notable difference between g++-4.9 output and g++-5 output is that,
while both hoist the "(word == seven)" comparison out of the innermost
loop, gcc-4.9 splits inner loop into two versions, one that increments 
scores by 3 and another that increments by 1, where g++-5 saves 3 or 1
into a register and uses the same inner loop for both cases.

Rewriting the critical loop
  - to run with separate inner loops
 - does not slow down the fast g++-4.9-compiled program, but
 - fails to speed up the slow g++-5-compiled program.
  - to precompute a 1 or 3 increment, with one inner loop for both cases
 - does slow down the previously fast g++-4.9-compiled program, and
 - does not change the speed of the slow g++-5-compiled program

[Bug c++/65201] range-for range-init containing variable named like for-range-declaration iterates over uninitialized for-range-declaration

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||miyuki at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #3 from Mikhail Maltsev  ---
> `range-init` most certainly can't refer to `for-range-declaration`, as of 
> what I understand.

I believe, it's a dup of PR54430.

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

[Bug c++/54430] [C++11] For-Loop: Scope of iterating variable begins too early

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 CC||bloerwald at googlemail dot com

--- Comment #6 from Mikhail Maltsev  ---
*** Bug 65201 has been marked as a duplicate of this bug. ***

[Bug c++/67238] New: [C++11][C++14]cc1plus crash for nested decltype expression in parameter pack in trailing return type when '-g' enabled

[webrown.cpp at gmail dot com]

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

Bug ID: 67238
   Summary: [C++11][C++14]cc1plus crash for nested decltype
expression in parameter pack in trailing return type
when '-g' enabled
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frankhb1989 at gmail dot com
CC: webrown.cpp at gmail dot com
  Target Milestone: ---
CC: webrown.cpp at gmail dot com

g++ -v
...
gcc version 5.2.0 (Rev3, Built by MSYS2 project)

Case:
//a.cc
template
void
g(F&&, A&&...)
{}

template
auto
h(A&&... a) -> decltype(g(0, g(a)...))
{
return g([]{}, a...); // Crash if any error here.
}

int
main()
{
h();
}

g++ a.cc -std=c++11 -g1

The frontend crashes, and no diagnostics shown for this particular case on my
machine. Otherwise there may be segfault. Same for -std=c++14, but '-g0' seems
to be OK.

BTW, it seems that nested decltype expression in trailing return types are
often buggy playing with lambdas. Should there be any other reports?

[Bug tree-optimization/67153] [5/6 Regression] integer optimizations 53% slower than std::bitset<>

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 CC||miyuki at gcc dot gnu.org

--- Comment #15 from Mikhail Maltsev  ---
(In reply to ncm from comment #13)
> I am very curious whether this has been reproduced on others' Haswells,
> and on Ivybridge and Skylake.

I could reproduce this with Haswell i7-5820K (affected) and also tested on
Ivybridge i7-3770K (not affected).

Haswell:

GCC 4.9.3 native

real0m0.150s
user0m0.149s
sys 0m0.001s
GCC 6.0.0 native

real0m0.213s
user0m0.212s
sys 0m0.000s
GCC 6.0.0 native + count

real0m0.166s
user0m0.165s
sys 0m0.000s



GCC 4.9.3 generic

real0m0.128s
user0m0.127s
sys 0m0.001s
GCC 6.0.0 generic

real0m0.213s
user0m0.213s
sys 0m0.000s
GCC 6.0.0 generic + count

real0m0.125s
user0m0.124s
sys 0m0.000s


Ivybridge:

GCC 4.9.2 native

real0m0.218s
user0m0.216s
sys 0m0.000s
GCC 6.0.0 native

real0m0.186s
user0m0.184s
sys 0m0.000s
GCC 6.0.0 native + count

real0m0.266s
user0m0.264s
sys 0m0.000s



GCC 4.9.2 generic

real0m0.224s
user0m0.220s
sys 0m0.004s
GCC 6.0.0 generic

real0m0.183s
user0m0.180s
sys 0m0.000s
GCC 6.0.0 generic + count

real0m0.181s
user0m0.176s
sys 0m0.004s

Here "native" means "-march=native -mtune=native", "generic" means no arch
options. "+count" means adding a counter into the loop and writing it's value
to a global volatile variable after the loop.

[Bug tree-optimization/16107] missed optimization with some math function builtins

[naveenh at gcc dot gnu.org]

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

--- Comment #7 from naveenh at gcc dot gnu.org ---
Author: naveenh
Date: Mon Aug 17 04:47:45 2015
New Revision: 226934

URL: https://gcc.gnu.org/viewcvs?rev=226934&root=gcc&view=rev
Log:
2015-08-17  Richard Biener  
Naveen H.S  

PR middle-end/16107
* match.pd (div (coss (op @0) : New simplifier.


Added:
trunk/gcc/testsuite/gcc.dg/pr16107.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd

[Bug c++/67244] New: internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:1801

[shadewind at gmail dot com]

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

Bug ID: 67244
   Summary: internal compiler error: in gimplify_var_or_parm_decl,
at gimplify.c:1801
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shadewind at gmail dot com
  Target Milestone: ---

Created attachment 36192
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36192&action=edit
The preprocessed source

Internal compiler error with GCC 5.2.0 when building the attached preprocessed
source on OS X 10.10.2:

build_gcc❯ g++-5 -std=c++11 Unique.pp.cpp -o test  
   
   
rapidcheck/git/dev 
../test/gen/ContainerTests/Unique.cpp: In lambda function:
../test/gen/ContainerTests/Unique.cpp:59:37: internal compiler error: in
gimplify_var_or_parm_decl, at gimplify.c:1801
 return std::count_if(begin(elements),
 ^

../test/gen/ContainerTests/Unique.cpp:59:37: internal compiler error: Abort
trap: 6
g++-5: internal compiler error: Abort trap: 6 (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/62272] Gimplify throws error on method call from inside nested lambdas

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||ppluzhnikov at google dot com

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

[Bug c++/62272] Gimplify throws error on method call from inside nested lambdas

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||shadewind at gmail dot com

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

[Bug c++/58907] [c++11] ICE in gimplify_var_or_parm_decl, at gimplify.c:NNNN

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
dup.

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

[Bug c++/54367] [meta-bug] lambda expressions

[trippels at gcc dot gnu.org]

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

Bug 58907 Summary: [c++11] ICE in gimplify_var_or_parm_decl, at gimplify.c:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58907

   What|Removed |Added

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

[Bug c++/67244] internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:1801

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
dup.

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