[Bug middle-end/81318] [8 regression] ICE in to_reg_br_prob_base, at profile-count.h:189

2017-09-02 Thread zeccav at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81318

--- Comment #24 from Vittorio Zecca  ---
I confirm this bug prevents building the Linux kernel 4.12 with gcc trunk
251201.
gcc 7.2 seems to build the kernel just fine.

[Bug target/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

2017-09-02 Thread howarth.at.gcc at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #13 from Jack Howarth  ---
The following hack allows gcc 7.2.0 to complete the 3 stage bootstrap of the
c,c++,fortran,lto,objc,obj-c++ language set under High Sierra on an APFS
volume...

diff -uNr gcc-7.2.0.orig/libstdc++-v3/include/Makefile.in
gcc-7.2.0/libstdc++-v3/include/Makefile.in
--- gcc-7.2.0.orig/libstdc++-v3/include/Makefile.in 2017-07-25
14:05:07.0 -0400
+++ gcc-7.2.0/libstdc++-v3/include/Makefile.in  2017-09-02 12:22:08.0
-0400
@@ -1764,6 +1764,8 @@
 @GLIBCXX_HOSTED_TRUE@install-data-local: install-headers
 @GLIBCXX_HOSTED_FALSE@install-data-local: install-freestanding-headers

+.NOTPARALLEL: install-headers
+
 # This is a subset of the full install-headers rule.  We only need ,
 # , , , , , , ,
 # , , , , ,

[Bug target/53687] _mm_cmpistri generates redundant movslq %ecx,%rcx on x86-64

2017-09-02 Thread peter at cordes dot ca 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53687

Peter Cordes  changed:

   What|Removed |Added

 CC||peter at cordes dot ca

--- Comment #1 from Peter Cordes  ---
This behaviour is pretty understandable.  gcc doesn't know that the
return-value range is only 0-16, i.e. guaranteed non-negative integers.  Since
you used a signed int offset, makes sense that it *sign* extends from 32 to 64.

If you use  unsigned offset, the missed-optimization becomes more obvious. 
gcc7.2 still uses a  movl%ecx, %ecx  to zero-extend into rcx.

https://godbolt.org/g/wWvqpa

(Incidentally, same,same is the worst possible choice of registers for Intel
CPUs.  It means the mov can never be eliminated in the rename stage, and always
needs an execution port with non-zero latency.)

Even uintptr_t offset doesn't avoid it, because then the conversion from the
intrinsic to the variable results in sign-extension up to 64-bit.  It treats it
exactly like a function that returns int, which in the SysV ABI is allowed to
have garbage in the upper32.


(BTW, this use of flags from inline asm is not guaranteed to be safe.  Nothing
stops the optimizer from doing the pointer-increment after the `pcmpistri`,
which would clobber flags.  You could do `pcmpistri` inside the asm and produce
a uintptr_t output operand, except that doesn't work with goto.  So really you
should write the whole loop in inline asm)


Or better, don't use inline asm at all: gcc can CSE _mm_cmpistri with
_mm_cmpistra, so you can just use the intrinsic twice to get multiple operands,
and it will compile to a single instruction.  This is like using `/` and `%`
operators to get both results of a `div`.

[Bug target/81995] [8.0 Regression] gcc/reg-stack.c:2073:1: error: unrecognizable insn:

2017-09-02 Thread gerald at pfeifer dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81995

Gerald Pfeifer  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #4 from Gerald Pfeifer  ---
Confirmed as fixed.

[Bug fortran/82086] New: namelist read with repeat count fails when item is member of array of structures

2017-09-02 Thread jsberg at bnl dot gov 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82086

Bug ID: 82086
   Summary: namelist read with repeat count fails when item is
member of array of structures
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsberg at bnl dot gov
  Target Milestone: ---

This program:

program t170902a
  implicit none
  type t
 character(64) :: c=''
  end type t
  type(t), dimension(16) :: ta
  namelist /n/ta

  open(1,file='170902a.txt')
  read(1,nml=n)
end program t170902a

With this text in '170902a.txt':


 ta(1:8)%c = 8*'bogus'
/

Gives the following on execution:

At line 10 of file 170902a.f90 (unit = 1, file = '170902a.txt')
Fortran runtime error: Repeat count too large for namelist object ta%c

Error termination. Backtrace:

Could not print backtrace: libbacktrace could not find executable to open
#0  0x
#1  0x
#2  0x
#3  0x
#4  0x
#5  0x
#6  0x
#7  0x
#8  0x
#9  0x
#10  0x
#11  0x
#12  0x

Compiler command line:

gfortran.exe -Wall -Wextra 170902a.f90 -o 170902a.exe

gcc -v:

Using built-in specs.
COLLECT_GCC=\mingw64-7_1_0\bin\gfortran.exe
COLLECT_LTO_WRAPPER=C:/mingw64-7_1_0/bin/../libexec/gcc/x86_64-w64-mingw32/7.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-7.1.0/configure --host=x86_64-w64-mingw32
--build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64
--with-sysroot=/c/mingw710/x86_64-710-win32-seh-rt_v5-rev2/mingw64
--enable-shared --enable-static --disable-multilib
--enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes
--enable-threads=win32 --enable-libgomp --enable-libatomic --enable-lto
--enable-graphite --enable-checking=release --enable-fully-dynamic-string
--enable-version-specific-runtime-libs --enable-libstdcxx-filesystem-ts=yes
--disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona
--with-tune=core2 --with-libiconv --with-system-zlib
--with-gmp=/c/mingw710/prerequisites/x86_64-w64-mingw32-static
--with-mpfr=/c/mingw710/prerequisites/x86_64-w64-mingw32-static
--with-mpc=/c/mingw710/prerequisites/x86_64-w64-mingw32-static
--with-isl=/c/mingw710/prerequisites/x86_64-w64-mingw32-static
--with-pkgversion='x86_64-win32-seh-rev2, Built by MinGW-W64 project'
--with-bugurl=https://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe
-fno-ident -I/c/mingw710/x86_64-710-win32-seh-rt_v5-rev2/mingw64/opt/include
-I/c/mingw710/prerequisites/x86_64-zlib-static/include
-I/c/mingw710/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2
-pipe -fno-ident
-I/c/mingw710/x86_64-710-win32-seh-rt_v5-rev2/mingw64/opt/include
-I/c/mingw710/prerequisites/x86_64-zlib-static/include
-I/c/mingw710/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS='
-I/c/mingw710/x86_64-710-win32-seh-rt_v5-rev2/mingw64/opt/include
-I/c/mingw710/prerequisites/x86_64-zlib-static/include
-I/c/mingw710/prerequisites/x86_64-w64-mingw32-static/include' LDFLAGS='-pipe
-fno-ident -L/c/mingw710/x86_64-710-win32-seh-rt_v5-rev2/mingw64/opt/lib
-L/c/mingw710/prerequisites/x86_64-zlib-static/lib
-L/c/mingw710/prerequisites/x86_64-w64-mingw32-static/lib '
Thread model: win32
gcc version 7.1.0 (x86_64-win32-seh-rev2, Built by MinGW-W64 project)

[Bug c++/43745] [avr] g++ puts VTABLES in SRAM

2017-09-02 Thread gjl at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43745

--- Comment #13 from Georg-Johann Lay  ---
(In reply to Matthijs Kooijman from comment #12)
> Apologies if this is an obvious question, but I'm not familiar with gcc/g++
> internals. Georg-Johann, you say this requires address space support in c++,
> but I'm not sure I follow you there. Two things:
> You say WG21 will never add AS support to C++, but also say that language
> support for AS is not needed, only internal support in gcc/g++. So that
> means what WG21 does is not relevant for vtable handling in particular?

Front-end maintainers usually follow the WGs in what they implement and are
willing to approve.  When you propose some non-standard extensions — even as a
working patch with testcases, documentation, etc. — the maintainers will reject
it.  They fear it might be inconsistent with existing features or the code
"just being dropped" and maintenance burden is up to them.

Adding AS in the c++ front-end without exposing them to the language (i.e. you
still can't use __flash in c++) will be rejected by the maintainers as "too
specific", see below for similar case.

> Even if AS would not be used, what prevents g++ from emitting the vtables
> in the `progmem.data` section and generating vtable-invocation code using
> LPM instructions?

vtables are generated by the c++ front-end.  Some hacking in the avr back-end
might be enough to but these tables in flash, but you cannot access it
correctly without qualifying all accesses.  These qualifiers must be added by
the c++ FE so that any pointers / accesses / (internal) variables derived from
it use the correct AS.

We just saw the maintainers rejecting PR49857 (which is about putting
tree-switch-converted lookup-tables into flash / named AS) as "too specific". 
The avr part was approved.  The only change to the middle-end was a well
documented hook (statically) invoked only once in tree-switch-conversion
module.  The maintainers proposed "more generic" solution; none of proposals
would work and none of them would be more generic because the only object
that's opt to such optimization is CSWTCH from tree-switch-conversion.

I got the impression it wasn't even understood why one cannot just patch
sections.  And patching ASes won't work if any pass might copy a pointer. The
tables must be read-only, in static storage, not public, not weak, not
linkonce, not comdat, and must be artificial, i.e. cooked up by the compiler
(otherwise inline asm will break).  So the only use case was CSWTCH anyway...

For details see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49857#c17

vtables are even more restrictive because it would be an ABI change: all
modules accessing the vtable must agree upon it's AS, i.e. you cannot specify
the AS per command option.

> or some gcc-specific attribute on a class?

Attributes won't work — due to the same reason for why progmem does not work
with c / c++: with progmem: you'd need inline asm.  And because vtables are
artificial, you'll never gat a hand on them.

And to be honest:  My current impression is that avr-gcc is a dead horse. 
http://gcc.gnu.org/ml/gcc/2017-07/msg00224.html

Maintainers are proposing to deprecate bunch of backends as a side effect of
deprecating two essential features that are "old code" and not used by the
targets they get their bucks for.  Sooner or later they will succeed,
effectively throwing bunch of targets into the dust bin.

With that perspective and my recent impressions, I think working on avr-gcc has
become a waste of time.

[Bug sanitizer/82072] sanitizer does not detect an overflow from LLONG_MIN

2017-09-02 Thread zeccav at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82072

--- Comment #10 from Vittorio Zecca  ---
A related issue is the following:

/* UB sanitizer should detect undefined negation of LLONG_MIN */
/* must be compiled with -fsanitize=undefined and run */
#include 
int main()
{
long long int llnum=LLONG_MIN;
unsigned  int unum;
unum = - llnum;/*negation of -9223372036854775808 cannot be represented in type
'long long int'*/
return 0;
}

Or should I open a new bug?

[Bug fortran/81770] [5/6/7 Regression] Bogus warning: Pointer in pointer assignment might outlive the pointer target

2017-09-02 Thread janus at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81770

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from janus at gcc dot gnu.org ---
Fixed on trunk and all open release branches. Closing.

[Bug fortran/81770] [5/6/7 Regression] Bogus warning: Pointer in pointer assignment might outlive the pointer target

2017-09-02 Thread janus at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81770

--- Comment #5 from janus at gcc dot gnu.org ---
Author: janus
Date: Sat Sep  2 20:13:49 2017
New Revision: 251620

URL: https://gcc.gnu.org/viewcvs?rev=251620=gcc=rev
Log:
2017-09-02  Janus Weil  

Backport from trunk
PR fortran/81770
* expr.c (gfc_check_pointer_assign): Improve the check whether pointer
may outlive pointer target.


2017-09-02  Janus Weil  

Backport from trunk
PR fortran/81770
* gfortran.dg/warn_target_lifetime_3.f90: Fix a typo.
* gfortran.dg/warn_target_lifetime_4.f90: New testcase.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/warn_target_lifetime_4.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/expr.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/warn_target_lifetime_3.f90

[Bug fortran/82077] [7/8 Regression] ICE on associating polymorphic array dummy with a type-guarded array section

2017-09-02 Thread janus at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82077

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-02
 Ever confirmed|0   |1

--- Comment #2 from janus at gcc dot gnu.org ---
This slightly reduced test case only needs a sinlge type and a one-dimensional
array:

  type :: child
  end type
  class(child), allocatable :: foo(:)
  allocate(foo(1))
  select type(foo)
class is (child)
  call gfortran7_ICE(foo(1:1))
  end select
contains
  subroutine gfortran7_ICE(bar)
class(child) bar(:)
  end subroutine
end

[Bug fortran/82077] [7/8 Regression] ICE on associating polymorphic array dummy with a type-guarded array section

2017-09-02 Thread janus at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82077

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||janus at gcc dot gnu.org
Summary|[7.1 Regression]: ICE on|[7/8 Regression] ICE on
   |associating polymorphic |associating polymorphic
   |array dummy with a  |array dummy with a
   |type-guarded array section  |type-guarded array section

--- Comment #1 from janus at gcc dot gnu.org ---
Confirmed.

[Bug fortran/81770] [5/6/7 Regression] Bogus warning: Pointer in pointer assignment might outlive the pointer target

2017-09-02 Thread janus at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81770

--- Comment #4 from janus at gcc dot gnu.org ---
Author: janus
Date: Sat Sep  2 19:31:44 2017
New Revision: 251619

URL: https://gcc.gnu.org/viewcvs?rev=251619=gcc=rev
Log:
2017-09-02  Janus Weil  

Backport from trunk
PR fortran/81770
* expr.c (gfc_check_pointer_assign): Improve the check whether pointer
may outlive pointer target.


2017-09-02  Janus Weil  

Backport from trunk
PR fortran/81770
* gfortran.dg/warn_target_lifetime_3.f90: Fix a typo.
* gfortran.dg/warn_target_lifetime_4.f90: New testcase.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/warn_target_lifetime_4.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/expr.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/warn_target_lifetime_3.f90

[Bug fortran/82064] [7/8 Regression] [OOP] multiple incompatible definitions of extended derived type via module use

2017-09-02 Thread janus at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82064

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-02
 CC||janus at gcc dot gnu.org
Summary|[OOP] multiple incompatible |[7/8 Regression] [OOP]
   |definitions of extended |multiple incompatible
   |derived type via module use |definitions of extended
   ||derived type via module use
 Ever confirmed|0   |1

--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to Daan van Vugt from comment #0)
> In the attached zip file are the files needed to reproduce.
> Run `make` to create `test_sep` from test_sep.f90 which prints ERR twice on
> my machine.
> Putting all the modules and the program together in one file yields a
> program that prints OK twice. (test.f90)

I can confirm that behavior with gfortran 7.1 and trunk.

Earlier versions (e.g. 6.3 and 5.1) seem to print OK twice with both variants.

[Bug fortran/81770] [5/6/7 Regression] Bogus warning: Pointer in pointer assignment might outlive the pointer target

2017-09-02 Thread janus at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81770

--- Comment #3 from janus at gcc dot gnu.org ---
Author: janus
Date: Sat Sep  2 19:04:08 2017
New Revision: 251618

URL: https://gcc.gnu.org/viewcvs?rev=251618=gcc=rev
Log:
2017-09-02  Janus Weil  

Backport from trunk
PR fortran/81770
* expr.c (gfc_check_pointer_assign): Improve the check whether pointer
may outlive pointer target.


2017-09-02  Janus Weil  

Backport from trunk
PR fortran/81770
* gfortran.dg/warn_target_lifetime_3.f90: Fix a typo.
* gfortran.dg/warn_target_lifetime_4.f90: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/warn_target_lifetime_4.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/expr.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/warn_target_lifetime_3.f90

[Bug c++/82085] New: Crash: Template variable reference used in nested template alias

2017-09-02 Thread rbock at eudoxos dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82085

Bug ID: 82085
   Summary: Crash: Template variable reference used in nested
template alias
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rbock at eudoxos dot de
  Target Milestone: ---

I am currently porting sqlpp11 to C++17 and encountered a compiler crash using
the following code

// ---
template 
using char_sequence_t = int;

template 
constexpr char name_of_v = 'x';

template 
using type = char_sequence_t<name_of_v>;
// ---


g++ (GCC) 8.0.0 20170902 (experimental)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug target/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

2017-09-02 Thread howarth.at.gcc at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #12 from Jack Howarth  ---
Just to add in things that don't fix these failures, the following doesn't
help...

--- gcc-7.2.0/libstdc++-v3/include/Makefile.in.orig 2017-09-02
11:00:08.0 -0400
+++ gcc-7.2.0/libstdc++-v3/include/Makefile.in  2017-09-02 11:12:38.0
-0400
@@ -1887,16 +1887,37 @@
 # developer tries to create them via make in the include build
 # directory. (This is more of an example of how this kind of rule can
 # be made.)
-.PRECIOUS: $(std_headers) $(c_base_headers) $(tr1_headers) $(tr2_headers)
+.PRECIOUS: $(std_headers) $(bits_headers) $(c_base_headers) $(tr1_headers)
$(tr2_headers)
   $(decimal_headers) $(ext_headers) $(experimental_headers)
-  $(experimental_bits_headers)
+  $(experimental_bits_headers) $(bits_host_headers)
$(bits_sup_headers)
+  $(backward_headers) $(ext_compat_headers) $(ext_host_headers) 
+  $(experimental_filesystem_headers)
$(experimental_bits_filesystem_headers)
+  $(c_compatibility_headers) $(debug_headers) $(parallel_headers)
+  $(profile_headers) $(profile_impl_headers) $(host_headers)
$(thread_host_headers)
 $(std_headers): ; @:
+$(bits_headers): ; @:
+$(bits_host_headers): ; @:
+$(bits_sup_headers): ; @:
+$(backward_headers): ; @:
 $(c_base_headers): ; @:
 $(tr1_headers): ; @:
+$(tr2_headers): ; @:
 $(decimal_headers): ; @:
 $(ext_headers): ; @:
+$(ext_compat_headers): ; @:
+$(ext_host_headers): ; @:
 $(experimental_headers): ; @:
 $(experimental_bits_headers): ; @:
+$(experimental_filesystem_headers): ; @:
+$(experimental_bits_filesystem_headers): ; @:
+$(c_compatibility_headers): ; @:
+$(debug_headers): ; @:
+$(parallel_headers): ; @:
+$(profile_headers): ; @:
+$(profile_impl_headers): ; @:
+$(host_headers): ; @:
+$(thread_host_headers): ; @:
+

 # Tell versions [3.59,3.63) of GNU make to not export all variables.
 # Otherwise a system limit (for SysV at least) may be exceeded.

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2017-09-02 Thread andysem at mail dot ru 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878

andysem at mail dot ru changed:

   What|Removed |Added

 CC||andysem at mail dot ru

--- Comment #9 from andysem at mail dot ru ---
The docs
(https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/_005f_005fatomic-Builtins.html#g_t_005f_005fatomic-Builtins)
still says that `__atomic` builtins are intended to replace `__sync` builtins
and should be preferred in the new code. This is no longer true as `__sync`
builtins are now the only way to generate cmpxchg16b without having to write
assembler code. Please, update the docs accordingly.

[Bug c++/82084] New: internal compiler error: constructing wstring with -O3

2017-09-02 Thread no_s...@loehndorf-flintbek.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82084

Bug ID: 82084
   Summary: internal compiler error: constructing wstring with -O3
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: no_s...@loehndorf-flintbek.de
  Target Milestone: ---

Created attachment 42107
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42107=edit
preprocessed file for gcc 7

#include 
int main()
{
wchar_t strs[4][2]= {  L"A", L"B", L"C" , L"D"};
std::wstring ss(strs[0]);
return 0;
}


Commandline:
gcc -O3 -c test.cpp -o test.o



Error message:
test.cpp: In function ‘int main()’:
test.cpp:2:5: internal compiler error: in vect_get_constant_vectors, at
tree-vect-slp.c:3221
 int main()
 ^~~~
0xcc009a vect_get_constant_vectors
../../src/gcc/tree-vect-slp.c:3221
0xcc084a vect_get_slp_defs(vec, _slp_tree*,
vec, va_heap, vl_ptr>*, int)
../../src/gcc/tree-vect-slp.c:3453
0xc93060 vect_get_vec_defs(tree_node*, tree_node*, gimple*, vec*, vec*, _slp_tree*, int)
../../src/gcc/tree-vect-stmts.c:1558
0xc9bc16 vectorizable_store
../../src/gcc/tree-vect-stmts.c:6201
0xca68d6 vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*,
_slp_instance*)
../../src/gcc/tree-vect-stmts.c:8696
0xcbdeca vect_schedule_slp_instance
../../src/gcc/tree-vect-slp.c:3787
0xcbf715 vect_schedule_slp(vec_info*)
../../src/gcc/tree-vect-slp.c:3858
0xcc4d47 vect_slp_bb(basic_block_def*)
../../src/gcc/tree-vect-slp.c:2891
0xcc5fb5 execute
../../src/gcc/tree-vectorizer.c:908

gcc version: gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 7.2.0-1'
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --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 --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.2.0 (Debian 7.2.0-1) 


Compiles fine without optimization or -O2, also fails in with gcc-6

Using built-in specs.
COLLECT_GCC=gcc-6
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.4.0-3'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --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 --enable-default-pie
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--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 6.4.0 20170805 (Debian 6.4.0-3)

[Bug c++/82069] [8 Regression] ICE: Segmentation fault

2017-09-02 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82069

Markus Trippelsdorf  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug c++/82082] [8 Regression] ICE: in tsubst, at cp/pt.c:13700

2017-09-02 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82082

Markus Trippelsdorf  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug middle-end/82083] New: sanitizer detects signed integer overflow in tree-data-ref.c with -O3

2017-09-02 Thread zeccav at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82083

Bug ID: 82083
   Summary: sanitizer detects signed integer overflow in
tree-data-ref.c with -O3
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
 Build: trunk 251201

// from test case pr60183.c
// must be compiled with -O3 option
// signed integer overflow in tree-data-ref.c
int j = 2;

void
foo (unsigned long *x, unsigned char *y)
{
  int i;
  unsigned long w = x[0];
  for (i = 0; i < j; i++)
{
  w += *y;
  y += 0x1;
  w += *y;
}
  x[1] = w;
}
/*../../gcc/gcc/tree-data-ref.c:3427:16: runtime error: signed integer
overflow: 65536 * -65536 cannot be represented in type 'int'
../../gcc/gcc/tree-data-ref.c:3350:16: runtime error: signed integer overflow:
1073741824 + 1073741824 cannot be represented in type 'int'
../../gcc/gcc/tree-data-ref.c:3429:7: runtime error: negation of -2147483648
cannot be represented in type 'int'; cast to an unsigned type to negate this
value to itself
../../gcc/gcc/tree-data-ref.c:3428:7: runtime error: negation of -2147483648
cannot be represented in type 'int'; cast to an unsigned type to negate this
value to itself*/

[Bug c++/82082] New: [8 Regression] ICE: in tsubst, at cp/pt.c:13700

2017-09-02 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82082

Bug ID: 82082
   Summary: [8 Regression] ICE: in tsubst, at cp/pt.c:13700
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

Created attachment 42106
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42106=edit
Somewhat reduced testcase

More r251433 outfall:

 % g++ -w -c logical.ii
logical.ii: In instantiation of ‘TestLogical< 
>::TestLogical(Xs) [with Xs = tuple;  =
when]:: [with auto:1 =
; auto:2 = ; auto:3 = ; auto:4 = ]’:
logical.ii:80:29:   required from ‘auto partial_t::operator()(Y ...) [with Y = {ebo,
int>}; long unsigned int ...n = {0}; F = partial_t::TestLogical(Xs) [with Xs = tuple;
 = when]::, int>, int>; X = {int}]’
logical.ii:138:18:   required from ‘void on_each::operator()(Xs ...) [with
Xs = {ebo, int>}; F = partial_t::TestLogical(Xs) [with Xs = tuple;
 = when]::, int>, int>, int>*]’
logical.ii:63:7:   required from ‘static auto
unpack_impl::apply(basic_tuple_impl, F) [with long unsigned int ...i = {0}; Xn = {int}; F =
on_each::TestLogical(Xs) [with Xs = tuple;
 = when]::, int>, int>, int>*>]’
logical.ii:87:16:   [ skipping 20 instantiation contexts, use
-ftemplate-backtrace-limit=0 to disable ]
logical.ii:87:16:   required from ‘constexpr decltype(auto)
unpack_t::operator()(Xs&&, F&&) const [with Xs = basic_tuple&; F =
on_each<_compose, tuple >, partial_t::TestLogical(Xs) [with Xs = tuple;
 = when]::, int> > >*>&]’
logical.ii:109:11:   required from ‘static auto
unpack_impl::apply(Xs, F) [with Xs = tuple; F =
on_each<_compose, tuple >, partial_t::TestLogical(Xs) [with Xs = tuple;
 = when]::, int> > >*>]’
logical.ii:87:16:   required from ‘constexpr decltype(auto)
unpack_t::operator()(Xs&&, F&&) const [with Xs = tuple&; F =
on_each<_compose, tuple >, partial_t::TestLogical(Xs) [with Xs = tuple;
 = when]::, int> > >*>]’
logical.ii:143:11:   required from ‘static void for_each_impl::apply(Xs, F) [with Xs = tuple; F =
_compose,
tuple >, partial_t::TestLogical(Xs) [with Xs = tuple;
 = when]::, int> > >; T = tuple_tag; bool condition = false]’
logical.ii:132:17:   required from ‘constexpr void for_each_t::operator()(Xs&&,
F&&) const [with Xs = tuple&; F = _compose, tuple >,
partial_t::TestLogical(Xs) [with Xs = tuple;
 = when]::, int> > >]’
logical.ii:148:13:   required from ‘void for_each_n_t::operator()(Xs, F)
[with Xs = tuple; F = partial_t::TestLogical(Xs) [with Xs = tuple;
 = when]::, int>; int i = 3]’
logical.ii:162:13:   required from ‘TestLogical< 
>::TestLogical(Xs) [with Xs = tuple;  =
when]’
logical.ii:167:41:   required from here
logical.ii:163:56: internal compiler error: in tsubst, at cp/pt.c:13700
  [](auto, auto, auto, auto) { auto true_valued = [] {};
}));
^~~
0x1044231b tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:13700
0x1043cb13 tsubst_decl
../../gcc/gcc/cp/pt.c:13047
0x104406f3 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:13552
0x1042ebe3 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16013
0x1042e217 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15944
0x1042ed0f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16183
0x1042ed0f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16183

