[Bug c/71539] incomplete execution of a nested loop for -O2 and -O3

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
.

[Bug c/71539] incomplete execution of a nested loop for -O2 and -O3

[cubitect at gmail dot com]

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

--- Comment #2 from cubitect at gmail dot com ---
Thank you for the tip! I was unaware that signed integer overflow is undefined
in standard C. I was rewriting some java code in C when I ran into this
problem, so this makes sense now. (Though I still don't see how this caused the
loop to abort prematurely.)

[Bug c/71539] incomplete execution of a nested loop for -O2 and -O3

[mednafen at sent dot com]

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

mednafen at sent dot com changed:

   What|Removed |Added

 CC||mednafen at sent dot com

--- Comment #1 from mednafen at sent dot com ---
test.c:9:17: runtime error: signed integer overflow: 2 * 4611686018427387904
cannot be represented in type 'long int'
test.c:9:8: runtime error: signed integer overflow: 2 * -9223372036854775808
cannot be represented in type 'long int'

Refer to the C standard, and use -fwrapv
https://gcc.gnu.org/onlinedocs/gcc-5.3.0/gcc/Code-Gen-Options.html#index-fwrapv-2791
if you really need to write such code(or want a safety net against
unpredictable future optimizations that take advantage of such undefined
behavior).

[Bug c++/69523] -Wliteral-suffix should not warn within namespace std

[eric at efcs dot ca]

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

--- Comment #7 from Eric Fiselier  ---
> The warning should be controlled by *some* flag, but I'm not sure whether or 
> not linking it with -Wliteral-suffix makes sense. I'll prepare a patch and 
> see what people think.

Any update? I would be happy with anything so long as I can enable warnings
again.

[Bug c/71539] New: incomplete execution of a nested loop for -O2 and -O3

[cubitect at gmail dot com]

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

Bug ID: 71539
   Summary: incomplete execution of a nested loop for -O2 and -O3
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cubitect at gmail dot com
  Target Milestone: ---

Created attachment 38700
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38700=edit
example source file

For the optimisation levels -O2 and -O3, the exact behaviour of the attached
program falsely depends on the values of BIGNUM and siz. For the given example,
the nested loop in init() terminates early.

Both -O0 and -O1 give the expected output:
$ gcc -Wall -Wextra -Wpedantic test.c -o test -O1 && ./test 
 1 1 1 1 1 1 1 1 1
 2 2 2 2 2 2 2 2 2
 1 1 1 1 1 1 1 1 1
 4 4 4 4 4 4 4 4 4
 1 1 1 1 1 1 1 1 1
 6 6 6 6 6 6 6 6 6
 1 1 1 1 1 1 1 1 1
 8 8 8 8 8 8 8 8 8
 1 1 1 1 1 1 1 1 1

However:
$ gcc -Wall -Wextra -Wpedantic test.c -o test -O2 && ./test 
 1 1 0 0 0 0 0 0 0
 2 2 0 0 0 0 0 0 0
 1 1 0 0 0 0 0 0 0
 4 4 0 0 0 0 0 0 0
 1 1 0 0 0 0 0 0 0
 6 6 0 0 0 0 0 0 0
 1 1 0 0 0 0 0 0 0
 8 8 0 0 0 0 0 0 0
 1 1 0 0 0 0 0 0 0

$ gcc -Wall -Wextra -Wpedantic test.c -o test -O3 && ./test 
 1 1 1 0 0 0 0 0 0
 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0 0


In my tests, the issue occurred for gcc versions 5.3.1 and 6.0, but not for
version 4.9.3.

$ uname -a
Linux cubuntu-pc 4.4.0-22-generic #40-Ubuntu SMP Thu May 12 22:03:46 UTC 2016
x86_64 x86_64 x86_64 GNU/Linux

$ gcc -v
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.3.1-14ubuntu2.1' --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.3.1 20160413 (Ubuntu 5.3.1-14ubuntu2.1)

[Bug c++/71537] GCC rejects consetxpr boolean conversions and comparisons on the result of pointer arithmetic.

[eric at efcs dot ca]

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

--- Comment #2 from Eric Fiselier  ---
Hi Martin,

The  'xx' case is only accepted if it occurs at a global scope. If it appears
in a function body it is still rejected.

[Bug c++/71537] GCC rejects consetxpr boolean conversions and comparisons on the result of pointer arithmetic.

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-14
 CC||jakub at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
 Blocks||55004
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.3.0, 6.1.0, 7.0

--- Comment #1 from Martin Sebor  ---
Confirmed, though only the xxx initialization is rejected with GCC 5 and later,
the array case works (4.9.3 rejects both xx and xxx).  It looks like the
fold_comparison function that handles these operations for arrays isn't
prepared to do the same for a string literal.  Below is the test with the
failing case simplified to converting a POINTER_PLUS expression directly to
bool.  (The -Waddress warning should probably get its own bug.)

I CC Jakub who has been making improvements in this area lately (bug 71448 and
bug 67376 before it).

$ cat t.C && /home/msebor/build/gcc-trunk-svn/gcc/xgcc -B
/home/msebor/build/gcc-trunk-svn/gcc -Wall -Wextra -Wpedantic t.C
constexpr int n[42] = {1};
constexpr int x = n ? 1 : 0;   // Accepted
constexpr int xx = n + 1 ? 1 : 0;  // Accepted 
constexpr int xxx = "abc" + 1 ? 1 : 0; // Rejected

constexpr bool b = "abc" + 1;  // Rejected (#2)
t.C:2:27: warning: the address of ‘n’ will always evaluate as ‘true’
[-Waddress]
 constexpr int x = n ? 1 : 0; // Accepted.
   ^
t.C:4:37: error: ‘const char*)"abc") + 1u) != 0u)’ is not a constant
expression
 constexpr int xxx = "abc" + 1 ? 1 : 0; // Rejected
 ^
t.C:6:28: error: ‘const char*)"abc") + 1u) != 0u)’ is not a constant
expression
 constexpr bool b = "abc" + 1;  // Rejected (#2)
^


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
[Bug 55004] [meta-bug] constexpr issues

[Bug bootstrap/71435] [7 regression] sparc bootstrap failure since r235625

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #8 from Eric Botcazou  ---
Created attachment 38699
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38699=edit
Tentative fix.

[Bug c/71538] Obvious optimization related to arrays aren't performed.

[sasho648 at gmail dot com]

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

--- Comment #1 from sasho648 at gmail dot com ---
The exact command used to compile this code was "gcc -O3 test.c" (as test.c
containing the snippet above).

[Bug c/71538] New: Obvious optimization related to arrays aren't performed.

[sasho648 at gmail dot com]

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

Bug ID: 71538
   Summary: Obvious optimization related to arrays aren't
performed.
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sasho648 at gmail dot com
  Target Milestone: ---

Consider this code:

#include 

extern void f(int *p) 
{
p = *((int (*)[6])p);

if(p == NULL)
printf("NULL");
}


It's obvious (at least for me) that p can't be possibly NULL because it's
assigned the value of pointer to the first element of array with 6 elements.
However the assembly output of this code for my native machine compiled on
linux (x86-64 - dumped using ida pro with general assembler for intel) is:

;f function

testrdi, rdi
jz  short loc_400550
rep retn
; ---
align 10h

