[Bug target/77610] [sh] memcpy is wrongly inlined even for large copies

[olegendo at gcc dot gnu.org]

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

--- Comment #6 from Oleg Endo  ---
(In reply to Rich Felker from comment #5)
> Of course, fancy memcpy in general is only a win beyond a certain size. For
> DMA I did not mean I want to use DMA for any size beyond gcc's proposed
> function-call threshold. Rather, the vdso-provided function would choose
> what to do appropriately for the hardware. But on J2 (nommu, no special
> kernel mode) I suspect DMA could be a win at sizes as low as 256 bytes, with
> spin-to-completion and a lock shared between user (vdso) and kernel rather
> than using a syscall (not sure this is justified, though). Using a syscall
> with sleep-during-dma would have a significantly larger threshold before
> it's worthwhile.

I see.  Anyway, I agree that something like attachment 39642 is useful.

> Regarding how I measured kernel performance increase, I was just looking at
> boot timing with printk timestamps enabled. The main time consumer is
> unpacking initramfs.

Ah right, that sounds like copying memory around.  Do you happen to have any
other runtime measurements?

[Bug target/77610] [sh] memcpy is wrongly inlined even for large copies

[bugdal at aerifal dot cx]

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

--- Comment #5 from Rich Felker  ---
Of course, fancy memcpy in general is only a win beyond a certain size. For DMA
I did not mean I want to use DMA for any size beyond gcc's proposed
function-call threshold. Rather, the vdso-provided function would choose what
to do appropriately for the hardware. But on J2 (nommu, no special kernel mode)
I suspect DMA could be a win at sizes as low as 256 bytes, with
spin-to-completion and a lock shared between user (vdso) and kernel rather than
using a syscall (not sure this is justified, though). Using a syscall with
sleep-during-dma would have a significantly larger threshold before it's
worthwhile.

Regarding how I measured kernel performance increase, I was just looking at
boot timing with printk timestamps enabled. The main time consumer is unpacking
initramfs.

[Bug tree-optimization/72835] [7 Regression] Incorrect arithmetic optimization involving bitfield arguments

[kugan at gcc dot gnu.org]

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

--- Comment #5 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Wed Sep 21 03:28:24 2016
New Revision: 240299

URL: https://gcc.gnu.org/viewcvs?rev=240299=gcc=rev
Log:
Incorrect arithmetic optimization involving bitfield arguments

gcc/ChangeLog:

2016-09-21  Kugan Vivekanandarajah  

PR tree-optimization/72835
* tree-ssa-reassoc.c (make_new_ssa_for_def): New.
(make_new_ssa_for_all_defs): Likewise.
(zero_one_operation): Replace all SSA_NAMEs defined in the chain.


gcc/testsuite/ChangeLog:

2016-09-21  Kugan Vivekanandarajah  

PR tree-optimization/72835
* gcc.dg/tree-ssa/pr72835.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr72835.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-reassoc.c

[Bug middle-end/77672] New: wrong rich location in warning: writing a terminating nul past the end

[msebor at gcc dot gnu.org]

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

Bug ID: 77672
   Summary: wrong rich location in warning: writing a terminating
nul past the end
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Most -Wformat-length warnings underscore the part of the format string that
causes a buffer overflow.  For example, in the call to sprintf in function f
below the exclamation point (!) is underscored in format character because it's
written past the end of the destination.

However, when the terminating nul character overflows the destination, the
whole format string rather than the (invisible) nul character is underscored. 
The expected output in this case is one of the following (or something
similar):

   sprintf (d, "%-s", "abc");
   ^
or

   sprintf (d, "%-s", "abc");
   ^

This appears to be a limitation of the substring_loc class which is capable of
underscoring the whole format string, including the quotes, but which doesn't
make it possible to point the caret at the closing quote.

$ cat v.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -S -Wall
-Wextra -Wpedantic v.c
char d[3];

extern int sprintf (char*, const char*, ...);

void f (void) {
  sprintf (d, "%-s!", "abc");
}

void g (void) {
  sprintf (d, "%-s", "abc");
}

v.c: In function ‘f’:
v.c:6:19: warning: writing format character ‘!’ at offset 3 past the end of the
destination [-Wformat-length=]
   sprintf (d, "%-s!", "abc");
   ^
v.c:6:3: note: format output 5 bytes into a destination of size 3
   sprintf (d, "%-s!", "abc");
   ^~
v.c: In function ‘g’:
v.c:10:15: warning: writing a terminating nul past the end of the destination
[-Wformat-length=]
   sprintf (d, "%-s", "abc");
   ^
v.c:10:3: note: format output 4 bytes into a destination of size 3
   sprintf (d, "%-s", "abc");
   ^

[Bug middle-end/77671] missing -Wformat-length warning on sprintf overflow with "%s"

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
Summary|missing -Wformat-length |missing -Wformat-length
   |warning on overflow  %s |warning on sprintf overflow
   ||with "%s"

--- Comment #1 from Martin Sebor  ---
As the test case in comment #0 shows, GCC issues a -Wformat-length warning for
the call in function f but fails to do the same thing for the equivalent call
in function g.

[Bug middle-end/77671] New: missing -Wformat-length warning on overflow %s

[msebor at gcc dot gnu.org]

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

Bug ID: 77671
   Summary: missing -Wformat-length warning on overflow  %s
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

$ cat v.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -S -Wall
-Wextra -Wpedantic v.c
char d[3];

extern int sprintf (char*, const char*, ...);

void f (void) {
  sprintf (d, "%-s", "abcd");
}

void g (void) {
  sprintf (d, "%s", "abcd");
}

v.c: In function ‘f’:
v.c:6:16: warning: ‘%-s’ directive writing 4 bytes into a region of size 3
[-Wformat-length=]
   sprintf (d, "%-s", "abcd");
^~~   ~~
v.c:6:3: note: format output 5 bytes into a destination of size 3
   sprintf (d, "%-s", "abcd");
   ^~

[Bug c/71501] missing warning on printf %s with a non-nul terminated string

[msebor at gcc dot gnu.org]

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

Bug 49905 Summary: Better sanity checking on sprintf src & dest to produce 
warning for dodgy code ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49905

   What|Removed |Added

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

[Bug middle-end/49905] Better sanity checking on sprintf src & dest to produce warning for dodgy code ?

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #19 from Martin Sebor  ---
Enhancement committed in r240298.

[Bug middle-end/49905] Better sanity checking on sprintf src & dest to produce warning for dodgy code ?

[msebor at gcc dot gnu.org]

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

--- Comment #18 from Martin Sebor  ---
Author: msebor
Date: Wed Sep 21 01:39:27 2016
New Revision: 240298

URL: https://gcc.gnu.org/viewcvs?rev=240298=gcc=rev
Log:
PR middle-end/49905 - Better sanity checking on sprintf src & dest to

gcc/ChangeLog:

PR middle-end/49905
* Makefile.in (OBJS): Add gimple-ssa-sprintf.o.
* config/linux.h (TARGET_PRINTF_POINTER_FORMAT): Redefine.
* config/linux.c (gnu_libc_printf_pointer_format): New function.
* config/sol2.h (TARGET_PRINTF_POINTER_FORMAT): Same.
* config/sol2.c (solaris_printf_pointer_format): New function.
* doc/invoke.texi (-Wformat-length, -fprintf-return-value): New
options.
* doc/tm.texi.in (TARGET_PRINTF_POINTER_FORMAT): Document.
* doc/tm.texi: Regenerate.
* gimple-fold.h (get_range_strlen): New function.
(get_maxval_strlen): Declare existing function.
* gimple-fold.c (get_range_strlen): Add arguments and compute both
maximum and minimum.
 (get_range_strlen): Define overload.
(get_maxval_strlen): Adjust.
* gimple-ssa-sprintf.c: New file and pass.
* passes.def (pass_sprintf_length): Add new pass.
* targhooks.h (default_printf_pointer_format): Declare new function.
(gnu_libc_printf_pointer_format): Same.
(solaris_libc_printf_pointer_format): Same.
* targhooks.c (default_printf_pointer_format): Define new function.
* tree-pass.h (make_pass_sprintf_length): Declare new function.
* print-tree.c: Increase buffer size.

gcc/c-family/ChangeLog:

PR middle-end/49905
* c.opt: Add -Wformat-length and -fprintf-return-value.

gcc/testsuite/ChangeLog:

PR middle-end/49905
* gcc.dg/builtin-stringop-chk-1.c: Adjust.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf-warn-2.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf-warn-3.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf-warn-4.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf-2.c: New test.


Added:
trunk/gcc/gimple-ssa-sprintf.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-4.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/config/linux.c
trunk/gcc/config/linux.h
trunk/gcc/config/sol2.c
trunk/gcc/config/sol2.h
trunk/gcc/doc/invoke.texi
trunk/gcc/doc/tm.texi
trunk/gcc/doc/tm.texi.in
trunk/gcc/gimple-fold.c
trunk/gcc/gimple-fold.h
trunk/gcc/passes.def
trunk/gcc/print-tree.c
trunk/gcc/target.def
trunk/gcc/targhooks.c
trunk/gcc/targhooks.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/builtin-stringop-chk-1.c
trunk/gcc/tree-pass.h

[Bug rtl-optimization/71309] Copying fields within a struct followed by use results in load hit store

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from Bill Schmidt  ---
Probably related to PR74585.  In both cases we have full stores followed by
partial loads, and DSE isn't able to figure out the store is dead as a result.

[Bug c++/58589] diagnostics: missing proper file:line on C++ compilation error

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

[Bug target/77670] PowerPC64 Spec 2006 fails on 453.povray using -mcpu=power9 -mpower9-minmax

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Author: meissner
Date: Tue Sep 20 23:51:01 2016
New Revision: 240294

URL: https://gcc.gnu.org/viewcvs?rev=240294=gcc=rev
Log:
Fix PR 77670

Modified:
branches/ibm/minmax/gcc/ChangeLog.meissner
branches/ibm/minmax/gcc/config/rs6000/predicates.md
branches/ibm/minmax/gcc/config/rs6000/rs6000.md

[Bug target/77669] Incorrect LTO code on embedded ARM

[wgh at beyondunreal dot com]

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

--- Comment #2 from wgh at beyondunreal dot com ---
It looks like LTO somehow breaks constructors for static variables. I have no
better idea ATM.

[Bug lto/77669] Incorrect LTO code on embedded ARM

[wgh at beyondunreal dot com]

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

--- Comment #1 from wgh at beyondunreal dot com ---
The loop in question looks like this, in C++ and aseembly:

if (__urngrange > __urange)
  {
// downscaling
const __uctype __uerange = __urange + 1; // __urange can be zero
const __uctype __scaling = __urngrange / __uerange;
const __uctype __past = __uerange * __scaling;
do
  __ret = __uctype(__urng()) - __urngmin;
while (__ret >= __past);
__ret /= __scaling;
  }


080001d6
<_ZNSt24uniform_int_distributionIiEclISt26linear_congruential_engineIjLj48271ELj0ELj2147483647iRT_RKNS0_10param_typeE.constprop.6>:
 ...
 ...
 80001f4:   f7ff ffda   bl  80001ac
<_ZNSt8__detail4_ModIjLj2147483647ELj48271ELj0ELb0ELb1EE6__calcEj>
 80001f8:   1e43subsr3, r0, #1
 80001fa:   429ccmp r4, r3
 80001fc:   d9fabls.n   80001f4
<_ZNSt24uniform_int_distributionIiEclISt26linear_congruential_engineIjLj48271ELj0ELj2147483647iRT_RKNS0_10param_typeE.constprop.6+0x1e>

So LCG has been greatly optimized and has become a single __calc call.
gdb shows some extra "fake" frames, even though they have been optimized out.

#0  __calc (__x=0) at
/usr/lib/gcc/armv7m-hardfloat-eabi/5.4.0/include/g++-v5/bits/random.tcc:62
#1  0x080001f8 in std::__detail::__mod(unsigned int) ()
at
/usr/lib/gcc/armv7m-hardfloat-eabi/5.4.0/include/g++-v5/bits/random.h:151   
#2  operator() (this=0x2430 ) at
/usr/lib/gcc/armv7m-hardfloat-eabi/5.4.0/include/g++-v5/bits/random.h:332
#3  operator() (this=this@entry=0x2001ffd0, __param=..., __urng=...)
at
/usr/lib/gcc/armv7m-hardfloat-eabi/5.4.0/include/g++-v5/bits/uniform_int_dist.h:242
#4  0x080002be in operator() (__urng=..., this=0x2001ffd0) at
/usr/lib/gcc/armv7m-hardfloat-eabi/5.4.0/include/g++-v5/bits/uniform_int_dist.h:16

The __calc function looks like this in assembly:
080001ac <_ZNSt8__detail4_ModIjLj2147483647ELj48271ELj0ELb0ELb1EE6__calcEj>:
 80001ac:   f64a 52c8   movwr2, #44488  ; 0xadc8
 80001b0:   fbb0 f1f2   udivr1, r0, r2
 80001b4:   fb02 0311   mls r3, r2, r1, r0
 80001b8:   f64b 428f   movwr2, #48271  ; 0xbc8f
 80001bc:   4353mulsr3, r2
 80001be:   f640 5247   movwr2, #3399   ; 0xd47
 80001c2:   fb02 f001   mul.w   r0, r2, r1
 80001c6:   4283cmp r3, r0
 80001c8:   bf3citt cc
 80001ca:   f103 4300   addcc.w r3, r3, #2147483648 ; 0x8000
 80001ce:   f103 33ff   addcc.w r3, r3, #4294967295 ; 0x
 80001d2:   1a18subsr0, r3, r0
 80001d4:   4770bx  lr

It should calculate x = (ax + c) mod m, where a = 48271u, c = 0u, m =
2147483647u

So in case of x=0, new x will also be zero. Hmm, sounds weird.

[Bug target/77670] PowerPC64 Spec 2006 fails on 453.povray using -mcpu=power9 -mpower9-minmax

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-09-20
 Ever confirmed|0   |1

[Bug target/77670] New: PowerPC64 Spec 2006 fails on 453.povray using -mcpu=power9 -mpower9-minmax

[meissner at gcc dot gnu.org]

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

Bug ID: 77670
   Summary: PowerPC64 Spec 2006 fails on 453.povray using
-mcpu=power9 -mpower9-minmax
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

Created attachment 39662
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39662=edit
-save-temps file (cut down) that shows the problem

The new min/max instructions in PowerPC ISA 3.0 generate an insn not found
error.  Note, these instructions are not currently enabled with -mcpu=power9,
they are enabled with a separate switch: -mpower9-minmax.  It is likely that
the same bug appears in GCC 6.2.

To replicate, compile the attached .ii file with -O3 -mcpu=power9
-mpower9-minmax -ffast-math -w.  The following error is generated:

hcmplx.cpp: In function 'void pov::Normal_Calc_HCompl_Reciprocal(double*, int,
pov::FRACTAL*)':
hcmplx.cpp:891:1: error: unrecognizable insn:
(insn 62 61 63 5 (parallel [
(set (reg:DF 305)
(if_then_else:DF (ne:CCFP (reg:DF 310)
(reg/v:DF 230 [ det ]))
(reg:DF 309)
(reg/v:DF 203 [ xx ])))
(clobber (scratch:V2DI))
]) -1
 (nil))