[Bug c++/43745] [avr] g++ puts VTABLES in SRAM

2017-09-02 Thread matthijs at stdin dot nl 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43745

Matthijs Kooijman  changed:

   What|Removed |Added

 CC||matthijs at stdin dot nl

--- Comment #12 from Matthijs Kooijman  ---
Apologies if this is an obvious question, but I'm not familiar with gcc/g++
internals. Georg-Johann, you say this requires address space support in c++,
but I'm not sure I follow you there. Two things:
 - You say WG21 will never add AS support to C++, but also say that language
support for AS is not needed, only internal support in gcc/g++. So that means
what WG21 does is not relevant for vtable handling in particular?
 - Even if AS would not be used, what prevents g++ from emitting the vtables in
the `progmem.data` section and generating vtable-invocation code using LPM
instructions? This behaviour could be toggled using a commandline option, or
some gcc-specific attribute on a class?

I would be happy if you could comment on the feasibility of these two
approaches, thanks!

[Bug libstdc++/71660] [5/6/7/8 regression] alignment of std::atomic<8 byte primitive type> (long long, double) is wrong on x86

2017-09-02 Thread chgans at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71660

Christian Gagneraud  changed:

   What|Removed |Added

 CC||chgans at gmail dot com

--- Comment #6 from Christian Gagneraud  ---
Hi there,