loc_400550: 
mov edi, (offset format+4) ; "NULL"
xor eax, eax
jmp _printf
;f function end

As you see the branch where printf is called with "NULL" is still present in
the code although on theory it should never be reached.

I don't think there is requirement by the standard to disallow evaluation of
this expression (as opposed to for example *).

[Bug c++/70572] [4.9/5 Regression] ICE on code with decltype (auto) in digest_init_r, at cp/typeck2.c:1103 with -std=c++14

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org
   Target Milestone|4.9.4   |6.2
Summary|[4.9/5/6 Regression] ICE on |[4.9/5 Regression] ICE on
   |code with decltype (auto)   |code with decltype (auto)
   |in digest_init_r, at|in digest_init_r, at
   |cp/typeck2.c:1103 with  |cp/typeck2.c:1103 with
   |-std=c++14  |-std=c++14

--- Comment #6 from Paolo Carlini  ---
Fixed for 6.2 too. Wontfix in older branches.

[Bug c++/70572] [4.9/5/6 Regression] ICE on code with decltype (auto) in digest_init_r, at cp/typeck2.c:1103 with -std=c++14

[paolo at gcc dot gnu.org]

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

--- Comment #5 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Tue Jun 14 20:55:08 2016
New Revision: 237460

URL: https://gcc.gnu.org/viewcvs?rev=237460=gcc=rev
Log:
/cp
2016-06-14  Paolo Carlini  

PR c++/70572
* decl.c (cp_finish_decl): Check do_auto_deduction return value
and return immediately in case of erroneous code.

/testsuite
2016-06-14  Paolo Carlini  

PR c++/70572
* g++.dg/cpp1y/auto-fn31.C: New.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp1y/auto-fn31.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/decl.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug middle-end/71509] Bitfield causes load hit store with larger store than load

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
(In reply to Richard Biener from comment #1)
> It looks like we didn't adjust the bitfield read paths for the mem model
> because in practice it doesn't matter and it may generate larger/slower code
> not to do loads in larger types on some archs.

It still generates correct (or at least working) code, yeah.

> Note that we conservatively compute the extent for
> DECL_BIT_FIELD_REPRESENTATIVE
> by prefering smaller modes.  There's some ??? in
> finish_bitfield_representative
> and the above remark about tail padding re-use is only implemented via
> prefering
> smaller modes.  Thus when adding a 'long foo' after csum_level the
> representative doesn't change to 64bit width but stays at 8bits (both are
> valid from the C++ memory model).

Smaller modes are slightly better here, they allow more efficient insn
sequences to manipulate the data, esp. on big endian.  For example on
PowerPC, on BE, our 16-bit immediates (in e.g. ior) can handle QImode
and HImode, but not DImode; and e.g. the rlwinm insn can handle SImode
but not DImode.  In general, with smaller modes you do not need to
worry about preserving the other bits.

> Note that the proposed simple lowering of bitfield accesses on GIMPLE would
> do accesses of DECL_BIT_FIELD_REPRESENTATIVE and thus in this case use byte
> accesses.

That would be lovely :-)

> I suppose we want to be less conservative about DECL_BIT_FIELD_REPRESENTATIVE
> and leave it up to the target how to do the actual accesses.

Maybe.  Always smallest is a good choice for PowerPC at least.

> Widening the representative generates
> 
> __skb_decr_checksum_unnecessary:
> ld 9,8(3)
> addi 10,9,3
> rldicr 9,9,0,61
> rldicl 10,10,0,62
> or 9,9,10
> std 9,8(3)
> blr

Making all accesses use QImode yields

__skb_decr_checksum_unnecessary:
lbz 9,8(3)
addi 10,9,3
rlwinm 9,9,0,0,29
rlwinm 10,10,0,30,31
or 9,9,10
stb 9,8(3)
blr

(the rlwinm's and the or could be a rlwimi together, not sure why they
aren't merged)

and on BE it gives

.L.__skb_decr_checksum_unnecessary:
lbz 9,8(3)
srwi 10,9,6
rlwinm 9,9,0,26,31
addi 10,10,3
rlwinm 10,10,6,24,25
or 9,9,10
stb 9,8(3)
blr

which could be just

lbz 9,8(3)
addi 9,9,192
stb 9,8(3)
blr

[Bug c++/71537] New: GCC rejects consetxpr boolean conversions and comparisons on the result of pointer arithmetic.

[eric at efcs dot ca]

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

Bug ID: 71537
   Summary: GCC rejects consetxpr boolean conversions and
comparisons on the result of pointer arithmetic.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

For example:

constexpr int n[42] = {1};
constexpr int x = n ? 1 : 0; // Accepted.
constexpr int xx = n + 1 ? 1 : 0; // Rejected
constexpr int xxx = "abc" + 1 ? 1 : 0; // Also Rejected

This has a significant impact on constexpr algorithms which operate over raw
pointers since pointer comparisons are not considered constant expressions.

For example this bug breaks libc++'s implementation of string_view::find and
renders the "char_traits::find(...)" interface useless since it returns a
possibly null pointer.

[Bug c++/71528] [5/6/7 Regression] multiple extern reference declarations produce uninitialized access

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jun 14 19:55:08 2016
New Revision: 237458

URL: https://gcc.gnu.org/viewcvs?rev=237458=gcc=rev
Log:
PR c++/71528
* decl.c (duplicate_decls): For DECL_INITIALIZED_P non-external
olddecl vars, preserve their TREE_READONLY bit.

* g++.dg/opt/pr71528.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr71528.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/70703] [6/7 regression] Regression in register usage on x86

[aldot at gcc dot gnu.org]

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

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug rtl-optimization/70703] [6/7 regression] Regression in register usage on x86

[aldot at gcc dot gnu.org]

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

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

   Last reconfirmed||2016-6-14
 CC||rdsandiford at googlemail dot 
com,
   ||vmakarov at redhat dot com
  Known to work||4.9.3
  Known to fail||5.1.0

--- Comment #3 from Bernhard Reutner-Fischer  ---
CCing Vlad and Richard S.
Started with r211072

https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02482.html

[Bug lto/71536] New: lto1 ICE: func-static constant in openmp offloaded function

[bisqwit at iki dot fi]

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

Bug ID: 71536
   Summary: lto1 ICE: func-static constant in openmp offloaded
function
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bisqwit at iki dot fi
  Target Milestone: ---

With this example program:

#pragma omp declare target
void Process()
{
static const int value = 12;
}
#pragma omp end declare target

int main()
{
#pragma omp target
{
Process();
}
}

g++ crash.cc -fopenmp -O1

lto1: internal compiler error: Segmentation fault
0x93bcaf crash_signal
../../gcc/toplev.c:333
0x82d2eb input_offload_tables(bool)
../../gcc/lto-cgraph.c:1931
0x5c6590 read_cgraph_and_symbols
../../gcc/lto/lto.c:2858
0x5c6590 lto_main()
../../gcc/lto/lto.c:3304
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
mkoffload-intelmic: fatal error:
x86_64-pc-linux-gnu-accel-x86_64-intelmicemul-linux-gnu-gcc returned 1 exit
status
compilation terminated.
lto-wrapper: fatal error:
/usr/local/libexec/gcc/x86_64-pc-linux-gnu/6.1.0//accel/x86_64-intelmicemul-linux-gnu/mkoffload
returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