hcmplx.cpp:891:1: internal compiler error: in extract_insn, at recog.c:2310
0x10a83fe3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/meissner/fsf-src/trunk-240142/gcc/rtl-error.c:108
0x10a84047 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/meissner/fsf-src/trunk-240142/gcc/rtl-error.c:116
0x10a49a1b extract_insn(rtx_insn*)
/home/meissner/fsf-src/trunk-240142/gcc/recog.c:2310
0x10791fbb instantiate_virtual_regs_in_insn
/home/meissner/fsf-src/trunk-240142/gcc/function.c:1580
0x10791fbb instantiate_virtual_regs
/home/meissner/fsf-src/trunk-240142/gcc/function.c:1948
0x10791fbb execute
/home/meissner/fsf-src/trunk-240142/gcc/function.c:1997
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Similar errors occur on the gamess and soplex benchmarks.

The reason this occurs it creates a floating point CMOVE instruction with a NE.
 The way to fix it is to provide insns to invert the sense of the test.

[Bug lto/77669] New: Incorrect LTO code on embedded ARM

[wgh at beyondunreal dot com]

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

Bug ID: 77669
   Summary: Incorrect LTO code on embedded ARM
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wgh at beyondunreal dot com
  Target Milestone: ---

So I've been playing around with my STM32 microcontroller and various compiler
options, and noticed that my program doesn't work when I build it with LTO.

I've observed this behaviour on GCC 4.9.3 and 5.4.0.

The problematic piece of code looks like this:
auto i = std::uniform_int_distribution<>(0, ncolors - 1)(random_engine);

Where random_engine is declared at global level
static std::minstd_rand random_engine;

The function simply never returns.

According to my debugging, the generator returns always zero, and it causes the
"downscale" loop inside uniform_int_distribution::operator()
(/usr/lib/gcc/armv7m-hardfloat-eabi/5.4.0/include/g++-v5/bits/uniform_int_dist.h)
to loop forever.

I'll try to post some more debugging info soon.

Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/armv7m-hardfloat-eabi/gcc-bin/5.4.0/armv7m-hardfloat-eabi-g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv7m-hardfloat-eabi/5.4.0/lto-wrapper
Target: armv7m-hardfloat-eabi
Configured with:
/var/tmp/portage/cross-armv7m-hardfloat-eabi/gcc-5.4.0/work/gcc-5.4.0/configure
--host=x86_64-pc-linux-gnu --target=armv7m-hardfloat-eabi
--build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/armv7m-hardfloat-eabi/gcc-bin/5.4.0
--includedir=/usr/lib/gcc/armv7m-hardfloat-eabi/5.4.0/include
--datadir=/usr/share/gcc-data/armv7m-hardfloat-eabi/5.4.0
--mandir=/usr/share/gcc-data/armv7m-hardfloat-eabi/5.4.0/man
--infodir=/usr/share/gcc-data/armv7m-hardfloat-eabi/5.4.0/info
--with-gxx-include-dir=/usr/lib/gcc/armv7m-hardfloat-eabi/5.4.0/include/g++-v5
--with-python-dir=/share/gcc-data/armv7m-hardfloat-eabi/5.4.0/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 5.4.0 p1.0, pie-0.6.5' --enable-libstdcxx-time
--enable-poison-system-directories --with-sysroot=/usr/armv7m-hardfloat-eabi
--disable-bootstrap --with-newlib --enable-multilib --disable-altivec
--disable-fixed-point --with-float=hard --with-arch=armv7-m --with-mode=thumb
--with-float=hard --with-fpu=vfpv3-d16 --disable-libgcj --disable-libgomp
--disable-libmudflap --disable-libssp --disable-libcilkrts --disable-libmpx
--enable-vtable-verify --enable-libvtv --disable-libquadmath --enable-lto
--without-isl --disable-libsanitizer
Thread model: single
gcc version 5.4.0 (Gentoo 5.4.0 p1.0, pie-0.6.5)

[Bug fortran/77667] ICE in expand_call, at calls.c:2588

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-20
 CC||marxin at gcc dot gnu.org
  Known to work||4.5.4
 Ever confirmed|0   |1
  Known to fail||4.6.0

--- Comment #2 from Martin Liška  ---
Started with 4.6.0, ICE messages are various, as reported.

[Bug fortran/77666] ICE in gfc_omp_clause_default_ctor, at fortran/trans-openmp.c:471

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||openmp
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-20
 CC||jakub at redhat dot com,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
All releases that I have are affected (4.5.0+).

[Bug fortran/77665] ICE in expand_GOMP_SIMD_VF, at internal-fn.c:172

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||openmp
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-20
 CC||marxin at gcc dot gnu.org
  Known to work||4.9.0
 Ever confirmed|0   |1
  Known to fail||4.9.1

--- Comment #1 from Martin Liška  ---
Confirmed, started in between 4.9.0 and 4.9.1.

[Bug fortran/77657] link error with implementation of user-defined derived type input/output (UD-DTIO) in child extending abstract parent

[damian at sourceryinstitute dot org]

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

--- Comment #2 from Damian Rouson  ---
Bravo!

:D

[Bug bootstrap/77512] gcc compilation stops with Arithmetic Exception

[michael at mijobe dot org]

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

--- Comment #9 from michael at mijobe dot org ---
same result

[Bug c++/66362] Compiling and linking with option -static-libgcc breaks pthread library stack (funcs and macroses)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
This is not a supported config as glibc needs to call into the shared libgcc to
throw the exception and there needs to be only one copy of the unwinding
functions.

[Bug target/77478] Incorrect code generated with -O3, m32, -msse2 and -ffast-math

[amonakov at gcc dot gnu.org]

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

--- Comment #6 from Alexander Monakov  ---
Thanks, seeing alignment info in dumps helps (I think you meant -vops rather
than -alias?).

This doesn't seem to reproduce on trunk. On gcc-5 branch, I see alignment
increasing in dom2 pass.

Specifically, the 147t.slsr dump prior to dom2 has:

  :
...
  vectp.10_4 = vectp.22_88;
...
  # rhs access alignment 32+0
  vect__22.11_163 = MEM[(float *)vectp.10_4];

