[Bug c++/71814] New: ICE on valid C++11 code: in write_type, at cp/mangle.c:2158

[su at cs dot ucdavis.edu]

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

Bug ID: 71814
   Summary: ICE on valid C++11 code: in write_type, at
cp/mangle.c:2158
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following C++11 code causes an ICE when compiled with the current GCC trunk
on x86_64-linux-gnu in both 32-bit and 64-bit modes.  

It also affects 6.1.x and is a regression from 5.4.x. 


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160707 (experimental) [trunk revision 238117] (GCC)
$
$ g++-5.4 -std=c++11 -c small.cpp
$ clang++-3.8 -std=c++11 -c small.cpp
$
$ g++-trunk -std=c++11 -c small.cpp
small.cpp: In instantiation of ‘void foo(int (&)[sizeof (int, U ..., int,
typename U::type ...)]) [with U = {A, A}; TN<int, U ..., int,
typename U::type ...> = int [6]]’:
small.cpp:8:57:   required from here
small.cpp:6:6: internal compiler error: in write_type, at cp/mangle.c:2158
 void foo (TN < int, U ..., int, typename U::type ... >&) {}
  ^~~
0x861088 write_type
../../gcc-source-trunk/gcc/cp/mangle.c:2158
0x8622aa write_array_type
../../gcc-source-trunk/gcc/cp/mangle.c:3319
0x8622aa write_type
../../gcc-source-trunk/gcc/cp/mangle.c:1935
0x861411 write_type
../../gcc-source-trunk/gcc/cp/mangle.c:2082
0x8639d7 write_method_parms
../../gcc-source-trunk/gcc/cp/mangle.c:2602
0x863d70 write_bare_function_type
../../gcc-source-trunk/gcc/cp/mangle.c:2544
0x865f25 mangle_decl_string
../../gcc-source-trunk/gcc/cp/mangle.c:3515
0x866078 get_mangled_id
../../gcc-source-trunk/gcc/cp/mangle.c:3537
0x866348 mangle_decl(tree_node*)
../../gcc-source-trunk/gcc/cp/mangle.c:3607
0x10605b0 decl_assembler_name(tree_node*)
../../gcc-source-trunk/gcc/tree.c:669
0x10b1d68 notice_global_symbol(tree_node*)
../../gcc-source-trunk/gcc/varasm.c:1654
0x9c2149 cgraph_node::finalize_function(tree_node*, bool)
../../gcc-source-trunk/gcc/cgraphunit.c:426
0x81a96f expand_or_defer_fn(tree_node*)
../../gcc-source-trunk/gcc/cp/semantics.c:4223
0x6d4c1a instantiate_decl(tree_node*, int, bool)
../../gcc-source-trunk/gcc/cp/pt.c:22118
0x721842 instantiate_pending_templates(int)
../../gcc-source-trunk/gcc/cp/pt.c:22214
0x764975 c_parse_final_cleanups()
../../gcc-source-trunk/gcc/cp/decl2.c:4600
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.





template < typename > struct A {  using type = int;  };

template < typename ... T > using TN = int[sizeof ... (T)];

template < typename ... U >
void foo (TN < int, U ..., int, typename U::type ... >&) {}

template void foo < A < int >, A < float > > (int (&)[6]);

[Bug c/71813] New: fprintf/printf function exception

[szhebin at yahoo dot com]

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

Bug ID: 71813
   Summary: fprintf/printf function exception
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: szhebin at yahoo dot com
  Target Milestone: ---

I wrote a program:
#include 
#include 

char *test2()
{
char testArray[2];
char *testP;

memcpy(testArray, "2", 2);

testP = testArray;

return testP;
}

char *test()
{
return test2();
}

int main()
{
char *ret;

ret = test();

fprintf(stdout, "%s\n", ret);

return 0;
}

but, when I ran it, it output some things that people cannot understand.
such as:'�d/
when I changed fprintf to printf, it output NULL.
then, I use gdb-7.10.1 to check it, 
I could know:
before fprintf/printf, the value of ret is correct.
but after fprintf/printf, it went wrong.

[Bug c/71812] gcc6/c++/functional:1726:40: internal compiler error: in assign_temp, at function.c:961

[noloader at gmail dot com]

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

--- Comment #1 from Jeffrey Walton  ---

> I can't submit pubkey_pkcs8.ii.zip. It appears to be causing Gateway
> Timeouts.

The preprocessed source file is available at
https://trac.macports.org/ticket/51796#no1

[Bug c/71812] New: gcc6/c++/functional:1726:40: internal compiler error: in assign_temp, at function.c:961

[noloader at gmail dot com]

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

Bug ID: 71812
   Summary: gcc6/c++/functional:1726:40: internal compiler error:
in assign_temp, at function.c:961
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: noloader at gmail dot com
  Target Milestone: ---

I'm working on OS X 10.8.5 with MacPorts 2.3.4 installed. I'm attempting to
compile Jack Lloyd's Botan (http://github.com/randombit/botan) with GCC 6.1
from the port. Botan is a C++ TLS library.

I don't have a minimal test case because I did not write the code. I'm hoping
one of the GCC devs with C++/STL knowledge can spot the issue. Or maybe spot
the bad interaction and craft a test case.

The MacPorts bug report is at https://trac.macports.org/ticket/51796. The
MacPorts maintainers suggested to file the bug upstream.

**

I can't submit pubkey_pkcs8.ii.zip. It appears to be causing Gateway Timeouts.

**

$ make
 ...

 /opt/local/bin/g++-mp-6  -m64 -pthread -fstack-protector -Wa,-q -fPIC
 -fvisibility=hidden -std=c++11 -D_REENTRANT -O3 -momit-leaf-frame-pointer
 -Wall -Wextra -Wpedantic -Wshadow -Wstrict-aliasing -Wstrict-overflow=5
 -Wcast-align -Wmissing-declarations -Wpointer-arith -Wcast-qual -Wzero-as-
 null-pointer-constant -Wnon-virtual-dtor -Ibuild/include -c
 ./src/lib/pubkey/pkcs8.cpp -o build/obj/lib/pubkey_pkcs8.o
 In file included from /opt/local/include/gcc6/c++/memory:79:0,
  from build/include/botan/types.h:16,
  from build/include/botan/mem_ops.h:11,
  from build/include/botan/secmem.h:11,
  from build/include/botan/pk_keys.h:11,
  from build/include/botan/x509_key.h:11,
  from build/include/botan/pkcs8.h:11,
  from ./src/lib/pubkey/pkcs8.cpp:8:
 /opt/local/include/gcc6/c++/functional: In static member function 'static
 _Res std::_Function_handler<_Res(_ArgTypes ...),
 _Functor>::_M_invoke(const std::_Any_data&, _ArgTypes&& ...) [with _Res =
 std::__cxx11::basic_string; _Functor =
 Botan::PKCS8::load_key(Botan::DataSource&,
 Botan::RandomNumberGenerator&)::; _ArgTypes = {}]':
 /opt/local/include/gcc6/c++/functional:1726:40: internal compiler error:
 in assign_temp, at function.c:961
   std::forward<_ArgTypes>(__args)...);
 ^

 /opt/local/include/gcc6/c++/functional:1726:40: internal compiler error:
 Abort trap: 6
 g++-mp-6: internal compiler error: Abort trap: 6 (program cc1plus)
 Please submit a full bug report,
 with preprocessed source if appropriate.
 See  for instructions.
 Makefile:1152: recipe for target 'build/obj/lib/pubkey_pkcs8.o' failed
 make: *** [build/obj/lib/pubkey_pkcs8.o] Error 4


*

Here's Botan's configuration. Also note the configuration uses -Wa,-q, which
means the Clang integrated assembler is used. I dont know if it makes a
difference, but its mentioned for completeness.

 $ ./configure.py --os=darwin --cc=gcc --cpu=x86_64 --cc-
 bin=/opt/local/bin/g++-mp-6 --cc-abi-flags="-Wa,-q"
INFO: Platform: OS="Darwin" machine="x86_64" proc="i386"
INFO: Canonicalizized CPU target x86_64 to x86_64/x86_64
INFO: Target is gcc-darwin-x86_64-x86_64
INFO: Skipping, dependency failure - sessions_sqlite3
INFO: Skipping, incompatible CPU - mp_x86_32 simd_altivec
INFO: Skipping, incompatible OS - beos_stats cryptoapi_rng win32_stats
INFO: Skipping, incompatible compiler - mp_x86_32_msvc
INFO: Skipping, only used if needed or requested - dyn_load mp_generic
 simd_scalar
INFO: Skipping, requires external dependency - boost bzip2 lzma openssl
 pkcs11 sqlite3 tpm zlib
INFO: Using MP module mp_x86_64
INFO: Using SIMD module simd_sse2
INFO: Loading modules adler32 aead aes aes_ni aes_ssse3 aont asn1
 auto_rng base base64 bcrypt bigint blake2 block blowfish camellia cascade
 cast cbc cbc_mac ccm cfb chacha chacha20poly1305 clmul cmac codec_filt
 comb4p compression crc24 crc32 cryptobox ctr curve25519 darwin_secrandom
 datastor des dev_random dh dl_algo dl_group dlies dsa eax ec_gfp ec_group
 ecb ecc_key ecdh ecdsa ecgdsa ecies eckcdsa egd elgamal eme_oaep eme_pkcs1
 eme_raw emsa1 emsa_pkcs1 emsa_pssr emsa_raw emsa_x931 entropy fd_unix ffi
 filters fpe_fe1 gcm gost_28147 gost_3410 gost_3411 has160 hash hash_id hex
 hkdf hmac hmac_drbg hmac_rng hres_timer http_util idea idea_sse2 if_algo
 kasumi kdf kdf1 kdf1_iso18033 kdf2 keccak keypair lion locking_allocator
 mac mars mce mceies md2 md4 md5 mdx_hash mgf1 misty1 mode_pad modes mp
 mp_x86_64 noekeon noekeon_simd nr numbertheory ocb ofb oid_lookup openpgp
 par_hash passhash9 pbes2 pbkdf pbkdf1 pbkdf2 pem pk_pad poly1305 prf_tls
 prf_x942 proc_walk pubkey rc2 rc4 rc5 rc6 rdrand rdseed rfc3394 rfc6979
 

[Bug target/71801] [7 Regression] ice in fix_debug_reg_uses

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
markus@x4 tmp % cat bug_.i
struct {
  char uuid[16];
} c;
struct {
  int s_uuid[6];
} a, b;
void *memcpy();
int lseek();
static int get_label_uuid(char *p1) {
  memcpy(p1, a.s_uuid, sizeof(a));
  if (lseek())
memcpy(p1, b.s_uuid, sizeof(b));
  return 0;
}
void uuidcache_addentry(char *p1) { memcpy(, p1, sizeof(c)); }
void uuidcache_init() {
  char d[1];
  get_label_uuid(d);
  uuidcache_addentry(d);
}

markus@x4 tmp % gcc -c -O2 -g bug_.i
bug_.i: In function ‘uuidcache_init’:
bug_.i:20:1: internal compiler error: in fix_debug_reg_uses, at
config/i386/i386.c:3818
 }
 ^