The main() can be deleted from the program, and the error still occurs.
This error requires at least -O1 to trigger it.

GCC version: 6.1.0

[Bug lto/71535] New: ICE in LTO1 with -fopenmp offloading

[bisqwit at iki dot fi]

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

Bug ID: 71535
   Summary: ICE in LTO1 with -fopenmp offloading
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bisqwit at iki dot fi
  Target Milestone: ---

With this example program:

#include 

void Process(unsigned* Target)
{
for(int s=0; s<4; ++s)
Target[s] = 100u * std::min(255, std::max(0, 0))
 +  200u * std::min(255, std::max(0, 0));
}

int main()
{
#pragma omp target teams distribute parallel for
for(unsigned y=0; y<16; ++y)
{
unsigned Line[16];
Process(Line);
}
}

g++ tmps.cc -fopenmp

lto1: internal compiler error: in input_overwrite_node, at lto-cgraph.c:1203
0x82f4d5 input_overwrite_node
../../gcc/lto-cgraph.c:1201
0x82f4d5 input_node
../../gcc/lto-cgraph.c:1296
0x82f4d5 input_cgraph_1
../../gcc/lto-cgraph.c:1546
0x82f4d5 input_symtab()
../../gcc/lto-cgraph.c:1849
0x5c657b read_cgraph_and_symbols
../../gcc/lto/lto.c:2856
0x5c657b lto_main()
../../gcc/lto/lto.c:3304
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
mkoffload-intelmic: fatal error:
x86_64-pc-linux-gnu-accel-x86_64-intelmicemul-linux-gnu-gcc returned 1 exit
status
compilation terminated.
lto-wrapper: fatal error:
/usr/local/libexec/gcc/x86_64-pc-linux-gnu/6.1.0//accel/x86_64-intelmicemul-linux-gnu/mkoffload
returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

GCC version: 6.1.0
This bug is very likely related to PR71499.

[Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields

[tom at honermann dot net]

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

Tom Honermann  changed:

   What|Removed |Added

 CC||tom at honermann dot net

--- Comment #27 from Tom Honermann  ---
We got bit by this warning recently.  We compile with -Werror and, without an
option to suppress warnings in the following code, gcc rejects it.  We think
this code should be accepted without a warning given the constant expressions
involved.

Clang does not issue a warning for this code.  However, if an assignment to the
bit-field from a literal '2' (cast to E) is added, then Clang warns on the
assignment itself (as opposed to on the bit-field declaration).  This seems
like a more useful approach.

$ cat t.cpp
enum E : unsigned char {
e0 = 0,
e1 = 1
};
struct S {
E e : 1;
};
void f(S s) {
s.e = e0;
s.e = e1;
s.e = (E)0;
s.e = (E)1;
};

$ g++ --version
g++ (GCC) 6.1.1 20160531
...

$ g++ -c -std=c++11 -Werror t.cpp
t.cpp:6:11: error: ‘S::e’ is too small to hold all values of ‘enum E’ [-Werror]
 E e : 1;
   ^
cc1plus: all warnings being treated as errors

[Bug c++/71534] New: Initializing a static constexpr data member of a base class by using a static constexpr data member of a derived class should be an error

[michele.caini at gmail dot com]

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

Bug ID: 71534
   Summary: Initializing a static constexpr data member of a base
class by using a static constexpr data member of a
derived class should be an error
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michele.caini at gmail dot com
  Target Milestone: ---

Consider the following code:

template
struct S { static constexpr int bar = T::foo; };

struct U: S { static constexpr int foo = 42; };

int main() { }

GCC compiles it, but it shouldn't.
The type T is not a complete type when bar is initialized.

Here is a discussion on stackoverflow where reasons are discussed:
http://stackoverflow.com/questions/37816186/initializing-a-static-constexpr-data-member-of-the-base-class-by-using-a-static

Link to the standard (working draft) are provided as well in the discussion.

Other compilers (mostly clang) correctly reject it.

[Bug c/71533] New: -fdump-tree-fre1 hangs while printing an unnormal long double

[ch3root at openwall dot com]

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

Bug ID: 71533
   Summary: -fdump-tree-fre1 hangs while printing an unnormal long
double
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ch3root at openwall dot com
  Target Milestone: ---

`gcc -O1 -fdump-tree-fre1 test.c` hangs presumably while trying to print an
unnormal long double value. I think it shouldn't hang even if the program is
invalid.

Source code:

--
#include 
#include 

int main()
{
  long double d;

  memcpy(, "\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0", sizeof d);

  printf("%Lf\n", d);
}
--

gcc version: gcc (GCC) 7.0.0 20160614 (experimental)

[Bug rtl-optimization/71532] [7 Regression] FAIL: gfortran.dg/select_char_1.f90 -O2 execution test

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-14
 CC||jakub at redhat dot com
 Ever confirmed|0   |1

[Bug rtl-optimization/71532] New: [7 Regression] FAIL: gfortran.dg/select_char_1.f90 -O2 execution test

[hjl.tools at gmail dot com]

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

Bug ID: 71532
   Summary: [7 Regression] FAIL: gfortran.dg/select_char_1.f90
-O2  execution test
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

On Linux/i386, r235765 caused:

# gfortran  -march=corei7 -mtune=slm -m32
gcc/gcc/testsuite/gfortran.dg/select_char_1.f90 -O2 && ./a.out
Program aborted. Backtrace:
#0  0xf76c8c95 in ???
#1  0xf76c97a7 in ???
#2  0xf777c107 in ???
#3  0x8048470 in ???
#4  0xf7409644 in ???
#5  0x804895e in ???

[Bug middle-end/71531] [7 Regression] FAIL: gfortran.dg/select_char_1.f90 -O2 execution test

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-14
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
The offending commit is r236789.

[Bug middle-end/71531] New: [7 Regression] FAIL: gfortran.dg/select_char_1.f90 -O2 execution test

[hjl.tools at gmail dot com]

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

Bug ID: 71531
   Summary: [7 Regression] FAIL: gfortran.dg/select_char_1.f90
-O2  execution test
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: amodra at gmail dot com
  Target Milestone: ---

On Linux/i386, r71275 caused:

# gfortran  -march=corei7 -mtune=slm -m32
gcc/gcc/testsuite/gfortran.dg/intrinsic_verify_1.f90 -O2 && ./a.out
Program aborted. Backtrace:
#0  0xf762dcd5 in ???
#1  0xf762e7f7 in ???
#2  0xf76e0fc7 in ???
#3  0x80484d8 in ???
#4  0xf7378644 in ???
#5  0x80484f9 in ???

[Bug bootstrap/71435] [7 regression] sparc bootstrap failure since r235625

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  ---
> Maybe we need an arg for that function to say whether to look at individual
> insn chains?

That, or just fiddle with the existing one, its only purpose in the function is
to guard the problematic global register allocation.  Maybe:

  /* If we allocated another stack slot, redo elimination bookkeeping.  */
  if (something_was_spilled || starting_frame_size != get_frame_size ())
{
  if (update_eliminables_and_spill ())
finish_spills (0);
  continue;
}

[...]

  if (update_eliminables_and_spill ())
{
  finish_spills (0);
  something_changed = 1;
}
  else
{
  select_reload_regs ();
  if (failure)
goto failed;
 if (insns_need_reload)
  something_changed |= finish_spills (global);
}

and did_spill can go.

[Bug tree-optimization/71104] [7 Regression] ICE: verify_ssa failed (with vfork / error: definition in block 3 does not dominate use in block 7 )

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #10 from Jason Merrill  ---
(In reply to Marc Glisse from comment #9)
> (In reply to rguent...@suse.de from comment #8)
> > Not that I like this proposal at all (given it changes function arg
> > evaluation order on x86_64).
> 
> Does it?
> "the  function is evaluated before all its arguments, but any pair of
> arguments (from the argument list) is indeterminately sequenced"
> 
> The notation a(b1, b2, b3) means that there is no particular order between
> b1 and b2, otherwise it would be written a(b, c, d).

That's a variant of the proposal, but at the last meeting there was more of a
push toward requiring left-to-right evaluation.

[Bug bootstrap/71435] [7 regression] sparc bootstrap failure since r235625

[bernds at gcc dot gnu.org]

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

--- Comment #6 from Bernd Schmidt  ---
Not calling finish_spills however could miss cases where pseudos got spilled by
update_eliminables_and_spill->spill_hard_reg.

Maybe we need an arg for that function to say whether to look at individual
insn chains?

[Bug bootstrap/71435] [7 regression] sparc bootstrap failure since r235625

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  ---
I think that calling finish_spills before select_reload_regs is incorrect:

static void
select_reload_regs (void)
{
  struct insn_chain *chain;

  /* Try to satisfy the needs for each insn.  */
  for (chain = insns_need_reload; chain != 0;
   chain = chain->next_need_reload)
find_reload_regs (chain);
}

/* After find_reload_regs has been run for all insn that need reloads,
   and/or spill_hard_regs was called, this function is used to actually
   spill pseudo registers and try to reallocate them.  It also sets up the
   spill_regs array for use by choose_reload_regs.  */

static int
finish_spills (int global)

because finish_spills works globally, in particular:

  /* Retry global register allocation if possible.  */
  if (global && ira_conflicts_p)
{
  unsigned int n;

  memset (pseudo_forbidden_regs, 0, max_regno * sizeof (HARD_REG_SET));
  /* For every insn that needs reloads, set the registers used as spill
 regs in pseudo_forbidden_regs for every pseudo live across the
 insn.  */
  for (chain = insns_need_reload; chain; chain = chain->next_need_reload)
{
  EXECUTE_IF_SET_IN_REG_SET
(>live_throughout, FIRST_PSEUDO_REGISTER, i, rsi)
{
  IOR_HARD_REG_SET (pseudo_forbidden_regs[i],
chain->used_spill_regs);
}
  EXECUTE_IF_SET_IN_REG_SET
(>dead_or_set, FIRST_PSEUDO_REGISTER, i, rsi)
{
  IOR_HARD_REG_SET (pseudo_forbidden_regs[i],
chain->used_spill_regs);
}
}

i.e. chain->used_spill_regs might be uninitialized for some insns here.

Index: reload1.c
===
--- reload1.c   (revision 237323)
+++ reload1.c   (working copy)
@@ -498,6 +498,7 @@ new_insn_chain (void)
   c->need_operand_change = 0;
   c->need_reload = 0;
   c->need_elim = 0;
+  CLEAR_HARD_REG_SET (c->used_spill_regs);
   return c;
 }

fixes the comparison failure, but it is still incorrect to access the regsets
at this point as they may not have been computed for some insns yet.

[Bug c++/71516] [5 Regression] ICE on invalid C++ code (invalid use of forward declared type) on x86_64-linux-gnu: Segmentation fault (program cc1plus)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] ICE on   |[5 Regression] ICE on
   |invalid C++ code (invalid   |invalid C++ code (invalid
   |use of forward declared |use of forward declared
   |type) on x86_64-linux-gnu:  |type) on x86_64-linux-gnu:
   |Segmentation fault (program |Segmentation fault (program
   |cc1plus)|cc1plus)

--- Comment #6 from Jakub Jelinek  ---
Fixed for 6.2+ so far.

[Bug c/68657] [6 Regression] "gcc -Werror=sign-conversion test.i" shows invalid: -Wsign-conversion is not an option that controls warnings

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from Jakub Jelinek  ---
Fixed for 6.2+.

[Bug tree-optimization/71405] [6 Regression] ICE on valid C++ code at -Os and above on x86_64-linux-gnu: verify_gimple failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed for 6.2+.

[Bug middle-end/71494] [4.9/5 Regression] label as value in nested function

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[4.9/5/6/7 Regression]  |[4.9/5 Regression] label as
   |label as value in nested|value in nested function
   |function|

--- Comment #5 from Jakub Jelinek  ---
Fixed for 6.2+ so far.

[Bug c/68657] [6 Regression] "gcc -Werror=sign-conversion test.i" shows invalid: -Wsign-conversion is not an option that controls warnings

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jun 14 14:44:28 2016
New Revision: 237448

URL: https://gcc.gnu.org/viewcvs?rev=237448=gcc=rev
Log:
Backported from mainline
2016-06-10  Jakub Jelinek  

PR c/68657
* c.opt (Wpsabi): Add Warning flag.

* gcc.target/i386/pr68657.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr68657.c
Modified:
branches/gcc-6-branch/gcc/c-family/ChangeLog
branches/gcc-6-branch/gcc/c-family/c.opt
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/71516] [5/6/7 Regression] ICE on invalid C++ code (invalid use of forward declared type) on x86_64-linux-gnu: Segmentation fault (program cc1plus)

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jun 14 14:47:17 2016
New Revision: 237450

URL: https://gcc.gnu.org/viewcvs?rev=237450=gcc=rev
Log:
PR c++/71516
* decl.c (complete_vars): Handle gracefully type == error_mark_node.

* g++.dg/init/pr71516.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/init/pr71516.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/decl.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug debug/71530] the caching does not work

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ktkachov at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Invalid.
Please follow the instructions at https://gcc.gnu.org/bugs/ when reporting
bugs.

[Bug middle-end/71494] [4.9/5/6/7 Regression] label as value in nested function

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jun 14 14:45:23 2016
New Revision: 237449

URL: https://gcc.gnu.org/viewcvs?rev=237449=gcc=rev
Log:
Backported from mainline
2016-06-10  Jakub Jelinek  

PR middle-end/71494
* tree-nested.c (convert_nonlocal_reference_stmt): For GIMPLE_GOTO
without LABEL_DECL, set *handled_ops_p to false instead of true.

* gcc.c-torture/execute/pr71494.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.c-torture/execute/pr71494.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-nested.c

[Bug c++/71448] pointer relational comparison fails inside constant expression

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jun 14 14:43:42 2016
New Revision: 237447

URL: https://gcc.gnu.org/viewcvs?rev=237447=gcc=rev
Log:
Backported from mainline
2016-06-08  Jakub Jelinek  
Richard Biener  

PR c++/71448
* fold-const.c (fold_comparison): Handle CONSTANT_CLASS_P (base0)
the same as DECL_P (base0) for indirect_base0.  Use equality_code
in one further place.

* g++.dg/torture/pr71448.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/pr71448.C
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/fold-const.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/71405] [6 Regression] ICE on valid C++ code at -Os and above on x86_64-linux-gnu: verify_gimple failed

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jun 14 14:42:46 2016
New Revision: 237446