What is the status of this bug report? Will this be fixed one day? Isn't this a
serious issue?

Qt cannot currently be fully built because of this. See
http://lists.qt-project.org/pipermail/interest/2017-September/027953.html
http://lists.qt-project.org/pipermail/interest/2017-September/027955.html

Honestly this all look scary to me, either gcc behaviour or Qt beahaviour or
both.

Full thread on Qt ML:
http://lists.qt-project.org/pipermail/interest/2017-September/027948.html

[Bug c++/82081] Tail call optimisation of noexcept function leads to exception allowed through

2017-09-02 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82081

--- Comment #1 from Andrew Pinski  ---
The C++ front-end should have wrapped noexcept_function's body with:
try {
...
} catch(..)
{
  std::terminate();
}

Like it does for throw() case.

[Bug c++/82081] New: Tail call optimisation of noexcept function leads to exception allowed through

2017-09-02 Thread thiago at kde dot org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82081

Bug ID: 82081
   Summary: Tail call optimisation of noexcept function leads to
exception allowed through
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thiago at kde dot org
  Target Milestone: ---

When a noexcept function gets optimised with tail-call, the frame disappears so
the unwinder cannot know that the function was noexcept and thus
std::terminate() should be called.

Code:

$ cat throw.cpp
void noexcept_function() noexcept;