and then 149.dom2 has:

  :
...
  vectp.10_4 = vectp.22_88;
...
  # rhs access alignment 128+0
  vect__22.11_163 = MEM[(float *)vectp.22_88];

[Bug rtl-optimization/77668] New: register allocation shoud not occupy register for return value early

[yumeyao at hotmail dot com]

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

Bug ID: 77668
   Summary: register allocation shoud not occupy register for
return value early
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yumeyao at hotmail dot com
  Target Milestone: ---

when return value is declared (or, RVO introduced returning this pointer), RA
seems to be very greedy on occupying r0(eax/rax) for the return value, even if
the return value is not used yet.

With such RA strategy, the quick register reserved for return value is no
longer usable for tmp variables.

Here is just one simple example demonstrating this issue:
compile with -m32 -O[anylevel] targeting Intel x86
always able to reproduce on gcc 4.x to 6.2.0 and on 7.0 snapshots.

getA() is where RVO is applied, resulting "this" pointer (for returning)
occupying one register.
In total, 4 registers used. The life-scope of "this" pointer and one tmp
variable don't overlap, where 1 register should be enough, but 2 registers
allocated.

getA_RVO() with the complex syntax is where we 'manually' do the RVO stuff to
make the function prototype identical to RVO'ed getA() (calling convention on
returning stack poping is not same, though)
in getA_RVO(), I just showed up that we can use the same register for ret (eax)
as a temp register before we actually start using it, thus only 3 registers
used.

getA_RVO2() is just a simple test to clarify the problem is not caused by RVO,
as we manually declare the return var and assign to it, but the return var
still extended its life-span. So likely the problem is caused by RA being
greedy on ret reg.


struct A {
  int a;
  int b;
  int c;

  A(int i, int j) {
int tmp;
int h = i;
int e;
__asm__ __volatile__( //do something in assembly
  "or $123, %0;"
  "mov %0, %1;"
  "xor $234, %1;"
  "lea 20(%0), %2;"
  : "+r"(h), "=r"(tmp), "=r"(e)
);
b = h;
c = e;
a = j;
  }
};


A getA(int i, int j) {
  return A(i, j);
}

getA(int, int):
 push   %ebx
 mov0x8(%esp),%eax
 mov0xc(%esp),%edx
 or $0x7b,%edx
 mov%edx,%ebx
 xor$0xea,%ebx
 lea0x14(%edx),%ecx
 mov%edx,0x4(%eax)
 mov0x10(%esp),%edx
 mov%ecx,0x8(%eax)
 mov%edx,(%eax)
 pop%ebx
 ret$0x4

A* getA_RVO(A* src, int i, int j) {
  A* ret;
  int h = i;
  int e;
  __asm__ __volatile__(
"or $123, %0;"
"mov %0, %1;"
"xor $234, %1;"
"lea 20(%0), %2;"
"mov %3, %1;"  //switch this line with ret = src
: "+r"(h), "=r"(ret), "=r"(e)
: "rm"(src)
  );
  //ret = src;
  ret->b = h;
  ret->c = e;
  ret->a = j;
  return ret;
}

getA_RVO(A*, int, int):
 mov0x8(%esp),%edx
 or $0x7b,%edx
 mov%edx,%eax
 xor$0xea,%eax
 lea0x14(%edx),%ecx
 mov0x4(%esp),%eax
 mov%edx,0x4(%eax)
 mov0xc(%esp),%edx
 mov%ecx,0x8(%eax)
 mov%edx,(%eax)
 ret

//switch the commented lines in getA_RVO() to get getA_RVO2

getA_RVO2(A*, int, int):
 push   %ebx
 mov0x8(%esp),%eax
 mov0xc(%esp),%edx
 or $0x7b,%edx
 mov%edx,%ebx
 xor$0xea,%ebx
 lea0x14(%edx),%ecx
 mov%edx,0x4(%eax)
 mov0x10(%esp),%edx
 mov%ecx,0x8(%eax)
 mov%edx,(%eax)
 pop%ebx
 ret

[Bug fortran/77667] ICE in expand_call, at calls.c:2588

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---
Variants with a type mismatch give a suboptimal error message :


$ cat z2.f90
program p
   type t
  integer :: a
  integer, pointer :: b
   end type
   type(t) :: x
   data x /t(4, f())/
   print *, x%a, associated(x%b)
end


$ cat z3.f90
program p
   type t
  integer :: a
  logical, pointer :: b
   end type
   type(t) :: x
   data x /t(4, f())/
   print *, x%a, associated(x%b)
end


$ gfortran-7-20160918 z3.f90
z3.f90:9:0:

 end

Error: initializer for floating value is not a floating constant

[Bug fortran/77667] New: ICE in expand_call, at calls.c:2588

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 77667
   Summary: ICE in expand_call, at calls.c:2588
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With invalid code :


$ cat z1.f90
program p
   type t
  integer :: a
  integer, pointer :: b
   end type
   type(t) :: x
   data x /t(4, nul())/
   print *, x%a, associated(x%b)
end


$ gfortran-7-20160918 z1.f90
z1.f90:9:0:

 end

internal compiler error: Segmentation fault
0xc21a5f crash_signal
../../gcc/toplev.c:336
0x7eea98 expand_call(tree_node*, rtx_def*, int)
../../gcc/calls.c:2588
0x9058ac expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:10737
0xf092a3 expand_expr
../../gcc/expr.h:279
0xf092a3 output_constant
../../gcc/varasm.c:4758
0xf0a311 output_constant
../../gcc/varasm.c:4665
0xf0a311 output_constructor_regular_field
../../gcc/varasm.c:5018
0xf0a311 output_constructor
../../gcc/varasm.c:5288
0xf0bbb4 output_constant
../../gcc/varasm.c:4665
0xf0bbb4 assemble_variable_contents
../../gcc/varasm.c:2074
0xf133f9 assemble_variable(tree_node*, int, int, int)
../../gcc/varasm.c:2250
0xf18be8 varpool_node::assemble_decl()
../../gcc/varpool.c:589
0x83ee1b output_in_order
../../gcc/cgraphunit.c:2232
0x83f1fd symbol_table::compile()
../../gcc/cgraphunit.c:2472
0x841c52 symbol_table::compile()
../../gcc/cgraphunit.c:2542
0x841c52 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2568

---


Older releases give :


$ gfortran-6 z1.f90
z1.f90:9:0:

 end

internal compiler error: Segmentation fault


$ gfortran-5 z1.f90
z1.f90:9:0:

 end
 ^
internal compiler error: in gen_reg_rtx, at emit-rtl.c:1059


$ gfortran-4.9 z1.f90
z1.f90:9:0: internal compiler error: in gen_reg_rtx, at emit-rtl.c:866
 end
 ^
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug go/77625] go/gofrontend/ast-dump.cc:169:42: error: ‘new’ of type ‘std::ofstr eam {aka std::basic_ofstream}’ with extended alignment 16

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
Fixed.

[Bug fortran/77666] New: ICE in gfc_omp_clause_default_ctor, at fortran/trans-openmp.c:471

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 77666
   Summary: ICE in gfc_omp_clause_default_ctor, at
fortran/trans-openmp.c:471
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Affects versions down to at least 4.8 :


$ cat z1.f90
subroutine s(x)
   integer, allocatable :: x(:)
   integer :: q
   q = 0
!$omp parallel private(x) reduction(+:q)
   q = q + sum(x)
!$omp end parallel
   print *, q
end


$ cat z2.f90
subroutine s(x)
   integer, allocatable :: x(:)
   logical :: q
   q = .false.
!$omp parallel private(x) reduction(.or.:q)
   q = q .or. any (x > 0)
!$omp end parallel
   print *, q
end


$ _g2d_nofo_v7test -fopenmp -c z1.f90
z1.f90:5:0:

 !$omp parallel private(x) reduction(+:q)

internal compiler error: in gfc_omp_clause_default_ctor, at
fortran/trans-openmp.c:471
0x78f7b6 gfc_omp_clause_default_ctor(tree_node*, tree_node*, tree_node*)
../../gcc/fortran/trans-openmp.c:471
0xb25a4b lower_rec_input_clauses
../../gcc/omp-low.c:4953
0xb2a17d lower_omp_taskreg
../../gcc/omp-low.c:15661
0xb1c0e6 lower_omp_1
../../gcc/omp-low.c:17036
0xb1c0e6 lower_omp
../../gcc/omp-low.c:17180
0xb1b44c lower_omp_1
../../gcc/omp-low.c:17019
0xb1b44c lower_omp
../../gcc/omp-low.c:17180
0xb1bdec lower_omp_1
../../gcc/omp-low.c:17028
0xb1bdec lower_omp
../../gcc/omp-low.c:17180
0xb22fcf execute_lower_omp
../../gcc/omp-low.c:17915
0xb22fcf execute
../../gcc/omp-low.c:17952

[Bug go/77625] go/gofrontend/ast-dump.cc:169:42: error: ‘new’ of type ‘std::ofstr eam {aka std::basic_ofstream}’ with extended alignment 16

[ian at gcc dot gnu.org]

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

--- Comment #1 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue Sep 20 17:52:23 2016
New Revision: 240279

URL: https://gcc.gnu.org/viewcvs?rev=240279=gcc=rev
Log:
PR go/77625

compiler: allocate std::ofstream as a local variable

GCC PR 77625 points out a warning about new std::ofstream.  I don't know
how that is supposed to work, but in this case the std::ofstream may as
well be a local variable anyhow.

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

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/gcc/go/gofrontend/ast-dump.cc

[Bug fortran/77665] New: ICE in expand_GOMP_SIMD_VF, at internal-fn.c:172

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 77665
   Summary: ICE in expand_GOMP_SIMD_VF, at internal-fn.c:172
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Affects versions 5, 6, 7 at optimization level -Os, -O1 or higher.


$ cat z1.f90
program p
   type t
  integer :: a = 0
   end type
   type(t) :: x
   integer :: i
   !$omp declare reduction (+:t: omp_out%a = omp_out%a + omp_in%a)
   !$omp simd reduction(+:x)
   do i = 1, 8
! if ( abs(i) > 5 )  stop  ! or "call abort" etc.
  if ( abs(i) < 5 )  stop
! if ( abs(i) <= 5 ) stop
! if ( abs(i) /= 5 ) stop
  x%a = x%a + 1
   end do
   print *, x%a
end


$ gfortran-7-20160918 -O2 -fopenmp z1.f90
z1.f90:17:0:

 end

internal compiler error: in expand_GOMP_SIMD_VF, at internal-fn.c:172
0xa152a7 expand_GOMP_SIMD_VF
../../gcc/internal-fn.c:172
0x80348f expand_call_stmt
../../gcc/cfgexpand.c:2578
0x80348f expand_gimple_stmt_1
../../gcc/cfgexpand.c:3579
0x80348f expand_gimple_stmt
../../gcc/cfgexpand.c:3745
0x8050ce expand_gimple_basic_block
../../gcc/cfgexpand.c:5752
0x80b276 execute
../../gcc/cfgexpand.c:6363

[Bug tree-optimization/77621] [6/7 Regression] Internal compiler error for mtune=atom + msse2

[uros at gcc dot gnu.org]

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

--- Comment #19 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Sep 20 17:36:03 2016
New Revision: 240277

URL: https://gcc.gnu.org/viewcvs?rev=240277=gcc=rev
Log:
PR target/77621
* config/i386/i386.c (ix86_preferred_simd_mode) :
Don't return word_mode for !TARGET_VECTORIZE_DOUBLE.
(ix86_add_stmt_cost): Penalize DFmode vector operations
for !TARGET_VECTORIZE_DOUBLE.

testsuite/ChangeLog:

PR target/77621
* gcc.target/i386/pr77621.c: New test.
* gcc.target/i386/vect-double-2.c: Update scan-tree-dump-times
pattern, loop should vectorize with -mtune=atom.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr77621.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/vect-double-2.c

[Bug go/77642] GO Bootstrap fail starting with r239872 splitstack signature does not match

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #4 from Ian Lance Taylor  ---
Should be fixed.  Thanks for the patch.

[Bug go/77642] GO Bootstrap fail starting with r239872 splitstack signature does not match

[ian at gcc dot gnu.org]

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

--- Comment #3 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue Sep 20 16:48:19 2016
New Revision: 240275

URL: https://gcc.gnu.org/viewcvs?rev=240275=gcc=rev
Log:
PR go/77642

runtime: pass correct type to __splitstack_find

The code was passing uintptr* to a function that expected size_t*.

Based on patch by Andreas Krebbel.

Fixes GCC PR 77642.

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

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/runtime/proc.c

[Bug c++/69481] ICE with C++11 alias using with templates

[akim.demaille at gmail dot com]

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

Akim Demaille  changed:

   What|Removed |Added

 CC||akim.demaille at gmail dot com

--- Comment #9 from Akim Demaille  ---
Hi all,

Our of curiosity, could someone explain why GCC makes a difference between
typedef and using here?  I guess that if GCC does not map them all to the same
type of structure, then it must be because it needs to tell the difference
later.  And I guess it's not a does/does-not support templates that makes the
difference, as the grammar probably suffice here.

Thanks in advance!

[Bug rtl-optimization/77664] New: Missed optimization: signed int >= 0 && < unsigned short

[achurch+gcc at achurch dot org]

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

Bug ID: 77664
   Summary: Missed optimization: signed int >= 0 && < unsigned
short
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: achurch+gcc at achurch dot org
  Target Milestone: ---

Given the following code:

extern void foo(void);
void bar(int a, unsigned short b)
{
  if (a >= 0 && a < b)
foo();
}

the "a >= 0 && a < b" test could be implemented as a single unsigned
comparison, e.g. on x86-64:

bar:
   cmp %esi,%edi
   jb foo
   ret

GCC, however, misses this optimization (even at -O3) and generates two separate
comparisons:

bar:
   test %edi,%edi
   js 0f
   movzwl %si,%esi
   cmp %esi,%edi
   jl 1f
0: repz ret
   nopl (%rax)
1: jmp foo

(The movzwl is also unnecessary per my reading of the x86-64 ABI, but that's a
different issue.)

FWIW, Clang 3.8.1 successfully optimizes this at -O and higher.

(Component is a guess; please move if appropriate.)

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

  Attachment #39659|0   |1
is obsolete||

--- Comment #20 from Iain Sandoe  ---
Created attachment 39661
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39661=edit
patchset cf 240230


patchset rebased to 240230 - should apply cleanly.

[Bug libfortran/77663] New: libgfortran/caf/single.c: four minor problems

[dcb314 at hotmail dot com]

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

Bug ID: 77663
   Summary: libgfortran/caf/single.c: four minor problems
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

[trunk/libgfortran/caf/single.c:1468]: (style) Redundant condition:
realloc_need
ed. '!realloc_needed || (realloc_needed && dst_reallocatable)' is equivalent to 
'!realloc_needed || dst_reallocatable'
[trunk/libgfortran/caf/single.c:153]: (error) Memory leak: local
[trunk/libgfortran/caf/single.c:1923]: (error) Memory leak: single_token
[trunk/libgfortran/caf/single.c:90]: (error) va_list 'args' was opened but not
c
losed by va_end().

#1 is a simple optimisation, #2 looks only slightly pointful,
#3 I'm not sure about and #4 I know of no architecture where
this matters.

[Bug c++/77637] ICE on x86_64-linux-gnu (Segmentation fault, tree_check, cp_parser_std_attribute_list...)

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Tue Sep 20 15:16:55 2016
New Revision: 240265

URL: https://gcc.gnu.org/viewcvs?rev=240265=gcc=rev
Log:
PR c++/77637
* parser.c (cp_parser_std_attribute_list): Reject ... without
preceding attribute.

* g++.dg/cpp0x/gen-attrs-62.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/gen-attrs-62.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug testsuite/63299] ASan reported alloc-dealloc-mismatch in g++.old-deja/g++.jason/init3.C

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
 Resolution|WONTFIX |FIXED

--- Comment #4 from Jakub Jelinek  ---
Actually fixed.

[Bug c++/77626] [6 Regression] ICE with -Wall on x86_64-linux-gnu (internal compiler error: Segmentation fault, byte_from_pos, cxx_fold_indirect_ref)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7 Regression] ICE with   |[6 Regression] ICE with
   |-Wall on x86_64-linux-gnu   |-Wall on x86_64-linux-gnu
   |(internal compiler error:   |(internal compiler error:
   |Segmentation fault, |Segmentation fault,
   |byte_from_pos,  |byte_from_pos,
   |cxx_fold_indirect_ref)  |cxx_fold_indirect_ref)

--- Comment #4 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/77638] [6 Regression] ICE on x86_64-linux-gnu (internal compiler error: tree check: expected tree that contains ‘decl common’ structure, have ‘error_mark’ in cp_parser_template_declaration_af

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7 Regression] ICE on |[6 Regression] ICE on
   |x86_64-linux-gnu (internal  |x86_64-linux-gnu (internal
   |compiler error: tree check: |compiler error: tree check:
   |expected tree that contains |expected tree that contains
   |‘decl common’ structure,|‘decl common’ structure,
   |have ‘error_mark’ in|have ‘error_mark’ in
   |cp_parser_template_declarat |cp_parser_template_declarat
   |ion_after_parameters, at|ion_after_parameters, at
   |cp/parser.c:25722)  |cp/parser.c:25722)

--- Comment #4 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/77637] ICE on x86_64-linux-gnu (Segmentation fault, tree_check, cp_parser_std_attribute_list...)

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Fixed on the trunk so far, leaving still open for possible backports.

[Bug testsuite/63299] ASan reported alloc-dealloc-mismatch in g++.old-deja/g++.jason/init3.C

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Sep 20 15:19:14 2016
New Revision: 240268

URL: https://gcc.gnu.org/viewcvs?rev=240268=gcc=rev
Log:
PR testsuite/63299
* g++.old-deja/g++.jason/init3.C (My_string::~My_string): Use delete[]
instead of delete.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.old-deja/g++.jason/init3.C

[Bug c++/77626] [6/7 Regression] ICE with -Wall on x86_64-linux-gnu (internal compiler error: Segmentation fault, byte_from_pos, cxx_fold_indirect_ref)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Sep 20 15:18:31 2016
New Revision: 240267

URL: https://gcc.gnu.org/viewcvs?rev=240267=gcc=rev
Log:
PR c++/77626
* constexpr.c (cxx_fold_indirect_ref): Don't call byte_position on
FIELD_DECLs with error_mark_node type.  Remove useless break; after
return.

* g++.dg/other/pr77626.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/other/pr77626.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/77638] [6/7 Regression] ICE on x86_64-linux-gnu (internal compiler error: tree check: expected tree that contains ‘decl common’ structure, have ‘error_mark’ in cp_parser_template_declaration_

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Sep 20 15:17:41 2016
New Revision: 240266

URL: https://gcc.gnu.org/viewcvs?rev=240266=gcc=rev
Log:
PR c++/77638
* parser.c (cp_parser_template_declaration_after_parameter): For 2
argument operator"" template set ok to false for
parm == error_mark_node.

* g++.dg/cpp0x/udlit-tmpl-arg-neg2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/udlit-tmpl-arg-neg2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/77619] uninitialized_meow_construct and friends not exception safe

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

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

--- Comment #4 from Ville Voutilainen  ---
Fixed.

[Bug libstdc++/77619] uninitialized_meow_construct and friends not exception safe

[ville at gcc dot gnu.org]

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

--- Comment #3 from ville at gcc dot gnu.org ---
Author: ville
Date: Tue Sep 20 15:15:36 2016
New Revision: 240264

URL: https://gcc.gnu.org/viewcvs?rev=240264=gcc=rev
Log:
PR libstdc++/77619
* include/bits/stl_construct.h: (_Construct_novalue): New.
(_Destroy_n_aux, _Destroy_n): New.
* include/bits/stl_uninitialized.h: (type_traits):
New include in C++11 mode.
(__uninitialized_default_novalue_1): New.
(__uninitialized_default_novalue_n_1): Likewise.
(__uninitialized_default_novalue): Likewise.
(__uninitialized_default_novalue_n): Likewise.
(__uninitialized_copy_n_pair): Likewise.
(uninitialized_default_construct):
Use __uninitialized_default_novalue.
(uninitialized_default_construct_n):
Use __uninitialized_default_novalue_n.
(uninitialized_value_construct): Use __uninitialized_default.
(uninitialized_value_construct_n): Use __uninitialized_default_n.
(uninitialized_move): Use uninitialized_copy.
(uninitialized_move_n): Use __uninitialized_copy_n_pair.
(destroy_at): Use _Destroy.
(destroy): Likewise.
(destroy_n): Likewise.
* testsuite/20_util/specialized_algorithms/
memory_management_tools/1.cc: Add tests for exceptions,
add tests for trivial cases for construct and move.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_construct.h
trunk/libstdc++-v3/include/bits/stl_uninitialized.h
   
trunk/libstdc++-v3/testsuite/20_util/specialized_algorithms/memory_management_tools/1.cc

[Bug go/77642] GO Bootstrap fail starting with r239872 splitstack signature does not match

[krebbel at gcc dot gnu.org]

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

--- Comment #2 from Andreas Krebbel  ---
Created attachment 39660
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39660=edit
Patch proposal