URL: https://gcc.gnu.org/viewcvs?rev=237446=gcc=rev
Log:
Backported from mainline
2016-06-04  Jakub Jelinek  

PR tree-optimization/71405
* tree-ssa.c (execute_update_addresses_taken): For clobber with
incompatible type, build a new clobber with the right type instead
of building a VIEW_CONVERT_EXPR around it.

* g++.dg/torture/pr71405.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/pr71405.C
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-ssa.c

[Bug debug/71530] New: the caching does not work

[saeed.abbasi at telus dot com]

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

Bug ID: 71530
   Summary: the caching does not work
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: saeed.abbasi at telus dot com
  Target Milestone: ---

the caching does not work

[Bug c++/71516] [5/6/7 Regression] ICE on invalid C++ code (invalid use of forward declared type) on x86_64-linux-gnu: Segmentation fault (program cc1plus)

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jun 14 14:33:11 2016
New Revision: 237445

URL: https://gcc.gnu.org/viewcvs?rev=237445=gcc=rev
Log:
PR c++/71516
* decl.c (complete_vars): Handle gracefully type == error_mark_node.

* g++.dg/init/pr71516.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/init/pr71516.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/71488] [6/7 Regression] Wrong code for vector comparisons with ivybridge and westmere targets

[ienkovich at gcc dot gnu.org]

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

--- Comment #6 from Ilya Enkovich  ---
I think we should disable vectorization of boolean comparison (except '==' and
'!=') and handle them applying patterns.  E.g. a > b ==> a & !b, a >= b ==> a |
!b etc.  Bitwise operations are better because work for both vector and scalar
masks.

[Bug c++/71528] [5/6/7 Regression] multiple extern reference declarations produce uninitialized access

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug middle-end/71488] [6/7 Regression] Wrong code for vector comparisons with ivybridge and westmere targets

[ienkovich at gcc dot gnu.org]

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

--- Comment #5 from Ilya Enkovich  ---
What seems suspicious to me is how we vectorize boolean comparison.  Before
vectorization we have (_3, _5, _6 are bool):

  _3 = var_9.0_2 == 0;
  _6 = _3 > _5;

vectorized code:

  mask__3.59_62 = vect_cst__47 == vect_cst__66;
  mask__6.60_49 = mask__3.59_48 > vect_cst__63;

Boolean comparison is transformed into signed integer vector (according to mask
mode) comparison.  So in scalar code 'true' (1) > 'false (0) but in vector code
'true' (-1) < 'false' (0).

[Bug middle-end/71526] [7 Regression] ICE: verify_gimple failed

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Tue Jun 14 13:47:01 2016
New Revision: 237441

URL: https://gcc.gnu.org/viewcvs?rev=237441=gcc=rev
Log:
2016-06-14  Richard Biener  

PR middle-end/71526
* genmatch.c (expr::gen_transform): Use in_type for comparisons
if available.

* gfortran.dg/pr71526.f90: New testcase.

Added:
trunk/gcc/testsuite/gfortran.dg/pr71526.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/genmatch.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/71526] [7 Regression] ICE: verify_gimple failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Fixd.

[Bug middle-end/71529] [7 regression][CHKP] ICE in expand_expr_real_1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug c++/71528] [5/6/7 Regression] multiple extern reference declarations produce uninitialized access

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-14
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
That said, I believe the bug is not there, but in the FE.
x is initially marked TREE_READONLY, then cp_finish_decl clears the
TREE_READONLY bit:
6782{
6783  was_readonly = 1;
6784  TREE_READONLY (decl) = 0;
6785}
because it has an initializer that is invoked at runtime, but then
duplicate_decls sets it again:
2117  /* Merge the type qualifiers.  */
2118  if (TREE_READONLY (newdecl))
2119TREE_READONLY (olddecl) = 1;

[Bug middle-end/71529] [7 regression][CHKP] ICE in expand_expr_real_1

[ienkovich at gcc dot gnu.org]

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

--- Comment #1 from Ilya Enkovich  ---
Arguments copied for instrumented functions with no body don't have their
context fixed.  It didn't trigger any problems before but does now because we
may inline into thunks.  I'm testing this patch now:

diff --git a/gcc/ipa-chkp.c b/gcc/ipa-chkp.c
index 5f5df64..86c48f1 100644
--- a/gcc/ipa-chkp.c
+++ b/gcc/ipa-chkp.c
@@ -207,7 +207,13 @@ chkp_build_instrumented_fndecl (tree fndecl)
   /* For functions with body versioning will make a copy of arguments.
  For functions with no body we need to do it here.  */
   if (!gimple_has_body_p (fndecl))
-DECL_ARGUMENTS (new_decl) = copy_list (DECL_ARGUMENTS (fndecl));
+{
+  tree arg;
+
+  DECL_ARGUMENTS (new_decl) = copy_list (DECL_ARGUMENTS (fndecl));
+  for (arg = DECL_ARGUMENTS (new_decl); arg; arg = DECL_CHAIN (arg))
+   DECL_CONTEXT (arg) = new_decl;
+}

   /* We are going to modify attributes list and therefore should
  make own copy.  */

[Bug c++/71528] [5/6/7 Regression] multiple extern reference declarations produce uninitialized access

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |5.5
Summary|multiple extern reference   |[5/6/7 Regression] multiple
   |declarations produce|extern reference
   |uninitialized access|declarations produce
   ||uninitialized access

--- Comment #1 from Jakub Jelinek  ---
This changed with r218076.
The difference in *.gimple (*.original is the same) vs. r218075 is:
--- pr71528.C.004t.gimple_  2016-06-14 09:08:02.0 -0400
+++ pr71528.C.004t.gimple   2016-06-14 09:08:20.0 -0400
@@ -4,7 +4,7 @@ int main() ()
   int & x.0;
   bool D.1618;

-  x.0 = x;
+  x.0 = 0;
   D.1618 = x.0 == 0B;
   D.1616 = (int) D.1618;
   return D.1616;

[Bug middle-end/71529] New: [7 regression][CHKP] ICE in expand_expr_real_1

[ienkovich at gcc dot gnu.org]

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

Bug ID: 71529
   Summary: [7 regression][CHKP] ICE in expand_expr_real_1
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ienkovich at gcc dot gnu.org
  Target Milestone: ---

This fail starts with r236299.  Looks like it happens because 'this' parameter
of instrumented constructor has wrong DECL_CONTEXT (not instrumented version of
function is used).

>cat small.ii
class c1
{
 public:
  virtual ~c1 ();
};

class c2
{
 public:
  virtual ~c2 ();
};

class c3 : c1, c2 { };