0xe92015 timode_scalar_chain::fix_debug_reg_uses(rtx_def*)
../../gcc/gcc/config/i386/i386.c:3817
0xea5482 timode_scalar_chain::fix_debug_reg_uses(rtx_def*)
../../gcc/gcc/config/i386/i386.c:3799
0xea5482 timode_scalar_chain::convert_insn(rtx_insn*)
../../gcc/gcc/config/i386/i386.c:3844
0xea5d04 scalar_chain::convert()
../../gcc/gcc/config/i386/i386.c:3932
0xea64f6 convert_scalars_to_vector
../../gcc/gcc/config/i386/i386.c:3998
0xea64f6 execute
../../gcc/gcc/config/i386/i386.c:4092
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++/71811] New: gcc6/c++/functional:1726:40: internal compiler error: in assign_temp, at function.c:961

[noloader at gmail dot com]

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

Bug ID: 71811
   Summary: gcc6/c++/functional:1726:40: internal compiler error:
in assign_temp, at function.c:961
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: noloader at gmail dot com
  Target Milestone: ---

Created attachment 38862
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38862=edit
Preprocessed pubkey_pkcs8 source file

I'm working on OS X 10.8.5 with MacPorts 2.3.4 installed. I'm attempting to
compile Jack Lloyd's Botan (http://github.com/randombit/botan) with GCC 6.1
from the port. Botan is a C++ TLS library.

I don't have a minimal test case because I did not write the code. I'm hoping
one of the GCC devs with C++/STL knowledge can spot the issue. Or maybe spot
the bad interaction and craft a test case.

The MacPorts bug report is at https://trac.macports.org/ticket/51796. The
MacPorts maintainers suggested to file the bug upstream.

**

$ make
 ...

 /opt/local/bin/g++-mp-6  -m64 -pthread -fstack-protector -Wa,-q -fPIC
 -fvisibility=hidden -std=c++11 -D_REENTRANT -O3 -momit-leaf-frame-pointer
 -Wall -Wextra -Wpedantic -Wshadow -Wstrict-aliasing -Wstrict-overflow=5
 -Wcast-align -Wmissing-declarations -Wpointer-arith -Wcast-qual -Wzero-as-
 null-pointer-constant -Wnon-virtual-dtor -Ibuild/include -c
 ./src/lib/pubkey/pkcs8.cpp -o build/obj/lib/pubkey_pkcs8.o
 In file included from /opt/local/include/gcc6/c++/memory:79:0,
  from build/include/botan/types.h:16,
  from build/include/botan/mem_ops.h:11,
  from build/include/botan/secmem.h:11,
  from build/include/botan/pk_keys.h:11,
  from build/include/botan/x509_key.h:11,
  from build/include/botan/pkcs8.h:11,
  from ./src/lib/pubkey/pkcs8.cpp:8:
 /opt/local/include/gcc6/c++/functional: In static member function 'static
 _Res std::_Function_handler<_Res(_ArgTypes ...),
 _Functor>::_M_invoke(const std::_Any_data&, _ArgTypes&& ...) [with _Res =
 std::__cxx11::basic_string; _Functor =
 Botan::PKCS8::load_key(Botan::DataSource&,
 Botan::RandomNumberGenerator&)::; _ArgTypes = {}]':
 /opt/local/include/gcc6/c++/functional:1726:40: internal compiler error:
 in assign_temp, at function.c:961
   std::forward<_ArgTypes>(__args)...);
 ^

 /opt/local/include/gcc6/c++/functional:1726:40: internal compiler error:
 Abort trap: 6
 g++-mp-6: internal compiler error: Abort trap: 6 (program cc1plus)
 Please submit a full bug report,
 with preprocessed source if appropriate.
 See  for instructions.
 Makefile:1152: recipe for target 'build/obj/lib/pubkey_pkcs8.o' failed
 make: *** [build/obj/lib/pubkey_pkcs8.o] Error 4


*

Here's Botan's configuration. Also note the configuration uses -Wa,-q, which
means the Clang integrated assembler is used. I dont know if it makes a
difference, but its mentioned for completeness.

 $ ./configure.py --os=darwin --cc=gcc --cpu=x86_64 --cc-
 bin=/opt/local/bin/g++-mp-6 --cc-abi-flags="-Wa,-q"
INFO: Platform: OS="Darwin" machine="x86_64" proc="i386"
INFO: Canonicalizized CPU target x86_64 to x86_64/x86_64
INFO: Target is gcc-darwin-x86_64-x86_64
INFO: Skipping, dependency failure - sessions_sqlite3
INFO: Skipping, incompatible CPU - mp_x86_32 simd_altivec
INFO: Skipping, incompatible OS - beos_stats cryptoapi_rng win32_stats
INFO: Skipping, incompatible compiler - mp_x86_32_msvc
INFO: Skipping, only used if needed or requested - dyn_load mp_generic
 simd_scalar
INFO: Skipping, requires external dependency - boost bzip2 lzma openssl
 pkcs11 sqlite3 tpm zlib
INFO: Using MP module mp_x86_64
INFO: Using SIMD module simd_sse2
INFO: Loading modules adler32 aead aes aes_ni aes_ssse3 aont asn1
 auto_rng base base64 bcrypt bigint blake2 block blowfish camellia cascade
 cast cbc cbc_mac ccm cfb chacha chacha20poly1305 clmul cmac codec_filt
 comb4p compression crc24 crc32 cryptobox ctr curve25519 darwin_secrandom
 datastor des dev_random dh dl_algo dl_group dlies dsa eax ec_gfp ec_group
 ecb ecc_key ecdh ecdsa ecgdsa ecies eckcdsa egd elgamal eme_oaep eme_pkcs1
 eme_raw emsa1 emsa_pkcs1 emsa_pssr emsa_raw emsa_x931 entropy fd_unix ffi
 filters fpe_fe1 gcm gost_28147 gost_3410 gost_3411 has160 hash hash_id hex
 hkdf hmac hmac_drbg hmac_rng hres_timer http_util idea idea_sse2 if_algo
 kasumi kdf kdf1 kdf1_iso18033 kdf2 keccak keypair lion locking_allocator
 mac mars mce mceies md2 md4 md5 mdx_hash mgf1 misty1 mode_pad modes mp
 mp_x86_64 noekeon noekeon_simd nr numbertheory ocb ofb oid_lookup openpgp
 par_hash passhash9 pbes2 pbkdf pbkdf1 pbkdf2 pem pk_pad poly1305 prf_tls
 prf_x942 proc_walk pubkey rc2 rc4 rc5 

10 x 1036778084 = ??

[Nobby-Hirand]

I have just find strange answer, 10 x 1036778084 = 1777846248??

I'm using gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4 and gcc (GCC) 4.8.5
20150623 (Red Hat 4.8.5-4).
These are same results, 10 x 1036778084 = 1777846248

C Lang:

printf("%d \n", atoi("10367780849"));
 1777846248
Result is 1777846257, and also following source,

int y = 1036778084;
int x = 10;
int z;

z = x * y;
printf("%d x %d = %d\n", x,y,z);

10 x 1036778084 = 1777846248





--
View this message in context: 
http://gcc.1065356.n5.nabble.com/10-x-1036778084-tp1279231.html
Sent from the gcc - bugs mailing list archive at Nabble.com.

[Bug fortran/71764] [4.9/5/6/7 Regression] ICE in gfc_trans_structure_assign

[jvdelisle at gcc dot gnu.org]

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

--- Comment #9 from Jerry DeLisle  ---
Author: jvdelisle
Date: Fri Jul  8 04:36:16 2016
New Revision: 238156

URL: https://gcc.gnu.org/viewcvs?rev=238156=gcc=rev
Log:
2016-07-07  Jerry DeLisle  

PR fortran/71764
* trans-expr.c (gfc_trans_structure_assign): Remove assert.

* gfortran.dg/pr71764.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr71764.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/71809] compile llvm3.8.0 failed by the libstdc++ of gcc6.1.0

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
http://lists.llvm.org/pipermail/cfe-dev/2016-March/047761.html

[Bug libstdc++/71809] compile llvm3.8.0 failed by the libstdc++ of gcc6.1.0

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
https://bugzilla.suse.com/show_bug.cgi?id=964143

[Bug libstdc++/66338] std::forward_as_tuple() issue with single argument

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

--- Comment #14 from Andrew Pinski  ---
Fixed.

[Bug target/71009] g++: ICE on modified gdb/valarith.c with -Ofast

[egall at gwmail dot gwu.edu]

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

--- Comment #5 from Eric Gallager  ---
I rebuilt with debugging info and got a better backtrace:

Breakpoint 1, internal_error (gmsgid=0x15ee807 "in %s, at %s:%d") at
../../gcc/diagnostic.c:1337
1337  va_start (ap, gmsgid);
(gdb) bt
#0  internal_error (gmsgid=0x15ee807 "in %s, at %s:%d") at
../../gcc/diagnostic.c:1337
#1  0x01266866 in fancy_abort (file=0x157ccd5 "../../gcc/emit-rtl.c",
line=1025, function=0x190cd98 "gen_reg_rtx") at ../../gcc/diagnostic.c:1405
#2  0x00945479 in gen_reg_rtx (mode=V2DImode) at ../../gcc/emit-rtl.c:1025
#3  0x00579f86 in gen_split_349 (curr_insn=0x325acf0, operands=0x1ff95c0) at
../../gcc/config/i386/sse.md:1129
#4  0x0076bb58 in split_8 (x1=0x3255ce4, insn=0x325acf0) at
../../gcc/config/i386/sse.md:1115
#5  0x00778c75 in split_insns (x1=0x3255ce4, insn=0x325acf0) at
../../gcc/config/i386/sse.md:13387
#6  0x0094b3e4 in try_split (pat=0x3255ce4, trial=0x325acf0, last=1) at
../../gcc/emit-rtl.c:3658
#7  0x00d4a502 in split_insn (insn=0x325acf0) at ../../gcc/recog.c:2887
#8  0x00d4a7c5 in split_all_insns () at ../../gcc/recog.c:2977
#9  0x00d4c34b in rest_of_handle_split_after_reload () at
../../gcc/recog.c:3913
#10 0x00d4c389 in (anonymous namespace)::pass_split_after_reload::execute
(this=0x50d0e190) at ../../gcc/recog.c:3942
#11 0x00d12144 in execute_one_pass (pass=0x50d0e190) at ../../gcc/passes.c:2344
#12 0x00d12495 in execute_pass_list_1 (pass=0x50d0e190) at
../../gcc/passes.c:2428
#13 0x00d124c5 in execute_pass_list_1 (pass=0x50d0e0d0) at
../../gcc/passes.c:2429
#14 0x00d124c5 in execute_pass_list_1 (pass=0x50d0d590) at
../../gcc/passes.c:2429
#15 0x00d12515 in execute_pass_list (fn=0x2b35bb8, pass=0x50d0b190) at
../../gcc/passes.c:2439
#16 0x008539ee in cgraph_node::expand (this=0x2d4b424) at
../../gcc/cgraphunit.c:1983
#17 0x00853fff in expand_all_functions () at ../../gcc/cgraphunit.c:2119
#18 0x00854c8b in symbol_table::compile (this=0x50e0b000) at
../../gcc/cgraphunit.c:2475
#19 0x00854ed1 in symbol_table::finalize_compilation_unit (this=0x50e0b000) at
../../gcc/cgraphunit.c:2565
#20 0x00e246cd in compile_file () at ../../gcc/toplev.c:490
#21 0x00e26f70 in do_compile () at ../../gcc/toplev.c:1998
#22 0x00e27332 in toplev::main (this=0xbfff94de, argc=140, argv=0xbfff9510) at
../../gcc/toplev.c:2132
#23 0x0124f80f in main (argc=140, argv=0xbfff9510) at ../../gcc/main.c:39
Current language:  auto; currently c++
(gdb) bt full
#0  internal_error (gmsgid=0x15ee807 "in %s, at %s:%d") at
../../gcc/diagnostic.c:1337
ap = 0x0
richloc = {
  static MAX_RANGES = , 
  static MAX_FIXIT_HINTS = , 
  m_num_ranges = 0, 
  m_ranges = {{
  m_loc = 33527040, 
  m_show_caret_p = 204
}, {
  m_loc = 0, 
  m_show_caret_p = false
}, {
  m_loc = 0, 
  m_show_caret_p = true
}}, 
  m_column_override = 0, 
  m_have_expanded_location = 104, 
  m_expanded_location = {
file = 0xd47953 "??\020\017U???\030?x?\001\002??u2?E\b\017?", 
line = 18, 
column = 1356874188, 
data = 0x0, 
sysp = false
  }, 
  m_num_fixit_hints = 18, 
  m_fixit_hints = {0x50e041cc, 0x0}
}
__FUNCTION__ = "internal_error"
#1  0x01266866 in fancy_abort (file=0x157ccd5 "../../gcc/emit-rtl.c",
line=1025, function=0x190cd98 "gen_reg_rtx") at ../../gcc/diagnostic.c:1405
No locals.
#2  0x00945479 in gen_reg_rtx (mode=V2DImode) at ../../gcc/emit-rtl.c:1025
val = (rtx) 0xd479ef
align = 128
__FUNCTION__ = "gen_reg_rtx"
#3  0x00579f86 in gen_split_349 (curr_insn=0x325acf0, operands=0x1ff95c0) at
../../gcc/config/i386/sse.md:1129
tmp = (rtx) 0x50e0e430
_val = (rtx_insn *) 0x0
__FUNCTION__ = "gen_split_349"
#4  0x0076bb58 in split_8 (x1=0x3255ce4, insn=0x325acf0) at
../../gcc/config/i386/sse.md:1115
operands = (rtx * const) 0x1ff95c0
x2 = (rtx) 0x3259dd0
x3 = (rtx) 0x3259dc0
x4 = (rtx) 0x32c22f0
x5 = (rtx) 0x27c6018
x6 = (rtx) 0x0
x7 = (rtx) 0x3255ccc
x8 = (rtx) 0x3254eb0
x9 = (rtx) 0x32797e0
x10 = (rtx) 0x0
#5  0x00778c75 in split_insns (x1=0x3255ce4, insn=0x325acf0) at
../../gcc/config/i386/sse.md:13387
operands = (rtx * const) 0x1ff95c0
x2 = (rtx) 0xbfff91d8
x3 = (rtx) 0xbfff922b
x4 = (rtx) 0x2d4b424
x5 = (rtx) 0x3251a28
x6 = (rtx) 0xbfff91c8
x7 = (rtx) 0x27c0cdc
x8 = (rtx) 0x325acf0
x9 = (rtx) 0xc07a4e
x10 = (rtx) 0xbfff91c8
x11 = (rtx) 0x0
x12 = (rtx) 0x3251a28
x13 = (rtx) 0x95215c
x14 = (rtx) 0xbfff91b8
x15 = (rtx) 0x27c0cdc
x16 = (rtx) 0x325ad14
x17 = (rtx) 0x9521eb
#6  0x0094b3e4 in try_split (pat=0x3255ce4, trial=0x325acf0, last=1) at
../../gcc/emit-rtl.c:3658
before = (rtx_insn *) 0x325aca8
after = (rtx_insn *) 0x325ad14
note = (rtx) 0x325aca8
seq = (rtx_insn *) 0x0
tem = (rtx_insn *) 0xbfff9248

[Bug libquadmath/71809] New: compile llvm3.8.0 failed by the libstdc++ of gcc6.1.0

[sulitsrc at 163 dot com]

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

Bug ID: 71809
   Summary: compile llvm3.8.0 failed by the libstdc++ of gcc6.1.0
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libquadmath
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sulitsrc at 163 dot com
  Target Milestone: ---

Created attachment 38861
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38861=edit
compile and build log file

I compile llvm3.8.0  by libstdc++ of gcc6.1.0, and get the error, I suspect
this is a bug, but don't make sure that. The error as flow:

/usr/bin/../lib/gcc/x86_64-isoft-linux/6.1.0/../../../../include/c++/6.1.0/tuple:1381:14:
error: no matching constructor for initialization of 'tuple'
{ return tuple<_Elements&&...>(std::forward<_Elements>(__args)...); }
 ^ ~~~

[Bug c++/71804] Default-generated constructor does not construct base class

[guille at cal dot berkeley.edu]

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

--- Comment #3 from Guille  ---
Sorry, this was silly. I'll try to get some sleep before posting something at
5am.

[Bug c++/71808] New: [concepts] ICE in finish_member_declaration

[lucdanton at free dot fr]

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

Bug ID: 71808
   Summary: [concepts] ICE in finish_member_declaration
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lucdanton at free dot fr
  Target Milestone: ---

ICE on both 6.1 and 7 trunk (rev. 238124), although I can't verify if the
stacktraces are similar. I don't know if the code should be rejected or not.

$ cat main.cpp
template
concept bool Fooable = requires(X x) { x.foo(); };

Fooable{X}
struct container {
using member_type = typename X::member_type;

X payload;
};

template
struct model {
using member_type = X;

void foo() {}

container bar() { return {}; }
};