There was another location in proc.c which was in need of a conversion.

[Bug ipa/77587] [5/6 Regression] C compiler produces incorrect stack alignment with __attribute__((weak))

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[5/6/7 Regression] C|[5/6 Regression] C compiler
   |compiler produces incorrect |produces incorrect stack
   |stack alignment with|alignment with
   |__attribute__((weak))   |__attribute__((weak))
  Known to fail|7.0 |

--- Comment #6 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug middle-end/77624] [5/6 Regression] ICE on x86_64-linux-gnu (internal compiler error: in fold_builtin_atomic_always_lock_free, at builtins.c:5583)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] ICE on   |[5/6 Regression] ICE on
   |x86_64-linux-gnu (internal  |x86_64-linux-gnu (internal
   |compiler error: in  |compiler error: in
   |fold_builtin_atomic_always_ |fold_builtin_atomic_always_
   |lock_free, at   |lock_free, at
   |builtins.c:5583)|builtins.c:5583)

--- Comment #6 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[iains at gcc dot gnu.org]

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

--- Comment #19 from Iain Sandoe  ---
Created attachment 39659
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39659=edit
proposed patch set.

So I think this is working reasonably, but haven't tested fully across the
range of Darwins yet == have a go please!

There are 4 patches here:

1. A patch that solves a latent problem with atom-recognition where a
non-weak-local follows a weak-global in a data or const sections.   This is
exposed by the fixes for the actual bug. (needed once patch 3 is applied)

2a. A patch that allows ld64 to be recognized as a linker, and picks up its
version (and as an example also checks support for -export_dynamic) - this was
part of another patch set but is needed now to support patch 3 (which actually
solves the PR)

2b - just the regenerated config files for 2a.

3. This is the one that does the actual fix, by switching section use when the
linker supports merging of weak stuff without special sections - we might be
able to refine the 'earliest linker' version somewhat - this only represents
what I could test reasonably quickly.

The patch provides a target flag "-mtarget-linker" (after the similarly-named
LLVM one) and uses it to determine if the linker needs coalesced sections to
deal with weak symbols.  If not, then we emit in the regular sections.

 - needed a tweak to config/i386.c to allow for PICbase thunk output to be
switched to a non-coalesced section too.

[Bug c/77650] struct with a nested flexible array followed by another member accepted

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Documenting the semantics of this extension would work, though to be usable
safely, GCC would also need to change to recognize that the nested flexible
array member aliases the subsequent members and treat the two sets as if they
were declared in a union.  My own preference, however, would be to reject such
constructs in user code.  As long as changing Glibc to use a zero-length array
is feasible (those would continue to be accepted in this context), it should be
possible to do.

[Bug middle-end/77624] [5/6/7 Regression] ICE on x86_64-linux-gnu (internal compiler error: in fold_builtin_atomic_always_lock_free, at builtins.c:5583)

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Sep 20 13:48:40 2016
New Revision: 240263

URL: https://gcc.gnu.org/viewcvs?rev=240263=gcc=rev
Log:
PR middle-end/77624
* builtins.c (fold_builtin_atomic_always_lock_free): Only look through
cast to void * if the cast is from some other pointer type.

* c-c++-common/pr77624-1.c: New test.
* c-c++-common/pr77624-2.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/pr77624-1.c
trunk/gcc/testsuite/c-c++-common/pr77624-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/77657] link error with implementation of user-defined derived type input/output (UD-DTIO) in child extending abstract parent

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-20
 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Paul Thomas  ---
Created attachment 39658
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39658=edit
Patch for the PR

This is regtesting as I write. All the dtio testcases are fine.

Paul

[Bug c++/77662] arm-linux-gnueabihf-g++: internal compiler error: Killed (program cgcc)

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
GCC 4.9 is no longer supported.
Please try a newer version (GCC 5 and onwards).
In any case, this looks to me like the kernel killing the process because it
used too much memory.

Try adding some swap memory.

[Bug c++/77662] New: arm-linux-gnueabihf-g++: internal compiler error: Killed (program cgcc)

[shopaddr1234 at dubna dot us]

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

Bug ID: 77662
   Summary: arm-linux-gnueabihf-g++: internal compiler error:
Killed (program cgcc)
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shopaddr1234 at dubna dot us
  Target Milestone: ---

computer: raspberry pi model B

OS:
$ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"
NAME="Raspbian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=raspbian
ID_LIKE=debian

$ uname -a
Linux raspberrypi 4.4.11+ #888 Mon May 23 20:02:58 BST 2016 armv6l GNU/Linux

gcc version 4.9.2 (Raspbian 4.9.2-10)

I tried apt-get install -s gcc++ to upgrade, it said I already have the newest
version.

I am trying to install scikit-learn for python 3.4. I first need to install
scikit-learn dependencies: numpy and scipy. numpy was built and installed fine.
used pip3 to install them: 

sudo pip3 install scipy. 

Installation compiles sources, because I guess there is no compiled version of
scipy for this OS or processor.

After running for several hours I got this output:

arm-linux-gnueabihf-g++: internal compiler error: Killed (program cc1plus)
  Please submit a full bug report,
  with preprocessed source if appropriate.
  See  for instructions.
  In file included from
/usr/local/lib/python3.4/dist-packages/numpy/core/include/numpy/ndarraytypes.h:1777:0,
   from
/usr/local/lib/python3.4/dist-packages/numpy/core/include/numpy/ndarrayobject.h:18,
   from scipy/sparse/sparsetools/sparsetools.h:5,
   from scipy/sparse/sparsetools/bsr.cxx:4:
 
/usr/local/lib/python3.4/dist-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:15:2:
warning: #warning "Using deprecated NumPy API, disable it by " "#defining
NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp]
   #warning "Using deprecated NumPy API, disable it by " \
^
  arm-linux-gnueabihf-g++: internal compiler error: Killed (program cgcc)
  Please submit a full bug report,
  with preprocessed source if appropriate.
  See  for instructions.
  error: Command "arm-linux-gnueabihf-g++ -pthread -DNDEBUG -g -fwrapv -O2
-Wall -g -fstack-protector-strong -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2 -fPIC -D__STDC_FORMAT_MACROS=1 -Iscipy/sparse/sparsetools
-I/usr/local/lib/python3.4/dist-packages/numpy/core/include
-I/usr/include/python3.4m -c scipy/sparse/sparsetools/bsr.cxx -o
build/temp.linux-armv6l-3.4/scipy/sparse/sparsetools/bsr.o" failed with exit
status 4

  
  Failed building wheel for scipy
  Running setup.py clean for scipy
  Complete output from command /usr/bin/python3 -u -c "import setuptools,