int main (int, char **)
{
  c3 obj;
}
>gcc-build/bin/g++ -O2 -fcheck-pointer-bounds -mmpx small.ii -S
small.i: In member function 'virtual void
c3::_ZThn8_N2c3D0Ev.chkp(#'pointer_bounds_type' not supported by
dump_type#, void, ...)':
small.i:13:7: internal compiler error: in expand_expr_real_1, at expr.c:9518
 class c3 : c1, c2 { };
   ^~
0xc6518c expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/export/users/ienkovic/issues/common/gcc/gcc/expr.c:9512
0xc5e180 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/export/users/ienkovic/issues/common/gcc/gcc/expr.c:7829
0xc462e7 expand_expr
/export/users/ienkovic/issues/common/gcc/gcc/expr.h:272
0xc5cea3 expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
rtx_def**, expand_modifier)
/export/users/ienkovic/issues/common/gcc/gcc/expr.c:7429
0xc6017b expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/export/users/ienkovic/issues/common/gcc/gcc/expr.c:8270
0xc6a472 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/export/users/ienkovic/issues/common/gcc/gcc/expr.c:10747
0xc5e180 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/export/users/ienkovic/issues/common/gcc/gcc/expr.c:7829
0xc462e7 expand_expr
/export/users/ienkovic/issues/common/gcc/gcc/expr.h:272
0xc5d0c3 expand_expr_addr_expr_1
/export/users/ienkovic/issues/common/gcc/gcc/expr.c:7488
0xc5d8b4 expand_expr_addr_expr_1
/export/users/ienkovic/issues/common/gcc/gcc/expr.c:7585
0xc5dd14 expand_expr_addr_expr
/export/users/ienkovic/issues/common/gcc/gcc/expr.c:7661
0xc6a379 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/export/users/ienkovic/issues/common/gcc/gcc/expr.c:10691
0xc5e180 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/export/users/ienkovic/issues/common/gcc/gcc/expr.c:7829
0xc5525f store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
/export/users/ienkovic/issues/common/gcc/gcc/expr.c:5276
0xc53e82 expand_assignment(tree_node*, tree_node*, bool)
/export/users/ienkovic/issues/common/gcc/gcc/expr.c:5042
0xb0d8bd expand_gimple_stmt_1
/export/users/ienkovic/issues/common/gcc/gcc/cfgexpand.c:3618
0xb0dca8 expand_gimple_stmt
/export/users/ienkovic/issues/common/gcc/gcc/cfgexpand.c:3714
0xb14db9 expand_gimple_basic_block
/export/users/ienkovic/issues/common/gcc/gcc/cfgexpand.c:5720
0xb168b9 execute
/export/users/ienkovic/issues/common/gcc/gcc/cfgexpand.c:6335
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/71528] New: multiple extern reference declarations produce uninitialized access

[P at draigBrady dot com]

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

Bug ID: 71528
   Summary: multiple extern reference declarations produce
uninitialized access
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: P at draigBrady dot com
  Target Milestone: ---

This is a regression since 5.1 which works with clang and gcc 4.x
The issue is due to the redundant extern reference declaration,
which results in use of an unitialized reference. I.E. in this snippet,
x will have the NULL pointer rather than that of the "new int":

extern int& x;
int& x = *(new int);
int main() { return !(); }
// Comment out the following line for expected operation
extern int& x;

https://godbolt.org/g/dDDPnw

[Bug c++/71527] New: wrong type mismatch while template argument deduction/substitution

[benni.buch at gmail dot com]

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

Bug ID: 71527
   Summary: wrong type mismatch while template argument
deduction/substitution
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: benni.buch at gmail dot com
  Target Milestone: ---

// Example ==
// Convert C-String to int
template < int N >
constexpr int parse_int(char const()[N])noexcept{
int number = 0;
int base = 1;
for(int i = 0; i < N; ++i){
number += (static_cast< int >(arr[N - 1 - i]) - 48) * base;
base *= 10;
}
return number;
}

// A compile time int-type
template < int I >
struct size{};

// Create a compile time int via user literals
template < char ... S >
constexpr auto operator"" _S()noexcept{
return size< parse_int< sizeof...(S) >({S ...}) >();
}


// The problem:
template < typename T, int N >
void f(size< N >, T(&&)[N]){}


int main(){
// OK: T is int
f(2_S, {0, 1});

// Bug: wrong type mismatch, T should be float
f< float >(2_S, {0, 1});

// OK: error conflicting types
/* f(2_S, {0, 1.f}); */

// Bug: wrong type mismatch, T should be float
f< float >(2_S, {0, 1.f});
}
//===

clang compiles it well, GCC reports a type mismatch:

~$ g++ -o main -std=c++14 main.cpp 
bug.cpp: In function ‘int main()’:
bug.cpp:34:24: error: no matching function for call to ‘f(size<2>,
)’
  f< float >(2_S, {0, 1});
^
bug.cpp:26:6: note: candidate: template void f(size, T
(&&)[N])
 void f(size< N >, T(&&)[N]){}
  ^
bug.cpp:26:6: note:   template argument deduction/substitution failed:
bug.cpp:34:24: note:   mismatched types ‘float’ and ‘int’
  f< float >(2_S, {0, 1});
^
bug.cpp:40:26: error: no matching function for call to ‘f(size<2>,
)’
  f< float >(2_S, {0, 1.f});
  ^
bug.cpp:26:6: note: candidate: template void f(size, T
(&&)[N])
 void f(size< N >, T(&&)[N]){}
  ^
bug.cpp:26:6: note:   template argument deduction/substitution failed:
bug.cpp:40:26: note:   mismatched types ‘float’ and ‘int’
  f< float >(2_S, {0, 1.f});

[Bug c++/71385] Internal compiler error when using concept as placeholder

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-14
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed on current trunk and GCC 6.1.1 with following back-trace:

#35 0x008afe74 in (anonymous namespace)::satisfy_conjunction
(complain=0, in_decl=0x0, args=0x769e63a0, t=0x769ef2f8) at
../../gcc/cp/constraint.cc:1936
#36 (anonymous namespace)::satisfy_constraint_1 (t=0x769ef2f8,
args=args@entry=0x769e63a0, in_decl=0x0, complain=0) at
../../gcc/cp/constraint.cc:1996
#37 0x008afd2c in (anonymous
namespace)::satisfy_parameterized_constraint (complain=0, in_decl=0x0,
args=0x769e63a0, t=0x769ef320) at ../../gcc/cp/constraint.cc:1918
#38 (anonymous namespace)::satisfy_constraint_1 (t=t@entry=0x769ef320,
args=0x769e63a0, in_decl=0x0, complain=0) at
../../gcc/cp/constraint.cc:1993
#39 0x008b0277 in (anonymous namespace)::satisfy_constraint
(t=0x769ef320, args=) at ../../gcc/cp/constraint.cc:2026
#40 0x008b14f5 in constraints_satisfied_p (t=t@entry=0x769e6360,
args=args@entry=0x769e63a0) at ../../gcc/cp/constraint.cc:2146
#41 0x006d010b in do_auto_deduction (type=type@entry=0x769e8f18,
init=init@entry=0x769ef140, auto_node=auto_node@entry=0x769e8f18,
complain=complain@entry=0, context=context@entry=adc_requirement) at
../../gcc/cp/pt.c:24084
#42 0x008afe15 in (anonymous
namespace)::satisfy_argument_deduction_constraint (complain=0, in_decl=0x0,
args=0x769e6300, t=) at ../../gcc/cp/constraint.cc:1879
#43 (anonymous namespace)::satisfy_constraint_1 (t=,
args=args@entry=0x769e6300, in_decl=0x0, complain=0) at
../../gcc/cp/constraint.cc:1987
#44 0x008afe74 in (anonymous namespace)::satisfy_conjunction
(complain=0, in_decl=0x0, args=0x769e6300, t=0x769ef0c8) at
../../gcc/cp/constraint.cc:1936
#45 (anonymous namespace)::satisfy_constraint_1 (t=0x769ef0c8,
args=args@entry=0x769e6300, in_decl=0x0, complain=0) at
../../gcc/cp/constraint.cc:1996
#46 0x008afd2c in (anonymous
namespace)::satisfy_parameterized_constraint (complain=0, in_decl=0x0,
args=0x769e6300, t=0x769ef0f0) at ../../gcc/cp/constraint.cc:1918
#47 (anonymous namespace)::satisfy_constraint_1 (t=t@entry=0x769ef0f0,
args=0x769e6300, in_decl=0x0, complain=0) at
../../gcc/cp/constraint.cc:1993
#48 0x008b0277 in (anonymous namespace)::satisfy_constraint
(t=0x769ef0f0, args=) at ../../gcc/cp/constraint.cc:2026
#49 0x008b14f5 in constraints_satisfied_p (t=t@entry=0x769e62c0,
args=args@entry=0x769e6300) at ../../gcc/cp/constraint.cc:2146
#50 0x006d010b in do_auto_deduction (type=type@entry=0x769e8f18,
init=0x768a21f8, auto_node=auto_node@entry=0x769e8f18,
complain=complain@entry=3, context=context@entry=adc_variable_type) at
../../gcc/cp/pt.c:24084
#51 0x006a4090 in cp_finish_decl (decl=decl@entry=0x77fedc60,
init=init@entry=0x768a21f8, init_const_expr_p=true, asmspec_tree=, asmspec_tree@entry=0x0, flags=5) at ../../gcc/cp/decl.c:6625
#52 0x007a59fe in cp_parser_init_declarator
(parser=parser@entry=0x77fed990,
decl_specifiers=decl_specifiers@entry=0x7fffd300, checks=checks@entry=0x0,
function_definition_allowed_p=function_definition_allowed_p@entry=false, 
member_p=member_p@entry=false, declares_class_or_enum=,
function_definition_p=0x7fffd2ef, maybe_range_for_decl=0x0,
init_loc=0x7fffd2f4, auto_result=0x7fffd2f8) at
../../gcc/cp/parser.c:18697
#53 0x007a60d2 in cp_parser_simple_declaration
(parser=parser@entry=0x77fed990, function_definition_allowed_p=false,
maybe_range_for_decl=maybe_range_for_decl@entry=0x0) at
../../gcc/cp/parser.c:12378
#54 0x007a63db in cp_parser_block_declaration (parser=0x77fed990,
statement_p=statement_p@entry=true) at ../../gcc/cp/parser.c:12246
#55 0x007a6ea9 in cp_parser_declaration_statement
(parser=parser@entry=0x77fed990) at ../../gcc/cp/parser.c:11858
#56 0x007a388c in cp_parser_statement
(parser=parser@entry=0x77fed990,
in_statement_expr=in_statement_expr@entry=0x0, in_compound=,
in_compound@entry=true, if_p=if_p@entry=0x0, chain=chain@entry=0x0) at
../../gcc/cp/parser.c:10526
#57 0x007a422d in cp_parser_statement_seq_opt
(parser=parser@entry=0x77fed990,
in_statement_expr=in_statement_expr@entry=0x0) at ../../gcc/cp/parser.c:10804
#58 0x007a4340 in cp_parser_compound_statement
(parser=parser@entry=0x77fed990,
in_statement_expr=in_statement_expr@entry=0x0, bcs_flags=bcs_flags@entry=0,
function_body=function_body@entry=true) at 

[Bug tree-optimization/71522] [5/6 Regression] Wrong optimization of memcpy through a var of type long double

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[5/6/7 Regression] Wrong|[5/6 Regression] Wrong
   |optimization of memcpy  |optimization of memcpy
   |through a var of type long  |through a var of type long
   |double  |double
  Known to fail|7.0 |

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

[Bug tree-optimization/71522] [5/6/7 Regression] Wrong optimization of memcpy through a var of type long double

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Tue Jun 14 10:42:00 2016
New Revision: 237429

URL: https://gcc.gnu.org/viewcvs?rev=237429=gcc=rev
Log:
2016-06-14  Richard Biener  

PR tree-optimization/71522
* tree-ssa.c (non_rewritable_lvalue_p): Do not rewrite non-float
copying into float copying.

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

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

[Bug tree-optimization/71521] [6 Regression] Regression in GCC-7.0.0's optimizer

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Tue Jun 14 10:28:23 2016
New Revision: 237428

URL: https://gcc.gnu.org/viewcvs?rev=237428=gcc=rev
Log:
2016-06-14  Richard Biener  

PR tree-optimization/71521
* tree-vrp.c (extract_range_from_binary_expr_1): Guard
division int_const_binop against zero divisor.

* gcc.dg/tree-ssa/vrp101.c: New testcase.

Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/71520] Missing cross-jumping of switch cases

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jun 14 10:20:04 2016
New Revision: 237427

URL: https://gcc.gnu.org/viewcvs?rev=237427=gcc=rev
Log:
PR tree-optimization/71520
* tree-ssa-tail-merge.c (find_duplicate): Handle labels.
(replace_block_by): Move user labels from bb1 to bb2.

* gcc.dg/tree-ssa/pr71520.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71520.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-tail-merge.c

[Bug middle-end/71526] [7 Regression] ICE: verify_gimple failed

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
(In reply to Richard Biener from comment #1)
> this is the new /* MIN (X, C1) < C2 -> X < C2 || C1 < C2  */ pattern matching
> and using boolean_type (guessed by genmatch) for the result comparisons
> instead of 'type'.

Ah, it works so well at guessing types usually that I stopped checking the
resulting code...

> I'll see if I can fix genmatch.

If it is complicated, I guess that writing cmp:type in the transformation would
work as a temporary fix. But indeed, we don't seem to use in_type for
comparisons.

[Bug middle-end/71488] [6/7 Regression] Wrong code for vector comparisons with ivybridge and westmere targets

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|7.0 |6.2
  Known to fail||6.1.0

[Bug middle-end/71488] [6/7 Regression] Wrong code for vector comparisons with ivybridge and westmere targets

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Tue, 14 Jun 2016, ubizjak at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71488
> 
> Uroš Bizjak  changed:
> 
>What|Removed |Added
> 
>  CC||ienkovich at gcc dot gnu.org,
>||rguenther at suse dot de
> 
> --- Comment #3 from Uroš Bizjak  ---
> (In reply to Uroš Bizjak from comment #1)
> 
> > The problem already exists at RTL expand time. The corresponding insn
> > sequence is:
> > 
> > ;; mask__3.59_48 = vect_cst__51 == { 0, 0 };
> 
> Richi, shouldn't this be a VEC_COND_EXPR ?

I think we're supposed to handle this fine now.  Ilja should know this
better though.

[Bug middle-end/71526] [7 Regression] ICE: verify_gimple failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-06-14
 CC||glisse at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed, caused by forwprop.

Applying pattern match.pd:2375, gimple-match.c:2344
Applying pattern match.pd:1367, gimple-match.c:2155
Applying pattern match.pd:559, gimple-match.c:46169
gimple_simplified to _62 = n_64(D) <= 0;
_47 = _62;
Applying pattern match.pd:853, gimple-match.c:164
gimple_simplified to _48 = _46 | _62;

this is the new /* MIN (X, C1) < C2 -> X < C2 || C1 < C2  */ pattern matching
and using boolean_type (guessed by genmatch) for the result comparisons instead
of 'type'.

I'll see if I can fix genmatch.

[Bug middle-end/71488] [6/7 Regression] Wrong code for vector comparisons with ivybridge and westmere targets

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||ienkovich at gcc dot gnu.org,
   ||rguenther at suse dot de

--- Comment #3 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #1)

> The problem already exists at RTL expand time. The corresponding insn
> sequence is:
> 
> ;; mask__3.59_48 = vect_cst__51 == { 0, 0 };

Richi, shouldn't this be a VEC_COND_EXPR ?

[Bug tree-optimization/71509] Bitfield causes load hit store with larger store than load

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Bitfield extraction on ppc64le goes the

  /* Try loading part of OP0 into a register and extracting the
 bitfield from that.  */
  unsigned HOST_WIDE_INT bitpos;
  rtx xop0 = adjust_bit_field_mem_for_reg (pattern, op0, bitsize, bitnum,
   0, 0, tmode, );

way which ends up generating the DImode load using the fact that the struct
alignment adds padding after csum_level.  The store path OTOH ends up
honoring the C++ mem model which says to access the bitfield in ints declared
type (IIRC?) and the bit region via DECL_BIT_FIELD_REPRESENTATIVE is of size 8
(because of C++ inheritance that tail padding can be re-used).

It looks like we didn't adjust the bitfield read paths for the mem model
because in practice it doesn't matter and it may generate larger/slower code
not to do loads in larger types on some archs.

This leads to the observed load-store / store-load issues.

Note that we conservatively compute the extent for
DECL_BIT_FIELD_REPRESENTATIVE
by prefering smaller modes.  There's some ??? in finish_bitfield_representative
and the above remark about tail padding re-use is only implemented via
prefering
smaller modes.  Thus when adding a 'long foo' after csum_level the
representative doesn't change to 64bit width but stays at 8bits (both are valid
from the C++ memory model).

Note that the proposed simple lowering of bitfield accesses on GIMPLE would
do accesses of DECL_BIT_FIELD_REPRESENTATIVE and thus in this case use byte
accesses.

I suppose we want to be less conservative about DECL_BIT_FIELD_REPRESENTATIVE
and leave it up to the target how to do the actual accesses.

Widening the representative generates

__skb_decr_checksum_unnecessary:
ld 9,8(3)
addi 10,9,3
rldicr 9,9,0,61
rldicl 10,10,0,62
or 9,9,10
std 9,8(3)
blr

[Bug middle-end/71310] Bitfields cause load hit store with smaller store and larger load

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #11 from Richard Biener  ---
Fixed on trunk.

[Bug tree-optimization/71509] Bitfield causes load hit store with larger store than load

[rguenth at gcc dot gnu.org]

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

Bug 71310 Summary: Bitfields cause load hit store with smaller store and larger 
load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71310

   What|Removed |Added

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

[Bug bootstrap/71510] [7 Regression] Failed to bootstrap with --with-arch=corei7 --with-cpu=intel

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Tue Jun 14 07:26:52 2016
New Revision: 237426

URL: https://gcc.gnu.org/viewcvs?rev=237426=gcc=rev
Log:
2016-06-14  Richard Biener  

PR middle-end/71310
PR bootstrap/71510
* expr.h (get_bit_range): Declare.
* expr.c (get_bit_range): Export.
* fold-const.c (optimize_bit_field_compare): Use get_bit_range and
word_mode again to constrain the bitfield access.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/expr.h
trunk/gcc/fold-const.c

[Bug middle-end/71310] Bitfields cause load hit store with smaller store and larger load

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Author: rguenth
Date: Tue Jun 14 07:26:52 2016
New Revision: 237426

URL: https://gcc.gnu.org/viewcvs?rev=237426=gcc=rev
Log:
2016-06-14  Richard Biener  

PR middle-end/71310
PR bootstrap/71510
* expr.h (get_bit_range): Declare.
* expr.c (get_bit_range): Export.
* fold-const.c (optimize_bit_field_compare): Use get_bit_range and
word_mode again to constrain the bitfield access.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/expr.h
trunk/gcc/fold-const.c

[Bug bootstrap/71510] [7 Regression] Failed to bootstrap with --with-arch=corei7 --with-cpu=intel

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug tree-optimization/71521] [6 Regression] Regression in GCC-7.0.0's optimizer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[6/7 Regression] Regression |[6 Regression] Regression
   |in GCC-7.0.0's optimizer|in GCC-7.0.0's optimizer
  Known to fail|7.0 |

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

[Bug tree-optimization/71521] [6/7 Regression] Regression in GCC-7.0.0's optimizer

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Tue Jun 14 07:22:04 2016
New Revision: 237425

URL: https://gcc.gnu.org/viewcvs?rev=237425=gcc=rev
Log:
2016-06-14  Richard Biener  

PR tree-optimization/71521
* tree-vrp.c (extract_range_from_binary_expr_1): Guard
division int_const_binop against zero divisor.

* gcc.dg/tree-ssa/vrp101.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp101.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c

[Bug middle-end/71526] New: [7 Regression] ICE: verify_gimple failed

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 71526
   Summary: [7 Regression] ICE: verify_gimple failed
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch
  Target Milestone: ---

Overnight trunk regression, requires LTO.

> cat bug.f90
MODULE util
  INTERFACE sort
 MODULE PROCEDURE sort_cv
  END INTERFACE
CONTAINS
  SUBROUTINE sort_cv ( arr, n, index )
CHARACTER(LEN=*), INTENT(INOUT)  :: arr(1:n)
INTEGER, INTENT(OUT) :: INDEX(1:n)
INTEGER, ALLOCATABLE, DIMENSION(:, :):: entries
ALLOCATE(entries(max_length,SIZE(arr)))
  END SUBROUTINE sort_cv
END MODULE util
USE util
INTEGER, ALLOCATABLE :: ind(:)
character(len=3), ALLOCATABLE :: d(:)
CALL sort(d,N,ind)
END

> gfortran -fno-inline -flto -O2 bug.f90
bug.f90: In function ‘sort_cv.constprop’:
bug.f90:6:0: error: non-trivial conversion at assignment
   SUBROUTINE sort_cv ( arr, n, index )

logical(kind=4)
bool
_60 = _37;
bug.f90:6:0: error: type mismatch in binary expression
logical(kind=4)

bool

logical(kind=4)

_68 = _37 | _67;
bug.f90:6:0: internal compiler error: verify_gimple failed
0xaaada4 verify_gimple_in_cfg(function*, bool)
../../gcc/gcc/tree-cfg.c:5212
0x9908ac execute_function_todo
../../gcc/gcc/passes.c:1964
0x99135b execute_todo
../../gcc/gcc/passes.c:2016
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
lto-wrapper: fatal error: gfortran returned 1 exit status
compilation terminated.
/data/vjoost/gnu/binutils-2.23.2/install/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status

> gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/data/vjoost/gnu/gcc_trunk/install/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/data/vjoost/gnu/gcc_trunk/install
--enable-languages=c,c++,fortran --disable-multilib --enable-plugins
--enable-lto --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160614 (experimental) [trunk revision 237423] (GCC)