[Bug middle-end/79012] New: basic block reordering causes suboptimal code

[saaadhu at gcc dot gnu.org]

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

Bug ID: 79012
   Summary: basic block reordering causes suboptimal code
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: saaadhu at gcc dot gnu.org
CC: segher at kernel dot crashing.org
  Target Milestone: ---

For this C code (slightly modified from PR 30908)

void wait(int i)
{
while (i-- > 0)
asm volatile("nop" ::: "memory");
}

  gcc 4.8 at -Os produces

jmp .L2
.L3:
nop
decl%edi
.L2:
testl   %edi, %edi
jg  .L3
ret

whereas gcc trunk (and 4.9 onwards, from a quick check) produces

.L2:
testl   %edi, %edi
jle .L5
nop
decl%edi
jmp .L2
.L5:
ret

The code size is identical, but the trunk version executes one more
instruction everytime the loop runs (explicit jump to .L5 with trunk vs
fallthrough with 4.8) - it's faster only if the loop never runs. This
happens irrespective of the memory clobber inline assembler statement.

Digging into the dump files, I found that the transformation occurs in
the bb reorder pass, when it calls cfg_layout_initialize, which
eventually calls try_redirect_by_replacing_jump with in_cfglayout set to
true. That function then removes the jump and causes the RTL
transformation that eventually results in slower code.

RTL before and after bbro.

Before:

(jump_insn 24 6 25 2 (set (pc)
(label_ref 15)) "pr30908.c":3 678 {jump}
 (nil)
 -> 15)