bool false_condition = false;
void will_throw()
{
throw 1;
}

void wrapper()
{
noexcept_function();
if (false_condition)
throw 42;
}
$ cat main.cpp
#include 

void will_throw();  // throws int
void wrapper();
extern bool false_condition;

void noexcept_function() noexcept { will_throw(); }

int main()
{
try {
wrapper();
} catch (int v) {
std::cout << "Caught " << v;
return v;
}
return 0;
}

By bouncing around translation units, we prevent inlining. The compiler cannot
know that wrapper() calls noexcept_function(), which calls will_throw().

In debug mode, the program behaves as expected

$ g++ -O0 -g throw.cpp main.cpp
$ ./a.out
terminate called after throwing an instance of 'int'
[1]46552 abort (core dumped)  ./a.out
(gdb) bt
#0  0x7f9df0ce1a90 in raise () from /lib64/libc.so.6
#1  0x7f9df0ce30f6 in abort () from /lib64/libc.so.6
#2  0x7f9df1615235 in __gnu_cxx::__verbose_terminate_handler() () from
/usr/lib64/libstdc++.so.6
#3  0x7f9df1613026 in ?? () from /usr/lib64/libstdc++.so.6
#4  0x7f9df1611fe9 in ?? () from /usr/lib64/libstdc++.so.6
#5  0x7f9df1612958 in __gxx_personality_v0 () from
/usr/lib64/libstdc++.so.6
#6  0x7f9df10633a3 in ?? () from /lib64/libgcc_s.so.1
#7  0x7f9df10638b0 in _Unwind_RaiseException () from /lib64/libgcc_s.so.1
#8  0x7f9df16132a6 in __cxa_throw () from /usr/lib64/libstdc++.so.6
#9  0x004009ed in will_throw () at throw.cpp:6
#10 0x00400a2f in noexcept_function () at main.cpp:7
#11 0x004009f6 in wrapper () at throw.cpp:11
#12 0x00400a40 in main () at main.cpp:12

However, when optimised, we see that the exception thrown from will_throw()
does pass through and is caught by main():

$ g++ -O2 -g throw.cpp main.cpp
$ ./a.out 
Caught 1
(gdb) disass noexcept_function
Dump of assembler code for function noexcept_function():
   0x00400b10 <+0>: jmpq   0x400aa0 


I see two possible paths to solving this.
1) forbid tail-call optimisation of a noexcept(false) call in a noexcept
function, so that there is a frame in place for the unwinder to find. That is,
the noexcept_function should be:
  sub  %rsp, 8
  call will_throw()
  retq
(GCC generates this under some conditions, like placing all functions in the
same TU but using -fno-inline)

2) wrap the call point of the noexcept function (in this case, wrapper()) with
an EH table that enforces that no exceptions should come out of it.

The first solution implies a performance penalty due to optimisation that could
not be used. If you choose to implement this, please try to disable this
correction under -fno-exceptions.

The second solution allows the runtime performance at the expense of expanding
EH tables around every noexcept function.

Neither solution completely solves the problem for mixed-age code in different
libraries: solution 1 solves the problem if the callee is recompiled but lets
the problem still happen if only the caller is recompiled. Solution 2 is the
dual converse: if the caller is recompiled, the problem is solved, but the
problem still happens if only the callee is recompiled.