[Bug sanitizer/78294] -fsanitize=thread broken

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
(gdb) up
#2  0x76f8b00a in
__tsan::ScopedIgnoreInterceptors::ScopedIgnoreInterceptors (this=) at ../../../../gcc/libsanitizer/tsan/tsan_rtl.h:549
549 cur_thread()->ignore_interceptors++;
(gdb) disass
Dump of assembler code for function __tsan::Initialize(__tsan::ThreadState*):
   0x76f8afd0 <+0>: cmpb   $0x0,0x278ff5(%rip)#
0x77203fcc <_ZZN6__tsan10InitializeEPNS_11ThreadStateEE14is_initialized>
   0x76f8afd7 <+7>: je 0x76f8afe0
<__tsan::Initialize(__tsan::ThreadState*)+16>
   0x76f8afd9 <+9>: repz retq
   0x76f8afdb <+11>:nopl   0x0(%rax,%rax,1)
   0x76f8afe0 <+16>:push   %r15
   0x76f8afe2 <+18>:push   %r14
   0x76f8afe4 <+20>:push   %r13
   0x76f8afe6 <+22>:push   %r12
   0x76f8afe8 <+24>:push   %rbp
   0x76f8afe9 <+25>:push   %rbx
   0x76f8afea <+26>:sub$0x48,%rsp
   0x76f8afee <+30>:movb   $0x1,0x278fd7(%rip)#
0x77203fcc <_ZZN6__tsan10InitializeEPNS_11ThreadStateEE14is_initialized>
   0x76f8aff5 <+37>:mov%rdi,0x18(%rsp)
   0x76f8affa <+42>:data16 lea 0x6cf66(%rip),%rdi#
0x76ff7f68
   0x76f8b002 <+50>:data16 data16 callq 0x76f3ed20
<__tls_get_addr@plt>
=> 0x76f8b00a <+58>:lea0xce6f(%rip),%rdi#
0x76f97e80 <__tsan::TsanCheckFailed(char const*, int, char const*, unsigned
long long, unsigned long long)>
   0x76f8b011 <+65>:lea0x3df3b(%rip),%rcx#
0x76fc8f53
   0x76f8b018 <+72>:addl   $0x1,0x20298(%rax)
   0x76f8b01f <+79>:lea0x6f4b2(%rip),%rax#
0x76ffa4d8 <_ZN11__sanitizer17SanitizerToolNameE>
   0x76f8b026 <+86>:mov%rcx,(%rax)
   0x76f8b029 <+89>:callq  0x76fb4760
<__sanitizer::SetCheckFailedCallback(void (*)(char const*, int, char const*,
unsigned long long, unsigned long long))>
   0x76f8b02e <+94>:lea0x27908b(%rip),%rdi#
0x772040c0 <_ZN6__tsanL15ctx_placeholderE>
   0x76f8b035 <+101>:   callq  0x76f8a960
<__tsan::Context::Context()>

[Bug sanitizer/78294] -fsanitize=thread broken

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
(gdb) up
#3  __tsan::Initialize (thr=thr@entry=0x76277780) at
../../../../gcc/libsanitizer/tsan/tsan_rtl.cc:331
331   ScopedIgnoreInterceptors ignore;
(gdb) disass
Dump of assembler code for function __tsan::Initialize(__tsan::ThreadState*):
   0x76f8afd0 <+0>: cmpb   $0x0,0x278ff5(%rip)#
0x77203fcc <_ZZN6__tsan10InitializeEPNS_11ThreadStateEE14is_initialized>
   0x76f8afd7 <+7>: je 0x76f8afe0
<__tsan::Initialize(__tsan::ThreadState*)+16>
   0x76f8afd9 <+9>: repz retq
   0x76f8afdb <+11>:nopl   0x0(%rax,%rax,1)
   0x76f8afe0 <+16>:push   %r15
   0x76f8afe2 <+18>:push   %r14
   0x76f8afe4 <+20>:push   %r13
   0x76f8afe6 <+22>:push   %r12
   0x76f8afe8 <+24>:push   %rbp
   0x76f8afe9 <+25>:push   %rbx
   0x76f8afea <+26>:sub$0x48,%rsp
   0x76f8afee <+30>:movb   $0x1,0x278fd7(%rip)#
0x77203fcc <_ZZN6__tsan10InitializeEPNS_11ThreadStateEE14is_initialized>
   0x76f8aff5 <+37>:mov%rdi,0x18(%rsp)
   0x76f8affa <+42>:data16 lea 0x6cf66(%rip),%rdi#
0x76ff7f68
   0x76f8b002 <+50>:data16 data16 callq 0x76f3ed20
<__tls_get_addr@plt>
=> 0x76f8b00a <+58>:lea0xce6f(%rip),%rdi#
0x76f97e80 <__tsan::TsanCheckFailed(char const*, int, char const*, unsigned
long long, unsigned long long)>
   0x76f8b011 <+65>:lea0x3df3b(%rip),%rcx#
0x76fc8f53
   0x76f8b018 <+72>:addl   $0x1,0x20298(%rax)
   0x76f8b01f <+79>:lea0x6f4b2(%rip),%rax#
0x76ffa4d8 <_ZN11__sanitizer17SanitizerToolNameE>
   0x76f8b026 <+86>:mov%rcx,(%rax)

[Bug tree-optimization/71575] [6/7 Regression] [graphite] internal compiler error: in copy_cond_phi_nodes, at graphite-isl-ast-to-gimple.c:2500

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
We run into

#1  0x0175ce2f in translate_isl_ast_to_gimple::copy_cond_phi_nodes (
this=0x7fffd9a0, bb=, 
new_bb=, iv_map=...)
at
/space/rguenther/src/svn/gcc-6-branch/gcc/graphite-isl-ast-to-gimple.c:2498
2498gcc_unreachable ();
(gdb) l
2493  tree res = gimple_phi_result (phi);
2494  if (virtual_operand_p (res))
2495continue;
2496  if (is_gimple_reg (res) && scev_analyzable_p (res,
region->region))
2497/* Cond phi nodes should not be scev_analyzable_p.  */
2498gcc_unreachable ();
2499
2500  gphi *new_phi = create_phi_node (SSA_NAME_VAR (res), new_bb);
2501  tree new_res = create_new_def_for (res, new_phi,
2502 gimple_phi_result_ptr
(new_phi));

the issue went latent on the trunk.

[Bug tree-optimization/71575] [6/7 Regression] [graphite] internal compiler error: in copy_cond_phi_nodes, at graphite-isl-ast-to-gimple.c:2500

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #9 from Richard Biener  ---
I believe the assertion is simply bogus -- some condition PHIs _can_ be
analyzed by SCEV.  Removing the assert "fixes" the testcase.

[Bug tree-optimization/59859] [meta-bug] GRAPHITE issues

[rguenth at gcc dot gnu.org]

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

Bug 71380 Summary: [7 Regression] internal compiler error: in 
copy_cond_phi_nodes, at graphite-isl-ast-to-gimple.c:2498
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71380

   What|Removed |Added

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

[Bug tree-optimization/71380] [7 Regression] internal compiler error: in copy_cond_phi_nodes, at graphite-isl-ast-to-gimple.c:2498

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Duplicate of PR71575, same fix works.

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

[Bug tree-optimization/71575] [6/7 Regression] [graphite] internal compiler error: in copy_cond_phi_nodes, at graphite-isl-ast-to-gimple.c:2500

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Testcase from the duplicate (ICEs on trunk)

int *a;
int b, c, d, e, g;
char f;

void fn1() {
  for (; c;) {
b = 0;
for (; b <= 2; b++) {
  unsigned **h = (unsigned **) &a[b];
  *h = (g && (e = d)) != f++;
}
  }
}

on aarch64 with -Ofast -floop-interchange.

[Bug tree-optimization/71575] [6/7 Regression] [graphite] internal compiler error: in copy_cond_phi_nodes, at graphite-isl-ast-to-gimple.c:2500

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #10 from Richard Biener  ---
*** Bug 71380 has been marked as a duplicate of this bug. ***

[Bug testsuite/78292] [7 regression] test case gcc.dg/vect/vect-cond-2.c fails starting with r241967

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-11
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
also seen on x86-64

[Bug fortran/78293] [5/6/7 Regression] SIGABRT with function result used as argument

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |5.5

[Bug middle-end/78295] [7 Regression] Spurious -Wuninitialized warning for vector element assignment

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
The late uninit pass warns about

;; 2 loops found
f (double x)
{
  int i;
  vectype t;

  :
  t_16 = BIT_INSERT_EXPR ;
  t_2 = BIT_INSERT_EXPR ;
  return t_2;

}