(barrier 25 24 17)
(code_label 17 25 12 3 3 "" [1 uses])
(note 12 17 13 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(insn 13 12 14 3 (parallel [
(asm_operands/v ("nop") ("") 0 []
 []
 [] pr30908.c:4)
(clobber (mem:BLK (scratch) [0  A8]))
(clobber (reg:CCFP 18 fpsr))
(clobber (reg:CC 17 flags))
]) "pr30908.c":4 -1
 (expr_list:REG_UNUSED (reg:CCFP 18 fpsr)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 14 13 15 3 (parallel [
(set (reg:SI 5 di [orig:90 ivtmp.9 ] [90])
(plus:SI (reg:SI 5 di [orig:90 ivtmp.9 ] [90])
(const_int -1 [0x])))
(clobber (reg:CC 17 flags))
]) 210 {*addsi_1}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(code_label 15 14 16 4 2 "" [1 uses])
(note 16 15 18 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn 18 16 19 4 (set (reg:CCNO 17 flags)
(compare:CCNO (reg:SI 5 di [orig:90 ivtmp.9 ] [90])
(const_int 0 [0]))) "pr30908.c":3 3 {*cmpsi_ccno_1}
 (nil))
(jump_insn 19 18 30 4 (set (pc)
(if_then_else (gt (reg:CCNO 17 flags)
(const_int 0 [0]))
(label_ref 17)
(pc))) "pr30908.c":3 646 {*jcc_1}
 (expr_list:REG_DEAD (reg:CCNO 17 flags)
(int_list:REG_BR_PROB 8500 (nil)))
 -> 17)
(note 30 19 28 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(note 28 30 29 5 NOTE_INSN_EPILOGUE_BEG)
(jump_insn 29 28 31 5 (simple_return) "pr30908.c":5 708
{simple_return_internal}
 (nil)
 -> simple_return)

After:


(code_label 15 6 16 3 2 "" [1 uses])
(note 16 15 18 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(insn 18 16 19 3 (set (reg:CCNO 17 flags)
(compare:CCNO (reg:SI 5 di [orig:90 ivtmp.9 ] [90])
(const_int 0 [0]))) "pr30908.c":3 3 {*cmpsi_ccno_1}
 (nil))
(jump_insn 19 18 12 3 (set (pc)
(if_then_else (le (reg:CCNO 17 flags)
(const_int 0 [0]))
(label_ref:DI 34)
(pc))) "pr30908.c":3 646 {*jcc_1}
 (expr_list:REG_DEAD (reg:CCNO 17 flags)
(int_list:REG_BR_PROB 1500 (nil)))
 -> 34)
(note 12 19 13 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn 13 12 14 4 (parallel [
(asm_operands/v ("nop") ("") 0 []
 []
 [] pr30908.c:4)
(clobber (mem:BLK (scratch) [0  A8]))
(clobber (reg:CCFP 18 fpsr))
(clobber (reg:CC 17 flags))
]) "pr30908.c":4 -1
 (expr_list:REG_UNUSED (reg:CCFP 18 fpsr)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 14 13 35 4 (parallel [
(set (reg:SI 5 di [orig:90 ivtmp.9 ] [90])
(plus:SI (reg:SI 5 di [orig:90 ivtmp.9 ] [90])
(const_int -1 [0x])))
(clobber (reg:CC 17 flags))
]) 210 {*addsi_1}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(jump_insn 35 14 36 4 (set (pc)
(label_ref 15)) -1
 (nil)
 -> 15)
(barrier 36 35 34)
(code_label 34 36 30 5 5 "" [1 uses])
(note 30 34 28 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(note 28 30 29 5 NOTE_INSN_EPILOGUE_BEG)
(jump_insn 29 28 31 5 (simple_return) "pr30908.c":5 708
{simple_return_internal}
 (nil)
 -> simple_return)

[Bug target/79004] ICE in gcc.dg/torture/fp-int-convert-float128-ieee.c with -mcpu=power9

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-01-06
   Assignee|unassigned at gcc dot gnu.org  |meissner at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug target/79004] ICE in gcc.dg/torture/fp-int-convert-float128-ieee.c with -mcpu=power9

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner  ---
This was caused by subversion id 237806 that added small integer support in
vector registers (32-bit on power8, 8/16-bit on power9).  Unfortunately, the
IEEE 128-bit hardware support was not adjusted for small integer support.

[Bug c/79011] New: incorrect form of warning options listed in the manual

[msebor at gcc dot gnu.org]

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

Bug ID: 79011
   Summary: incorrect form of warning options listed in the manual
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Section 3.8 of the manual, Options to Request or Suppress Warnings, states
that:

  "This manual lists only one of the two forms, whichever is not the default."

The following is a list of options listed in that section that, according to
the manual, are enabled by default (and thus should be listed in the -Wno-xxx
form).

-Wignored-attributes
-Wshift-count-negative
-Wshift-count-overflow
-Wshift-overflow (in C99 and later)
-Wswitch-unreachable
-Winvalid-memory-model
-Wstringop-overflow=2
-Wplacement-new
-Wpointer-compare
-Wno-endif-labels
-Wwrite-strings (in C++)
-Wsubobject-linkage
-Wdate-time
-Wenum-compare (in C++)
-Wsizeof-array-argument
-Wnormalized
-Woverride-init-side-effects
-Wpacked-bitfield-compat
-Wvarargs

[Bug middle-end/71905] bogus -Wlarger-than=N and -Wframe-larger-than= -Wstack-usage= warnings on small objects with large N

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
To get around the INT_MAX limit the -Walloc-size-larger-than accepts numbers
with suffixes like KB and MB.  Other options that accept sizes should probably
accept the same suffixes for consistency.

[Bug c/79010] New: -Wlarger-than ineffective for VLAs, alloca, malloc

[msebor at gcc dot gnu.org]

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

Bug ID: 79010
   Summary: -Wlarger-than ineffective for VLAs, alloca, malloc
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The -Wlarger-than is documented to "Warn whenever an object of larger than len
bytes is defined."  Setting aside the typo ("object of larger than") the option
doesn't has the advertised effect: it fails to warn when either a VLA object of
excessive size is created, or when such an object is created by a call to
alloca or malloc.  (The warning for the unnamed array is also duplicated.)

For alloca there is -Walloca-larger-than, and for malloc and other allocation
functions there is -Walloc-size-larger-than, so -Walrger-than should either be
documented to have a limited effect or the option should also enable the other
two.

Either way, the typo in the manual should be corrected and the duplicate
warning suppressed.

$ cat b.c && gcc -DN=123456 -S -Wall -Wextra -Wpedantic  -Wlarger-than=123 b.c
void sink (void*);

char a[N];

void farray (void)
{
  char a[N];
  sink (a);
}

void funnamed_array (void)
{
  sink ((char[N]){ 0 });
}

void fvla (void)
{
  int n = N;
  char a[n];
  sink (a);
}

void falloca (void)
{
  void *a = __builtin_alloca (N);
  sink (a);
}

void fmalloc (void)
{
  void *a = __builtin_malloc (N);
  sink (a);
}
b.c:3:6: warning: size of ‘a’ is 123456 bytes [-Wlarger-than=]
 char a[N];
  ^
b.c: In function ‘farray’:
b.c:7:8: warning: size of ‘a’ is 123456 bytes [-Wlarger-than=]
   char a[N];
^
b.c: In function ‘funnamed_array’:
b.c:13:18: warning: size of ‘({anonymous})’ is 123456 bytes [-Wlarger-than=]
   sink ((char[N]){ 0 });
  ^
b.c:13:18: warning: size of ‘({anonymous})’ is 123456 bytes [-Wlarger-than=]

[Bug c++/79009] New: Missing 'inconsistent deduction for ‘auto’' error when having a dependent initializer and a nondependent one in the same declaration

[jakub at gcc dot gnu.org]

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

Bug ID: 79009
   Summary: Missing 'inconsistent deduction for ‘auto’' error when
having a dependent initializer and a nondependent one
in the same declaration
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: inadgob at yahoo dot com, jakub at gcc dot gnu.org,
jason at gcc dot gnu.org, lhyatt at gmail dot com,
marxin at gcc dot gnu.org, rs2740 at gmail dot com,
unassigned at gcc dot gnu.org, webrown.cpp at gmail dot com
Depends on: 78693
  Target Milestone: ---

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

The following testcase should be rejected during instantiation, because the
auto deduced type in the same simple declaration is deduced differently.
But we don't preserve the information what decls appeared together until
instantiation, so don't diagnose it right now.

template 
void
foo (T t)
{
  auto i = t, j = 1;
}

template 
void
bar (T t)
{
  auto i = 1, j = t, k = 2;
}

template 
void
foo (T t, U u)
{
  auto i = t, j = u;
}

void
foo ()
{
  foo (0L);
  bar (0L);
  foo (1, 2L);
}


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78693
[Bug 78693] [6 Regression] Bogus 'inconsistent deduction for ‘auto’' error when
having a dependent initializer and a nondependent one in the same declaration

[Bug c++/78931] [7 Regression] ICE on C++17 structured bindings from struct with reference member

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/71016] [6 Regression] Redundant sign extension with conditional __builtin_clzl

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7 Regression] Redundant  |[6 Regression] Redundant
   |sign extension with |sign extension with
   |conditional __builtin_clzl  |conditional __builtin_clzl

--- Comment #11 from Jakub Jelinek  ---
Fixed on the trunk.  Probably undesirable to backport.

[Bug c++/78890] [5/6 Regression] ICE on invalid reference type in union

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] ICE on   |[5/6 Regression] ICE on
   |invalid reference type in   |invalid reference type in
   |union   |union

--- Comment #9 from Jakub Jelinek  ---
Fixed on the trunk.
Not sure what to do for the older branches, perhaps #c2 patch might be better
there, so that we don't start rejecting something earlier snapshots of those
releases didn't reject.

[Bug tree-optimization/78910] Wrong print-return-value for a negative number

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fixed in r244116.

[Bug tree-optimization/78910] Wrong print-return-value for a negative number

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Thu Jan  5 22:32:09 2017
New Revision: 244116

URL: https://gcc.gnu.org/viewcvs?rev=244116=gcc=rev
Log:
PR tree-optimization/78910 - Wrong print-return-value for a negative number

gcc/ChangeLog:

PR tree-optimization/78910
* gimple-ssa-sprintf.c (tree_digits): Add an argument.
(format_integer): Correct off-by-one error in the handling
of precision with negative numbers in signed conversions..

gcc/testsuite/ChangeLog:

PR tree-optimization/78910
* gcc.dg/tree-ssa/builtin-sprintf-warn-7.c: Adjust text of expected
diagnostics.
* gcc.dg/tree-ssa/builtin-sprintf.c: Add test cases.
* gcc.dg/tree-ssa/pr78910.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr78910.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-7.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c

[Bug middle-end/78973] [7.0 regression] warning: ‘memcpy’: specified size between 18446744071562067968 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
  Component|c   |middle-end

--- Comment #5 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00344.html

[Bug tree-optimization/79007] [7 regression] gcc.dg/tree-ssa/dse-points-to.c fails starting with r244067

[seurer at linux dot vnet.ibm.com]

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

--- Comment #2 from Bill Seurer  ---
I just tried it on an x86 system and it also fails there.

[Bug tree-optimization/71016] [6/7 Regression] Redundant sign extension with conditional __builtin_clzl

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan  5 21:14:19 2017
New Revision: 244114

URL: https://gcc.gnu.org/viewcvs?rev=244114=gcc=rev
Log:
PR tree-optimization/71016
* tree-ssa-phiopt.c (tree_ssa_phiopt_worker): Pass cond_stmt to
factor_out_conditional_conversion.  Formatting fix.
(factor_out_conditional_conversion): Add cond_stmt argument.
If arg1 is INTEGER_CST, punt if new_arg0 is not any operand of
cond_stmt and if arg0_def_stmt is not the only stmt in its bb.
Formatting fix.

* gcc.target/i386/pr71016.c: New test.
* gcc.target/aarch64/pr71016.c: New test.
* gcc.dg/tree-ssa/pr66726-3.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr66726-3.c
trunk/gcc/testsuite/gcc.target/aarch64/pr71016.c
trunk/gcc/testsuite/gcc.target/i386/pr71016.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-phiopt.c

[Bug c++/78931] [7 Regression] ICE on C++17 structured bindings from struct with reference member

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan  5 21:13:09 2017
New Revision: 244113

URL: https://gcc.gnu.org/viewcvs?rev=244113=gcc=rev
Log:
PR c++/78931
* decl.c (cp_finish_decomp): Remove probe variable, if tt is
REFERENCE_REF_P, set tt to its operand.

* g++.dg/cpp1z/decomp19.C: New test.

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

[Bug c++/78890] [5/6/7 Regression] ICE on invalid reference type in union

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan  5 21:12:02 2017
New Revision: 244112

URL: https://gcc.gnu.org/viewcvs?rev=244112=gcc=rev
Log:
PR c++/78890
* class.c (check_field_decls): Diagnose REFERENCE_TYPE fields in
unions even for C++11 and later.

* g++.dg/init/ref14.C: Expect error even in C++11 and later.
* g++.dg/init/union1.C: Likewise.
* g++.dg/cpp0x/union6.C: Expect errors.
* g++.dg/cpp0x/union8.C: New test.
* g++.dg/cpp0x/pr78890-1.C: New test.
* g++.dg/cpp0x/pr78890-2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr78890-1.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr78890-2.C
trunk/gcc/testsuite/g++.dg/cpp0x/union8.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/union6.C
trunk/gcc/testsuite/g++.dg/init/ref14.C
trunk/gcc/testsuite/g++.dg/init/union1.C

[Bug target/79004] ICE in gcc.dg/torture/fp-int-convert-float128-ieee.c with -mcpu=power9

[bergner at gcc dot gnu.org]

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

--- Comment #3 from Peter Bergner  ---
Minimal test case:

bergner@genoa:~/gcc/BUGS/PR79004$ cat pr79004.i 
int
main (void)
{
  char ivin;
  _Float64x fv2 = ivin;
}
bergner@genoa:~/gcc/BUGS/PR79004$
/home/bergner/gcc/build/gcc-fsf-mainline-reg-move_costs-debug/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-reg-move_costs-debug/gcc -O0
-mfloat128 -mvsx -S -mcpu=power9 pr79004.i 
pr79004.i: In function ‘main’:
pr79004.i:6:1: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1026
 }
 ^
0x106e9fbb gen_reg_rtx(machine_mode)
   
/home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-lra/gcc/emit-rtl.c:1026
0x1137ea7f convert_int_to_float128(rtx_def**, rtx_code)
   
/home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-lra/gcc/config/rs6000/rs6000.c:24395
0x11694d2b gen_split_412(rtx_insn*, rtx_def**)
   
/home/bergner/gcc/gcc-fsf-mainline-reg-move_costs-lra/gcc/config/rs6000/rs6000.md:14358

The problem is that we're trying to generate a new reg, but reload_completed is
true, so we cannot.  We're trying to generate the new reg here:

void
convert_int_to_float128 (rtx *operands, enum rtx_code code)
{
  rtx dest = operands[0];
  rtx src = operands[1];
  rtx tmp = operands[2];
  rtx cvt;
  rtvec cvt_vec;
  rtx cvt_unspec;
  rtvec move_vec;
  rtx move_unspec;
  rtx unsigned_flag;

  if (GET_CODE (tmp) == SCRATCH)
tmp = gen_reg_rtx (V2DImode);

[Bug c++/79008] New: missing detail in -Wbuiltin-declaration-mismatch

[msebor at gcc dot gnu.org]

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

Bug ID: 79008
   Summary: missing detail in -Wbuiltin-declaration-mismatch
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In C++ (but not in C) -Wbuiltin-declaration-mismatch prints the conflicting
declarations of the function as shown below.  This is helpful when the
declarations visibly differ but not so much when they look the same as is
likely to be common in code that declares the function based on the C or POSIX
standards.

To avoid this problem, when the conflict is due to missing attributes, the
warning should also include the attributes that cause the conflict.

To make this feature generally available beyond this specific warning I would
suggest to enhance the pretty printer to make it possible to also include
attributes in a declaration.  E.g., by interpreting the pound ('#') flag as a
request to do so ("%#qE").

$ cat b.c && gcc -S -Wall -Wextra -Wpedantic -xc++ b.c
extern "C" int sprintf (char*, ...);

b.c:1:16: warning: declaration of ‘int sprintf(char*, ...)’ conflicts with
built-in declaration ‘int sprintf(char*, const char*, ...)’
[-Wbuiltin-declaration-mismatch]
 extern "C" int sprintf (char*, ...);
^~~

[Bug tree-optimization/79007] [7 regression] gcc.dg/tree-ssa/dse-points-to.c fails starting with r244067

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-05
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.

[Bug tree-optimization/79007] New: [7 regression] gcc.dg/tree-ssa/dse-points-to.c fails starting with r244067

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 79007
   Summary: [7 regression] gcc.dg/tree-ssa/dse-points-to.c fails
starting with r244067
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

This test case, which was introduced recently in r243325, now fails.

Executing on host: /home/seurer/gcc/build/gcc-trunk/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk/gcc/
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/dse-points-to.c 
-fno-diagnostics-show-caret -fdiagnostics-color=never   -O2 -fno-tree-ccp
-fno-tree-forwprop -fno-tree-fre -fno-tree-vrp -fdump-tree-dse1-details -S   -o
dse-points-to.s(timeout = 300)
spawn /home/seurer/gcc/build/gcc-trunk/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk/gcc/
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/dse-points-to.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fno-tree-ccp
-fno-tree-forwprop -fno-tree-fre -fno-tree-vrp -fdump-tree-dse1-details -S -o
dse-points-to.s
PASS: gcc.dg/tree-ssa/dse-points-to.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/dse-points-to.c scan-tree-dump-times dse1 "Deleted dead
store.*p_1" 1
testcase /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/tree-ssa.exp
completed in 2 seconds

=== gcc Summary ===

# of expected passes1
# of unexpected failures1

[Bug tree-optimization/79006] New: [6/7 Regression] Invalid transformation in tree-dominators pass

[wschmidt at gcc dot gnu.org]

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

Bug ID: 79006
   Summary: [6/7 Regression] Invalid transformation in
tree-dominators pass
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wschmidt at gcc dot gnu.org
  Target Milestone: ---

Compile the following with -Os on GCC 6.3 or current trunk:

typedef struct
{
  unsigned long a_type;
  union
  {
unsigned long a_val;
  } a_un;
} Elf64_auxv_t;

void
auxv_up (Elf64_auxv_t *av, unsigned type, unsigned const value)
{
  if (av)
for (;; ++av)
  {
if (av->a_type == type
|| (av->a_type == 1 && type != 0))
  {
av->a_type = type;
av->a_un.a_val = value;
return;
  }
  }
}

The generated code causes av->a_type to receive a wrong value along the
fall-through path.  On powerpc64le, this is what we see:

auxv_up:
cmpdi 0,3,0
beqlr 0
cmpdi 5,4,0
.L6:
ld 9,0(3)
cmpld 7,9,4
bne 7,.L3
.L5:
std 9,0(3)  <-- Should be std 4,0(3) to store "type"
std 5,8(3)
blr
.L7:
mr 9,4
b .L5
.L3:
cmpldi 7,9,1
bne 7,.L4
bne 5,.L7
.L4:
addi 3,3,16
b .L6

I've narrowed this down to the dom3 pass.  Prior to dom3, the GIMPLE is:

auxv_up (struct Elf64_auxv_t * av, unsigned int type, const unsigned int value)
{
  long unsigned int _1;
  long unsigned int _2;
  long unsigned int _3;
  long unsigned int _4;
  long unsigned int _5;
  long unsigned int _18;

   [13.5%]:
  if (av_8(D) != 0B)
goto ; [73.3%]
  else
goto ; [26.7%]

   [9.9%]:

   [100.0%]:
  # av_6 = PHI 
  _1 = MEM[base: av_6, offset: 0B];
  _2 = (long unsigned int) type_10(D);
  if (_1 == _2)
goto ; [7.5%]
  else
goto ; [92.5%]

   [7.5%]:
  # _3 = PHI <_2(3)>
  # av_19 = PHI 

   [9.9%]:
  # _18 = PHI <_3(4), _4(8)>  ; _18 always equal to _2
  # av_15 = PHI 
  av_15->a_type = _18;
  _5 = (long unsigned int) value_13(D);
  av_15->a_un.a_val = _5;
  goto ; [100.0%]

   [92.5%]:
  if (_1 == 1)
goto ; [34.0%]
  else
goto ; [66.0%]

   [31.4%]:
  if (type_10(D) != 0)
goto ; [7.5%]
  else
goto ; [92.5%]

   [2.4%]:
  # _4 = PHI <_2(7)>
  # av_16 = PHI 
  goto ; [100.0%]

   [90.1%]:
  av_11 = av_6 + 16;
  goto ; [100.0%]

   [13.5%]:
  return;

}

Following dom3 we have:

auxv_up (struct Elf64_auxv_t * av, unsigned int type, const unsigned int value)
{
  long unsigned int _1;
  long unsigned int _2;
  long unsigned int _3;
  long unsigned int _4;
  long unsigned int _5;
  long unsigned int _18;

   [13.5%]:
  if (av_8(D) != 0B)
goto ; [73.3%]
  else
goto ; [26.7%]

   [100.0%]:
  # av_6 = PHI 
  _1 = MEM[base: av_6, offset: 0B];
  _2 = (long unsigned int) type_10(D);
  if (_1 == _2)
goto ; [7.5%]
  else
goto ; [92.5%]

   [7.5%]:
  # _3 = PHI <_2(3)>
  # av_19 = PHI 

   [9.9%]:
  # _18 = PHI <_1(4), _2(8)> ; _18 can now equal av->a_type instead
  # av_15 = PHI 
  av_6->a_type = _18;
  _5 = (long unsigned int) value_13(D);
  av_6->a_un.a_val = _5;
  goto ; [100.0%]

   [92.5%]:
  if (_1 == 1)
goto ; [34.0%]
  else
goto ; [66.0%]

   [31.4%]:
  if (type_10(D) != 0)
goto ; [7.5%]
  else
goto ; [92.5%]

   [2.4%]:
  # _4 = PHI <_2(7)>
  # av_16 = PHI 
  goto ; [100.0%]

   [90.1%]:
  av_11 = av_6 + 16;
  goto ; [100.0%]

   [13.5%]:
  return;

}

[Bug c/78973] [7.0 regression] warning: ‘memcpy’: specified size between 18446744071562067968 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
Summary|warning: ‘memcpy’:  |[7.0 regression] warning:
   |specified size between  |‘memcpy’: specified size
   |18446744071562067968 and|between
   |18446744073709551615|18446744071562067968 and
   |exceeds maximum object size |18446744073709551615
   |9223372036854775807 |exceeds maximum object size
   |[-Wstringop-overflow=]  |9223372036854775807
   ||[-Wstringop-overflow=]
   Severity|enhancement |normal

--- Comment #4 from Martin Sebor  ---
Thanks.  The range printed in the diagnostic corresponds to the range of the
signed variable passed to memcpy() after conversion to size_t.  The (signed)
range is reported by the get_range_info() function as [-2147483648, -1].  The
converted variable's def_stmt looks like this:

  _309 = (long unsigned int) len_137;

The range of the len_137 variable whose type is int is [-2147483648,
2147483647], or the full range of its type, so the unsigned range has to be
considered to be [0, SIZE_MAX].  I'm testing a patch to detect this and avoid
the false positive.

[Bug rtl-optimization/78812] [5/6 Regression] Wrong code generation due to hoisting memory load across function call

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #17 from Eric Botcazou  ---
> ABNORMAL_CALL and EH imply ABNORMAL, at least for RTL CFG according to their
> documentation.  I haven't gone through the trouble to see where that is
> enforced, but I did very that the edges had EH and ABNORMAL set in the dumps.

This was historically the case in GIMPLE too but Jan changed it at some point.

[Bug c++/79005] Use of a captured variable within nested generic lambdas provokes internal compiler error.

[mmccutcheon at nuvucameras dot com]

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

--- Comment #3 from M. McCutcheon  ---
Sorry, forgot to include the actual error message, though it doesn't seem very
illuminating :

auto-lambda_sub-capture.cpp: In lambda function:
auto-lambda_sub-capture.cpp:28:8: internal compiler error: Segmentation fault
result = b * c; // Provokes internal compiler error
^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/cc5qcmOS.out file, please attach this to
your bug report.

[Bug c++/79005] Use of a captured variable within nested generic lambdas provokes internal compiler error.

[mmccutcheon at nuvucameras dot com]

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

--- Comment #2 from M. McCutcheon  ---
Created attachment 40469
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40469=edit
Preprocessed source as requested by the error message

[Bug rtl-optimization/78812] [5/6 Regression] Wrong code generation due to hoisting memory load across function call

[law at redhat dot com]

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

--- Comment #16 from Jeffrey A. Law  ---
ABNORMAL_CALL and EH imply ABNORMAL, at least for RTL CFG according to their
documentation.  I haven't gone through the trouble to see where that is
enforced, but I did very that the edges had EH and ABNORMAL set in the dumps.

[Bug c++/79005] Use of a captured variable within nested generic lambdas provokes internal compiler error.

[mmccutcheon at nuvucameras dot com]

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

--- Comment #1 from M. McCutcheon  ---
The following code provokes an internal compiler error with :
g++ -save-temps -Wall -Wextra -std=c++14 

int main()
{
  auto glambda = [] (auto a)
  {
const int c = a;
auto cglambda = [&] ( auto b )
{ 
  double result;
  result = b * a;
  result = b * c; // Provokes internal compiler error
  return result;
};
cglambda ( 1 );
a = c;
  };

  glambda( 1 );

  return 0;
}

The specifics on the GCC version used are posted at the end of this comment but
the same code generates a similar error on Coliru with GCC 6.3.0

There seem to be similarities with Bug 69977.


--
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.9.4-2ubuntu1~12.04' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--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.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-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 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.4 (Ubuntu 4.9.4-2ubuntu1~12.04)

[Bug c++/79005] New: Use of a captured variable within nested generic lambdas provokes internal compiler error.

[mmccutcheon at nuvucameras dot com]

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

Bug ID: 79005
   Summary: Use of a captured variable within nested generic
lambdas provokes internal compiler error.
   Product: gcc
   Version: 4.9.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mmccutcheon at nuvucameras dot com
  Target Milestone: ---

Created attachment 40468
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40468=edit
Preprocessed file generated via -save-temps

[Bug libstdc++/63829] _Lock_policy used in thread.cc can cause incompatibilities with binaries using different -mcpu

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||rearnsha at gcc dot gnu.org

--- Comment #7 from Jonathan Wakely  ---
(In reply to Richard Earnshaw from comment #6)
> arm linux code should always be using the _S_atomic sequences.  When the
> processor doesn't have the required instructions, kernel helper routines
> will be used.

Richard, do you mean this should happen via libatomic, or by libstdc++ calling
the kernel helpers directly?

It would be relatively easy to make ARM always use _S_atomic, but for some
programs that would add dependency on libatomic which IIUC is optional today.

Solving the backwards-compatibility problem would be harder (code compiled with
existing GCC releases would be using the _S_mutex implementation and mixing
object code would run into the same problems described above, but now even when
using the same -mcpu settings).

[Bug target/79004] ICE in gcc.dg/torture/fp-int-convert-float128-ieee.c with -mcpu=power9

[acsawdey at gcc dot gnu.org]

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

--- Comment #2 from acsawdey at gcc dot gnu.org ---
Just checked and it also fails with 244106 from 20 minutes ago.

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[jvdelisle at gcc dot gnu.org]

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

--- Comment #19 from Jerry DeLisle  ---
(In reply to janus from comment #18)
> Created attachment 40364 [details]
> updated patch
> 
> Here is an updated patch, which fixes all wrong-code issues AFAICS. It
> includes improved handling of CLASS-vs-TYPE variables (analogous to PR
> 78848) and a full-featured test case (which currently fails due to PR 78854).
> 
> Note that the patch does not handle the rejects-valid problem of comment 5
> (which rather belong into PR 78659).

I would suggest committing this with no internal unit test or those parts
commented out and then when I do get 78854 fixed we can update the test or add
a new one.

[Bug target/79004] ICE in gcc.dg/torture/fp-int-convert-float128-ieee.c with -mcpu=power9

[acsawdey at gcc dot gnu.org]

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

--- Comment #1 from acsawdey at gcc dot gnu.org ---
gcc.dg/torture/fp-int-convert-float64x.c also fails in the same way.

[Bug target/79004] New: ICE in gcc.dg/torture/fp-int-convert-float128-ieee.c with -mcpu=power9

[acsawdey at gcc dot gnu.org]

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

Bug ID: 79004
   Summary: ICE in gcc.dg/torture/fp-int-convert-float128-ieee.c
with -mcpu=power9
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acsawdey at gcc dot gnu.org
CC: meissner at gcc dot gnu.org, wschmidt at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64*-*-*

This is different that 78597 which just reported that this test fails
execution. Now we also seem to be getting an ICE from it. The test case
compiles without error if you use -mcpu=power8.

Compiler is gcc 7 trunk 244035 on ppc64le

genoa 356 -> /home/sawdey/src/gcc/trunk2/build/gcc/xgcc
-B/home/sawdey/src/gcc/trunk2/build/gcc/
/home/sawdey/src/gcc/trunk2/trunk/gcc/testsuite/gcc.dg/torture/fp-int-convert-float128-ieee.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -mfloat128 -mvsx
-Wl,-rpath=/tmp/lib64 -Wl,-rpath=/home/sawdey/install/gcc/trunk_base/lib64 -lm
-mcpu=power9 -o ./fp-int-convert-float128-ieee.exe
/home/sawdey/src/gcc/trunk2/trunk/gcc/testsuite/gcc.dg/torture/fp-int-convert-float128-ieee.c:
In function âmainâ:
/home/sawdey/src/gcc/trunk2/trunk/gcc/testsuite/gcc.dg/torture/fp-int-convert-float128-ieee.c:20:1:
internal compiler error: in gen_reg_rtx, at emit-rtl.c:1026
0x104bbb8b gen_reg_rtx(machine_mode)
../../trunk/gcc/emit-rtl.c:1026
0x10d8bc5b convert_int_to_float128(rtx_def**, rtx_code)
../../trunk/gcc/config/rs6000/rs6000.c:24239
0x10fd3bbb gen_split_405(rtx_insn*, rtx_def**)
../../trunk/gcc/config/rs6000/rs6000.md:14119
0x110ecc3b split_6
../../trunk/gcc/config/rs6000/rs6000.md:14118
0x104c25a7 try_split(rtx_def*, rtx_insn*, int)
../../trunk/gcc/emit-rtl.c:3663
0x104c2f3b try_split(rtx_def*, rtx_insn*, int)
../../trunk/gcc/emit-rtl.c:3834
0x10857607 split_insn
../../trunk/gcc/recog.c:2889
0x1085dc57 split_all_insns_noflow()
../../trunk/gcc/recog.c:3025
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/78977] [7 Regression] g++7 snprintf() of double produces wrong code with -O3

[h2+bugs at fsfe dot org]

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

--- Comment #13 from Hannes Hauswedell  ---
(In reply to Jakub Jelinek from comment #12)
> So that looks like r244037 has fixed this bug.  Please reopen if that is not
> the case.  Given Martin's description that
> 2.99988897769753748434595763683319091796875e-1 could be printed
> with %g as
> 0.29 or as 0.3 depending on rounding, assuming range [3, 8] is
> reasonable, hardcoding return value of 8 is obviously wrong.

Ok, great, then we will just wait. Otherwise I would have done more of the
debugging, but I am also quite busy so we'll wait for the weekly snapshots!

[Bug middle-end/78977] [7 Regression] g++7 snprintf() of double produces wrong code with -O3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #12 from Jakub Jelinek  ---
Actually, diffing the pr78977.ii.173t.printf-return-value2 file between r244036
and r244037, I see:
--- pr78977.ii.173t.printf-return-value2.r244036   2017-01-05
11:37:32.0 -0500
+++ pr78977.ii.173t.printf-return-value2.r244037   2017-01-05
11:38:39.0 -0500
@@ -16052,7 +16052,7 @@ seqan::String

[Bug rtl-optimization/79003] [7 Regression] r238991 breaks ODR

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I think struct lra_invariant looks better to me over the anon namespace.

[Bug rtl-optimization/79003] [7 Regression] r238991 breaks ODR

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #2 from Martin Liška  ---
I've talked to Honza and he's suggesting to add -fno-lto to libdecnumber. I'll
prepare patch for both the library and struct invariant.

[Bug c/16351] NULL dereference warnings

[msebor at gcc dot gnu.org]

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

--- Comment #48 from Martin Sebor  ---
Send a check to Manuel ;)  The feature is available under the
-Wnull-dereference option (see comment 31).  Unfortunately, due to false
positives, the option was removed from -Wall in a subsequent commit (r226751)
and has to be enabled explicitly.

The similar -Wnonnull option that was just recently enhanced to detect related
problems is in -Wall, and it seems to me that it would make sense to treat both
of these options the same: i.e., enable both with -Wall.  To do that, the
former option might need to be tweaked to reduce its false positive rate.  At
the same time, the -Wnonnull option still has a high rate of false negatives
and so it could stand to be enhanced to do a better job.  The challenge is
striking the right balance between the two rates that is acceptable to
everyone.

[Bug c++/79002] Weird c++ assembly code generated for tail call

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
So do you suggest to run ehcleanup earlier, or another pass of it, or move
tailr?

[Bug fortran/78990] [5/6/7 Regression] ICE when assigning polymorphic array function result

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Started with r220482.

[Bug tree-optimization/78938] [7 Regression] ICE in expand_vec_cond_expr, at optabs.c:5636 w/ -mavx512bw -ftree-loop-vectorize -O1

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug libgcc/77265] Casting an extended precision long double "inf" to __float128 results in "nan"

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org

--- Comment #7 from Francois-Xavier Coudert  ---
Don't we want to backport this to fix the bug in GCC 6 series?

[Bug fortran/78983] [7 Regression] ICE with CAF-DT with allocatable member

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-05
 CC||vehre at gcc dot gnu.org
Summary|ICE with CAF-DT with|[7 Regression] ICE with
   |allocatable member  |CAF-DT with allocatable
   ||member
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
The code compiles with revision r242984 (2016-11-29), but gives an ICE with
r243219, likely r243021. Note the code compiles with -fcoarray=single.

[Bug fortran/78990] [5/6/7 Regression] ICE when assigning polymorphic array function result

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||4.8.5, 4.9.3
   Keywords||ice-on-valid-code
   Last reconfirmed||2017-01-05
 CC||pault at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ICE when assigning  |[5/6/7 Regression] ICE when
   |polymorphic array function  |assigning polymorphic array
   |result  |function result
  Known to fail||5.4.0, 6.3.0, 7.0

--- Comment #1 from Dominique d'Humieres  ---
I get the ICE from 5.4.0 up to trunk (7.0). The code compiles with 4.8.5 and
4.9.3 and gives at run time

   0   0   0

If I replace 'mold' with 'source', compiling the modified test gives an ICE
from 4.8 (at least) up to trunk (7.0).

The change occurred between revisions r220481 (2015-02-06, compile) and r220509
(2015-02-08, ICE), may be r 220482(?).

[Bug fortran/78958] FAIL: gfortran.dg/alloc_comp_class_5.f03 - Segmentation fault

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-05
 CC||vehre at gcc dot gnu.org
 Blocks||78672
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
On x86_64-apple-darwin16, compiling gfortran.dg/alloc_comp_class_5.f03 with
-fsanitize=address gives at run time

=
==15392==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x60200273 at pc 0x000108ec2ed9 bp 0x7fff56f7fb80 sp 0x7fff56f7f330
WRITE of size 3 at 0x60200273 thread T0
#0 0x108ec2ed8 in wrap_memmove (/opt/gcc/gcc7w/lib/libasan.4.dylib+0x41ed8)
#1 0x108c86723 in __copy_character_1.3652
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x17723)
#2 0x108c85c1f in __array_list_MOD_add_item
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x16c1f)
#3 0x108c86f82 in MAIN__
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x17f82)
#4 0x108c8919e in main
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x1a19e)
#5 0x7fffbd674254 in start (/usr/lib/system/libdyld.dylib+0x5254)