int main()
{
container {}.payload.bar();
}
$ g++-trunk -std=c++1z -fconcepts main.cpp
main.cpp: In instantiation of 'struct container':
main.cpp:22:42:   required from here
main.cpp:5:18: internal compiler error: in finish_member_declaration, at
cp/semantics.c:2949
 struct container {
  ^
0x7032d9 finish_member_declaration(tree_node*)
../../gcc/gcc/cp/semantics.c:2949
0x674916 instantiate_class_template_1
../../gcc/gcc/cp/pt.c:10203
0x674916 instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.c:10417
0x6d682d complete_type(tree_node*)
../../gcc/gcc/cp/typeck.c:133
0x6d68d4 complete_type_or_maybe_complain(tree_node*, tree_node*, int)
../../gcc/gcc/cp/typeck.c:145
0x6d69b1 require_complete_type_sfinae(tree_node*, int)
../../gcc/gcc/cp/typeck.c:89
0x61e969 build_cxx_call(tree_node*, int, tree_node**, int)
../../gcc/gcc/cp/call.c:7920
0x628c13 build_over_call
../../gcc/gcc/cp/call.c:7831
0x627694 build_new_method_call_1
../../gcc/gcc/cp/call.c:8521
0x627694 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc/gcc/cp/call.c:8591
0x6b3f78 cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:6880
0x6b2142 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7991
0x6ba157 cp_parser_cast_expression
../../gcc/gcc/cp/parser.c:8668
0x6ba723 cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:8769
0x6bae04 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:9056
0x6bd27a cp_parser_expression
../../gcc/gcc/cp/parser.c:9225
0x6bd85f cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:10686
0x6c9a83 cp_parser_statement
../../gcc/gcc/cp/parser.c:10537
0x6ca2fc cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:10809
0x6ca3df cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:10763

[Bug rtl-optimization/71779] [5/6/7 regression] isl miscompiled with -mabi=ilp32

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
Ok, the one which I was looking into did the correct thing for reload which is
why I was confused.  Anyways reload is where the problem is.  It is doing a
store of SI mode but then loading it via DI mode without knowing we thought the
upper bits were zero.

Or we can declare what combine was doing is wrong.  Anyways it is either
related to TRULY_NOOP_TRUNCATION or WORD_REGISTER_OPERATIONS but I can't seem
to figure out combine that much right now.

[Bug fortran/71764] [4.9/5/6/7 Regression] ICE in gfc_trans_structure_assign

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
I have regression tested the fix and tried some various manipulations of test
code and it all seems to be fine. So I will commit this.

[Bug rtl-optimization/71779] [5/6/7 regression] isl miscompiled with -mabi=ilp32

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #5)
> Is an invalid combine.  GCC must be thinking the upper bits of reg 419 (aka
> 487) was zero for some reason.

No that is fine.  In fact reg 487 was done using add which will cause zeros in
the upper bits.

Oh I might be looking into the wrong one ...

[Bug fortran/71807] New: Internal compiler error with NULL() reference in structure constructor

[ian_harvey at bigpond dot com]

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

Bug ID: 71807
   Summary: Internal compiler error with NULL() reference in
structure constructor
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ian_harvey at bigpond dot com
  Target Milestone: ---

The following snippet, when compiled with gfortran recent trunk (r238061) or
6.1.1 results in an internal compiler error.

~~

MODULE fold_convert_loc_ice
  IMPLICIT NONE
  PRIVATE

  TYPE, PUBLIC :: ta
PRIVATE
INTEGER :: a_comp
  END TYPE ta

  TYPE, PUBLIC :: tb
TYPE(ta), ALLOCATABLE :: b_comp
  END TYPE tb
CONTAINS
  SUBROUTINE proc
TYPE(tb) :: b

b = tb(null())
  END SUBROUTINE proc
END MODULE fold_convert_loc_ice

~~

$ gfortran -c -v fold_convert_loc_ice.f90
Using built-in specs.
COLLECT_GCC=gfortran
Target: x86_64-pc-linux-gnu
Configured with: .././src/configure --prefix=/home/MEGMS2/ian/usr/gcc-7.0.0
--enable-languages=c,c++,fortran --enable-libgomp --enable-checking=release
Thread model: posix
gcc version 7.0.0 20160706 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic' '-march=x86-64'
 /home/MEGMS2/ian/usr/gcc-7.0.0/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/f951
fold_convert_loc_ice.f90 -quiet -dumpbase fold_convert_loc_ice.f90
-mtune=generic -march=x86-64 -auxbase fold_convert_loc_ice -version
-fintrinsic-modules-path
/home/MEGMS2/ian/usr/gcc-7.0.0/lib/gcc/x86_64-pc-linux-gnu/7.0.0/finclude -o
/tmp/cc3kuTzv.s
GNU Fortran (GCC) version 7.0.0 20160706 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 7.0.0 20160704 (experimental), GMP version
6.1.0, MPFR version 3.1.4, MPC version 1.0.2, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 7.0.0 20160706 (experimental)
(x86_64-pc-linux-gnu)
compiled by GNU C version 7.0.0 20160704 (experimental), GMP version
6.1.0, MPFR version 3.1.4, MPC version 1.0.2, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
fold_convert_loc_ice.f90:17:0:

 b = tb(null())

internal compiler error: in fold_convert_loc, at fold-const.c:2371
0x833153 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../.././src/gcc/fold-const.c:2371
0x6b6e27 gfc_trans_subcomponent_assign
../.././src/gcc/fortran/trans-expr.c:7250
0x6b6653 gfc_trans_structure_assign(tree_node*, gfc_expr*, bool)
../.././src/gcc/fortran/trans-expr.c:7391
0x6b7dbf gfc_conv_structure(gfc_se*, gfc_expr*, int)
../.././src/gcc/fortran/trans-expr.c:7420
0x6b8e62 gfc_trans_assignment_1
../.././src/gcc/fortran/trans-expr.c:9317
0x682275 trans_code
../.././src/gcc/fortran/trans.c:1678
0x6a6019 gfc_generate_function_code(gfc_namespace*)
../.././src/gcc/fortran/trans-decl.c:6202
0x685a39 gfc_generate_module_code(gfc_namespace*)
../.././src/gcc/fortran/trans.c:2056
0x63d2eb translate_all_program_units
../.././src/gcc/fortran/parse.c:5873
0x63d2eb gfc_parse_file()
../.././src/gcc/fortran/parse.c:6092
0x67ec62 gfc_be_parse_file
../.././src/gcc/fortran/f95-lang.c:198
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug rtl-optimization/71779] [5/6/7 regression] isl miscompiled with -mabi=ilp32

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
That is the following (I am using ubuntu's 5.3.1 in 1604 right now):
Trying 944, 945 -> 946:
Successfully matched this instruction:
(set (reg:DI 1 x1)
(ior:DI (ashift:DI (reg/f:DI 110 [ obj1$4 ])
(const_int 32 [0x20]))
(reg/f:DI 419)))


Where 944, 945 and 946 was:
(insn 944 943 945 100 (set (zero_extract:DI (reg/v:DI 197 [ obj1 ])
(const_int 32 [0x20])
(const_int 0 [0]))
(reg/f:DI 419)) isl_input.c:2496 687 {*insv_regdi}
 (nil))
(insn 945 944 946 100 (set (zero_extract:DI (reg/v:DI 197 [ obj1 ])
(const_int 32 [0x20])
(const_int 32 [0x20]))
(reg/f:DI 110 [ obj1$4 ])) isl_input.c:2496 687 {*insv_regdi}
 (expr_list:REG_DEAD (reg/f:DI 110 [ obj1$4 ])
(nil)))
(insn 946 945 947 100 (set (reg:DI 1 x1)
(reg/v:DI 197 [ obj1 ])) isl_input.c:2496 48 {*movdi_aarch64}
 (expr_list:REG_DEAD (reg/v:DI 197 [ obj1 ])
(nil)))

Is an invalid combine.  GCC must be thinking the upper bits of reg 419 (aka
487) was zero for some reason.

[Bug rtl-optimization/71779] [5/6/7 regression] isl miscompiled with -mabi=ilp32

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|target  |rtl-optimization

--- Comment #4 from Andrew Pinski  ---
BY the way it looks like combine:
> The next major change is after combine, which merges the zero_extract in with 
> some other operations...

Should not have done that because of the way paradoxical subreg are defined as
not caring about the top bits of the register.

[Bug target/71779] [5/6/7 regression] isl miscompiled with -mabi=ilp32

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-08
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
(In reply to James Greenhalgh from comment #2)
> 
> First, where did the DImode paradoxical subreg come from in the first place,
> and why wasn't it a zero-extend?

Because it is creating the struct:
struct isl_obj {
 isl_obj_type type; // typedef struct isl_obj_vtable *isl_obj_type;
 void *v;
};

Which is passed via one register via the following reules:
C.10  If the argument is a Composite Type and the size in double-words of the
argument is not more than 8
minus NGRN, then the argument is copied into consecutive general-purpose
registers, starting at
x[NGRN]. The argument is passed as though it had been loaded into the registers
from a double-wordaligned
address with an appropriate sequence of LDR instructions loading consecutive
registers from memory (the contents of any unused parts of the registers are
unspecified by this standard). The NGRN
is incremented by the number of registers used. The argument has now been
allocated.

 CUT -

So we have two SI objects which then are put into one DI register from the
above rule.  Doing zero-extending does not make sense as we are concatenating
the registers together (via an insert) to form only one.

> 
> Second, why did reload decide it was safe to choose a memory location for a
> paradoxical subreg and widen the size of the memory access?

That I don't know.


> Not marking it this as confirmed as I haven't verified the ISL code to check
> it isn't breaking any Undefined Behavior rules.
It is not based on the above reasoning.

[Bug c++/71804] Default-generated constructor does not construct base class

[guille at cal dot berkeley.edu]

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

--- Comment #2 from Guille  ---
(In reply to Marc Glisse from comment #1)
> This is not the right place to learn about C++. Before filing a bug report
> about a compiler, please find another compiler that behaves differently. If
> all compilers behave the same, it is unlikely to be a bug.

Right you are. Clang does the same. 
It's not exactly the first time I use c++, still amazed at this. I'll look
where the standard specifies this, I couldn't find reference to it online. 
I find it hard not assume something isn't quite right when one can create
simple code with non-matching ctor/dtor. 

Thanks for the clarification, I'll try to find out about this elsewhere.

[Bug target/71720] initialization of a vector of floats generates incorrect code for -mcpu=power9

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #5 from Michael Meissner  ---
Fix in trunk and back ported to GCC 6.2.

[Bug target/71806] PowerPC -mcpu=power9 enables __float128 without an explicit -mfloat128

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Created attachment 38860
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38860=edit
Proposed patch to fix the problem

[Bug target/71806] New: PowerPC -mcpu=power9 enables __float128 without an explicit -mfloat128

[meissner at gcc dot gnu.org]

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

Bug ID: 71806
   Summary: PowerPC -mcpu=power9 enables __float128 without an
explicit -mfloat128
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

The macro ISA_3_0_MASKS_SERVER includes OPTION_MASK_FLOAT128_HW, which enables
the -mfloat128 option.  The -mfloat128 option being on by default means that
some of the libraries (libstdc++, libquadmath, etc.) will add code for IEEE
128-bit floating point.

Until all of the libraries are updated to support IEEE 128-bit, the
-mcpu=power9 support should not enable IEEE 128-bit floating point support
(either hardware or software).

In addition, if you configure the compiler with the --with-cpu=power9 option,
it should not enable IEEE 128-bit floating point support by default.

If the user uses -mcpu=power9 -mfloat128, it should enable the hardware support
that is available in ISA 3.0.

[Bug target/71720] initialization of a vector of floats generates incorrect code for -mcpu=power9

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner  ---
Author: meissner
Date: Thu Jul  7 22:44:15 2016
New Revision: 238151

URL: https://gcc.gnu.org/viewcvs?rev=238151=gcc=rev
Log:
Back port from trunk

[gcc]
2016-07-01  Michael Meissner  

PR target/71720
* config/rs6000/vsx.md (vsx_splat_v4sf_internal): When splitting
the insns, use an insn form that does not adjust the offset on
little endian systems.

[gcc/testsuite]
2016-07-01  Michael Meissner  

PR target/71720
* gcc.target/powerpc/pr71720.c: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr71720.c
  - copied, changed from r238126,
trunk/gcc/testsuite/gcc.target/powerpc/pr71720.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/vsx.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/71677] PowerPC ISA 3.0 DImode load/store needs a fix

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #4 from Michael Meissner  ---
Fixed in subversion id 237898. This is not an issue in GCC 6.2, since the patch
that triggered this bug has not been backported to GCC 6.2.

[Bug tree-optimization/71802] [7 Regression] gcc ICE at -O3 on valid code on x86_64-linux-gnu in expand_LOOP_VECTORIZED

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |7.0
Summary|gcc ICE at -O3 on valid |[7 Regression] gcc ICE at
   |code on x86_64-linux-gnu in |-O3 on valid code on
   |expand_LOOP_VECTORIZED  |x86_64-linux-gnu in
   ||expand_LOOP_VECTORIZED

[Bug fortran/71717] A gfortran silent "wrong code" bug in the transition from 4.9.0 -> 4.9.1, using OpenMP.

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul  7 21:55:37 2016
New Revision: 238148

URL: https://gcc.gnu.org/viewcvs?rev=238148=gcc=rev
Log:
Backported from mainline
2016-07-01  Jakub Jelinek  

PR fortran/71717
* trans-openmp.c (gfc_omp_privatize_by_reference): Return false
for GFC_DECL_ASSOCIATE_VAR_P with POINTER_TYPE.

* testsuite/libgomp.fortran/associate3.f90: New test.

Added:
branches/gcc-4_9-branch/libgomp/testsuite/libgomp.fortran/associate3.f90
Modified:
branches/gcc-4_9-branch/gcc/fortran/ChangeLog
branches/gcc-4_9-branch/gcc/fortran/trans-openmp.c
branches/gcc-4_9-branch/libgomp/ChangeLog

[Bug c/71803] Wpedantic: enumerator value is not an integer constant expression

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
1 << 31

is not a constant integral expression in C99/C90/C11 since you are overflowing
the 1 to the sign bit.  If you want 1 << 31, then you can use "(int)(1u << 31)"
or if you want unsigned then you can just do 1u << 31.

[Bug fortran/71704] ICE with -fopenmp and some omp constructs

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul  7 21:54:34 2016
New Revision: 238147

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

PR fortran/71704
* parse.c (matchs, matcho): If spec_only, only gfc_match the keyword
and if successful, goto do_spec_only.
(matchds, matchdo): Define.
(decode_omp_directive): Add spec_only local var and set it.
Use matchds or matchdo macros instead of matchs or matcho
for declare target, declare simd, declare reduction and threadprivate
directives.  Return ST_GET_FCN_CHARACTERISTICS if a non-declarative
directive could be matched.
(next_statement): For ST_GET_FCN_CHARACTERISTICS restore
gfc_current_locus from old_locus even if there is no label.

* gfortran.dg/gomp/pr71704.f90: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/gomp/pr71704.f90
Modified:
branches/gcc-4_9-branch/gcc/fortran/ChangeLog
branches/gcc-4_9-branch/gcc/fortran/parse.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug fortran/71705] [4.9 Regression] ICE in lower_omp_target, at omp-low.c:16136

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul  7 21:53:53 2016
New Revision: 238146

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

PR fortran/71705
* trans-openmp.c (gfc_trans_omp_clauses): Set TREE_ADDRESSABLE on
decls in to/from clauses.

* gfortran.dg/gomp/pr71705.f90: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/gomp/pr71705.f90
Modified:
branches/gcc-4_9-branch/gcc/fortran/ChangeLog
branches/gcc-4_9-branch/gcc/fortran/trans-openmp.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug middle-end/71626] [4.9 regression] ICE at -O1 and above on x86_64-linux-gnu (in output_constant_pool_2, at varasm.c:3837)

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul  7 21:53:12 2016
New Revision: 238145

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

PR middle-end/71626
* config/i386/i386.c (ix86_expand_vector_move): For SUBREG of
a constant, force its SUBREG_REG into memory or register instead
of whole op1.