tokenize;__file__='/tmp/pip-build-r3h3rnv3/scipy/setup.py';exec(compile(getattr(tokenize,
'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" clean
--all:

  `setup.py clean` is not supported, use one of the following instead:

- `git clean -xdf` (cleans all files)
- `git clean -Xdf` (cleans all versioned files, doesn't touch
files that aren't checked into the git repo)

  Add `--force` to your command to use it anyway if you must (unsupported)

[Bug bootstrap/77661] --enable-maintainer-mode causes in-tree-build of MPC to fail

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01294.html

[Bug c++/77659] [5/6/7 Regression] internal compiler error: in gimplify_expr, at gimplify.c:8858

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |5.5
Summary|internal compiler error: in |[5/6/7 Regression] internal
   |gimplify_expr, at   |compiler error: in
   |gimplify.c:8858 |gimplify_expr, at
   ||gimplify.c:8858

--- Comment #3 from Jakub Jelinek  ---
Started with r216750.

[Bug bootstrap/77661] --enable-maintainer-mode causes in-tree-build of MPC to fail

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  ---
(In reply to Richard Biener from comment #1)
> Does adding --disable-maintainer-mode to Makefile.def extra_configure_flags
> for MPC help?

Yes, using

--- a/Makefile.def
+++ b/Makefile.def
@@ -65,3 +65,3 @@ host_modules= { module= mpfr; lib_path=src/.libs;
bootstrap=true;
 host_modules= { module= mpc; lib_path=src/.libs; bootstrap=true;
-   extra_configure_flags='--disable-shared
@extra_mpc_gmp_configure_flags@ @extra_mpc_mpfr_configure_flags@';
+   extra_configure_flags='--disable-shared
@extra_mpc_gmp_configure_flags@ @extra_mpc_mpfr_configure_flags@
--disable-maintainer-mode';
no_install= true; };

(Makefile.in will then get the changed by regenerating it.)

[Bug target/77610] [sh] memcpy is wrongly inlined even for large copies

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 CC||olegendo at gcc dot gnu.org

--- Comment #4 from Oleg Endo  ---
(In reply to Rich Felker from comment #0)
> 
> Even if we have a set-associative cache on J-core in the future, I plan to
> have Linux provide a vdso memcpy function that can use DMA transfers, which
> are several times faster than what you can achieve with any cpu-driven
> memcpy and which free up the cpu for other work. However it's impossible to
> for such a function to get called as long as gcc is inlining it.

Just a note on the side... the above can also be done on a off-the-shelf SH
MCU.  However, it is only going to be beneficial for large memory blocks, since
you'd have to synchronize (i.e. flush) the data cache lines of the memcpy'ed
regions.  For small blocks DMA packet setup time will dominate, unless you've
got one dedicated DMA channel sitting around just waiting for memcpy commands. 
Normally it's better to avoid copying large memory blocks at all and use
reference-counted buffers or something like that instead.   That is of course,
unless you've got some special cache coherent DMA machinery ready at hand and
memory is very fast :)


(In reply to Rich Felker from comment #2)
> I'm testing a patch where I used 256 as the limit and it made the Linux
> kernel very slightly faster (~1-2%) and does not seem
> to hurt anywhere.
> 

I'm curious, how did you measure this performance of the kernel?  Which part in
particular got faster in which situation?

[Bug c++/77656] 64-bit integral template parameter gets incorrectly sized as 32-bits

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-20
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
template> (sizeof(int) * __CHAR_BIT__))>
class A {};
template class B : A {};
template class C : A<(unsigned long long) T> {};

Perhaps tsubst of TEMPLATE_PARM_INDEX instead of just
return convert_from_reference (unshare_expr (arg));
also convert it to the TEMPLATE_PARM_INDEX's type (if it is integral type only,
or when?)?

Also, is e.g.

template class A {};
A<0xU> a;
A<0x1U> b;

valid C++11 (0x1U is too large to fit into unsigned short)?  clang++
accepts it in C++98 and rejects with narrowing conversion error in -std=c++11
and later, g++ only warns:
warning: large integer implicitly truncated to unsigned type [-Woverflow]

[Bug tree-optimization/77653] [7 Regression] wrong code at -Os and above on x86_64-linux-gnu (in both 32-bit and 64-bit modes)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-20
 CC||cltang at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Broken by r240155.

[Bug tree-optimization/77621] [6/7 Regression] Internal compiler error for mtune=atom + msse2

[rguenther at suse dot de]

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

--- Comment #18 from rguenther at suse dot de  ---
On Tue, 20 Sep 2016, ubizjak at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77621
> 
> --- Comment #17 from Uroš Bizjak  ---
> (In reply to rguent...@suse.de from comment #16)
> 
> > At least you won't get called for the scalar loop copy and you have
> > definite acccess to vectype.
> 
> Thanks for the hint, the following patch is effective as well:

Looks good to me.

> --cut here--
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 60b81bb..9d72681 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -49554,9 +49554,7 @@ ix86_preferred_simd_mode (machine_mode mode)
> return V4SFmode;
> 
>  case DFmode:
> -  if (!TARGET_VECTORIZE_DOUBLE)
> -   return word_mode;
> -  else if (TARGET_AVX512F)
> +  if (TARGET_AVX512F)
> return V8DFmode;
>else if (TARGET_AVX && !TARGET_PREFER_AVX128)
> return V4DFmode;
> @@ -49647,6 +49645,11 @@ ix86_add_stmt_cost (void *data, int count, enum
> vect_cost_for_stmt kind,
>tree vectype = stmt_info ? stmt_vectype (stmt_info) : NULL_TREE;
>int stmt_cost = ix86_builtin_vectorization_cost (kind, vectype, misalign);
> 
> +  /* Penalize DFmode vector operations for !TARGET_VECTORIZE_DOUBLE.  */
> +  if (kind == vector_stmt && !TARGET_VECTORIZE_DOUBLE
> +  && vectype && GET_MODE_INNER (TYPE_MODE (vectype)) == DFmode)
> +stmt_cost *= 5;  /* FIXME: The value here is arbitrary.  */
> +
>/* Statements in an inner loop relative to the loop being
>   vectorized are weighted more heavily.  The value here is
>arbitrary and could potentially be improved with analysis.  */
> --cut here--

[Bug tree-optimization/77621] [6/7 Regression] Internal compiler error for mtune=atom + msse2

[ubizjak at gmail dot com]

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

--- Comment #17 from Uroš Bizjak  ---
(In reply to rguent...@suse.de from comment #16)

> At least you won't get called for the scalar loop copy and you have
> definite acccess to vectype.

Thanks for the hint, the following patch is effective as well:

--cut here--
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 60b81bb..9d72681 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -49554,9 +49554,7 @@ ix86_preferred_simd_mode (machine_mode mode)
return V4SFmode;

 case DFmode:
-  if (!TARGET_VECTORIZE_DOUBLE)
-   return word_mode;
-  else if (TARGET_AVX512F)
+  if (TARGET_AVX512F)
return V8DFmode;
   else if (TARGET_AVX && !TARGET_PREFER_AVX128)
return V4DFmode;
@@ -49647,6 +49645,11 @@ ix86_add_stmt_cost (void *data, int count, enum
vect_cost_for_stmt kind,
   tree vectype = stmt_info ? stmt_vectype (stmt_info) : NULL_TREE;
   int stmt_cost = ix86_builtin_vectorization_cost (kind, vectype, misalign);

+  /* Penalize DFmode vector operations for !TARGET_VECTORIZE_DOUBLE.  */
+  if (kind == vector_stmt && !TARGET_VECTORIZE_DOUBLE
+  && vectype && GET_MODE_INNER (TYPE_MODE (vectype)) == DFmode)
+stmt_cost *= 5;  /* FIXME: The value here is arbitrary.  */
+
   /* Statements in an inner loop relative to the loop being
  vectorized are weighted more heavily.  The value here is
   arbitrary and could potentially be improved with analysis.  */
--cut here--

[Bug tree-optimization/77646] [5/6 Regression] GCC Segfault with -O3

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Tue Sep 20 12:20:37 2016
New Revision: 240261

URL: https://gcc.gnu.org/viewcvs?rev=240261=gcc=rev
Log:
2016-09-20  Richard Biener  

PR tree-optimization/77646
* tree-ssa-sccvn.c (visit_reference_op_call): Always value-number
a VDEF.

* gcc.dg/torture/pr77646.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr77646.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/77646] [5/6 Regression] GCC Segfault with -O3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[5/6/7 Regression] GCC  |[5/6 Regression] GCC
   |Segfault with -O3   |Segfault with -O3
  Known to fail|7.0 |

--- Comment #6 from Richard Biener  ---
Fixed on trunk sofar.

[Bug bootstrap/77661] --enable-maintainer-mode causes in-tree-build of MPC to fail

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Does adding --disable-maintainer-mode to Makefile.def extra_configure_flags for
MPC help?

[Bug tree-optimization/77621] [6/7 Regression] Internal compiler error for mtune=atom + msse2

[rguenther at suse dot de]

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

--- Comment #16 from rguenther at suse dot de  ---
On Tue, 20 Sep 2016, ubizjak at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77621
> 
> --- Comment #15 from Uroš Bizjak  ---
> (In reply to Richard Biener from comment #12)
> 
> > If V2DFmode moves are fine(?) then maybe not do this for the load/store
> > kinds - this means only handling vector_stmt this way (and maybe
> > vect_promote_demote?) - at least make sure to not handle scalar_*
> > (not sure if vectype is always NULL for those -- docs say only
> > memory ops may depend on vectype).
> 
> Moves are fine, V2DFmode vector arithmetic insns (addpd, subpd, mulpd) have
> much higher latencies (e.g. 6 for addpd, 9 for mulpd), comparing to their
> {SF,DF}mode (or V4SFmode) versions (1 for addps, 2 for mulps).
> 
> > Instead of += 20 I'd have done *=  to
> > make it more independent of the absolute value of the cost numbers.
> 
> IMO, having no other data at hand than Agner Fog's instruction tables, it 
> looks
> that penalizing vector_stmt cost with a factor of 5 should be OK for a start.
> 
> > If you'd do the cost adjustment in ix86_add_stmt_cost you have more control
> > over the details (there's also similar offsetting for silvermont)
> 
> ix86_builtin_vectorization_cost is also called from there. OTOH,
> ix86_add_stmt_cost uses some other arguments (e.g. location), which I think 
> are
> irrelevant to the insn type cost adjustment.

At least you won't get called for the scalar loop copy and you have
definite acccess to vectype.

[Bug tree-optimization/77621] [6/7 Regression] Internal compiler error for mtune=atom + msse2

[ubizjak at gmail dot com]

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

--- Comment #15 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #12)

> If V2DFmode moves are fine(?) then maybe not do this for the load/store
> kinds - this means only handling vector_stmt this way (and maybe
> vect_promote_demote?) - at least make sure to not handle scalar_*
> (not sure if vectype is always NULL for those -- docs say only
> memory ops may depend on vectype).

Moves are fine, V2DFmode vector arithmetic insns (addpd, subpd, mulpd) have
much higher latencies (e.g. 6 for addpd, 9 for mulpd), comparing to their
{SF,DF}mode (or V4SFmode) versions (1 for addps, 2 for mulps).

> Instead of += 20 I'd have done *=  to
> make it more independent of the absolute value of the cost numbers.

IMO, having no other data at hand than Agner Fog's instruction tables, it looks
that penalizing vector_stmt cost with a factor of 5 should be OK for a start.

> If you'd do the cost adjustment in ix86_add_stmt_cost you have more control
> over the details (there's also similar offsetting for silvermont)

ix86_builtin_vectorization_cost is also called from there. OTOH,
ix86_add_stmt_cost uses some other arguments (e.g. location), which I think are
irrelevant to the insn type cost adjustment.

Let me play a bit with the patch.

[Bug bootstrap/77661] New: --enable-maintainer-mode causes in-tree-build of MPC to fail

[burnus at gcc dot gnu.org]

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

Bug ID: 77661
   Summary: --enable-maintainer-mode causes in-tree-build of MPC
to fail
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

Compiling GCC with in-tree MPC (+ mpfr + gmp + ISL) fails with
--enable-maintainer-mode as the latter also updates the configure scripts of
those.

In particular, the in-tree-build of MPC fails with:

make[3]: Entering directory `build/mpc'
(CDPATH="${ZSH_VERSION+.}:" && cd ../../mpc && /bin/sh mpc/missing autoheader)
aclocal.m4:17: warning: this file was generated for autoconf 2.69.
You have another version of autoconf.  It may work, but is not guaranteed to.
If you have problems, you may need to regenerate the build system entirely.
To do so, use the procedure documented by the package, typically 'autoreconf'.
configure.ac:27: error: Autoconf version 2.65 or higher is required
aclocal.m4:497: AM_INIT_AUTOMAKE is expanded from...
configure.ac:27: the top level
autom4te: m4 failed with exit status: 63
autoheader: 'autom4te' failed with exit status: 63
WARNING: 'autoheader' is probably too old.
 You should only need it if you modified 'acconfig.h' or
 'configure.ac' or m4 files included by 'configure.ac'.
 The 'autoheader' program is part of the GNU Autoconf package:
 
 It also requires GNU m4 and Perl in order to run:
 
 
make[3]: *** [../../mpc/config.h.in] Error 63
make[3]: Leaving directory `build/mpc'

[Bug c++/77655] [5/6/7 Regression]ICE on invalid c++ code on x86_64-linux-gnu (internal compiler error: Segmentation fault (program cc1plus))

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||paolo at gcc dot gnu.org
  Known to work|5.4.0   |
   Target Milestone|6.3 |5.5
Summary|[6/7 Regression]ICE on  |[5/6/7 Regression]ICE on
   |invalid c++ code on |invalid c++ code on
   |x86_64-linux-gnu (internal  |x86_64-linux-gnu (internal
   |compiler error: |compiler error:
   |Segmentation fault (program |Segmentation fault (program
   |cc1plus))   |cc1plus))
  Known to fail||5.4.0

--- Comment #3 from Jakub Jelinek  ---
With -std=c++0x the ICE is much older.
In particular, r170459 started to ICE on this (before that it got rejected with

pr77655.C: In function ‘decltype (g(0, (g)(h::a)...)) h(A&& ...) [with A
= {}, decltype (g(0, (g)(h::a)...)) = void]’:
pr77655.C:8:5:   instantiated from here
pr77655.C:4:3: error: no matching function for call to ‘h(h(A&& ...) [with A =
{}, decltype (g(0, (g)(h::a)...)) = void]::)’
pr77655.C:4:3: note: candidate is:
pr77655.C:3:6: note: template decltype (g(0, (g)(h::a)...))
h(A&& ...)

while r170459 gives:

Internal compiler error: Error reporting routines re-entered.
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

and starting with r198487 it gets the current diagnostics + ICE afterwards.

[Bug tree-optimization/77648] [5/6/7 Regression] Setting conversion to a integer to double to 0 3/4 through a loop

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Created attachment 39657
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39657=edit
patch in testing

Contains two C testcases -- the Fortran bug is in another code path, a Fortran
testcase suitable for the testsuite would be appreciated (single-file, runtime,
fails without, passes with the patch).  Unfortunately(?) there is no way to
create "fn spec" attributes in C testcases.

[Bug c++/77660] New: Conversion operator unknown or ambiguous: gcc or clang behave differently

[naupacte at sfr dot fr]

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

Bug ID: 77660
   Summary: Conversion operator unknown or ambiguous: gcc or clang
behave differently
   Product: gcc
   Version: 5.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: naupacte at sfr dot fr
  Target Milestone: ---

In relation with bug #50306:
(using gcc5.4.1 or gcc6.1 from macports)

struct A;
struct B;

template  struct Ptr
{
template  operator const Ptr& () const;
#ifdef GCC_BUT_CLANG_DECLARES_IT_IS_AMBIGUOUS
template  operator   Ptr  () const; // required by gcc
but skipped for clang
#endif
};


const Ptr& foo1 (const Ptr& b) { return b;}//gcc ok 
  Ptr  foo2 (const Ptr& b) { return b;}// needs
GCC_BUT_CLANG_DECLARES_IT_IS_AMBIGUOUS to be set
  Ptr  foo2a(const Ptr& b) { return static_cast(b);} //gcc
patch


Who is right? Gcc cannot convert from const Ptr& to Ptr via const
Ptr&. I guess it has an influence on its inability to get the common type
for brace-lists or ?: pairs when only the reference conversion is given.

To avoid error: define GCC_BUT_CLANG_DECLARES_IT_IS_AMBIGUOUS only for gcc.
Otherwise, we get:

GCC

/opt/local/bin/gcc-mp-6 -x c++ -std=c++1y -c program.cpp

program.cpp: In function 'Ptr foo2(const Ptr&)':
program.cpp:22:47: error: could not convert 'b' from 'const Ptr' to 'Ptr'
   Ptr  foo2 (const Ptr& b) { return b;}// needs
GCC_BUT_CLANG_DECLARES_IT_IS_AMBIGUOUS to be set

CLANG
=

clang-mp-3.8 -x c++ -std=c++1y -c program.cpp
-DGCC_BUT_CLANG_DECLARES_IT_IS_AMBIGUOUS

program.cpp:22:47: error: conversion from 'const Ptr' to 'Ptr' is
ambiguous
  Ptr  foo2 (const Ptr& b) { return b;}// needs
GCC_BUT_CLANG_DECLARES_IT_IS_AMBIGUOUS to be set
  ^
program.cpp:13:76: note: candidate function [with U = A]
template  operator const Ptr& () const;
   ^
program.cpp:15:76: note: candidate function [with U = A]
template  operator   Ptr  () const;
   ^
program.cpp:23:47: error: ambiguous conversion for static_cast from 'const
Ptr' to 'Ptr'
  Ptr  foo2a(const Ptr& b) { return static_cast(b);} //gcc
patch
  ^~
program.cpp:11:27: note: candidate is the implicit copy constructor
template  struct Ptr
  ^
program.cpp:11:27: note: candidate is the implicit move constructor
2 errors generated.

[Bug tree-optimization/77621] [6/7 Regression] Internal compiler error for mtune=atom + msse2

[ubizjak at gmail dot com]

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

--- Comment #14 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #13)
> Created attachment 39656 [details]
> patch for the ICE

+/* { dg-additional-options "-march=i686 -mtune=atom -msse2" { target ia32 } }
*/

You can use

/* { dg-additional-options "-mtune=atom -msse2" { target i?86-*-* x86_64-*-* }
} */

and the test will also break on x86_64.

[Bug tree-optimization/77621] [6/7 Regression] Internal compiler error for mtune=atom + msse2

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Created attachment 39656
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39656=edit
patch for the ICE

[Bug tree-optimization/77644] missed optimization with sqrt in comparison

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement

[Bug c++/77467] Segmentation fault with switch statement in constexpr function

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #39559|0   |1
is obsolete||

--- Comment #3 from Jakub Jelinek  ---
Created attachment 39655
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39655=edit
gcc7-pr77467.patch

Updated untested fix.

[Bug tree-optimization/77621] [6/7 Regression] Internal compiler error for mtune=atom + msse2

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
(In reply to Uroš Bizjak from comment #11)
> (In reply to rguent...@suse.de from comment #9)
> 
> > I believe atom _does_ have full SSE2 support, no?  Using intrinsics
> > (even those expanding to GCC generic vector extension code) should
> > end up emitting SSE2 double instructions?
> 
> True.
> 
> > So what you want to tell the vectorizer is to not introduce vectorized
> > code using V2DFmode.  I still think a better way is to handle this
> > via costs (like a loop with mostly integer ops but a single FP double
> > op is probably still profitable to vectorize).
> 
> The patch, attached in the previous message implements the above suggestion,
> and also fixes the testcase with -mtune=atom. However, I have no performance
> data to base cost values on, so the patch artificially rises the cost of
> DFmode vector insns for 20:
> 
> +  /* FIXME: The value here is arbitrary
> + and could potentially be improved with analysis.  */
> +  if (vectype && GET_MODE_INNER (TYPE_MODE (vectype)) == DFmode
> +  && !TARGET_VECTORIZE_DOUBLE)
> +cost += 20;
> 
> [...]

If V2DFmode moves are fine(?) then maybe not do this for the load/store
kinds - this means only handling vector_stmt this way (and maybe
vect_promote_demote?) - at least make sure to not handle scalar_*
(not sure if vectype is always NULL for those -- docs say only
memory ops may depend on vectype).
Instead of += 20 I'd have done *=  to
make it more independent of the absolute value of the cost numbers.

If you'd do the cost adjustment in ix86_add_stmt_cost you have more control
over the details (there's also similar offsetting for silvermont)

> > not sure why we override TYPE_MODE with preferred_simd_mode.  It's not
> > that the x86 backend will emit word_mode loads/stores for V2DFmode
> > loads/stores on i?86 with -mtune=atom?
> 
> Oh... no. We *do* have V2DFmode, but we want to avoid it as much as possible.

That's what I thought.

[Bug c++/77658] internal compiler error: in assign_temp, at function.c:961

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Last reconfirmed||2016-9-20
 CC||marxin at gcc dot gnu.org
  Known to work||6.2.0, 7.0
 Resolution|--- |FIXED
  Known to fail||6.1.0

--- Comment #1 from Martin Liška  ---
The only affected release is 6.1.0, the ICE is fixed on both trunk and 6.2.0.
Fixed in r236430.

[Bug fortran/71952] [Coarray, F2008] Rejects valid coarray access with array partref

[vehre at gcc dot gnu.org]

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

--- Comment #5 from vehre at gcc dot gnu.org ---
Well, patch submitted as r240231 although it doesn't show here. Waiting one
week for regressions before closing.

[Bug tree-optimization/77648] [5/6/7 Regression] Setting conversion to a integer to double to 0 3/4 through a loop

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
struct S { int *p; int *q; };

int **__attribute__((noinline,noclone,pure)) foo (struct S *s)
{
  return >q;
}

int main()
{
  struct S s;
  int i = 1, j = 2;
  int **x;
  s.p = 
  s.q = 
  x = foo ();
  **x = 7;
  if (j != 7)
__builtin_abort ();
  return 0;
}

[Bug c++/77659] internal compiler error: in gimplify_expr, at gimplify.c:8858

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
on trunk with checking enabled:

markus@x4 tmp % g++ -c m.ii   
m.ii: In instantiation of ‘void A::m_fn1() [with  =
int]’:
m.ii:10:16:   required from here
m.ii:4:29: internal compiler error: in tsubst_copy, at cp/pt.c:14610
 int baz = get_max_value(baz);
 ^~~
0x6b8cb9 tsubst_copy
../../gcc/gcc/cp/pt.c:14610
0x6bd55a tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:16363
0x6bc863 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:16271
0x6bc90e tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:16170
0x6bc703 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:16147
0x6bd2cc tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:16928
0x6bd615 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:16617
0x6bdb64 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17086
0x6bca48 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:16910
0x6bc4d4 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:16479
0x6b2120 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15936
0x6b0280 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15242
0x6b183d tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15419
0x6aed50 instantiate_decl(tree_node*, int, bool)
../../gcc/gcc/cp/pt.c:22159
0x6f61fb instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:22276
0x73aa4f c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.c:4617

[Bug c++/77659] internal compiler error: in gimplify_expr, at gimplify.c:8858

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-20
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
template  Type get_max_value(Type);
struct A {
  struct B {
int baz = get_max_value(baz);
  };
  template  void m_fn1() { new B{}; }
};
void foo() {
  A a;
  a.m_fn1();
}

[Bug c++/77659] New: internal compiler error: in gimplify_expr, at gimplify.c:8858

[zoidbergx at tlen dot pl]

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

Bug ID: 77659
   Summary: internal compiler error: in gimplify_expr, at
gimplify.c:8858
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zoidbergx at tlen dot pl
  Target Milestone: ---

Created attachment 39654
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39654=edit
preprocessored file main.cpp

"gcc -v" output:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.2' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.2) 


command line:

g++ -std=c++14 main.cpp


compiler output:

main.cpp: In member function ‘void Foo::bar() [with T = char]’:
main.cpp:12:37: internal compiler error: in gimplify_expr, at gimplify.c:8858
 unsigned baz = get_max_value(baz);
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Comment:
internal compiler error appears in case of "-std=c++14" used; in case of
"-std=c++11" used everything is ok.

[Bug tree-optimization/77648] [5/6/7 Regression] Setting conversion to a integer to double to 0 3/4 through a loop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Hmm, the vectorized loop itself looks ok to me.  Unfortunately I can't get gdb
to
help me debugging the result array.  Looks like the 3rd invocation of
evaluate_1dim_real gets the bogus data:

-   0.0.   -1.1904761904761946E-002
  0.   0.12500  -0.1  
0.41663  -0.28571428571428570   0.10416  
-1.5873015873015872E-002
+   0.0.   -1.1904761904761946E-002
  0.   0.12500  -0.1  
0.41663  -0.285714285714285700.   
0. 

--param vect-max-peeling-for-alignment=0 simplifies the generated code but
doesn't fix the issue.

Adding -fno-tree-dse does.

;; Function integrate_poly_indefinite
(__poly_module_MOD_integrate_poly_indefinite, funcdef_no=17, decl_uid=3532,
cgraph_uid=17, symbol_order=17)

  Deleted dead store 'MEM[(real(kind=8)[0:] *)_14][_32] = _44;
'
  Deleted dead store 'MEM[(real(kind=8)[0:] *)_14][_91] = _97;
'
integrate_poly_indefinite (struct poly & restrict p)


And:

  # .MEM_5 = VDEF <.MEM_4(D)>
  p_intD.4173.coefficientsD.3452.dataD.3438 = 0B;
...
  # .MEM_12 = VDEF <.MEM_10>
  # USE = nonlocal escaped null { D.4173 D.4174 D.7974 D.7975 D.7976 }
(nonlocal)
  # CLB = nonlocal escaped null { D.4173 }
  init_poly (_intD.4173, , _11);
...
  # PT = null
  _14 = p_intD.4173.coefficients.data;

so somehow init_poly side effect is not properly reflected.  Constraints look
good:

p_int.128+64 = 
...
callarg(28) = _int.0+96
callarg(28) = *callarg(28) + UNKNOWN
CALLUSED(26) = callarg(28)
CALLCLOBBERED(27) = callarg(28)
*callarg(28) = NONLOCAL
...
_14 = p_int.128+64

but in the end:

p_int.0+96 = { ESCAPED NONLOCAL } same as p_int.0+96
p_int.128+64 = { NULL }
p_int.192+320 = { } same as _15
p_int.512+64 = { NULL }
p_int.576+320 = { } same as p_int.576+320

so somehow callarg(28) = *callarg(28) + UNKNOWN does not have the desired
effect.

[Bug c++/63693] ICE in resolve_typename_type

[yury.zaytsev at traveltainment dot de]

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

--- Comment #8 from Yury V. Zaytsev  ---
So, not going to be backported to 5.x?

[Bug c++/63693] ICE in resolve_typename_type

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||dannix84 at gmail dot com

--- Comment #7 from Paolo Carlini  ---
*** Bug 70254 has been marked as a duplicate of this bug. ***

[Bug c++/70254] Compiler crash

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #6 from Paolo Carlini  ---
Dup.

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

[Bug tree-optimization/77621] [6/7 Regression] Internal compiler error for mtune=atom + msse2

[ubizjak at gmail dot com]

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

--- Comment #11 from Uroš Bizjak  ---
(In reply to rguent...@suse.de from comment #9)

> I believe atom _does_ have full SSE2 support, no?  Using intrinsics
> (even those expanding to GCC generic vector extension code) should
> end up emitting SSE2 double instructions?

True.

> So what you want to tell the vectorizer is to not introduce vectorized
> code using V2DFmode.  I still think a better way is to handle this
> via costs (like a loop with mostly integer ops but a single FP double
> op is probably still profitable to vectorize).

The patch, attached in the previous message implements the above suggestion,
and also fixes the testcase with -mtune=atom. However, I have no performance
data to base cost values on, so the patch artificially rises the cost of DFmode
vector insns for 20:

+  /* FIXME: The value here is arbitrary
+ and could potentially be improved with analysis.  */
+  if (vectype && GET_MODE_INNER (TYPE_MODE (vectype)) == DFmode
+  && !TARGET_VECTORIZE_DOUBLE)
+cost += 20;

[...]

> not sure why we override TYPE_MODE with preferred_simd_mode.  It's not
> that the x86 backend will emit word_mode loads/stores for V2DFmode
> loads/stores on i?86 with -mtune=atom?

Oh... no. We *do* have V2DFmode, but we want to avoid it as much as possible.

[Bug tree-optimization/77621] [6/7 Regression] Internal compiler error for mtune=atom + msse2

[ubizjak at gmail dot com]

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

--- Comment #10 from Uroš Bizjak  ---
Created attachment 39653
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39653=edit
Target-dependent patch that disables DFmode vectorization via vector costs

Proposed target-dependent patch.

[Bug tree-optimization/57558] Loop not vectorized if iteration count could be infinite

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from amker at gcc dot gnu.org ---
Fixed.

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

[amker at gcc dot gnu.org]

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

Bug 57558 Summary: Loop not vectorized if iteration count could be infinite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57558

   What|Removed |Added

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

[Bug tree-optimization/57558] Loop not vectorized if iteration count could be infinite

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #7 from amker at gcc dot gnu.org ---
(In reply to Rainer Orth from comment #6)
> Created attachment 39057 [details]
> sparcv9 pr57558-1.c.149t.vect
> 
> The new gcc.dg/vect/pr57558-1.c test FAILs on 64-bit Solaris/SPARC:
> 
> +FAIL: gcc.dg/vect/pr57558-1.c -flto -ffat-lto-objects  scan-tree-dump vect
> "vec
> torized 1 loops"
> +FAIL: gcc.dg/vect/pr57558-1.c scan-tree-dump vect "vectorized 1 loops"
I revised the test and now this should be fixed.
> 
> I'm attaching the dump.
> 
>   Rainer

[Bug tree-optimization/77646] [5/6/7 Regression] GCC Segfault with -O3

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Ok, this is because we value-number the indirect call result to the result of
the direct call (correctly) but that has no VDEF (it's detected pure) and thus
we fail to value-number the indirect calls VDEF.

@@ -3470,6 +3577,10 @@ visit_reference_op_call (tree lhs, gcall
 {
   if (vnresult->result_vdef && vdef)
changed |= set_ssa_val_to (vdef, vnresult->result_vdef);
+  else if (vdef)
+   /* If the call was discovered to be pure or const reflect
+  that as far as possible.  */
+   changed |= set_ssa_val_to (vdef, gimple_vuse (stmt));

   if (!vnresult->result && lhs)
vnresult->result = lhs;

[Bug c++/77658] New: internal compiler error: in assign_temp, at function.c:961

[naupacte at sfr dot fr]

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

Bug ID: 77658
   Summary: internal compiler error: in assign_temp, at
function.c:961
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: naupacte at sfr dot fr
  Target Milestone: ---

//A very strange combination is needed to produce the ICE:
//Full program:

struct A
{
//A();
~A(); // NEEDED to produce ICE
};

#ifdef FIRST_CASE
A a (int) { throw ""; return {};}
A b (int) { throw ""; return {};}

A c (int) { throw ""; return {};}
A d (int) { throw ""; return {};}
A e (int) { throw ""; return {};}

#else // second case

A a (int) { throw 1;}
A b (int) { throw 1;}

A c (int) { throw 1;}
A d (int) { throw 1;}
A e (int) { throw 1;}

#endif
//EOF

NB: THERE MUST be at least 5 such functions:
- returning type A
- and throwing same type
- having one (unique?) same argument type





MacBookPro$  /opt/local/bin/gcc-mp-6 -x c++ -c .cpp  -O3
program.cpp: In function 'A a(int)':
program.cpp:16:3: internal compiler error: in assign_temp, at function.c:961
 A a (int) { throw 1;}
   ^

program.cpp:16:3: internal compiler error: Abort trap: 6
gcc-mp-6: internal compiler error: Abort trap: 6 (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


MacBookPro$ /opt/local/bin/gcc-mp-6 -v
Using built-in specs.
COLLECT_GCC=/opt/local/bin/gcc-mp-6
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin15/6.1.0/lto-wrapper
Target: x86_64-apple-darwin15
Configured with:
/opt/local/var/macports/build/_opt_mports_dports_lang_gcc6/gcc6/work/gcc-6.1.0/configure
--prefix=/opt/local --build=x86_64-apple-darwin15
--enable-languages=c,c++,objc,obj-c++,lto,fortran,java
--libdir=/opt/local/lib/gcc6 --includedir=/opt/local/include/gcc6
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-6 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-6
--with-gxx-include-dir=/opt/local/include/gcc6/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local
--enable-stage1-checking --disable-multilib --enable-lto
--enable-libstdcxx-time --with-build-config=bootstrap-debug
--with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket
--with-pkgversion='MacPorts gcc6 6.1.0_0'
Thread model: posix
gcc version 6.1.0 (MacPorts gcc6 6.1.0_0)

[Bug tree-optimization/77646] [5/6/7 Regression] GCC Segfault with -O3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |5.5

--- Comment #4 from Richard Biener  ---
Mine.

[Bug tree-optimization/77647] [6/7 Regression] Missed opportunity to use register value causes additional load

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Known to work||5.4.0
   Target Milestone|--- |6.3
Summary|Missed opportunity to use   |[6/7 Regression] Missed
   |register value causes   |opportunity to use register
   |additional load |value causes additional
   ||load

--- Comment #2 from Richard Biener  ---
DOM doesn't propagate the equivalence on the not unreachable edge, that is,
it doesn't copy-propagate because of PR71947

  if (ret_3 != _5)
goto ;
  else
goto ;

  :
  __builtin_unreachable ();

  :
  _4 = ret_3 + _5;

DOM does the following after Jeffs patch:

Optimizing block #4

1>>> STMT 1 = ret_3 le_expr _5
1>>> STMT 1 = ret_3 ge_expr _5
1>>> STMT 1 = ret_3 eq_expr _5
1>>> STMT 0 = ret_3 ne_expr _5
0>>> COPY ret_3 = _5
0>>> COPY _5 = ret_3
Optimizing statement _4 = ret_3 + _5;
  Replaced 'ret_3' with variable '_5'
  Replaced '_5' with variable 'ret_3'
  Folded to: _4 = ret_3 + _5;

which is of course a quite stupid replacement.  I still believe the change
should be reverted ... Jeff, are you still investigating this?

Works on the GCC 5 branch:

Optimizing block #4

0>>> COPY _5 = ret_3
1>>> STMT 1 = ret_3 le_expr _5
1>>> STMT 1 = ret_3 ge_expr _5
1>>> STMT 1 = ret_3 eq_expr _5
1>>> STMT 0 = ret_3 ne_expr _5
Optimizing statement _4 = ret_3 + _5;
  Replaced '_5' with variable 'ret_3'
LKUP STMT _4 = ret_3 plus_expr ret_3
2>>> STMT _4 = ret_3 plus_expr ret_3

with assembly

foo:
.LFB1:
.cfi_startproc
#APP
# 4 "t.c" 1
movq  (%rdi),%rax

# 0 "" 2
#NO_APP
addq%rax, %rax
ret

[Bug tree-optimization/77648] [5/6/7 Regression] Setting conversion to a integer to double to 0 3/4 through a loop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.5
Summary|[4.9/5/6/7 Regression]  |[5/6/7 Regression] Setting
   |Setting conversion to a |conversion to a integer to
   |integer to double to 0 3/4  |double to 0 3/4 through a
   |through a loop  |loop

[Bug c/77650] struct with a nested flexible array followed by another member accepted

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
So maybe document this as an extension (and specify its semantics -- I'm
curious how the glibc code behaves)