0x60200273 is located 0 bytes to the right of 3-byte region
[0x60200270,0x60200273)
allocated by thread T0 here:
#0 0x108ee1439 in wrap_malloc (/opt/gcc/gcc7w/lib/libasan.4.dylib+0x60439)
#1 0x108c84e71 in __array_list_MOD_add_item
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x15e71)
#2 0x108c86f82 in MAIN__
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x17f82)
#3 0x108c8919e in main
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x1a19e)
#4 0x7fffbd674254 in start (/usr/lib/system/libdyld.dylib+0x5254)

SUMMARY: AddressSanitizer: heap-buffer-overflow
(/opt/gcc/gcc7w/lib/libasan.4.dylib+0x41ed8) in wrap_memmove
Shadow bytes around the buggy address:
  0x1c03fff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c04: fa fa fd fd fa fa fd fd fa fa 00 07 fa fa 00 06
  0x1c040010: fa fa 03 fa fa fa 00 00 fa fa 00 06 fa fa 06 fa
  0x1c040020: fa fa 07 fa fa fa 07 fa fa fa fd fa fa fa fd fa
  0x1c040030: fa fa fd fd fa fa 00 fa fa fa 00 00 fa fa 00 fa
=>0x1c040040: fa fa 00 fa fa fa 00 00 fa fa 00 fa fa fa[03]fa
  0x1c040050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c040060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c040070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c040080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c040090: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==15392==ABORTING

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x108c8dee9
#1  0x108c8d243
#2  0x7fffbd881bb9
Abort