* gcc.c-torture/execute/pr71626-1.c: New test.
* gcc.c-torture/execute/pr71626-2.c: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.c-torture/execute/pr71626-1.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.c-torture/execute/pr71626-2.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/i386/i386.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/71588] [4.9 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in execute_todo, at passes.c:2009

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul  7 21:52:31 2016
New Revision: 238144

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

PR tree-optimization/71588
* tree-ssa-strlen.c (valid_builtin_call): New function.
(adjust_last_stmt, strlen_optimize_stmt): Use it.

* gcc.dg/pr71558.c: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr71558.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/tree-ssa-strlen.c

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

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul  7 21:51:57 2016
New Revision: 238143

URL: https://gcc.gnu.org/viewcvs?rev=238143=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-4_9-branch/gcc/testsuite/gcc.c-torture/execute/pr71494.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/tree-nested.c

[Bug sanitizer/71160] libasan: Backport support for malloc within dlsym

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul  7 21:51:21 2016
New Revision: 238142

URL: https://gcc.gnu.org/viewcvs?rev=238142=gcc=rev
Log:
Backported from mainline
2016-05-17  Jakub Jelinek  

PR sanitizer/71160
* asan/asan_malloc_linux.cc: Cherry pick upstream r254395
and r269633.

Modified:
branches/gcc-4_9-branch/libsanitizer/ChangeLog
branches/gcc-4_9-branch/libsanitizer/asan/asan_malloc_linux.cc

[Bug rtl-optimization/70429] Wrong code with -O1.

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul  7 21:50:41 2016
New Revision: 238141

URL: https://gcc.gnu.org/viewcvs?rev=238141=gcc=rev
Log:
Backported from mainline
2016-03-29  Jakub Jelinek  

PR rtl-optimization/70429
* combine.c (simplify_shift_const_1): For ASHIFTRT don't optimize
(cst1 >> count) >> cst2 into (cst1 >> cst2) >> count if
mode != result_mode.

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

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.c-torture/execute/pr70429.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/combine.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/70222] Test miscompiled with -O1

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul  7 21:49:58 2016
New Revision: 238140

URL: https://gcc.gnu.org/viewcvs?rev=238140=gcc=rev
Log:
Backported from mainline
2016-03-15  Jakub Jelinek  

PR rtl-optimization/70222
* combine.c (simplify_shift_const_1): For A >> B >> C LSHIFTRT
optimization if mode is different from result_mode, queue up masking
of the result in outer_op.  Formatting fix.

* gcc.c-torture/execute/pr70222-1.c: New test.
* gcc.c-torture/execute/pr70222-2.c: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.c-torture/execute/pr70222-1.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.c-torture/execute/pr70222-2.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/combine.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/70152] [4.9 Regression] gcc ICE at -O3 and above on valid code on x86_64-linux-gnu in "replace_uses_by"

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul  7 21:48:25 2016
New Revision: 238138

URL: https://gcc.gnu.org/viewcvs?rev=238138=gcc=rev
Log:
Backported from mainline
2016-03-09  Jakub Jelinek  

PR tree-optimization/70152
* tree-sra.c (replace_removed_params_ssa_names): Copy over
SSA_NAME_OCCURS_IN_ABNORMAL_PHI from old_name to new_name.

* gcc.dg/pr70152.c: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr70152.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/tree-sra.c

[Bug c/71805] New: incorrect code for test pr45752.c with -mcpu=power9

[acsawdey at gcc dot gnu.org]

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

Bug ID: 71805
   Summary: incorrect code for test pr45752.c with -mcpu=power9
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acsawdey at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, meissner at gcc dot gnu.org,
wschmidt at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64le-linux

Created attachment 38859
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38859=edit
objdump of generated binary plus my annotations which are abstracted in the
note above

testsuite/gcc.dg/vect/pr45752.c is producing some code where it seems like a
register value needed is being overwritten

Compile flags:

/home/sawdey/src/gcc/gcc-6-branch/build/gcc/xgcc
-B/home/sawdey/src/gcc/gcc-6-branch/build/gcc/
/home/sawdey/src/gcc/gcc-6-branch/gcc/gcc/testsuite/gcc.dg/vect/pr45752.c 
-mcpu=power9 -Wl,-rpath=/tmp/lib64  -fno-diagnostics-show-caret
-fdiagnostics-color=never  -flto -ffat-lto-objects -maltivec -mpower9-vector
-ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details
--param tree-reassoc-width=1  -lm  -o ./pr45752.exe

The compiler is gcc-6-branch 238072 plus bergner's p9 VMX ICE patch and
kelvin's vpermr fix.

The 4th group of 4 results is incorrect:
(gdb) p check_results
$24 = {3208, 1334, 28764, 35679, 2789, 13028, 4754, 168364, 91254, 12399,
22848, 8174, 307964, 146829, 22009, 32668, 11594, 447564, 202404, 31619}
(gdb) p output
$25 = {3208, 1334, 28764, 35679, 2789, 13028, 4754, 168364, 91254, 12399,
22848, 8174, 310424, 178137, 26529, 31036, 11594, 447564, 202404, 31619}

This is my extraction of the dataflow for the incorrect vector:

1788:   09 00 e9 f5 lxv vs47,0(r9) 
<< set vs47/v15 from load
17b8:   09 00 87 f6 lxv vs52,0(r7) 
<< set vs52/v20 from load
1898:   09 01 81 f4 lxv vs36,256(r1)   
<< set vs36/v4 from load
18f8:   99 01 61 f7 lxv vs59,400(r1)   
<< set vs59 from load
1900:   89 01 01 f4 lxv vs32,384(r1)   
<< set vs32 from load
1918:   01 00 e7 f7 lxv vs31,0(r7) 
<< set vs31 from load
194c:   01 00 49 f4 lxv vs2,0(r9)  
<< set vs2 from load
1950:   01 00 a7 f5 lxv vs13,0(r7) 
<< set vs13 from load
1958:   eb 03 fb 11 vperm   v15,v27,v0,v15 
<< set v15/vs47 from v27, v0, v15
1988:   8c 22 81 11 vspltw  v12,v4,1   
<< set v12/vs44 from v4/vs36
1994:   01 00 29 f4 lxv vs1,0(r9)  
<< set vs1 from load
19a0:   96 64 ac f2 xxlor   vs21,vs44,vs44 
<< set vs21 from vs44/v12
19a4:   8c 22 83 11 vspltw  v12,v4,3   
<< set v12/vs44 from v4/vs36
19c0:   96 64 8c f0 xxlor   vs4,vs44,vs44  
<< set vs4 from vs44/v12
19cc:   91 ac b5 f1 xxlor   vs45,vs21,vs21 
<< set vs45/v13 from vs21
19d0:   91 fc df f1 xxlor   vs46,vs31,vs31 
<< set vs46/v14 from vs31
19f0:   96 7c af f0 xxlor   vs5,vs47,vs47  
<< set vs5 from vs47/v15
19fc:   89 70 ed 10 vmuluwm v7,v13,v14 
<< set v7/vs39 from v13, v14
1a08:   91 14 a2 f1 xxlor   vs45,vs2,vs2   
<< set vs45/v13 from vs2
1a28:   91 24 84 f1 xxlor   vs44,vs4,vs4   
<< set v12/vs44 from vs4
1a2c:   89 68 8c 11 vmuluwm v12,v12,v13
<< set v12/vs44 from v12, v13
1a3c:   96 64 8c f0 xxlor   vs4,vs44,vs44  
<< set vs4 from vs44/v12
1a40:   f9 00 81 f5 lxv vs44,240(r1)   
<< set vs44/v12 from load
1a44:   8c 62 c0 11 vspltw  v14,v12,0  
<< set v14/vs46 from v12/vs44
1aa0:   d4 68 5a f1 xxperm  vs10,vs58,vs13 
<< set vs10 from vs58, vs13
1aa4:   8c 22 40 13 vspltw  v26,v4,0   
<< set v26/vs58 from v4/vs36
1acc:   01 00 c7 f7 lxv vs30,0(r7) 
<< set vs30 from load
1b08:   91 0c 81 f1 xxlor   vs44,vs1,vs1   
<< set vs44/v12 from vs1
1b0c:   89 60 ce 11 vmuluwm v14,v14,v12   

[Bug tree-optimization/70169] [4.9 Regression] ICE at -O1 and above on x86_64-linux-gnu in gen_lsm_tmp_name, at tree-ssa-loop.c:791

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul  7 21:49:12 2016
New Revision: 238139

URL: https://gcc.gnu.org/viewcvs?rev=238139=gcc=rev
Log:
Backported from mainline
2016-03-11  Jakub Jelinek  

PR tree-optimization/70169
* tree-ssa-loop.c (gen_lsm_tmp_name): Handle FUNCTION_DECL and
LABEL_DECL like VAR_DECL.  Emit nothing instead of gcc_unreachable
for unknown codes.

* gcc.dg/pr70169.c: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr70169.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/tree-ssa-loop.c

[Bug rtl-optimization/69891] wrong code with -mstringop-strategy=libcall @ i686

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul  7 21:47:40 2016
New Revision: 238137

URL: https://gcc.gnu.org/viewcvs?rev=238137=gcc=rev
Log:
Backported from mainline
2016-02-26  Jakub Jelinek  
Eric Botcazou  

PR rtl-optimization/69891
* dse.c (scan_insn): If we can't figure out memset arguments
or they are non-constant, call clear_rhs_from_active_local_stores.

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

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

[Bug c++/67767] -Wsuggest-attribute=noreturn suggests noreturn for function which already has noreturn and cold.

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul  7 21:46:54 2016
New Revision: 238136

URL: https://gcc.gnu.org/viewcvs?rev=238136=gcc=rev
Log:
Backported from mainline
2016-02-19  Jakub Jelinek  

PR c++/67767
* parser.c (cp_parser_std_attribute_spec_seq): Don't assume
attr_spec is always single element chain, chain all the attributes
properly together in the right order.

* g++.dg/cpp0x/pr67767.C: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/pr67767.C
Modified:
branches/gcc-4_9-branch/gcc/cp/ChangeLog
branches/gcc-4_9-branch/gcc/cp/parser.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/69802] [4.9 Regression] gcc ICE at -O1 and above on valid code on x86_64-linux-gnu with “seg fault”

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul  7 21:46:16 2016
New Revision: 238135

URL: https://gcc.gnu.org/viewcvs?rev=238135=gcc=rev
Log:
Backported from mainline
2016-02-16  Jakub Jelinek  

PR tree-optimization/69802
* tree-ssa-reassoc.c (update_range_test): If op is
SSA_NAME_IS_DEFAULT_DEF, give up unless tem is a positive
op == 1 test of precision 1 integral op, otherwise handle
that case as op itself.  Fix up formatting.
(optimize_range_tests_to_bit_test, optimize_range_tests): Fix
up formatting.

* gcc.dg/pr69802.c: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr69802.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/tree-ssa-reassoc.c

[Bug c++/69797] [4.9 Regression] ICE on invalid code on x86_64-linux-gnu in operator[], at vec.h:714

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul  7 21:45:11 2016
New Revision: 238134

URL: https://gcc.gnu.org/viewcvs?rev=238134=gcc=rev
Log:
Backported from mainline
2016-02-15  Jakub Jelinek  

PR c++/69797
* c-common.c (sync_resolve_size): Diagnose too few arguments
even when params is non-NULL empty vector.

* c-c++-common/pr69797.c: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/pr69797.c
Modified:
branches/gcc-4_9-branch/gcc/c-family/ChangeLog
branches/gcc-4_9-branch/gcc/c-family/c-common.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug c++/71804] Default-generated constructor does not construct base class

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

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