where the first statement constitutes a partial initialization of the
previously completely uninitialized t_12(D).  In BIT_INSERT_EXPR the
first argument is a "destination" and thus should not constitute a use
by late uninit.

[Bug ipa/78296] [7 regression] test case gcc.dg/ipa/vrp7.c fails starting with r242032

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug c/78304] [7 Regression] -Wformat doesn't warn anymore for inttypes.h format string argument type mismatches

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
   Target Milestone|--- |7.0
Summary|-Wformat doesn't warn   |[7 Regression] -Wformat
   |anymore for inttypes.h  |doesn't warn anymore for
   |format string argument type |inttypes.h format string
   |mismatches  |argument type mismatches

[Bug tree-optimization/78305] Wrong constant folding

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Huh, didn't I fix that ... ah no, I only fixed sth related (negating of x).

[Bug target/77822] [6 Regression] arm64 Error: immediate value out of range 0 to 63 at operand 3

[krebbel at gcc dot gnu.org]

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

--- Comment #27 from Andreas Krebbel  ---
Author: krebbel
Date: Fri Nov 11 08:48:29 2016
New Revision: 242066

URL: https://gcc.gnu.org/viewcvs?rev=242066&root=gcc&view=rev
Log:
PR77822: S/390: Add range checks for zero_extract operands.

Make sure the position and size operands of zero_extract are within
the proper range for the mode.

gcc/ChangeLog:

2016-11-11  Dominik Vogt  

PR target/77822
* config/s390/s390.md ("extzv", "*extzv_zEC12")
("*extzv_z10"): Check validity of zero_extend arguments.

gcc/testsuite/ChangeLog:

2016-11-11  Dominik Vogt  

PR target/77822
* gcc.target/s390/pr77822.c: New test for PR/77822.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/s390/s390.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/78298] ICE in lookup_decl_in_outer_ctx, bei omp-low.c:4115

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Confirmed, started with GCC 4.6.0.

[Bug fortran/78299] [6/7 Regression] ICE in expand_omp_for_static_nochunk, at omp-low.c:9622

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-11
 CC||marxin at gcc dot gnu.org,
   ||vries at gcc dot gnu.org
Summary|ICE in  |[6/7 Regression] ICE in
   |expand_omp_for_static_nochu |expand_omp_for_static_nochu
   |nk, at omp-low.c:9622   |nk, at omp-low.c:9622
 Ever confirmed|0   |1
  Known to fail||6.2.0, 7.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r226427.

[Bug c/78306] New: [CilkPlus] "inlining failed in call to always_inline ‘memset’: function not inlinable" with -fcilkplus

[iblue at gmx dot net]

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

Bug ID: 78306
   Summary: [CilkPlus] "inlining failed in call to always_inline
‘memset’: function not inlinable" with -fcilkplus
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iblue at gmx dot net
  Target Milestone: ---

Created attachment 40020
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40020&action=edit
Preprocessed file

Hello everyone,

I encountered a problem with compiling my code and wrote up a small snippet to
reproduce the issue (see below). I get the error message "inlining failed in
call to always_inline ‘memset’: function not inlinable" when setting
-fcilkplus.

Since I carefully read the bug reporting instructions, here are the necessary
informations:

GCC Version: 6.2.0 20161018 (Ubuntu 6.2.0-7ubuntu11).
Sytem type: x86_64-linux-gnu
GCC has been built with: ../src/configure -v --with-pkgversion='Ubuntu
6.2.0-7ubuntu11' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu

Complete commandline that triggers the bug: gcc-6 -O2 -fcilkplus -o test3
test3.c (it won't happen with -O0, but you can also use -O1, -O3 and -Os)

Compiler output:

In file included from /usr/include/features.h:364:0,
 from /usr/include/string.h:25,
 from test3.c:2:
test3.c: In function ‘sum’:
/usr/include/x86_64-linux-gnu/bits/string3.h:78:1: error: inlining failed in
call to always_inline ‘memset’: function not inlinable
 __NTH (memset (void *__dest, int __ch, size_t __len))
 ^
test3.c:16:3: note: called from here
   memset(foo, 0, 64*sizeof(int)); // <--- Fails
   ^~

Source code:
---
#include 
#include 
#include 

int sum(int low, int high) {
  if(low == high) {
return low;
  }

  int mid = low + (high-low)/2;
  int a = cilk_spawn sum(low, mid);
  int b = sum(mid+1, high);

  // Some very expensive computation here
  int foo[64];
  memset(foo, 0, 64*sizeof(int)); // <--- Fails

  cilk_sync;

  return a+b;
}

int main(void) {
  return sum(0, 100);
}
---

I have attached the preprocessed file (because it's quite lengthy).

I think there was a similar bug in GCC 5 when using intrinsics, but that has
been fixed in GCC 6 (see http://stackoverflow.com/q/31846389/773690 - Code
compiles just fine), so that might me a regression or other edge case.

If there is a workaround I can do that would be greatly appreciated if you
could give a short hint. clang compiles the code just fine (but generates slow
code) and icc is expensive.

Thank you very much!

[Bug sanitizer/78307] New: [7 Regression] missing symbols in libubsan without changing the soname

[doko at gcc dot gnu.org]

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

Bug ID: 78307
   Summary: [7 Regression] missing symbols in libubsan without
changing the soname
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

on trunk 20161110, libubsan is missing some symbols while not changing the
soname:

libubsan:
+#MISSING: 7-20161110-1# __ubsan_handle_cfi_bad_icall@Base 6
+#MISSING: 7-20161110-1# __ubsan_handle_cfi_bad_icall_abort@Base 6
+#MISSING: 7-20161110-1# __ubsan_handle_cfi_bad_type@Base 6
+#MISSING: 7-20161110-1# __ubsan_handle_cfi_bad_type_abort@Base 6

[Bug fortran/44348] ICE in build_function_decl

[janus at gcc dot gnu.org]

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

--- Comment #15 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #14)
> > The test in comment 2 compiles without error at revision r242002
> > although I think it is invalid. It gives an ICE with r241962.
> 
> This is due to r241972 (pr77596).

Huh, I don't see how r241972 (which only deals with pointer assignments) could
affect comment 2.

I see it ICEing with r242047, as it did with previous releases:

internal compiler error: in gfc_generate_function_code, at
fortran/trans-decl.c:6147
0x90a75b gfc_generate_function_code(gfc_namespace*)
/home/jweil/gcc/gcc7/trunk/gcc/fortran/trans-decl.c:6147
0x90802b gfc_generate_contained_functions
/home/jweil/gcc/gcc7/trunk/gcc/fortran/trans-decl.c:5241
0x90a92e gfc_generate_function_code(gfc_namespace*)
/home/jweil/gcc/gcc7/trunk/gcc/fortran/trans-decl.c:6190
0x8cdab7 gfc_generate_code(gfc_namespace*)
/home/jweil/gcc/gcc7/trunk/gcc/fortran/trans.c:2030
0x85cceb translate_all_program_units
/home/jweil/gcc/gcc7/trunk/gcc/fortran/parse.c:6038
0x85d360 gfc_parse_file()
/home/jweil/gcc/gcc7/trunk/gcc/fortran/parse.c:6238
0x8b645f gfc_be_parse_file
/home/jweil/gcc/gcc7/trunk/gcc/fortran/f95-lang.c:202

[Bug c++/78264] [7 regression] ICE in build_noexcept_spec, at cp/except.c:1196

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Aldy Hernandez  ---
> As Solaris boxes with their header files are not readily available (at least 
> to

I'm trying to change that (i.e. getting Solaris into the compile farm),
but my mail to Laurent Guerby has remained unanswered for many weeks.

> me), would you mind attaching a preprocessed reduced testcase exhibiting the
> behavior?  Thanks.

With a i386-pc-solaris2.12 compiler, I have this:

$ cat launder.ii
template
void launder(_Ret (*)(_Args...) noexcept (0x0004)) = delete;
$ cc1plus -fpreprocessed launder.ii -quiet -std=c++1z -fconcepts -o launder.s
launder.ii:1:50: error: expected '>' before numeric constant
 template
  ^~
launder.ii:2:53: internal compiler error: in build_noexcept_spec, at
cp/except.c:1196
 void launder(_Ret (*)(_Args...) noexcept (0x0004)) = delete;
 ^
0x8a2fa4b build_noexcept_spec(tree_node*, int)
/vol/gcc/src/hg/trunk/local/gcc/cp/except.c:1196
0x89ef4fa cp_parser_noexcept_specification_opt
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:23489
0x89f36af cp_parser_exception_specification_opt
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:23517
0x89e28b6 cp_parser_direct_declarator
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:19359
0x89e28b6 cp_parser_declarator
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:19205
0x89f199e cp_parser_parameter_declaration
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:20901
0x89f21dc cp_parser_parameter_declaration_list
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:20656
0x89f25c0 cp_parser_parameter_declaration_clause
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:20577
0x89e2e96 cp_parser_direct_declarator
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:19327
0x89e2e96 cp_parser_declarator
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:19205
0x89f7364 cp_parser_init_declarator
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:18739
0x89f9326 cp_parser_single_declaration
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:26334
0x89f94c4 cp_parser_template_declaration_after_parameters
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:25938
0x89f9e07 cp_parser_explicit_template_declaration
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:26174
0x89f9e07 cp_parser_template_declaration_after_export
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:26192
0x89fa479 cp_parser_declaration
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:12370
0x89fa7dd cp_parser_declaration_seq_opt
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:12297
0x89faac8 cp_parser_translation_unit
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:4360
0x89faac8 c_parse_file()
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:37988
0x8b4920b c_common_parse_file()
/vol/gcc/src/hg/trunk/local/gcc/c-family/c-opts.c:1086

Rainer

[Bug c++/78308] New: Hiding of member function templates introduced by using-decl

[g...@axel-naumann.de]

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

Bug ID: 78308
   Summary: Hiding of member function templates introduced by
using-decl
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: g...@axel-naumann.de
  Target Milestone: ---

Hi,

struct A {
  template  auto func(T t) -> decltype(T::member);
};

struct B: A {
  using A::func;
  template  auto func(T t) -> decltype(T::other);
};

struct P { int member; };

void call(B b, P p) {
  b.func(p);
}


GCC accepts this; ICC and clang reject this, refusing to introduce A::func in
B. See also [namespace.udecl](15):

"When a using-declaration brings declarations from a base class into a
derived class, member functions and
member function templates in the derived class override and/or hide
member functions and member function
templates with the same name, parameter-type-list (8.3.5),
cv-qualification, and ref-qualifier (if any) in a
base class (rather than conflicting). Such hidden or overridden
declarations are excluded from the set of
declarations introduced by the using-declaration."

Cheers, Axel.

[Bug fortran/44348] ICE in build_function_decl

[dominiq at lps dot ens.fr]

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

--- Comment #16 from Dominique d'Humieres  ---
> Huh, I don't see how r241972 (which only deals with pointer assignments)
> could affect comment 2.
>
> I see it ICEing with r242047, as it did with previous releases: ...

I am just reporting what I see:

[Book15] f90/bug% /opt/gcc/gcc7p-241962p4/bin/gfortran -c pr44348_1.f90
pr44348_1.f90:3:0:

   SUBROUTINE s

internal compiler error: in gfc_generate_function_code, at
fortran/trans-decl.c:6144

pr44348_1.f90:3:0: internal compiler error: Abort trap: 6
gfortran: internal compiler error: Abort trap: 6 (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[Book15] f90/bug% /opt/gcc/gcc7p-241972p4/bin/gfortran -c pr44348_1.f90
[Book15] f90/bug%

[Bug fortran/44348] ICE in build_function_decl

[janus at gcc dot gnu.org]

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

--- Comment #17 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #16)
> > Huh, I don't see how r241972 (which only deals with pointer assignments)
> > could affect comment 2.
> >
> > I see it ICEing with r242047, as it did with previous releases: ...
> 
> I am just reporting what I see:
>  
> internal compiler error: in gfc_generate_function_code, at
> fortran/trans-decl.c:6144

I do buy that. As mentioned I also see the same ICE.

But your previous message seems to suggest that the ICE is gone on trunk. This
I cannot confirm. And I cannot imagine how my commit would cause that ...

[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2016-11/msg01045.ht
   ||ml
   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org

--- Comment #24 from Rainer Orth  ---
Working fixincludes-based patch posted.

[Bug fortran/44348] ICE in build_function_decl

[dominiq at lps dot ens.fr]

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

--- Comment #18 from Dominique d'Humieres  ---
> But your previous message seems to suggest that the ICE is gone on trunk.
> This I cannot confirm. And I cannot imagine how my commit would cause that ...

You missed:

[Book15] f90/bug% /opt/gcc/gcc7p-241972p4/bin/gfortran -c pr44348_1.f90
[Book15] f90/bug%

I also see it with my latest build (r242058)

[Book15] f90/bug% gfc -c pr44348_1.f90
[Book15] f90/bug%

[Bug sanitizer/78270] [7 Regression] ICE in gimplify_switch_expr, at gimplify.c:2272

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
Not completelly fixed, there's another case from linux kernel.
I've been testing patch for that:

// { dg-do compile }
// { dg-additional-options "-Wno-switch-unreachable" }

int a;
void
fn1 ()
{
  switch (a)
{
  char b;
case 8:
  &b;
  switch (0)
;
}
}

[Bug fortran/44348] ICE in build_function_decl

[janus at gcc dot gnu.org]

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

--- Comment #19 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #18)
> I also see it with my latest build (r242058)
> 
> [Book15] f90/bug% gfc -c pr44348_1.f90
> [Book15] f90/bug%

I cannot confirm that. I do see the ICE on comment 2 at r242066.

[Bug target/77822] [6 Regression] arm64 Error: immediate value out of range 0 to 63 at operand 3

[krebbel at gcc dot gnu.org]

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

--- Comment #28 from Andreas Krebbel  ---
Author: krebbel
Date: Fri Nov 11 10:37:53 2016
New Revision: 242067

URL: https://gcc.gnu.org/viewcvs?rev=242067&root=gcc&view=rev
Log:
S/390: Add PR77822 testcase.

For real this time.

2016-11-11  Dominik Vogt  

PR target/77822
* gcc.target/s390/pr77822.c: New test for PR/77822.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/s390/pr77822.c

[Bug rtl-optimization/78200] [7 Regression] 429.mcf of cpu2006 regresses in GCC trunk for avx2 target.

[venkataramanan.kumar at amd dot com]

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

--- Comment #14 from Venkataramanan  ---
Between GCC 6.2.0 and GCC 7 (Nov/10/2016) I see three major differences in
gimple opts dump.

1. IPA inline is more aggressive in GCC 7. Looks like it is in-lining more in 
hot function "primal_bea_mpp". However completely disabling ipa inline still
produces regression in GCC 7.

2. Non canonicial gimple formation at tree if conversion. This is already
pointed in comment 1.  Using -fno-tree-loop-if-convert in GCC 7 brings back the
runtime same as GCC 6.

3. In GCC 7 the true block is kept after the "red_cost > 0" check. 

red_cost = arc->cost - arc->tail->potential + arc->head->potential;
if( bea_is_dual_infeasible( arc, red_cost ) )
{
 True block ==>   next++;
perm[next]->a = arc;
perm[next]->cost = red_cost;
perm[next]->abs_cost = ABS(red_cost);

Note bea_is_dual_infeasible is expanded by this check 
red_cost < 0 && arc->ident == AT_LOWER)
|| (red_cost > 0 && arc->ident == AT_UPPER)


Tree VRP in GCC6 moves the true block to the last of the gimple blocks.

Now When I compile GCC 6 with -fno-tree-vrp the true block is at same position
as in GCC 7 (trunk). I get the regression in GCC 6.

So block movement in GCC 6 and not done in GCC 7 is also interesting
observation.

[Bug rtl-optimization/78200] [7 Regression] 429.mcf of cpu2006 regresses in GCC trunk for avx2 target.

[rguenther at suse dot de]

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

--- Comment #15 from rguenther at suse dot de  ---
On Fri, 11 Nov 2016, venkataramanan.kumar at amd dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78200
> 
> --- Comment #14 from Venkataramanan  ---
> Between GCC 6.2.0 and GCC 7 (Nov/10/2016) I see three major differences in
> gimple opts dump.
> 
> 1. IPA inline is more aggressive in GCC 7. Looks like it is in-lining more in 
> hot function "primal_bea_mpp". However completely disabling ipa inline still
> produces regression in GCC 7.
> 
> 2. Non canonicial gimple formation at tree if conversion. This is already
> pointed in comment 1.  Using -fno-tree-loop-if-convert in GCC 7 brings back 
> the
> runtime same as GCC 6.
> 
> 3. In GCC 7 the true block is kept after the "red_cost > 0" check. 
> 
> red_cost = arc->cost - arc->tail->potential + 
> arc->head->potential;
> if( bea_is_dual_infeasible( arc, red_cost ) )
> {
>  True block ==>   next++;
> perm[next]->a = arc;
> perm[next]->cost = red_cost;
> perm[next]->abs_cost = ABS(red_cost);
> 
> Note bea_is_dual_infeasible is expanded by this check 
> red_cost < 0 && arc->ident == AT_LOWER)
> || (red_cost > 0 && arc->ident == AT_UPPER)
> 
> 
> Tree VRP in GCC6 moves the true block to the last of the gimple blocks.
> 
> Now When I compile GCC 6 with -fno-tree-vrp the true block is at same position
> as in GCC 7 (trunk). I get the regression in GCC 6.
> 
> So block movement in GCC 6 and not done in GCC 7 is also interesting
> observation.

block movement on gimple doesn't really mean anything but what is 
interesting is the (guessed) profile data on the blocks/edges.

[Bug c++/74762] [5/6/7 Regression] missing uninitialized warning (C++, parenthesized expr, TREE_NO_WARNING)

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
We really need fine grained TREE_NO_WARNING, will see if I manage to implement
something for stage3.

[Bug sanitizer/78307] [7 Regression] missing symbols in libubsan without changing the soname

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ABI
   Priority|P3  |P1
   Target Milestone|--- |7.0

[Bug ipa/78309] New: ICE: in get_hash, at ipa-icf.c:2124

[trippels at gcc dot gnu.org]

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

Bug ID: 78309
   Summary: ICE: in get_hash, at ipa-icf.c:2124
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

During Firefox LTO build I get:

lto1: internal compiler error: in get_hash, at ipa-icf.c:2124
0x11021833 ipa_icf::sem_variable::get_hash()
../../gcc/gcc/ipa-icf.c:2124
0x11020a1f ipa_icf::sem_item::update_hash_by_local_refs(hash_map,
ipa_icf::sem_item*> >&)
../../gcc/gcc/ipa-icf.c:843
0x1102eb93 ipa_icf::sem_item_optimizer::update_hash_by_addr_refs()
../../gcc/gcc/ipa-icf.c:2750
0x11031153 ipa_icf::sem_item_optimizer::execute()
../../gcc/gcc/ipa-icf.c:2612
0x110345cf ipa_icf_driver
../../gcc/gcc/ipa-icf.c:3552
0x110345cf ipa_icf::pass_ipa_icf::execute(function*)
../../gcc/gcc/ipa-icf.c:3599

[Bug c++/77285] [5/6/7 Regression] extern thread_local linkage

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
http://gcc.gnu.org/ml/gcc-patches/2016-11/msg01074.html

[Bug target/78310] New: ICE: insn does not satisfy its constraints: {*bmi2_rorxdi3_1} with -mbmi2

[zsojka at seznam dot cz]

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

Bug ID: 78310
   Summary: ICE: insn does not satisfy its constraints:
{*bmi2_rorxdi3_1} with -mbmi2
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -mbmi2 testcase.c 
testcase.c: In function 'fn1':
testcase.c:12:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 24 11 13 2 (set (reg:DI 0 ax [orig:92 _6 ] [92])
(rotatert:DI (reg:DI 0 ax [orig:90 a.0_4 ] [90])
(const_int 64 [0x40]))) "testcase.c":10 603 {*bmi2_rorxdi3_1}
 (nil))
testcase.c:12:1: internal compiler error: in extract_constrain_insn, at
recog.c:2213
0xb666b3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.c:108
0xb66727 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.c:119
0xb1d59d extract_constrain_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.c:2213
0xb2c448 copyprop_hardreg_forward_1
/repo/gcc-trunk/gcc/regcprop.c:794
0xb2d994 execute
/repo/gcc-trunk/gcc/regcprop.c:1301
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-242046-checking-yes-rtl-df-extra-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--without-cloog --without-ppl --without-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-242046-checking-yes-rtl-df-extra-nographite-amd64
Thread model: posix
gcc version 7.0.0 20161110 (experimental) (GCC)

[Bug c/78306] [CilkPlus] "inlining failed in call to always_inline ‘memset’: function not inlinable" with -fcilkplus

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-11
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
trunk is a little more informative:

> gcc-6 -O2 t.i -fcilkplus -S -fdump-tree-all-details -Winline -B 
> /abuild/rguenther/trunk-g/gcc
In file included from /usr/include/string.h:635:0,
 from test3.c:2:
test3.c: In function 'sum':
/usr/include/x86_64-linux-gnu/bits/string3.h:78:42: error: inlining failed in
call to always_inline 'memset': caller function contains cilk spawn
test3.c:16:3: note: called from here


static bool
can_inline_edge_p (struct cgraph_edge *e, bool report,
   bool disregard_limits = false, bool early = false)
{
...
  else if (inline_summaries->get (caller)->contains_cilk_spawn)
{
  e->inline_failed = CIF_CILK_SPAWN;
  inlinable = false;
}


for whatever (stupid) reason.  Honza added this code with r221706 (without
a testcase).  Disabling it works fine (for this testcase).

A workaround is to separate the memset part of the function to a separate
function...

[Bug inline-asm/78311] New: "register value used as expression" on i386 in inline assembly statement with "o" constraint

[gcc at abeckmann dot de]

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

Bug ID: 78311
   Summary: "register value used as expression" on i386 in inline
assembly statement with "o" constraint
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at abeckmann dot de
  Target Milestone: ---

This is a regression from GCC 5 on i386. 

This code example has been minimized from uqm source which fails to build with
gcc-6 (but succeeds with gcc-5):

== 8< ==
extern unsigned int A [ 42 ] ;
void f ()
{
__asm__ ( "movd %0 (, %%edx, 4), %%mm0 \n\t" : : "o" (*A) : "%edx" ) ;
}
== >8 ==

$ gcc-5 -m32 -W -Wall -c constraint-o.c ; echo $?
0

$ gcc-6 -m32 -W -Wall -c constraint-o.c; echo $?
constraint-o.c: Assembler messages:
constraint-o.c:4: Error: register value used as expression
1

== assembly generated by gcc-5 -S ==
.globl  f
.type   f, @function
f:
.LFB0:
.cfi_startproc
pushl   %ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl%esp, %ebp
.cfi_def_cfa_register 5
#APP
# 4 "constraint-o.c" 1
movd A (, %edx, 4), %mm0 

# 0 "" 2
#NO_APP
nop
popl%ebp
.cfi_restore 5
.cfi_def_cfa 4, 4
ret
.cfi_endproc
==

== assembly generated by gcc-6 -S ==
.globl  f
.type   f, @function
f:
.LFB0:
.cfi_startproc
pushl   %ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl%esp, %ebp
.cfi_def_cfa_register 5
call__x86.get_pc_thunk.ax
addl$_GLOBAL_OFFSET_TABLE_, %eax
movlA@GOT(%eax), %eax
#APP
# 4 "constraint-o.c" 1
movd (%eax) (, %edx, 4), %mm0 

# 0 "" 2
#NO_APP
nop
popl%ebp
.cfi_restore 5
.cfi_def_cfa 4, 4
ret
.cfi_endproc
==

$ gcc-6 --version
gcc-6 (Debian 6.2.0-10) 6.2.0 20161027
$ gcc-5 --version
gcc-5 (Debian 5.4.1-3) 5.4.1 20161019

[Bug ipa/78309] ICE: in get_hash, at ipa-icf.c:2124

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-11
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
That's mine, problem is that update_hash_by_addr_refs updates a non-zero m_hash
to zero by combining with another hashes. I'll prepare patch for that.

[Bug c++/72774] [7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (tree check: expected tree that contains ‘decl minimal’ structure, have ‘tree_list’ in consider_binding_level, at cp/name-loo

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

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

[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||bernds at gcc dot gnu.org,
   ||jgreenhalgh at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |bernds at gcc dot 
gnu.org

--- Comment #2 from Bernd Schmidt  ---
Looks like a mismatch where we use different cost calculations to compare
before/after sequences. The following seems to make it come out right, but it
probably needs a lot of testing to make sure it behaves as intended. (James?)

Index: gcc/rtlanal.c
===
--- gcc/rtlanal.c   (revision 242038)
+++ gcc/rtlanal.c   (working copy)
@@ -5224,13 +5224,8 @@ seq_cost (const rtx_insn *seq, bool spee
   rtx set;

   for (; seq; seq = NEXT_INSN (seq))
-{
-  set = single_set (seq);
-  if (set)
-cost += set_rtx_cost (set, speed);
-  else
-cost++;
-}
+if (NONDEBUG_INSN_P (seq))
+  cost += insn_rtx_cost (set, speed);

   return cost;
 }

[Bug tree-optimization/78312] New: [7 Regression] wrong code probably due to VRP of multiplication

[zsojka at seznam dot cz]

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

Bug ID: 78312
   Summary: [7 Regression] wrong code probably due to VRP of
multiplication
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

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

Output:
$ x86_64-pc-linux-gnu-gcc testcase.c -O2
$ ./a.out 
Aborted

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-242046-checking-yes-rtl-df-extra-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--without-cloog --without-ppl --without-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-242046-checking-yes-rtl-df-extra-nographite-amd64
Thread model: posix
gcc version 7.0.0 20161110 (experimental) (GCC) 


The .vrp1 dump shows:
...
  # RANGE ~[1, 65534]
  _6 = _2 * _5;
  # RANGE [0, 1] NONZERO 1
  _7 = _6 * _6;
...

I believe that the code has defined behavior due to the (unsigned) cast.

[Bug middle-end/78295] [7 Regression] Spurious -Wuninitialized warning for vector element assignment

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Fri Nov 11 12:53:36 2016
New Revision: 242068

URL: https://gcc.gnu.org/viewcvs?rev=242068&root=gcc&view=rev
Log:
2016-11-11  Richard Biener  

PR middle-end/78295
* tree-ssa-uninit.c (warn_uninitialized_vars): Do not warn
about uninitialized destination arg of BIT_INSERT_EXPR.

* gcc.dg/uninit-pr78295.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/uninit-pr78295.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-uninit.c

[Bug tree-optimization/71575] [6/7 Regression] [graphite] internal compiler error: in copy_cond_phi_nodes, at graphite-isl-ast-to-gimple.c:2500

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
Author: rguenth
Date: Fri Nov 11 12:54:25 2016
New Revision: 242069

URL: https://gcc.gnu.org/viewcvs?rev=242069&root=gcc&view=rev
Log:
2016-11-11  Richard Biener  

PR tree-optimization/71575
* graphite-isl-ast-to-gimple.c (copy_cond_phi_nodes): Remove
bogus assert.

* gcc.dg/graphite/pr71575-1.c: New testcase.
* gcc.dg/graphite/pr71575-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr71575-1.c
trunk/gcc/testsuite/gcc.dg/graphite/pr71575-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-isl-ast-to-gimple.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/78295] [7 Regression] Spurious -Wuninitialized warning for vector element assignment

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/71575] [6 Regression] [graphite] internal compiler error: in copy_cond_phi_nodes, at graphite-isl-ast-to-gimple.c:2500

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[6/7 Regression] [graphite] |[6 Regression] [graphite]
   |internal compiler error: in |internal compiler error: in
   |copy_cond_phi_nodes, at |copy_cond_phi_nodes, at
   |graphite-isl-ast-to-gimple. |graphite-isl-ast-to-gimple.
   |c:2500  |c:2500
  Known to fail||6.2.0

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

[Bug c++/72774] [7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (tree check: expected tree that contains ‘decl minimal’ structure, have ‘tree_list’ in consider_binding_level, at cp/name-loo

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Ah, and I've fixed it already in r240148.  I'll check the testcase in and
close.

[Bug target/78310] ICE: insn does not satisfy its constraints: {*bmi2_rorxdi3_1} with -mbmi2

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-11-11
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
   Target Milestone|--- |5.5
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
Yeah, we need to avoid overflow.

--cut here--
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index a5650a1..b46d6d1 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -10908,8 +10908,9 @@
   [(set (match_dup 0)
(rotatert:SWI48 (match_dup 1) (match_dup 2)))]
 {
-  operands[2]
-= GEN_INT (GET_MODE_BITSIZE (mode) - INTVAL (operands[2]));
+  int bitsize = GET_MODE_BITSIZE (mode);
+
+  operands[2] = GEN_INT ((bitsize - INTVAL (operands[2])) % bitsize);
 })

 (define_split
@@ -10975,8 +10976,9 @@
   [(set (match_dup 0)
(zero_extend:DI (rotatert:SI (match_dup 1) (match_dup 2]
 {
-  operands[2]
-= GEN_INT (GET_MODE_BITSIZE (SImode) - INTVAL (operands[2]));
+  int bitsize = GET_MODE_BITSIZE (SImode);
+
+  operands[2] = GEN_INT ((bitsize - INTVAL (operands[2])) % bitsize);
 })

 (define_split
--cut here--

[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed

[bernds at gcc dot gnu.org]

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

--- Comment #3 from Bernd Schmidt  ---
Gah, that's obviously bogus and fails elsewhere. Still looking...

[Bug target/77346] [7 Regression] ICE in push_reload, at reload.c:1350

[aldyh at gcc dot gnu.org]

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

--- Comment #3 from Aldy Hernandez  ---
Nope, still can't reproduce.  Can you run your compile line with -v and post
the results, to see if there are any other flags passed to cc1 that I am
unaware of?

powerpc-e300c3-linux-gnu-gcc-7.0.0-alpha20161106 -mno-lra -Os -fPIC
-fstack-protector -c -w buwdtjav.c

[Bug tree-optimization/78312] [7 Regression] wrong code probably due to VRP of multiplication

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-11-11
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Hmm.

So [0, 1] * ~[1, 65534] gets

MEET ([0, 1] * [0, 0] == [0, 0],
  [0, 1] * [65535, 65535] == ~[1, 65534]) == ~[1, 65534]

that looks ok to me.

And then ~[1, 65534] * ~[1, 65534] is [0, 1], also ok.

But then somewhen the IL changes to


  :
  # RANGE [0, 1]
  _1 = p1_8(D) > 0;
  # RANGE [0, 1] NONZERO 1
  _2 = (short unsigned int) _1;
  # RANGE ~[1, 65534]
  _3 = -_2;
  # RANGE [0, 1]
  _4 = _3 != 0;
  # RANGE [0, 1] NONZERO 1
  _5 = (short unsigned int) _4;
  # RANGE ~[1, 65534]
  _6 = _2 * _5;

and [0,1] * [0, 1] is not ~[1, 65534].

It is backprop messing up the IL, invalidating the range-info on SSA names.

Index: gcc/gimple-ssa-backprop.c
===
--- gcc/gimple-ssa-backprop.c   (revision 242066)
+++ gcc/gimple-ssa-backprop.c   (working copy)
@@ -728,6 +728,7 @@ backprop::prepare_change (tree var)
 {
   if (MAY_HAVE_DEBUG_STMTS)
 insert_debug_temp_for_var_def (NULL, var);
+  reset_flow_sensitive_info (var);
 }

 /* STMT has been changed.  Give the fold machinery a chance to simplify

[Bug sanitizer/78307] [7 Regression] missing symbols in libubsan without changing the soname

[m.ostapenko at samsung dot com]

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

Maxim Ostapenko  changed:

   What|Removed |Added

 CC||m.ostapenko at samsung dot com

--- Comment #1 from Maxim Ostapenko  ---
Did this cause the link error?

AFAIK GCC doesn't support CFI thus doesn't emit these symbols at compiler side.

[Bug sanitizer/78307] [7 Regression] missing symbols in libubsan without changing the soname

[doko at gcc dot gnu.org]

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

--- Comment #2 from Matthias Klose  ---
I can't tell. I was just looking at symbol difference in the library, like
using the abigail tools.

[Bug tree-optimization/78312] [7 Regression] wrong code probably due to VRP of multiplication

[zsojka at seznam dot cz]

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

--- Comment #2 from Zdenek Sojka  ---
(In reply to Richard Biener from comment #1)
> Hmm.
> 
> So [0, 1] * ~[1, 65534] gets
> 
> MEET ([0, 1] * [0, 0] == [0, 0],
>   [0, 1] * [65535, 65535] == ~[1, 65534]) == ~[1, 65534]
> 
> that looks ok to me.
> 
> And then ~[1, 65534] * ~[1, 65534] is [0, 1], also ok.
> 

Thanks, I didn't realize that ((65535 * 65535) & 0x) == 1.

[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed

[bernds at gcc dot gnu.org]

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

--- Comment #4 from Bernd Schmidt  ---
The other issue here seems to be simply that BRANCH_COST is 0 for predictable
branches on x86. Which makes the default implementation of the hook used here

  if_info.max_seq_cost
= targetm.max_noce_ifcvt_seq_cost (then_edge);

come out as zero, and we fail the conversion because of this.

[Bug sanitizer/78307] [7 Regression] missing symbols in libubsan without changing the soname

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Sure, it doesn't affect gcc emitted code unless somebody calls those directly,
but perhaps say llvm compiled code using the shared libubsan.so.  In any case,
we shouldn't be making ABI incompatible changes in the libraries.  So, either
we should bump soname, or preferably, if it is not that hard to readd those
symbols, just do that, so that people don't have to fight yet another changed
library.

[Bug debug/78112] [7 regression] invalid DWARF generated by the compiler: DIE has multiple AT_inline attributes

[ro at gcc dot gnu.org]

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

--- Comment #14 from Rainer Orth  ---
Created attachment 40023
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40023&action=edit
i386-pc-solaris2.12 assembler output: pr78112.s

Unfortunately, the new testcase FAILs on both Solaris/SPARC and Solaris/x86:

FAIL: g++.dg/pr78112.C   scan-assembler-times DW_AT_object_pointer 37

In both cases (and for either 32 and 64-bit), DW_AT_object_pointer occurs 39
times instead.  Attaching the Solaris/x86 assembler output.

I cannot yet tell if this is related to assembler capabilities: still waiting
for
bootstrap results with gas instead of as.

  Rainer

[Bug inline-asm/78311] "register value used as expression" on i386 in inline assembly statement with "o" constraint

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Requires -fpie to reproduce.  Your testcase is compiled to

f:
.LFB0:
.cfi_startproc
pushl   %ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl%esp, %ebp
.cfi_def_cfa_register 5
call__x86.get_pc_thunk.ax
addl$_GLOBAL_OFFSET_TABLE_, %eax
movlA@GOT(%eax), %eax
#APP
# 4 "t.c" 1
movd (%eax) (, %edx, 4), %mm0

# 0 "" 2
#NO_APP


and appearantly your GCC distributor chose to enable -fpie by default.

[Bug sanitizer/78307] [7 Regression] missing symbols in libubsan without changing the soname

[m.ostapenko at samsung dot com]

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

--- Comment #4 from Maxim Ostapenko  ---
(In reply to Jakub Jelinek from comment #3)
> Sure, it doesn't affect gcc emitted code unless somebody calls those
> directly, but perhaps say llvm compiled code using the shared libubsan.so. 

But LLVM doesn't support shared UBSan runtime (the only one supported is ASan)
and AFAIK there aren't any plans to support it there.

> In any case, we shouldn't be making ABI incompatible changes in the
> libraries.  So, either we should bump soname, or preferably, if it is not
> that hard to readd those symbols, just do that, so that people don't have to
> fight yet another changed library.

Do you mean we can apply a local patch?

[Bug c++/72774] [7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (tree check: expected tree that contains ‘decl minimal’ structure, have ‘tree_list’ in consider_binding_level, at cp/name-loo

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 11 13:39:06 2016
New Revision: 242070

URL: https://gcc.gnu.org/viewcvs?rev=242070&root=gcc&view=rev
Log:
PR c++/72774
* g++.dg/parse/pr72774.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/parse/pr72774.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/78307] [7 Regression] missing symbols in libubsan without changing the soname

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to Maxim Ostapenko from comment #4)
> But LLVM doesn't support shared UBSan runtime (the only one supported is
> ASan) and AFAIK there aren't any plans to support it there.

Yeah, it is a very weird policy.

> > In any case, we shouldn't be making ABI incompatible changes in the
> > libraries.  So, either we should bump soname, or preferably, if it is not
> > that hard to readd those symbols, just do that, so that people don't have to
> > fight yet another changed library.
> 
> Do you mean we can apply a local patch?

We can, sure.

[Bug c++/72774] [7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (tree check: expected tree that contains ‘decl minimal’ structure, have ‘tree_list’ in consider_binding_level, at cp/name-loo

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug sanitizer/78307] [7 Regression] missing symbols in libubsan without changing the soname

[m.ostapenko at samsung dot com]

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

--- Comment #6 from Maxim Ostapenko  ---
(In reply to Jakub Jelinek from comment #5)
> (In reply to Maxim Ostapenko from comment #4)
> > But LLVM doesn't support shared UBSan runtime (the only one supported is
> > ASan) and AFAIK there aren't any plans to support it there.
> 
> Yeah, it is a very weird policy.
> 
> > > In any case, we shouldn't be making ABI incompatible changes in the
> > > libraries.  So, either we should bump soname, or preferably, if it is not
> > > that hard to readd those symbols, just do that, so that people don't have 
> > > to
> > > fight yet another changed library.
> > 
> > Do you mean we can apply a local patch?
> 
> We can, sure.

Ok, I think I can just add (perhaps empty?) stubs into libubsan to readd those
symbols, this should be quite trivial.

[Bug c++/78313] New: [7 Regression] Misleading spelling suggestion

[jakub at gcc dot gnu.org]

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

Bug ID: 78313
   Summary: [7 Regression] Misleading spelling suggestion
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: bernds at gcc dot gnu.org, chengniansun at gmail dot com,
jakub at gcc dot gnu.org, unassigned at gcc dot gnu.org,
webrown.cpp at gmail dot com
Depends on: 72774
  Target Milestone: ---

+++ This bug was initially created as a clone of Bug #72774 +++

// PR c++/72774
// { dg-do compile }

void baz ();
namespace A { void foo (); }
void bar ()
{
  using A::foo;
  0 ? static_cast (0) : baz;   // { dg-error "does not name a type" }
}

Actually, the suggestion looks wrong:

pr72774.C:9:19: error: ‘foo’ does not name a type; did you mean ‘foo’?

We call lookup_name_fuzzy with kind that we want a typename, but we actually
except for members consider even FUNCTION_DECLs/VAR_DECLs.  That doesn't look
right.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72774
[Bug 72774] [7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (tree
check: expected tree that contains ‘decl minimal’ structure, have ‘tree_list’
in consider_binding_level, at cp/name-lookup.c:4721)

[Bug c++/78313] [7 Regression] Misleading spelling suggestion

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org
   Target Milestone|--- |7.0

--- Comment #1 from Jakub Jelinek  ---
CCing David as the author of r238538.

[Bug sanitizer/78307] [7 Regression] missing symbols in libubsan without changing the soname

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
(In reply to Maxim Ostapenko from comment #6)
> (In reply to Jakub Jelinek from comment #5)
> > (In reply to Maxim Ostapenko from comment #4)
> > > But LLVM doesn't support shared UBSan runtime (the only one supported is
> > > ASan) and AFAIK there aren't any plans to support it there.
> > 
> > Yeah, it is a very weird policy.
> > 
> > > > In any case, we shouldn't be making ABI incompatible changes in the
> > > > libraries.  So, either we should bump soname, or preferably, if it is 
> > > > not
> > > > that hard to readd those symbols, just do that, so that people don't 
> > > > have to
> > > > fight yet another changed library.
> > > 
> > > Do you mean we can apply a local patch?
> > 
> > We can, sure.
> 
> Ok, I think I can just add (perhaps empty?) stubs into libubsan to readd
> those symbols, this should be quite trivial.

I think we shouldn't add empty functions, instead look at upstream
http://llvm.org/viewvc/llvm-project?view=revision&revision=258744
change and undo the - parts of it essentially - most likely translate the old
CFIBadTypeData structure we are given into the new CFICheckFailData and just
call HandleCFIBadType.

[Bug c++/78313] [7 Regression] Misleading spelling suggestion

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Thanks. Has some similarities to PR 77922.

[Bug tree-optimization/78114] [7 regression] gfortran.dg/vect/fast-math-mgrid-resid.f FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #6 from amker at gcc dot gnu.org ---
> But for tests:
> FAIL: gfortran.dg/vect/fast-math-mgrid-resid.f   -O   scan-tree-dump-times 
> pcom
> "Executing predictive commoning without unrolling" 1
> FAIL: gfortran.dg/vect/fast-math-mgrid-resid.f   -O   scan-tree-dump-times 
> pcom
> "Predictive commoning failed: no suitable chains" 0
>
> they happened before 20161011.  I tried revision at:
> commit ab93a7014158ec67a0b34e2986742da8a55013f9
> Author: sje 
> Date:   Wed Oct 5 18:42:10 2016 +
>
> 2016-10-05  Steve Ellcey  
>
> * MAINTAINERS: Update email address after it got reverted.
>
>
> git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@240801
> 138bc75d-0d04-0410-961f-82ee72b054a4
>
> And it's not working either?

In my tests (Solaris on various x86 systems, both Intel and AMD), the
failure started consistently between 20161011 (r240990) and 20161013
(r241136).

Rainer

[Bug libfortran/78314] New: [aarch64] ieee_support_halting does not report unsupported fpu traps correctly

[nsz at gcc dot gnu.org]

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

Bug ID: 78314
   Summary: [aarch64] ieee_support_halting does not report
unsupported fpu traps correctly
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

on aarch64 trapping fpu exceptions are optional, but
ieee_support_halting(except_flag) does not report this
correctly, so fortran tests that depend on trap bit
changes would fail:

Program aborted. Backtrace:
#0  0x2472D3
FAIL: gfortran.dg/ieee/ieee_6.f90   -Os  execution test

[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[dominiq at lps dot ens.fr]

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

--- Comment #25 from Dominique d'Humieres  ---
Confirmed provided I run genfixes in the fixincludes directory.

For the record, note that configuring gcc with --disable-libsanitizer replace
an ICE with accept-invalid in pr44348.

[Bug fortran/44348] ICE in build_function_decl

[dominiq at lps dot ens.fr]

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

--- Comment #20 from Dominique d'Humieres  ---
> I cannot confirm that. I do see the ICE on comment 2 at r242066.

OK. I have "recovered" the ICE with the patch at
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01045.html (pr78267). AFAICT the
ICE is replaced by accept-invalid when gcc is configured with
--disable-libsanitizer or with the patch in pr78267 comment 15.

[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
No wonder that one fails on thunderx.

[Bug testsuite/78292] [7 regression] test case gcc.dg/vect/vect-cond-2.c fails starting with r241967

[amker at gcc dot gnu.org]

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

--- Comment #4 from amker at gcc dot gnu.org ---
Author: amker
Date: Fri Nov 11 14:59:48 2016
New Revision: 242073

URL: https://gcc.gnu.org/viewcvs?rev=242073&root=gcc&view=rev
Log:
gcc/testsuite
PR testsuite/78292
* gcc.dg/vect/vect-cond-2.c: Only drop xfail for targets supporting
vect_max_reduc.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/vect-cond-2.c

[Bug debug/78112] [7 regression] invalid DWARF generated by the compiler: DIE has multiple AT_inline attributes

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #15 from amker at gcc dot gnu.org ---
(In reply to Rainer Orth from comment #14)
> Created attachment 40023 [details]
> i386-pc-solaris2.12 assembler output: pr78112.s
> 
> Unfortunately, the new testcase FAILs on both Solaris/SPARC and Solaris/x86:
> 
> FAIL: g++.dg/pr78112.C   scan-assembler-times DW_AT_object_pointer 37
> 
> In both cases (and for either 32 and 64-bit), DW_AT_object_pointer occurs 39
> times instead.  Attaching the Solaris/x86 assembler output.
> 
> I cannot yet tell if this is related to assembler capabilities: still
> waiting for
> bootstrap results with gas instead of as.
> 
>   Rainer

Also on arm/aarch64.

Thanks,
bin

[Bug debug/78112] [7 regression] invalid DWARF generated by the compiler: DIE has multiple AT_inline attributes

[dominiq at lps dot ens.fr]

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

--- Comment #16 from Dominique d'Humieres  ---
> Also on arm/aarch64.

Also on x86_64-apple-darwin16.

[Bug ipa/78309] ICE: in get_hash, at ipa-icf.c:2124

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Created attachment 40024
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40024&action=edit
Un-tested patch

Can you please Markus test the attached patch?

[Bug web/78315] New: "Changes" don't explain what "LRA" is

[schnetter at gmail dot com]

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

Bug ID: 78315
   Summary: "Changes" don't explain what "LRA" is
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: schnetter at gmail dot com
  Target Milestone: ---

The page  points to the GCC wiki page
 "LRA by default". However, this page
never explains what "LRA" actually is. Since this wiki page is mentioned so
prominently, it could spend a paragraph explaining the acronym.

[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Earnshaw  ---
current code has 

int
support_fpu_trap (int flag)
{
  return support_fpu_flag (flag);
}


In other words, it assumes that if there is a flag for noting that an exception
has occurred, then it is also possible to trap on that flag being changed. 
That's not a valid assumption for AArch64.

[Bug ipa/78309] ICE: in get_hash, at ipa-icf.c:2124

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
Yes, your patch seems to fix the issue. Thanks.

[Bug ipa/78316] New: FAIL: gcc.dg/ipa/vrp7.c scan-ipa-dump-times cp "Setting value range of param 0 \\[-10, 9\\]" 1

[amker at gcc dot gnu.org]

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

Bug ID: 78316
   Summary: FAIL: gcc.dg/ipa/vrp7.c scan-ipa-dump-times cp
"Setting value range of param 0 \\[-10, 9\\]" 1
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amker at gcc dot gnu.org
  Target Milestone: ---

The new test case introduced by below commit failed on aarch64:

Author: kugan 
Date:   Wed Nov 9 01:44:04 2016 +

Handle unary pass-through jump functions for ipa-vrp
gcc/testsuite/ChangeLog:

2016-11-09  Kugan Vivekanandarajah  

* gcc.dg/ipa/vrp7.c: New test.


gcc/ChangeLog:

2016-11-09  Kugan Vivekanandarajah  

* ipa-cp.c (ipa_get_jf_pass_through_result): Handle unary expressions.
(propagate_vr_accross_jump_function): Likewise.
* ipa-prop.c (ipa_set_jf_unary_pass_through): New.
(load_from_param_1): New.
(load_from_unmodified_param): Factor common part into
load_from_param_1.
(load_from_param): New.
(compute_complex_assign_jump_func): Handle unary expressions.
(ipa_write_jump_function): Likewise.
(ipa_read_jump_function): Likewise.



git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@241990
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug ipa/78316] FAIL: gcc.dg/ipa/vrp7.c scan-ipa-dump-times cp "Setting value range of param 0 \\[-10, 9\\]" 1

[amker at gcc dot gnu.org]

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

--- Comment #1 from amker at gcc dot gnu.org ---
The gcc is configured as:

configure --target=aarch64-none-elf --prefix=... --with-gmp=... --with-mpfr=...
--with-mpc=... --with-isl=... --with-pkgversion=unknown --disable-shared
--disable-nls --disable-threads --disable-tls --enable-checking=yes
--enable-languages=c,c++ --with-newlib

[Bug c/78317] New: "if (x & constant) z |= constant" should not be rendered with jumps and conditional moves

[dhowells at redhat dot com]

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

Bug ID: 78317
   Summary: "if (x & constant) z |= constant" should not be
rendered with jumps and conditional moves
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

Created attachment 40025
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40025&action=edit
Test code

The following code:

unsigned test1(unsigned x)
{
unsigned z = 0;
if (x & 0x10)
z |= 0x10;
return z;
}

on x86_64 compiled with -Os to:

   0:   89 f8   mov%edi,%eax
   2:   ba 10 00 00 00  mov$0x10,%edx
   7:   83 e0 10and$0x10,%eax
   a:   0f 45 c2cmovne %edx,%eax
   d:   c3  retq   

when what it should probable do is what clang does:

   0:   83 e7 10and$0x10,%edi
   3:   89 f8   mov%edi,%eax
   5:   c3  retq   

as the bit can be transferred by an AND and an OR.

Further, two or more such statements can be combined, for instance:

unsigned test2(unsigned x)
{
unsigned z = 0;
if (x & 0x10)
z |= 0x10;
if (x & 0x40)
z |= 0x40;
return z;
}

but gcc gives the following:

   e:   89 f8   mov%edi,%eax
  10:   ba 10 00 00 00  mov$0x10,%edx
  15:   83 e0 10and$0x10,%eax
  18:   0f 45 c2cmovne %edx,%eax
  1b:   89 c2   mov%eax,%edx
  1d:   83 ca 40or $0x40,%edx
  20:   40 80 e7 40 and$0x40,%dil
  24:   0f 45 c2cmovne %edx,%eax
  27:   c3  retq   

when clang gives:

   6:   83 e7 50and$0x50,%edi
   9:   89 f8   mov%edi,%eax
   b:   c3  retq   


If z isn't passed in, but rather is initialised to another argument, say y:

unsigned test3(unsigned x, unsigned y)
{
unsigned z = y;
if (x & 0x10)
z |= 0x10;
return z;
}

unsigned test4(unsigned x, unsigned y)
{
unsigned z = y;
if (x & 0x10)
z |= 0x10;
if (x & 0x40)
z |= 0x40;
return z;
}

then gcc gives:

0028 :
  28:   89 f2   mov%esi,%edx
  2a:   89 f0   mov%esi,%eax
  2c:   83 ca 10or $0x10,%edx
  2f:   40 80 e7 10 and$0x10,%dil
  33:   0f 45 c2cmovne %edx,%eax
  36:   c3  retq   

0037 :
  37:   89 f2   mov%esi,%edx
  39:   89 f0   mov%esi,%eax
  3b:   83 ca 10or $0x10,%edx
  3e:   40 f6 c7 10 test   $0x10,%dil
  42:   0f 45 c2cmovne %edx,%eax
  45:   89 c2   mov%eax,%edx
  47:   83 ca 40or $0x40,%edx
  4a:   40 80 e7 40 and$0x40,%dil
  4e:   0f 45 c2cmovne %edx,%eax
  51:   c3  retq   

and clang gives:

000c :
   c:   83 e7 10and$0x10,%edi
   f:   09 f7   or %esi,%edi
  11:   89 f8   mov%edi,%eax
  13:   c3  retq   

0014 :
  14:   89 f8   mov%edi,%eax
  16:   83 e0 10and$0x10,%eax
  19:   09 f0   or %esi,%eax
  1b:   83 e7 40and$0x40,%edi
  1e:   09 c7   or %eax,%edi
  20:   89 f8   mov%edi,%eax
  22:   c3  retq   

Both gcc and clang give suboptimal code for test4().  What they should do is:

and$0x50,%edi
or %esi,%edi
mov%edi,%eax
retq

Note that gcc also produces similarly suboptimal output for targets other than
x86_64.

[Bug c/78317] "if (x & constant) z |= constant" should not be rendered with jumps and conditional moves

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #1 from Andrew Pinski  ---
I think there is another bug about this already.

[Bug middle-end/78317] "if (x & constant) z |= constant" should not be rendered with jumps and conditional moves

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Bug 9814 but that was marked as fixed 

[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #5 from James Greenhalgh  ---
If this is a 6 regression it may be more likely related to Kyrill's work on
if-converting arithmetic instructions ( r227368 and follow-ups) than my cost
work (which only landed for GCC 7) - though I'm sure my cost work won't have
helped as the impact of my changes would likely cause less if-conversion for
x86, which reports branches as cheap and conditional moves as expensive.

My ifcvt work for GCC 6 was more related to multiple sets in a basic block,
which I don't think this testcase requires.

[Bug testsuite/78318] New: FAIL: g++.dg/pr78112.C scan-assembler-times DW_AT_object_pointer 37

[thopre01 at gcc dot gnu.org]

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

Bug ID: 78318
   Summary: FAIL: g++.dg/pr78112.C scan-assembler-times
DW_AT_object_pointer 37
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thopre01 at gcc dot gnu.org
CC: derodat at adacore dot com, jakub at gcc dot gnu.org
  Target Milestone: ---
Target: arm-none-eabi

Created attachment 40026
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40026&action=edit
Assembly file produced for g++.dg/pr78112.C targeting ARM Cortex-M3

Hi,

scan-assembler-times DW_AT_object_pointer 37 fails for g++.dg/pr78112.C on
arm-none-eabi targets because there is 38 occurences of DW_AT_object_pointer.
Please find attached the assembly file produced when compiling for ARM
Cortex-M3.

Best regards.

[Bug target/78310] ICE: insn does not satisfy its constraints: {*bmi2_rorxdi3_1} with -mbmi2

[uros at gcc dot gnu.org]

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

--- Comment #2 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Nov 11 16:21:52 2016
New Revision: 242076

URL: https://gcc.gnu.org/viewcvs?rev=242076&root=gcc&view=rev
Log:
PR target/78310
* config/i386/i386.md (rotate to rotatex splitter): Avoid overflow
when calculating operand 2.
(rotate to rotatex zext splitter): Ditto.

testsuite/ChangeLog:

PR target/78310
* gcc.target/i386/pr78310.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr78310.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/78319] New: PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[thopre01 at gcc dot gnu.org]

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

Bug ID: 78319
   Summary: PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning
(test for bogus messages, line 20)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thopre01 at gcc dot gnu.org
CC: prathamesh3492 at gcc dot gnu.org
  Target Milestone: ---
Target: arm-none-eabi

Created attachment 40027
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40027&action=edit
Before and after tree dumps for uninit-pred-8_a.c on ARM Cortex-M7

Hi Prathamesh,

gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)
started to fail for arm-none-eabi after your commit r241915 when targeting ARM
Cortex-M7. The test PASS for ARM Cortex-M4 (which share the same ISA with ARM
Cortex-M7).

I'm attaching the tree dump before (good) and after (bad) the commit. Please
let me know if you need anything else to analyse the issue.

Best regards,

Thomas

[Bug target/78310] ICE: insn does not satisfy its constraints: {*bmi2_rorxdi3_1} with -mbmi2

[uros at gcc dot gnu.org]

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

--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Nov 11 16:42:54 2016
New Revision: 242077

URL: https://gcc.gnu.org/viewcvs?rev=242077&root=gcc&view=rev
Log:
PR target/78310
* config/i386/i386.md (rotate to rotatex splitter): Avoid overflow
when calculating operand 2.
(rotate to rotatex zext splitter): Ditto.

testsuite/ChangeLog:

PR target/78310
* gcc.target/i386/pr78310.c: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr78310.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/i386/i386.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug ipa/78316] FAIL: gcc.dg/ipa/vrp7.c scan-ipa-dump-times cp "Setting value range of param 0 \\[-10, 9\\]" 1

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
Also on x86_64-apple-darwin16.

[Bug target/78310] ICE: insn does not satisfy its constraints: {*bmi2_rorxdi3_1} with -mbmi2

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Nov 11 17:04:18 2016
New Revision: 242124

URL: https://gcc.gnu.org/viewcvs?rev=242124&root=gcc&view=rev
Log:
PR target/78310
* config/i386/i386.md (rotate to rotatex splitter): Avoid overflow
when calculating operand 2.
(rotate to rotatex zext splitter): Ditto.

testsuite/ChangeLog:

PR target/78310
* gcc.target/i386/pr78310.c: New test.


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

[Bug target/78310] ICE: insn does not satisfy its constraints: {*bmi2_rorxdi3_1} with -mbmi2

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

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

[Bug c++/56480] Explicit specialization in a namespace enclosing the specialized template

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/25071] dummy argument larger than actual argument

[dominiq at lps dot ens.fr]

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

--- Comment #19 from Dominique d'Humieres  ---
> Any opinions on this?

So far 2 for, 0 against. May be the patch can be committed?

[Bug fortran/50438] [F03] proc pointer to subroutine in structure constructors

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
> The patch in comment 5 regtests cleanly. However, it only fixes comment 1
> but not comment 0.

Any progress?

[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed

[bernds at gcc dot gnu.org]

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

--- Comment #6 from Bernd Schmidt  ---
Created attachment 40028
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40028&action=edit
Candidate patch

[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed

[bernds at gcc dot gnu.org]

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

--- Comment #7 from Bernd Schmidt  ---
Sorry James, I think these two got mixed up in my memory.

I've attached a candidate patch I'm testing. This tries to make a better effort
to calculate before/after costs for the speed case so we don't rely entirely on
max_seq_cost. I'd be interested in whether it produces good results on ARM (or
even on x86) if someone is set up to run benchmarks.

[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed

[ubizjak at gmail dot com]

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

--- Comment #8 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #0)

> typedef unsigned long u64;
> 
> typedef struct {
>   u64 hi, lo;
> } u128;
> 
> static inline u128 add_u128 (u128 a, u128 b)
> {
>   a.lo += b.lo;
>   if (a.lo < b.lo)
> a.hi++;
> 
>   return a;

While not connected to this problem, it has been pointed out that 

a.hi += b.hi;

is missing in the above source, if we want to implement true 128bit addition.

So, if we want to be pedantic, the missing line should be added to the test. It
doesn't change the outcome in any way.

[Bug sanitizer/77823] [7 Regression] ICE: in ubsan_encode_value, at ubsan.c:137 with -fsanitize=undefined and vector types

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 40029
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40029&action=edit
ubsan-pr77823.patch

Completely untested patch to allow libubsan handling vector types.
Though, not sure if it wouldn't be better to just always compute the sanitized
checks/operations for vectors as scalar, per element, operations.  It would be
certainly more precise, with this patch it would just report say for division
by { 5, 0, -1, 3 } that it is a division by -1 (or division by 0, but not
both).
For the arithmetic signed overflow checks, I think trying to implement it on
vectors might be too hard.  For cheaper tests like testing for shifts (e.g. lhs
< 0, or rhs < 0, or rhs >= bitsize, or division by 0 or by -1, etc.) e.g. SSE2
has pmovmskb instruction where we could check if any vector elements are false
or true, but I think we don't have something like that in GIMPLE IL.

[Bug sanitizer/78294] -fsanitize=thread broken

[dvyukov at google dot com]

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

--- Comment #5 from Dmitry Vyukov  ---
Markus, how do you configure and build gcc? Is there anything special?

Our tls accesses should not go through __tls_get_addr because we use
initial-exec attribute. __tls_get_addr vs indirect access through got is chosen
by compiler, right? So it's not linker. The question is why does your compiler
chooses to use the call... If I am not mistaken,
__tsan::ScopedInterceptor::ScopedInterceptor should have been already accesses
cur_thread, and that did not crash, which suggests that there is no
__tls_get_addr call.