See also pr78672.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78672
[Bug 78672] Gfortran test suite failures with a sanitized compiler

[Bug pch/78970] GCC crashes if input file is dash

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Fixed on trunk so far.

[Bug pch/78970] GCC crashes if input file is dash

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Thu Jan  5 14:17:07 2017
New Revision: 244103

URL: https://gcc.gnu.org/viewcvs?rev=244103=gcc=rev
Log:
Error for '-' as filename of a precompiled header (PR pch/78970)

2017-01-05  Martin Liska  

PR pch/78970
* c-opts.c (c_common_post_options): Reject '-' filename for a
precompiled
header.
2017-01-05  Martin Liska  

PR pch/78970
* gcc.c (lookup_compiler): Reject '-' filename for a precompiled
header.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-opts.c
trunk/gcc/gcc.c

[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP

[wilco at gcc dot gnu.org]

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

--- Comment #19 from wilco at gcc dot gnu.org ---
> The commit in comment 14 has instroduced size and runtime regressions in the
> Spec2006 testsuite on s390x:

I get reproducible regressions on AArch64 as well with the latest patch
(changes >0.5%):

400.perlbench   -1.26%
403.gcc -3.16%
445.gobmk   -2.70%
458.sjeng   1.65%
464.h264ref -0.78%
453.povray  -2.65%

It seems this is worse than the earlier versions of the patch which all used
NOT_TAKEN.

[Bug tree-optimization/29333] Jump threading getting in the way of PHI-OPT

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #8 from rsandifo at gcc dot gnu.org  
---
This may be worth filing as another PR (let me know if you
think I should), but another case of VRP stymieing phiopt is:

void bar (int);
void
foo (int a, int b)
{
  if (!b)
bar (1);
  else
{
  int c;
  if (a)
c = a;
  else
c = 0;
  if (c == b)
bar (2);
}
}

Before vrp1 we have:

   [100.0%]:
  if (b_3(D) == 0)
goto ; [29.6%]
  else
goto ; [70.4%]

   [29.6%]:
  bar (1);
  goto ; [100.0%]

   [70.4%]:
  if (a_4(D) != 0)
goto ; [50.0%]
  else
goto ; [50.0%]

   [35.2%]:

   [70.4%]:
  # c_1 = PHI 
  if (c_1 == b_3(D))
goto ; [22.9%]
  else
goto ; [77.0%]

   [16.2%]:
  bar (2);

   [100.0%]:
  return;

phiopt would tell that c_1 is equal to a_4,
and after making that substitution, cfgcleanup
would remove blocks 4 and 5, leaving two comparisons
rather than three.

However, VRP runs first and threads 4->5 to 4->8,
giving:

  [100.0%]:
  if (b_3(D) == 0)
goto ; [29.6%]
  else
goto ; [70.4%]

   [29.6%]:
  bar (1);
  goto ; [100.0%]

   [70.4%]:
  if (a_4(D) != 0)
goto ; [50.0%]
  else
goto ; [50.0%]

   [35.2%]:
  # c_1 = PHI 
  if (c_1 == b_3(D))
goto ; [45.9%]
  else
goto ; [54.1%]

   [16.2%]:
  bar (2);

   [100.0%]:
  return;

   [35.2%]:
  # c_11 = PHI <0(4)>
  goto ; [100.0%]

We never "recover" from that and so the three comparisons
survive into the final output.

Removing the first !b comparison leaves no jump threading
opportunities, so phiopt kicks in as expected.

This is a cut-down version of what happens with things like
the safe_as_a calls in NEXT_INSN.  E.g. in the basic-block
iterator:

#define FOR_BB_INSNS(BB, INSN)  \
  for ((INSN) = BB_HEAD (BB);   \
   (INSN) && (INSN) != NEXT_INSN (BB_END (BB)); \
   (INSN) = NEXT_INSN (INSN))

we never get rid of the p null test in:

template 
inline T
safe_as_a (U *p)
{
  if (p)
{
  gcc_checking_assert (is_a  (p));
  return is_a_helper ::cast (p);
}
  else
return NULL;
}

even though in release builds the function should
reduce to "return p".

[Bug c/78973] warning: ‘memcpy’: specified size between 18446744071562067968 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
Created attachment 40466
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40466=edit
unreduced testcase

[Bug rtl-optimization/79003] [7 Regression] r238991 breaks ODR

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-05
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
wrapping struct invariant inside a namespace {} seems to work (but maybe
renaming to lra_invariant is prefered)

[Bug rtl-optimization/79003] New: [7 Regression] r238991 breaks ODR

[trippels at gcc dot gnu.org]

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

Bug ID: 79003
   Summary: [7 Regression] r238991 breaks ODR
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: vmakarov at gcc dot gnu.org
  Target Milestone: ---

r238991 breaks the ODR (pointed out by LTO bootstrap):

../../gcc/gcc/loop-invariant.c:100:8: warning: type ‘struct invariant’ violates
the C++ One Definition Rule [-Wodr]
 struct invariant
^
../../gcc/gcc/lra-constraints.c:4752:8: note: a different type is defined in
another translation unit
 struct invariant
^
../../gcc/gcc/loop-invariant.c:103:12: note: the first difference of
corresponding definitions is field ‘invno’
   unsigned invno;
^
../../gcc/gcc/lra-constraints.c:4755:7: note: a field with different name is
defined in another translation unit
   int num;
   ^

[Bug c++/79002] Weird c++ assembly code generated for tail call

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
And difference before tailcall detection is

--- a/t.C.042t.eipa_sra 2017-01-05 13:42:55.792951212 +0100
+++ b/t.C.042t.eipa_sra 2017-01-05 13:42:43.280808614 +0100
@@ -8,13 +8,13 @@
   int i;
   unsigned char * p.0_1;
   unsigned char _2;
-  int g.1_3;
+  int g.1_4;

[0.0%]:
   p.0_1 = p;
   _2 = *p.0_1;
-  g.1_3 = g;
-  if (g.1_3 >= j_7(D))
+  g.1_4 = g;
+  if (g.1_4 >= j_9(D))
 goto ; [0.0%]
   else
 goto ; [0.0%]
@@ -31,6 +31,9 @@
[0.0%]:
   return;

+ [0.0%]:
+  resx 1
+
 }

thus this is a generic EH optimization issue as well.  ehcleanup1 fixes this
but that runs after tailr1.

[Bug c++/79002] Weird c++ assembly code generated for tail call

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Looks like (i) makes i TREE_ADDRESSABLE somehow.

[Bug c++/79002] Weird c++ assembly code generated for tail call

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target|s390x   |s390x x86_64-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-05
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed on x86_64.  The difference is an added CLOBBER in the paren case
which leads to try/finally which leads to the tail recursion not being detected
and recursive inlining applying.

[Bug c++/78765] [7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (internal compiler error: in cp_build_addr_expr_1, at cp/typeck.c:5708)

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #4 from Nathan Sidwell  ---
Fixed r244101

[Bug c++/78765] [7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (internal compiler error: in cp_build_addr_expr_1, at cp/typeck.c:5708)

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
Author: nathan
Date: Thu Jan  5 12:30:26 2017
New Revision: 244101

URL: https://gcc.gnu.org/viewcvs?rev=244101=gcc=rev
Log:
cp/
PR c++/78765
* pt.c (convert_nontype_argument): Don't try and see if integral
or enum expressions are constants prematurely.

testsuite/
PR c++/78765
* g++.dg/cpp0x/pr78765.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr78765.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug c/16351] NULL dereference warnings

[jg at jguk dot org]

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

--- Comment #47 from Jon Grant  ---
I'm happy to pay a 400 USD bug bounty to contributors who introduce this
feature in GCC. Let's get this feature in! :)

[Bug c++/79002] New: Weird c++ assembly code generated for tail call

[vogt at linux dot vnet.ibm.com]

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

Bug ID: 79002
   Summary: Weird c++ assembly code generated for tail call
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vogt at linux dot vnet.ibm.com
  Target Milestone: ---
Target: s390x

G++ (r244001) generates some pretty weird assembly code on s390x for this test
case.  (Note that j is not initialised and I couldn't find a variant of this
test case where it is).

-- test.C --
int g;
unsigned char *p;
void r1()
{
  int i;
  int j;
  i = *p;
  if (j <= g || (i) != 1) // < note: parentheses around (i)
r1();
}


$ gcc -O3 -march=z10 -mzarch -m64 -S test.C
$ cat test.s

--
_Z2r1v:
lgrl%r2,p  <-- r2 := 
lrl %r1,g  <-- r1 := 
llc %r2,0(%r2) <-- r2 := *r2
.L5:
cijlh   %r2,1,.L2  <-- compare with immediate and jump if !=
.L4:
cijhe   %r1,0,.L11 <-- ... if >=
.L1:
br  %r14
.L11:
cijl%r1,0,.L1  <-- ... if <
cijl%r1,0,.L1
cijhe   %r1,0,.L4
br  %r14
.L2:
cijl%r1,0,.L5
cijl%r1,0,.L5
j   .L2
--

If the parentheses are removed from "(i)", the result is sane:

  ...
  if (j <= g || i != 1) // < note: no parentheses around i
  ...

--
_Z2r1v:
lgrl%r2,p
lrl %r1,g
llc %r2,0(%r2)
.L2:
cijhe   %r1,0,.L2
cijlh   %r2,1,.L2
br  %r14
--

Not tested on other targets, but to me it looks like a general C++ problem
(does not happen with the C compiler, at least not with this test case).  While
the generated code is valid, this effect makes reducing test cases from the
Spec2006 suite harder (there are variants of the code that result in even more
unnecessary labels and assembly code).  It might be possible to trigger this
without relying on undefined variables.

[Bug c++/78948] [C++17] constexpr if instantiating too eagerly

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Related questions:
Are uses of deleted functions ok in discarded stmts?
Should we warn about uses of deprecated functions/vars in discarded stmts?
Shall we ever set DECL_ODR_USED on odr-used decls in discarded stmts?

[Bug middle-end/78995] A strange copy error caused by O3 optimization

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
(In reply to feiz from comment #4)
> (In reply to Richard Biener from comment #2)
> > static inline void
> > rte_memcpy(void *dst, const void *src, size_t n)
> > {
> > uintptr_t dstu = (uintptr_t)dst;
> > uintptr_t srcu = (uintptr_t)src;
> > 
> > *(uint32_t *)dstu = *(const uint32_t *)srcu;
> > 
> > this is violating strict aliasing rules as you are copying
> > 
> > typedef unsigned short  WORD;
> > 
> > struct TFieldHeader
> > {
> > WORD FieldID;
> > WORD Size;
> > };
> 
> Well, that's right. I add the compile option  -fno-strict-aliasing, and it
> works.
> To get a better performance, I got the rte_memcpy code from dpdk codes to
> replace memcpy in our project.
> 
> Very thanks for your  help. And I have one more question about this.
> 
> I check some instruction about aliasing, like 
> "Strict aliasing is an assumption, made by the C (or C++) compiler, that
> dereferencing pointers to objects of different types will never refer to the
> same memory location (i.e. alias eachother.)".
> 
> I am confused, we always use the following actions, does this safe?

yes

> char  buf[1024];
> struct A {
>  int a;
>  int b;
> };
> 
> struct p * = (struct A*)buf;
> p->a =01;
> p->b = 02;

[Bug c++/78948] [C++17] constexpr if instantiating too eagerly

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
During parsing, we call mark_used on the function to call, which in turn does
instantiate_decl -> add_pending_template.
So, shall we avoid calling mark_used from parser->in_discarded_stmt (we'd need
to propagate that flag down to call.c), something different?

[Bug libstdc++/78991] std::sort and std::unique can not use std::function with clang++ -std=c++14

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
   Last reconfirmed||2017-01-05
 Resolution|INVALID |---
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Jonathan Wakely  ---
I'm not convinced this is a clang bug, but either way we can work around it
fairly easily in libstdc++.

[Bug tree-optimization/78997] [7 regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Built by

#2  0x011c1759 in vectorizable_condition (
stmt=, gsi=0x7fffd460, 
vec_stmt=0x7fffd378, reduc_def=, reduc_index=0, 
slp_node=0x296b8a0)
at /space/rguenther/src/svn/gcc-7-branch/gcc/tree-vect-stmts.c:7962
7962  vec_else_clause);
(gdb) l
7957vec_cond_lhs, vec_cond_rhs);
7958}
7959  new_temp = make_ssa_name (vec_dest);
7960  new_stmt = gimple_build_assign (new_temp, VEC_COND_EXPR,
7961  vec_compare, vec_then_clause,
7962  vec_else_clause);
7963  vect_finish_stmt_generation (stmt, new_stmt, gsi);
7964  if (slp_node)
7965SLP_TREE_VEC_STMTS (slp_node).quick_push (new_stmt);
7966}

masked is true.

_ifc__822 = _898 ? _ifc__823 : _ifc__824;

with _898 _Bool and the type of the cond being short int.  We properly compute
comp_vectype to V8HI but the SLP defs are V16QI.

Not sure where we are supposed to fix this up (or reject vectorization).  But
it looks like

_898 = _854 & _879;

is in a pattern patt_711 = _854 & patt_712;

and that has a VECTYPE of V8HI (but ends up being vectorized as V16QI because
the LHS type is still _Bool).

The SLP node has different COND_EXPRs with all the same condition btw.

t.c:16:6: note: vect_recog_mask_conversion_pattern: detected:
t.c:16:6: note: mask_conversion pattern recognized: patt_711 = _854 & patt_712;

ah, and we're building the SLP node with the condition from scalars!  That's
where things must go wrong...

t.c:16:6: note: Final SLP tree for instance:
t.c:16:6: note: node
t.c:16:6: note: stmt 0 bc[2] = _ifc__822;
t.c:16:6: note: stmt 1 bc[3] = _ifc__819;
t.c:16:6: note: stmt 2 bc[4] = _ifc__816;
t.c:16:6: note: stmt 3 bc[5] = _ifc__813;
t.c:16:6: note: stmt 4 bc[6] = _ifc__810;
t.c:16:6: note: stmt 5 bc[7] = _ifc__807;
t.c:16:6: note: stmt 6 bc[8] = _ifc__804;
t.c:16:6: note: stmt 7 bc[9] = _ifc__801;
t.c:16:6: note: node
t.c:16:6: note: stmt 0 _ifc__822 = _898 ? _ifc__823 : _ifc__824;
t.c:16:6: note: stmt 1 _ifc__819 = _898 ? _ifc__820 : _ifc__821;
t.c:16:6: note: stmt 2 _ifc__816 = _898 ? _ifc__817 : _ifc__818;
t.c:16:6: note: stmt 3 _ifc__813 = _898 ? _ifc__814 : _ifc__815;
t.c:16:6: note: stmt 4 _ifc__810 = _898 ? _ifc__811 : _ifc__812;
t.c:16:6: note: stmt 5 _ifc__807 = _898 ? _ifc__808 : _ifc__809;
t.c:16:6: note: stmt 6 _ifc__804 = _898 ? _ifc__805 : _ifc__806;
t.c:16:6: note: stmt 7 _ifc__801 = _898 ? _ifc__802 : _ifc__803;
t.c:16:6: note: node (external)
t.c:16:6: note: stmt 0 patt_711 = _854 & patt_712;
t.c:16:6: note: stmt 1 patt_711 = _854 & patt_712;
t.c:16:6: note: stmt 2 patt_711 = _854 & patt_712;
...

OTOH vect_recog_mask_conversion_pattern looks somewhat odd -- we end up
with a pattern stmt _Bool(QI) = _Bool(QI) & _Bool(HI);


Fix that works for the testcase:

Index: gcc/tree-vect-slp.c
===
--- gcc/tree-vect-slp.c (revision 244093)
+++ gcc/tree-vect-slp.c (working copy)
@@ -2897,9 +2897,8 @@ vect_mask_constant_operand_p (gimple *st
   tree cond = gimple_assign_rhs1 (stmt);

   if (TREE_CODE (cond) == SSA_NAME)
-   return false;
-
-  if (opnum)
+   op = cond;
+  else if (opnum)
op = TREE_OPERAND (cond, 1);
   else
op = TREE_OPERAND (cond, 0);

[Bug c++/79001] New: spurious "defined but not used" warning with explicit instantiation

[jens.maurer at gmx dot net]

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

Bug ID: 79001
   Summary: spurious "defined but not used" warning with explicit
instantiation
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jens.maurer at gmx dot net
  Target Milestone: ---

The following testcase gives a "defined but not used" warning for "f", but not
for "g".  I agree that "f" cannot be used outside of the translation unit (due
to the use of a type from an anonymous namespace), but neither can "g".

Plus, if someone does use explicit instantiations on a class, it does not seem
helpful to  produce "unused function" warnings for functions generated from an
explicit instantiation on a class in the first place, because the class (maybe
from a library) might have a lot more member functions than actually in use in
any given file.


template 
class C {
  void f();
  void g() { }
};

template
void C::f() { }

namespace {
  struct X { };
}

template class C;


V$ gcc -Wunused-function   -c x.cc
x.cc:9:6: warning: ‘void C::f() [with T = {anonymous}::X]’ defined but not
used [-Wunused-function]
 void C::f() { }
  ^~~~

[Bug middle-end/78995] A strange copy error caused by O3 optimization

[zhangfei1 at cffex dot com.cn]

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

--- Comment #4 from feiz  ---
(In reply to Richard Biener from comment #2)
> static inline void
> rte_memcpy(void *dst, const void *src, size_t n)
> {
> uintptr_t dstu = (uintptr_t)dst;
> uintptr_t srcu = (uintptr_t)src;
> 
> *(uint32_t *)dstu = *(const uint32_t *)srcu;
> 
> this is violating strict aliasing rules as you are copying
> 
> typedef unsigned short  WORD;
> 
> struct TFieldHeader
> {
> WORD FieldID;
> WORD Size;
> };

Well, that's right. I add the compile option  -fno-strict-aliasing, and it
works.
To get a better performance, I got the rte_memcpy code from dpdk codes to
replace memcpy in our project.

Very thanks for your  help. And I have one more question about this.

I check some instruction about aliasing, like 
"Strict aliasing is an assumption, made by the C (or C++) compiler, that
dereferencing pointers to objects of different types will never refer to the
same memory location (i.e. alias eachother.)".

I am confused, we always use the following actions, does this safe?

char  buf[1024];
struct A {
 int a;
 int b;
};

struct p * = (struct A*)buf;
p->a =01;
p->b = 02;

[Bug middle-end/78995] A strange copy error caused by O3 optimization

[zhangfei1 at cffex dot com.cn]

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

--- Comment #3 from feiz  ---
(In reply to Andrew Pinski from comment #1)
> Does adding -fno-strict-aliasing fix the problem you are seeing?
> 
> I am suspecting the code is violating C/C++ aliasing rules.

Yeah, that's right. I try the -fno-strict-aliasing options, and it works.
Very thanks for your help.

[Bug debug/79000] ICE: in gen_member_die, at dwarf2out.c:23995

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-01-05
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Known to fail||7.0

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

(gdb) p type->type_common.main_variant 
$3 = 
(gdb) p type
$4 = 

we're coming from calling

#8  0x007a6f36 in lto_read_decls (decl_data=0x2aad8000, 
data=0x2aaf1628, resolutions=...)
at /space/rguenther/src/svn/gcc-7-branch/gcc/lto/lto.c:1756
1756  debug_hooks->type_decl (t, !DECL_FILE_SCOPE_P (t));

on the C11 TU type decl.  The type decls type is not the main variant (the C
FE builds a type for B with main variant A).

But the assert in dwarf2out is weird.  We're coming via

  if (is_naming_typedef_decl (TYPE_NAME (type)))
{
  /* Here, we are in the case of decl being a typedef naming
 an anonymous type, e.g:
 typedef struct {...} foo;
 In that case TREE_TYPE (decl) is not a typedef variant
 type and TYPE_NAME of the anonymous type is set to the
 TYPE_DECL of the typedef. This construct is emitted by
 the C++ FE. 

 TYPE is the anonymous struct named by the typedef
 DECL. As we need the DW_AT_type attribute of the
 DW_TAG_typedef to point to the DIE of TYPE, let's
 generate that DIE right away. add_type_attribute
 called below will then pick (via lookup_type_die) that
 anonymous struct DIE.  */
  if (!TREE_ASM_WRITTEN (type))
gen_tagged_type_die (type, context_die, DINFO_USAGE_DIR_USE);

but the type is from the C FE.  Of course we have

static bool
is_naming_typedef_decl (const_tree decl)
{   
  if (decl == NULL_TREE 
  || TREE_CODE (decl) != TYPE_DECL
  || DECL_NAMELESS (decl)
  || !is_tagged_type (TREE_TYPE (decl))
  || DECL_IS_BUILTIN (decl)
  || is_redundant_typedef (decl)
  /* It looks like Ada produces TYPE_DECLs that are very similar
 to C++ naming typedefs but that have different
 semantics. Let's be specific to c++ for now.  */
  || !is_cxx ())

but is_cxx doesn't work (it can't possibly without a context).  In LTO
we choose a "common" language and set it to C++ when combining C and C++
source.

With early LTO debug this will be solved by not generating type DIEs late.

Without this I don't see anything better than simply silencing the assert
but doing that results in

lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:29324
0x91b749 dwarf2out_finish
/space/rguenther/src/svn/gcc-7-branch/gcc/dwarf2out.c:29324
Please submit a full bug report,
(gdb) p *deferred_asm_name 
$2 = {
  die = >, created_for = , next = 0x0}
(gdb) p debug_dwarf_die (0x2c23c140)
DIE0: DW_TAG_structure_type (0x2c23c140)
  abbrev id: 0 offset: 0 mark: 0
  DW_AT_name: "b"
  DW_AT_byte_size: 0
  DW_AT_decl_file: "2.i" (0)
  DW_AT_decl_line: 2

from the very same code:

  /* This is a GNU Extension.  We are adding a
 DW_AT_linkage_name attribute to the DIE of the
 anonymous struct TYPE.  The value of that attribute
 is the name of the typedef decl naming the anonymous
 struct.  This greatly eases the work of consumers of
 this debug info.  */
  add_linkage_name_raw (lookup_type_die (type), decl);

but of course the C type doesn't have a DECL_ASSEMBLER_NAME set...

Fixing it with the following works though:

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 244093)
+++ gcc/dwarf2out.c (working copy)
@@ -3356,6 +3356,7 @@ static int get_AT_flag (dw_die_ref, enum
 static unsigned get_AT_unsigned (dw_die_ref, enum dwarf_attribute);
 static inline dw_die_ref get_AT_ref (dw_die_ref, enum dwarf_attribute);
 static bool is_cxx (void);
+static bool is_cxx (const_tree);
 static bool is_fortran (void);
 static bool is_ada (void);
 static bool remove_AT (dw_die_ref, enum dwarf_attribute);
@@ -4990,6 +4991,19 @@ is_cxx (void)
  || lang == DW_LANG_C_plus_plus_11 || lang == DW_LANG_C_plus_plus_14);
 }

+/* Return TRUE if DECL was created by the C++ frontend.  */
+
+static bool
+is_cxx (const_tree decl)
+{
+  while (DECL_CONTEXT (decl))
+decl = DECL_CONTEXT (decl);
+  if (TREE_CODE (decl) == TRANSLATION_UNIT_DECL
+  && TRANSLATION_UNIT_LANGUAGE (decl))
+return strncmp (TRANSLATION_UNIT_LANGUAGE (decl), "GNU 

[Bug testsuite/77734] FAIL: gcc.dg/plugin/must-tail-call-1.c -fplugin=./must_tail_call_plugin.so (test for excess errors)

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #2 from Rainer Orth  ---
David,

as you already mentioned in

https://gcc.gnu.org/ml/jit/2016-q2/msg00058.html

this is the last remaining failure.  How should we deal with it to get clean
testsuite results on the affected targets?

Thanks.
  Rainer

[Bug libstdc++/78979] 27_io/headers/cstdio/functions_neg.cc FAILs on Solaris

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2017-01/msg00290.ht
   ||ml
   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org

--- Comment #4 from Rainer Orth  ---
Mine, patch submitted.

[Bug middle-end/78995] A strange copy error caused by O3 optimization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Richard Biener  ---
static inline void
rte_memcpy(void *dst, const void *src, size_t n)
{
uintptr_t dstu = (uintptr_t)dst;
uintptr_t srcu = (uintptr_t)src;

*(uint32_t *)dstu = *(const uint32_t *)srcu;

this is violating strict aliasing rules as you are copying

typedef unsigned short  WORD;

struct TFieldHeader
{
WORD FieldID;
WORD Size;
};

[Bug tree-optimization/78997] [7 regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|NEW |ASSIGNED
Version|unknown |7.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |7.0
Summary|[7.0 regression] ICE on |[7 regression] ICE on valid
   |valid code at -O3 on|code at -O3 on
   |x86_64-linux-gnu:   |x86_64-linux-gnu:
   |verify_gimple failed|verify_gimple failed

--- Comment #2 from Richard Biener  ---
Mine then.

[Bug go/78978] [7 regression] runtime/pprof FAILs on Solaris 2/x86

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2017-01/msg00287.ht
   ||ml
   Last reconfirmed||2017-01-05
   Assignee|ian at airs dot com|ro at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Rainer Orth  ---
Mine, patch submitted.

[Bug sanitizer/78815] [7 Regression] ICE: segfault with -fopenmp -fsanitize=address

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Fixed.

[Bug sanitizer/78815] [7 Regression] ICE: segfault with -fopenmp -fsanitize=address

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Thu Jan  5 09:16:50 2017
New Revision: 244095

URL: https://gcc.gnu.org/viewcvs?rev=244095=gcc=rev
Log:
Do not sanitize in an abnormal context (PR sanitizer/78815).

2017-01-05  Martin Liska  

PR sanitizer/78815
* gimplify.c (gimplify_decl_expr): Compare to
asan_poisoned_variables instread of checking flags.
(gimplify_target_expr): Likewise.
(gimplify_expr): Likewise.
(gimplify_function_tree): Conditionally initialize
asan_poisoned_variables.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c

[Bug tree-optimization/76957] [7 regression] FAIL: gcc.dg/graphite/scop-dsyr2k.c scan-tree-dump-times graphite "number of SCoPs

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||law at redhat dot com

[Bug rtl-optimization/78342] ICE in rtl_verify_bb_insns, at cfgrtl.c:2657 (error: flow control insn inside a basic block)

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #13 from Segher Boessenkool  ---
Right, I cannot trigger any of these failures on 5 or 6.  So I'll just
close this PR.

[Bug rtl-optimization/78342] ICE in rtl_verify_bb_insns, at cfgrtl.c:2657 (error: flow control insn inside a basic block)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
Summary|[7 Regression] ICE in   |ICE in rtl_verify_bb_insns,
   |rtl_verify_bb_insns, at |at cfgrtl.c:2657 (error:
   |cfgrtl.c:2657 (error: flow  |flow control insn inside a
   |control insn inside a basic |basic block)
   |block)  |

--- Comment #12 from Jeffrey A. Law  ---
Given the combine issue for this BZ is resolved, it certainly shouldn't be
marked as a regression for gcc-7.  I'm also not sure a backport is really
warranted.  While it's possible in theory to trigger these failures in older
releases, it's hard.

The addition of path isolation of division by zero is what's made this stuff so
much easier to trigger on the trunk.

Segher keep open if you want to backport the fixes, but this shouldn't have a
gcc-7 regression marker anymore.

[Bug bootstrap/78616] Poison strndup in system.h

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
Summary|[7 regression] bootstrap|Poison strndup in system.h
   |fails for x86_64-darwin at  |
   |stage1 after 243030 when|
   |the bootstrap compiler  |
   |doesn't have strndup|

--- Comment #12 from Jeffrey A. Law  ---
Regression fixed (regression marker removed).  All that's left is to poison
strndup in system.h

[Bug rtl-optimization/78652] Add testcase for LRA generates wrong code by inheriting changed register

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-05
 CC||law at redhat dot com
Summary|[7 regression]LRA generates |Add testcase for LRA
   |wrong code by inheriting|generates wrong code by
   |changed register|inheriting changed register
 Ever confirmed|0   |1

--- Comment #6 from Jeffrey A. Law  ---
No longer a regression, just a need to add a testcase.

[Bug rtl-optimization/78812] [5/6 Regression] Wrong code generation due to hoisting memory load across function call

[rguenther at suse dot de]

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

--- Comment #15 from rguenther at suse dot de  ---
On Wed, 4 Jan 2017, law at redhat dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78812
> 
> Jeffrey A. Law  changed:
> 
>What|Removed |Added
> 
>Assignee|unassigned at gcc dot gnu.org  |law at redhat dot com
> 
> --- Comment #10 from Jeffrey A. Law  ---
> So EDGE_EH implies EDGE_ABNORMAL, so the patch in c#8 isn't going to have any
> impact.  The real bug is more subtle.

EDGE_EH does not imply EDGE_ABNORMAL.

[Bug bootstrap/78880] [7 Regression] Revision 243196 breaks bootstrap on x86_64-w64-mingw32

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |INVALID

--- Comment #2 from Jeffrey A. Law  ---
When using a sysroot STARTFILE_PREFIX is supposed to be relative to the sysroot
variable -- meaning the mingw port is no longer going to be looking in
/mingw/lib by default.  Instead it should be looking in $sysroot/mingw/lib.