--- Comment #1 from Marc Glisse  ---
This is not the right place to learn about C++. Before filing a bug report
about a compiler, please find another compiler that behaves differently. If all
compilers behave the same, it is unlikely to be a bug.

[Bug middle-end/70022] [4.9 Regression] ICE: in tree_to_shwi, at tree.c:7328 with out-of-bounds vector index

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul  7 21:44:11 2016
New Revision: 238133

URL: https://gcc.gnu.org/viewcvs?rev=238133=gcc=rev
Log:
Backported from mainline
2016-03-02  Jakub Jelinek  

PR middle-end/70022
* gcc.dg/pr70022.c: Add -w -Wno-psabi to dg-options.

Modified:
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr70022.c

[Bug tree-optimization/64280] [5 Regression] ICE in replace_uses_by, at tree-cfg.c:1789

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul  7 21:43:34 2016
New Revision: 238132

URL: https://gcc.gnu.org/viewcvs?rev=238132=gcc=rev
Log:
Backported from mainline
2014-12-12  Richard Biener  

PR middle-end/64280
* tree-cfg.c (replace_uses_by): Guard assert properly.

* g++.dg/torture/pr64280.C: New testcase.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/torture/pr64280.C
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/tree-cfg.c

[Bug c++/71804] New: Default-generated constructor does not construct base class

[guille at cal dot berkeley.edu]

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

Bug ID: 71804
   Summary: Default-generated constructor does not construct base
class
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: guille at cal dot berkeley.edu
  Target Milestone: ---

The following code (below) fails. 

The output of the program is:
B() -> INSERT: 0x7fff570c8b2f
~B() -> ERASE: 0x7fff570c8b2f
~B() -> ERASE: 0x7fff570c8b40
Assertion failed: (!all.empty()), function ~B, file gcc_bug.c, line 20.

Two default-generated constructors are generated for A, one has no arguments,
and another is a copy/move ctor. As you can see, the former default-generated
constructor constructs the base class B, but the latter doesn't. 

This is a refinement of a previous report, which was not presented correctly. 

*
#include 
#include 
#include 
#include 
#include 


std::set all;

struct B
{
B()
{
std::cerr << "B() -> INSERT: " << this << "\n";
all.insert((std::uintptr_t)this);
}
~B()
{
std::cerr << "~B() -> ERASE: " << this << "\n";
assert(!all.empty());   // FAILS
assert(all.find((std::uintptr_t)this) != all.end());// FAILS
all.erase((std::uintptr_t)this);
}
};
struct A : B {};

static std::experimental::optional f()
{
A a;
return a;
}

int main()
{
auto a = f();
return 0;
}

[Bug c++/71786] Constructor never called

[guille at cal dot berkeley.edu]

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

--- Comment #5 from Guille  ---
Sorry for the confusion, I'll post as a separate report for clarity.

[Bug c/71803] New: Wpedantic: enumerator value is not an integer constant expression

[johan at forberg dot se]

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

Bug ID: 71803
   Summary: Wpedantic: enumerator value is not an integer constant
expression
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johan at forberg dot se
  Target Milestone: ---

This concerns GCC 6.1.1 running on Arch Linux amd64. The following code will
produce a warning if compiled with -Wpedantic:

enum { TEST = 1 << 31 };

The warning is:

warning: enumerator value for ‘TEST’ is not an integer constant expression
[-Wpedantic]

But if I instead write 

enum { TEST = 1 << 30 };

There is no warning.

This is unforunate since e.g. the glib/gio headers contain such enums, so they
will add warnings to the compile if using -Wpedantic.

I don't feel that this warning is motivated. According to the C11 standard
(final draft, page 106), an integer constant expression "shall have integer
type and shall only have operands that are integer constants", which by my
understanding this expression satisfies.

Thanks for you attention,
Johan

[Bug tree-optimization/71802] New: gcc ICE at -O3 on valid code on x86_64-linux-gnu in expand_LOOP_VECTORIZED

[helloqirun at gmail dot com]

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

Bug ID: 71802
   Summary: gcc ICE at -O3 on valid code on x86_64-linux-gnu in
expand_LOOP_VECTORIZED
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

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


It appears to be a 7 regression.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 7.0.0 20160707 (experimental) [trunk revision 238108] (GCC) 



$ gcc-trunk -O3 abc.c
abc.c: In function ‘fn1’:
abc.c:26:7: warning: assignment from incompatible pointer type
[-Wincompatible-pointer-types]
 i = 
   ^
abc.c:28:7: warning: assignment from incompatible pointer type
[-Wincompatible-pointer-types]
 i = 
   ^
abc.c:3:6: internal compiler error: in expand_LOOP_VECTORIZED, at
internal-fn.c:1944
 void fn1() {
  ^~~
0x969f07 expand_LOOP_VECTORIZED
../../gcc/gcc/internal-fn.c:1944
0x75a117 expand_call_stmt
../../gcc/gcc/cfgexpand.c:2573
0x75a117 expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:3574
0x75a117 expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:3740
0x75d700 expand_gimple_basic_block
../../gcc/gcc/cfgexpand.c:5747
0x7624c6 execute
../../gcc/gcc/cfgexpand.c:6362
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.


$ cat abc.c
int b, c;
long d, f;
void fn1() {
  char g;
  long long h = 0;
  int *i;
  if (0) {
  L2:
b && (b = f);
d = 3;
for (; d;) {
  char *j = 
  c = *j = 0;
L3:
  *j %= b;
  for (; g <= 4;)
;
}
goto L2;
  }
  for (; *i; *i = 1) {
if ((h -= 4) == (h != (b ?: d))) {
  g = 3;
  goto L3;
}
i = 
*i = f;
i = 
if ((h && 6) - (h = 0))
  goto L2;
  }
  for (; d;)
goto L3;
}

[Bug target/71801] [7 Regrexssion] ice in fix_debug_reg_uses

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |7.0
Summary|ice in fix_debug_reg_uses   |[7 Regrexssion] ice in
   ||fix_debug_reg_uses

[Bug rtl-optimization/71621] [7 Regression] ICE in assign_by_spills, at lra-assigns.c:1417 (error: unable to find a register to spill) w/ -O2 -mavx2 -ftree-vectorize

[vmakarov at gcc dot gnu.org]

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

--- Comment #3 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #1)
> Started with r237556, but that just likely made it no longer latent.

Yes, it is a latent bug permitting wrong combination of class and mode for a
reload pseudo.  I am working on it and I hope the fix will be ready on Friday.

[Bug c/71801] New: ice in fix_debug_reg_uses

[dcb314 at hotmail dot com]

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

Bug ID: 71801
   Summary: ice in fix_debug_reg_uses
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 38858
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38858=edit
C source code

The attached code, when compiled by gcc trunk dated 20160706, and
compiler flags -g -O2, does this:

$ ../results/bin/gcc -c -O2 -g bug296.c
bylabel.c: In function ‘uuidcache_init’:
bylabel.c:197:1: internal compiler error: in fix_debug_reg_uses, at
config/i386/i386.c:3818
0xfa7d15 timode_scalar_chain::fix_debug_reg_uses(rtx_def*)
../../src/trunk/gcc/config/i386/i386.c:3817
0xfaba12 timode_scalar_chain::fix_debug_reg_uses(rtx_def*)
../../src/trunk/gcc/config/i386/i386.c:3799
0xfaba12 timode_scalar_chain::convert_insn(rtx_insn*)
../../src/trunk/gcc/config/i386/i386.c:3844
0xfd1b10 scalar_chain::convert()
../../src/trunk/gcc/config/i386/i386.c:3932

[Bug target/25287] PPC has conditional indirect jumps if ra allocates the a in ctr before the jumps

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #3 from Segher Boessenkool  ---
But then we always run the mtctr, also when the condition is false.
Are there CPUs where this is better than branching around it?  On most
CPUs "simple" conditional branches are free.

[Bug c++/71100] [6/7 regression] Internal compiler error while calling a pointer to member function that throws

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||dominik.strasser@onespin-so
   ||lutions.com

--- Comment #7 from Jakub Jelinek  ---
*** Bug 71553 has been marked as a duplicate of this bug. ***

[Bug c++/71553] [6 regression]ICE in assign_temp, at function.c:961

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
I believe this is a dup of PR71100, which is fixed on gcc-6-branch since
r236431.

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

[Bug c++/71786] Constructor never called

[guille at cal dot berkeley.edu]

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

--- Comment #4 from Guille  ---
Hi Marc, 

Thank you for your clarification. 

I realized my initial problem arose in a slightly more complicated case
(below).

In this case a copy/move ctor of A is used, but this default-generated ctor
does not construct the base case B. Shouldn't default ctors automatically
construct base classes?

std::set all;

struct B
{
B()
{
all.insert((std::uintptr_t)this);
}
~B()
{
assert(all.find((std::uintptr_t)this) != all.end());// FAILS
all.erase((std::uintptr_t)this);
}
};
struct A : B
{
A() : B() {}
//  A(const A&) : B() {}
~A() {}
};

static std::experimental::optional f()
{
A a;
return a;
}

int main()
{
auto a = f();
return 0;
}

[Bug c++/70869] [6/7 Regression] internal compiler error: Segmentation fault on array of pointer to function members

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul  7 18:45:43 2016
New Revision: 238124

URL: https://gcc.gnu.org/viewcvs?rev=238124=gcc=rev
Log:
PR c++/70869
PR c++/71054
* cp-gimplify.c (cp_genericize_r): For DECL_EXPR for non-static
artificial vars, genericize their initializers.

* g++.dg/cpp0x/pr70869.C: New test.
* g++.dg/cpp0x/pr71054.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr70869.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr71054.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/71054] [6/7 Regression] ICE: in expand_expr_real_2, at expr.c:8097

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul  7 18:45:43 2016
New Revision: 238124

URL: https://gcc.gnu.org/viewcvs?rev=238124=gcc=rev
Log:
PR c++/70869
PR c++/71054
* cp-gimplify.c (cp_genericize_r): For DECL_EXPR for non-static
artificial vars, genericize their initializers.

* g++.dg/cpp0x/pr70869.C: New test.
* g++.dg/cpp0x/pr71054.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr70869.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr71054.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/67308] FATAL: ThreadSanitizer: unexpected memory mapping

[ppnht at netscape dot net]

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

Paulo R. Panhoto  changed:

   What|Removed |Added

 CC||ppnht at netscape dot net

--- Comment #4 from Paulo R. Panhoto  ---
I've got the same problem with GCC 4.8.5 and that release doesn't allow me to
exclude the -pie flag. 

gcc: error: -fsanitize=thread linking must be done with -pie or -shared

[Bug tree-optimization/71702] dr_group_sort_cmp violates transitivity required for qsort

[amonakov at gcc dot gnu.org]

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

--- Comment #3 from Alexander Monakov  ---
On 6/trunk, this issue is fixed or made latent by r230667 that added

+  STRIP_NOPS (t1);
+  STRIP_NOPS (t2);

to tree-vect-data-refs.c:compare_tree (patch submission here:
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02444.html ).
Should this change be backported to 4.9/5 now that an ICE is demonstrated?

On trunk, backing out that change and adding a qsort comparator checking to
vec.h causes ICEs in:

gcc.c-torture/execute/pr20527-1.c
gcc.dg/torture/pr52028.c
gcc.dg/torture/pr69174.c
gcc.dg/vect/fast-math-pr43074.c
gcc.dg/vect/pr60841.c
gcc.dg/vect/pr66677.c

(but seemingly no ICEs without that backout on check-c, so — no apparent issue
in other comparators). Thus, qsort comparator checking would uncover this issue
much earlier. Would the corresponding patch be welcome? (under CHECKING_P,
check in O(n^2) time that all pairs in the vector are properly ordered after
qsort, limiting n to 100 to avoid quadraticness hit)

[Bug tree-optimization/71702] dr_group_sort_cmp violates transitivity required for qsort

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

  Attachment #38793|0   |1
is obsolete||

--- Comment #2 from Alexander Monakov  ---
Created attachment 38857
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38857=edit
small testcase

[Bug target/71800] New: GCC generates invalid instruction (stxsiwx) with -mcpu=power7

[pthaugen at gcc dot gnu.org]

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

Bug ID: 71800
   Summary: GCC generates invalid instruction (stxsiwx) with
-mcpu=power7
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pthaugen at gcc dot gnu.org
CC: dje at gcc dot gnu.org, meissner at gcc dot gnu.org,
wschmidt at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc64*-unknown-linux-gnu
Target: powerpc64*-unknown-linux-gnu
 Build: powerpc64*-unknown-linux-gnu

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

Noticed that GCC was generating a Power8 insn, stxsiwx, when -mcpu=power7 was
specified. First noticed in 177.mesa from cpu2000, but 435.gromacs and
454.calculix from cpu2006 have same issue.

Compile options : -O2 -mcpu=power7

[Bug c++/55922] brace initializing parent cause bogus virtual base constructor calls

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #4 from Martin Sebor  ---
I'm not sure how helpful or relevant this is at this point but according to my
testing the wrong code seems to have been emitted since r142404 committed in
the gcc 4.4.0 release cycle:

r142404 | jason | 2008-12-03 14:22:08 -0500 (Wed, 03 Dec 2008) | 6 lines

PR c++/38380
* decl.c (grokdeclarator): Only set DECL_NONCONVERTING_P
on explicit constructors.
* pt.c (tsubst_copy_and_build) [CONSTRUCTOR]: Propagate
CONSTRUCTOR_IS_DIRECT_INIT.

Prior to that, GCC rejected the program with the following error:

error: converting to ‘const B1’ from initializer list would use explicit
constructor ‘B1::B1()’

[Bug target/69019] [5 regression] Failure of test case gcc.target/powerpc/ti_math1.c

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
Author: segher
Date: Thu Jul  7 17:08:00 2016
New Revision: 238121

URL: https://gcc.gnu.org/viewcvs?rev=238121=gcc=rev
Log:
rs6000: Fix gcc.target/powerpc/ti_math1.c on GCC 5 (PR69019)

This testcase currently fails on GCC 5, for LE only.  Since it is fixed
for 6 and later, and backporting the relevant code is rather invasive,
let's just weaken the testcase for GCC 5 instead.


   PR target/69019
   * gcc.target/powerpc/ti_math1.c: Allow addze as well as adde.

Modified:
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/ti_math1.c

[Bug fortran/71796] Link error referencing compiler generated symbol __vtab_xxx

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (7.0).

[Bug fortran/71795] [4.9/5/6/7 Regression] Two Bugs in array constructors (optimization)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||tkoenig at gcc dot gnu.org
  Known to work||4.8.5
  Known to fail||4.9.3, 5.4.0, 6.1.0, 7.0

--- Comment #2 from Dominique d'Humieres  ---
While I can reproduce the problem with the first test in comment 0, I get

   1.1.1. 

with all the versions and optimizations I have tested.

Workaround for the first test: compile it with -fno-frontend-optimize.

[Bug fortran/71799] [7 Regression] ICE in DO loop code emission (gfc_resolve_iterator)

[kargl at gcc dot gnu.org]

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

--- Comment #1 from kargl at gcc dot gnu.org ---
Index: resolve.c
===
--- resolve.c   (revision 237855)
+++ resolve.c   (working copy)
@@ -6515,15 +6515,15 @@ gfc_resolve_iterator (gfc_iterator *iter
   /* Convert start, end, and step to the same type as var.  */
   if (iter->start->ts.kind != iter->var->ts.kind
   || iter->start->ts.type != iter->var->ts.type)
-gfc_convert_type (iter->start, >var->ts, 2);
+gfc_convert_type (iter->start, >var->ts, 1);

   if (iter->end->ts.kind != iter->var->ts.kind
   || iter->end->ts.type != iter->var->ts.type)
-gfc_convert_type (iter->end, >var->ts, 2);
+gfc_convert_type (iter->end, >var->ts, 1);

   if (iter->step->ts.kind != iter->var->ts.kind
   || iter->step->ts.type != iter->var->ts.type)
-gfc_convert_type (iter->step, >var->ts, 2);
+gfc_convert_type (iter->step, >var->ts, 1);

   if (iter->start->expr_type == EXPR_CONSTANT
   && iter->end->expr_type == EXPR_CONSTANT

[Bug fortran/71799] [7 Regression] ICE in DO loop code emission (gfc_resolve_iterator)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |7.0

[Bug fortran/71799] New: [7 Regression] ICE in DO loop code emission (gfc_resolve_iterator)

[marxin at gcc dot gnu.org]

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

Bug ID: 71799
   Summary: [7 Regression] ICE in DO loop code emission
(gfc_resolve_iterator)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Hello.

Accidentally, I came to the following code that triggers an ICE:

$ gfortran ~/Programming/testcases/do-loop-ice.f90
/home/marxin/Programming/testcases/do-loop-ice.f90:5:24:

 do i = 10, HUGE(i) - 10, 222
1
Error: Arithmetic overflow converting INTEGER(4) to INTEGER(1) at (1). This
check can be disabled with the option ‘-fno-range-check’
/home/marxin/Programming/testcases/do-loop-ice.f90:5:24: internal compiler
error: Can't convert ‘INTEGER(4)’ to ‘INTEGER(1)’ at (1)
0x687f81 gfc_internal_error(char const*, ...)
../../gcc/fortran/error.c:1312
0x6a2a8f gfc_convert_type_warn(gfc_expr*, gfc_typespec*, int, int)
../../gcc/fortran/intrinsic.c:4795
0x6ea76a gfc_resolve_iterator(gfc_iterator*, bool, bool)
../../gcc/fortran/resolve.c:6526
0x6ec76d gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:10689
0x6eec92 resolve_codes
../../gcc/fortran/resolve.c:15667
0x6eed81 gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:15701
0x6da18a resolve_all_program_units
../../gcc/fortran/parse.c:5825
0x6da18a gfc_parse_file()
../../gcc/fortran/parse.c:6077
0x71c5c2 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

where:
$ cat ~/Programming/testcases/do-loop-ice.f90
subroutine test2(array, s, block)
integer(1) :: i, block(9), array(2)
integer (8) :: s

do i = 10, HUGE(i) - 10, 222
  s = s + 1
end do

end subroutine test2


I'll prepare fix for that.

[Bug target/71297] [7 regression] ICE on invalid code in altivec_resolve_overloaded_builtin (rs6000-c.c:5106) on powerpc64le-linux

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-07
   Assignee|unassigned at gcc dot gnu.org  |wschmidt at gcc dot 
gnu.org
Summary|ICE on invalid code in  |[7 regression] ICE on
   |altivec_resolve_overloaded_ |invalid code in
   |builtin (rs6000-c.c:5106)   |altivec_resolve_overloaded_
   |on powerpc64le-linux|builtin (rs6000-c.c:5106)
   ||on powerpc64le-linux
 Ever confirmed|0   |1

--- Comment #2 from Bill Schmidt  ---
Confirmed, will submit a fix today.

[Bug rtl-optimization/71793] Volatile local variable passed by value is (wrongly?) optimised away, but the containing loop is not

[db0451 at gmail dot com]

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

--- Comment #2 from DB  ---
Thanks Richard! About this -

> RTL expansion expands x as register copy for some reason

- is this person's explanation about this originating in the ABI accurate?
http://stackoverflow.com/a/38248847/2757035

If so - again not that I expect anyone really to use this pattern! - but from a
Standard perspective, I'm interested whether it forbids such register
allocation, and whether any workaround is feasible. In practical terms, a very
academic exercise :-) but valuable for its implications wrt the Standard and
ABI

[Bug fortran/71798] failure to finalise fortran temporary

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-07
 Blocks||37336
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.9 up to trunk (7.0). Finalization is not implemented in 4.8.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
[Bug 37336] [F03] Finish derived-type finalization

[Bug fortran/58175] [OOP] Incorrect warning message on scalar finalizer

[jhogg41 at gmail dot com]

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

--- Comment #11 from Jonathan Hogg  ---
It looks like there's already a patch there, if you point me at a list of
what needs doing to get it into the code base, I'm happy to take a look.

Thanks,

Jonathan.

On Thu, Jul 7, 2016 at 4:14 PM, dominiq at lps dot ens.fr <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58175
>
> --- Comment #10 from Dominique d'Humieres  ---
> > Still present in 6.1.1, please fix.
>
> You're welcome to do it!
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug fortran/58175] [OOP] Incorrect warning message on scalar finalizer

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
> Still present in 6.1.1, please fix.

You're welcome to do it!

[Bug target/71777] __builtin_cpu_supports() doesn't work on powerpc

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #4 from Peter Bergner  ---
Closing per above.

[Bug target/71779] [5/6/7 regression] isl miscompiled with -mabi=ilp32

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #2 from James Greenhalgh  ---
I'd be surprised if that patch was the real root cause of the issue you're
reporting. Rather it looks like something latent that was exposed by that
patch.

The testcase is a bit too large to easily work with (any ideas for getting the
size down would be helpful), isn't an execute test, and  is difficult to
confirm the exact report with current trunk as the offsets and labels have
changed, but here is what I found:

Here is the relevant memory access coming out of expand. Watch what happens to
insn 1047 (why is that a DImode subreg of an SImode in the first place, rather
than a zero_extend?


;; MEM[(struct isl_obj *)] = _obj_map_vtable;

(insn 1045 1044 1046 (set (reg:SI 480)
(high:SI (symbol_ref:SI ("isl_obj_map_vtable") [flags 0xc0] ))) y.c:12702 -1
 (nil))

(insn 1046 1045 1047 (set (reg/f:SI 479)
(lo_sum:SI (reg:SI 480)
(symbol_ref:SI ("isl_obj_map_vtable") [flags 0xc0] ))) y.c:12702 -1
 (expr_list:REG_EQUAL (symbol_ref:SI ("isl_obj_map_vtable") [flags 0xc0]
)
(nil)))

(insn 1047 1046 1048 (set (reg:DI 481)
(subreg:DI (reg/f:SI 479) 0)) y.c:12702 -1
 (nil))

(insn 1048 1047 0 (set (zero_extract:DI (reg/v:DI 191 [ obj1D.17368 ])
(const_int 32 [0x20])
(const_int 0 [0]))
(reg:DI 481)) y.c:12702 -1
 (nil))
---
Here is the same set of insns just after cse1:

-
(insn 1045 1044 1046 107 (set (reg/f:SI 480)
(reg/f:SI 478)) y.c:12702 49 {*movsi_aarch64}
 (expr_list:REG_EQUAL (high:SI (symbol_ref:SI ("isl_obj_map_vtable") [flags
0xc0] ))
(nil)))
(insn 1046 1045 1047 107 (set (reg/f:SI 479)
(subreg/s/v:SI (reg/f:DI 141 [ SR.304D.17381 ]) 0)) y.c:12702 49
{*movsi_aarch64}
 (expr_list:REG_DEAD (reg/f:SI 480)
(expr_list:REG_EQUAL (symbol_ref:SI ("isl_obj_map_vtable") [flags 0xc0]
)
(nil
(insn 1047 1046 1048 107 (set (reg/f:DI 481)
(subreg:DI (reg/f:SI 477) 0)) y.c:12702 50 {*movdi_aarch64}
 (expr_list:REG_DEAD (reg/f:SI 479)
(nil)))
(insn 1048 1047 1049 107 (set (zero_extract:DI (reg/v:DI 191 [ obj1D.17368 ])
(const_int 32 [0x20])
(const_int 0 [0]))
(reg/f:DI 481)) y.c:12702 691 {*insv_regdi}
 (expr_list:REG_DEAD (reg/f:DI 481)
(nil)))
---
Which eliminates the common symbol_refs, and gets cleaned up as:
---
(insn 1047 1044 1048 107 (set (reg/f:DI 481)
(subreg:DI (reg/f:SI 477) 0)) y.c:12702 50 {*movdi_aarch64}
 (nil))
(insn 1048 1047 1049 107 (set (zero_extract:DI (reg/v:DI 191 [ obj1D.17368 ])
(const_int 32 [0x20])
(const_int 0 [0]))
(reg/f:DI 481)) y.c:12702 691 {*insv_regdi}
 (nil))
---
The next major change is after combine, which merges the zero_extract in with
some other operations...
---

(insn 1047 1044 1048 101 (set (reg/f:DI 481)
(subreg:DI (reg/f:SI 545) 0)) y.c:12702 50 {*movdi_aarch64}
 (nil))
(insn 1050 1049 1051 101 (set (reg:DI 1 x1)
(ior:DI (ashift:DI (reg/v/f:DI 144 [ SR.305D.17382 ])
(const_int 32 [0x20]))
(reg/f:DI 481))) y.c:12702 507 {*ior_ashldi3}
 (expr_list:REG_DEAD (reg/v/f:DI 144 [ SR.305D.17382 ])
(nil)))

---
Later, reload gets to it...
---
 Choosing alt 5 in insn 1047:  (0) r  (1) m {*movdi_aarch64}
  alt=0,overall=0,losers=0,rld_nregs=0
---
And here's what comes out the other side:
---

(insn 1047 1051 1050 102 (set (reg/f:DI 20 x20 [481])
(mem/c:DI (plus:DI (reg/f:DI 29 x29)
(const_int 112 [0x70])) [50 %sfpD.16965+-16 S8 A128]))
y.c:12702 50 {*movdi_aarch64}
 (nil))
---

So I have two questions.

First, where did the DImode paradoxical subreg come from in the first place,
and why wasn't it a zero-extend?

Second, why did reload decide it was safe to choose a memory location for a
paradoxical subreg and widen the size of the memory access?

Not marking it this as confirmed as I haven't verified the ISL code to check it
isn't breaking any Undefined Behavior rules.

[Bug target/71763] powerpc64: ICE due to need for output reload on jump

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #11 from Segher Boessenkool  ---
Fixed.

[Bug fortran/58175] [OOP] Incorrect warning message on scalar finalizer

[jhogg41 at gmail dot com]

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

Jonathan Hogg  changed:

   What|Removed |Added

 CC||jhogg41 at gmail dot com

--- Comment #9 from Jonathan Hogg  ---
Still present in 6.1.1, please fix.

[Bug fortran/71798] New: failure to finalise fortran temporary

[jonathan.hogg at stfc dot ac.uk]

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

Bug ID: 71798
   Summary: failure to finalise fortran temporary
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jonathan.hogg at stfc dot ac.uk
  Target Milestone: ---

Created attachment 38855
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38855=edit
test case

Compiling and running the attached code we get:

$ gfortran-6 -o assign_final assign_final.f90 && ./assign_final 
 Creating1
 Assigned2   1

This seems like a missing finalisation on copy assignment?

1) One might expect there to be a move assignment, and to get the following
output:
   Creating 1   [created in-place for x]
   Finalised 1  [may not happen if final not called on exit from program?]

2) Or a copy assignment, and to get the following:
   Creating 1   [create as temporary]
   Assigned 2 1 [copy temporary to x]
   Finalised 1  [temporary destroyed]
   Finalised 2  [may not happen if final not called on exit from program?]

I note that the intel compiler gives the second sequence, minus cleanup on
exit.
$ ifort -o assign_final assign_final.f90 && ./assign_final 
 Creating1
 Assigned2   1
 Finalised1

I'm using the following version of gfortran:
GNU Fortran (Ubuntu 6.1.1-3ubuntu11~14.04.1) 6.1.1 20160511

[Bug fortran/71705] [4.9 Regression] ICE in lower_omp_target, at omp-low.c:16136

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[4.9/5 Regression] ICE in   |[4.9 Regression] ICE in
   |lower_omp_target, at|lower_omp_target, at
   |omp-low.c:16136 |omp-low.c:16136

--- Comment #7 from Jakub Jelinek  ---
Fixed also for 5.5+.

[Bug middle-end/71626] [4.9 regression] ICE at -O1 and above on x86_64-linux-gnu (in output_constant_pool_2, at varasm.c:3837)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[4.9/5/6 regression] ICE at |[4.9 regression] ICE at -O1
   |-O1 and above on|and above on
   |x86_64-linux-gnu (in|x86_64-linux-gnu (in
   |output_constant_pool_2, at  |output_constant_pool_2, at
   |varasm.c:3837)  |varasm.c:3837)

--- Comment #8 from Jakub Jelinek  ---
Fixed also for 5.5+ and 6.2+.

[Bug tree-optimization/71588] [4.9 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in execute_todo, at passes.c:2009

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[4.9/5 Regression] ICE on   |[4.9 Regression] ICE on
   |valid code at -O2 and -O3   |valid code at -O2 and -O3
   |on x86_64-linux-gnu: in |on x86_64-linux-gnu: in
   |execute_todo, at|execute_todo, at
   |passes.c:2009   |passes.c:2009

--- Comment #8 from Jakub Jelinek  ---
Fixed for 5.5+ now.

[Bug middle-end/71581] [5 Regression] ICE on valid code on x86_64-linux-gnu with -Wuninitialized (Segmentation fault)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Fixed.

[Bug c++/71528] [5 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|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Jakub Jelinek  ---
Fixed.

[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

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

--- Comment #8 from Jakub Jelinek  ---
Fixed.

[Bug middle-end/71494] [4.9 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 Regression] label as |[4.9 Regression] label as
   |value in nested function|value in nested function

--- Comment #7 from Jakub Jelinek  ---
Fixed also for 5.5+.

[Bug sanitizer/71498] ubsan bounds checking influenced by surrounding code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
Fixed.

[Bug c++/70641] [5 Regression] ICE on valid code at -O1 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=70641

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Fixed.

[Bug target/70633] [5 Regression] ICE on valid code at -Os (in 32-bit mode) on x86_64-linux-gnu: output_operand: invalid expression as operand

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
Fixed.

[Bug debug/70628] [5 regression] ICE in get_reg_rtx, at emit-rtl.c:1025

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #15 from Jakub Jelinek  ---
Fixed.

[Bug target/70574] [5 Regression] wrong code with -mavx2, read of partially initialised stack variable

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Fixed.

[Bug c++/70336] [5 regression] Incorrect Wconversion warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #15 from Jakub Jelinek  ---
Fixed.

[Bug c++/71797] New: Spurious unused-variable warning with inline function and unrelated error

[r at queiro dot co.uk]

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

Bug ID: 71797
   Summary: Spurious unused-variable warning with inline function
and unrelated error
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: r at queiro dot co.uk
  Target Milestone: ---

Created attachment 38854
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38854=edit
test case

The unused-variable warning is only produced when another error is present and
FOO_CONSTANT is initialized with an inline function. Otherwise, no warning is
generated. Tested with g++ 4.8.4 and 4.9.3.

~ g++ -Wall foo.cc
In file included from foo.cc:2:0:
foo.h: In constructor ‘Foo::Foo()’:
foo.h:8:13: error: ‘create_a_compile_error’ was not declared in this scope
 Foo() { create_a_compile_error; };
 ^
foo.h: At global scope:
foo.h:5:16: warning: ‘FOO_CONSTANT’ defined but not used [-Wunused-variable]
 const unsigned FOO_CONSTANT = f(4);
^
~ g++ -v 
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.4-2ubuntu1~14.04.3' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--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-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-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 --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 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3)

~ cat foo.ii 
# 1 "foo.cc"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "foo.cc"
static inline unsigned f(unsigned x) {
return x;
}

const unsigned FOO_CONSTANT = f(4);

class Foo {
Foo() { create_a_compile_error; };
};

[Bug c/68062] [4.9 Regression] ICE when comparing vectors

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul  7 12:59:39 2016
New Revision: 238108

URL: https://gcc.gnu.org/viewcvs?rev=238108=gcc=rev
Log:
Backported from mainline
2016-03-02  Jakub Jelinek  

PR c/68062
* c-c++-common/vector-compare-4.c: Add -Wno-psabi to dg-options.

Modified:
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/c-c++-common/vector-compare-4.c

[Bug fortran/71717] A gfortran silent "wrong code" bug in the transition from 4.9.0 -> 4.9.1, using OpenMP.

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul  7 12:51:01 2016
New Revision: 238104

URL: https://gcc.gnu.org/viewcvs?rev=238104=gcc=rev
Log:
Backported from mainline
2016-07-01  Jakub Jelinek  

PR fortran/71717
* trans-openmp.c (gfc_omp_privatize_by_reference): Return false
for GFC_DECL_ASSOCIATE_VAR_P with POINTER_TYPE.

* testsuite/libgomp.fortran/associate3.f90: New test.

Added:
branches/gcc-5-branch/libgomp/testsuite/libgomp.fortran/associate3.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/trans-openmp.c
branches/gcc-5-branch/libgomp/ChangeLog

[Bug fortran/71704] ICE with -fopenmp and some omp constructs

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul  7 12:50:01 2016
New Revision: 238103

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

PR fortran/71704
* parse.c (matchs, matcho): Move right before decode_omp_directive.
If spec_only, only gfc_match the keyword and if successful, goto
do_spec_only.
(matchds, matchdo): Define.
(decode_omp_directive): Add spec_only local var and set it.
Use matchds or matchdo macros instead of matchs or matcho
for declare target, declare simd, declare reduction and threadprivate
directives.  Return ST_GET_FCN_CHARACTERISTICS if a non-declarative
directive could be matched.
(next_statement): For ST_GET_FCN_CHARACTERISTICS restore
gfc_current_locus from old_locus even if there is no label.

* gfortran.dg/gomp/pr71704.f90: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/gomp/pr71704.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/parse.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog