[Bug libstdc++/79195] New: make_array should not ask for common_type when the type is explicitly specified

[rs2740 at gmail dot com]

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

Bug ID: 79195
   Summary: make_array should not ask for common_type when the
type is explicitly specified
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

This does not compile:

#include 

struct A {};
struct B : A {};
struct C : A {};
auto arr = std::experimental::make_array(B{}, C{});

because make_array's return type computes

conditional_t, common_type_t<_Types...>, _Dest>

which instantiates common_type_t and results in a substitution failure.
There shouldn't be a need to instantiate it when the desired element type is
explicitly specified.

[Bug libstdc++/79195] make_array should not ask for common_type when the type is explicitly specified

[rs2740 at gmail dot com]

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

--- Comment #1 from TC  ---
While we are here, the `return {{forward<_Types>(__t)...}};` in the body should
call std::forward qualified.

[Bug middle-end/56727] Recursive call goes through the PLT unnecessarily

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #5 from Yuri Gribov  ---
Created attachment 40562
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40562&action=edit
Draft patch

(In reply to Thiago Macieira from comment #0)
> What's more, since the argument wasn't used, it's also
> unnecessary to set it.

This may be due to contrivedness of example (endless loop, etc.). The argument
seems to be forwarded in normal cases.

(In reply to Jan Hubicka from comment #3)
> The canonical way to do it is to create a static alias and the redirect call
> to the alias. We do that in FE for some specific examples (like thunks) but
> not in general.  Doing so would indeed make sense.

Would something like attached draft patch be ok?

(In reply to Jakub Jelinek from comment #4)
> Note it would need to be done with lots of care, because you can e.g. have
> aliases to the function and in that case you should go through the PLT:

Note that we already violate this. E.g. in Thiago's reprocase compiler
shouldn't have figured out
that there is and endless loop. I can also see that recursive factorial
implementation is expanded to loop
even under -fPIC. Should I fix this?

[Bug sanitizer/79168] [7 Regression] libtsan fails to link when cross compiling GCC tip for Aarch64 target

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
   Target Milestone|--- |7.0
Summary|libtsan fails to link when  |[7 Regression] libtsan
   |cross compiling GCC tip for |fails to link when cross
   |Aarch64 target  |compiling GCC tip for
   ||Aarch64 target

[Bug target/79173] add-with-carry and subtract-with-borrow support (x86_64 and others)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-23
Version|unknown |7.0
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #3 from Richard Biener  ---
Confirmed, the bug should possibly be split (Clang compatible builtins, target
specific detection of patterns, middle-end detection of patterns).  Note a
suitable middle-end representation would not have the address argument but
likely
return two values (via the usual _Complex int trick).

[Bug middle-end/79176] [6/7 Regression] ICE in mangle_decl with LTO and Os

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Component|c++ |middle-end
   Target Milestone|--- |6.4

[Bug tree-optimization/79186] [7 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: Segmentation fault (in VRP)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
I will have a looksee.

[Bug target/79185] [5/6/7 Regression] register allocation in the addition of two 128 bit ints

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/79187] [7 Regression] wrong code at -Os on x86_64-linux-gnu (generated code segfaults)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/79188] [7 Regression] wrong code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Maybe related to PR79088.

[Bug go/79146] [7 Regression] Bootstrapping go on s390x fails; redefined symbols

[vogt at linux dot vnet.ibm.com]

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

--- Comment #6 from Dominik Vogt  ---
Fixed.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

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

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Started with r242075 (though, most likely that just revealed a previously
latent RTL opt bug).

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-23
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug tree-optimization/77445] [7 Regression] Performance drop after r239219 on coremark test

[hubicka at gcc dot gnu.org]

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

--- Comment #19 from Jan Hubicka  ---
One change that would make sense to me is to always thread when there is a
non-cold block on the path: we are not only improving the path taken when
threading but because we eliminate incoming edges we also permit better
optimization of non-thread path later.

This way we thread the branch, because there is still non-cold BB on a way.

On related note, I have noticed that we give up on about 30% of jump threads in
early optimization because of:

   /* Skip edges pointing outside the current loop.  */
   if (!arg || var_bb->loop_father != bbi->loop_father)
continue;

This is very common case such as in:
char *c;
int t()
{
  for (int i=0;i<5000;i++)
c[i]=i;
}

before loop header copying there is threadable branch at first iteration.
Threading it before profile construction would be quite desirable.

There seem to be code deciding on loops when checking path profitability. It
seems to me that at least the code can be adjusted to accept thread starting by
loop header when there is only single edge in becausee that can't make
irreducible loops?

Honza

[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"

[chefmax at gcc dot gnu.org]

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

--- Comment #17 from chefmax at gcc dot gnu.org ---
Author: chefmax
Date: Mon Jan 23 09:12:29 2017
New Revision: 244773

URL: https://gcc.gnu.org/viewcvs?rev=244773&root=gcc&view=rev
Log:
Revert fix for PR lto/79061 due to this regresses compile-time by 100%
on some fortran cases.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/asan.c
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/cpp/mi1.c
trunk/gcc/testsuite/gcc.dg/pch/cpp-3.c
trunk/gcc/tree.c

[Bug tree-optimization/78604] [7 regression] test case gcc.target/powerpc/p8vector-vectorize-1.c fails starting with r242750

[amker at gcc dot gnu.org]

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

--- Comment #7 from amker at gcc dot gnu.org ---
(In reply to Michael Meissner from comment #6)
> Unless -ffast-math or -fno-honor-nans is used, you cannot invert < to >=,
> because you will get a different result if either operand is a NaN. 
> However, the basic code for vector compares hasn't changed much since the
> early power7 days.

I don't know details in power.  Though it's vectorized instruction, it has
integer inner type.  That's why the "<" is converted to ">=" in tree-ifcvt just
before vectorizer.  Is it safe to transform in this case?  Thanks.

[Bug tree-optimization/77445] [7 Regression] Performance drop after r239219 on coremark test

[rguenther at suse dot de]

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

--- Comment #20 from rguenther at suse dot de  ---
On Mon, 23 Jan 2017, hubicka at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
> 
> --- Comment #19 from Jan Hubicka  ---
> One change that would make sense to me is to always thread when there is a
> non-cold block on the path: we are not only improving the path taken when
> threading but because we eliminate incoming edges we also permit better
> optimization of non-thread path later.
> 
> This way we thread the branch, because there is still non-cold BB on a way.
> 
> On related note, I have noticed that we give up on about 30% of jump threads 
> in
> early optimization because of:
> 
>/* Skip edges pointing outside the current loop.  */
>if (!arg || var_bb->loop_father != bbi->loop_father)
> continue;
> 
> This is very common case such as in:
> char *c;
> int t()
> {
>   for (int i=0;i<5000;i++)
> c[i]=i;
> }
> 
> before loop header copying there is threadable branch at first iteration.
> Threading it before profile construction would be quite desirable.
> 
> There seem to be code deciding on loops when checking path profitability. It
> seems to me that at least the code can be adjusted to accept thread starting 
> by
> loop header when there is only single edge in becausee that can't make
> irreducible loops?

But it will rotate the loop and thus change the loop header block?  Then
we need to make sure to preserve that properly to not destroy loop
annotations by removing/rediscovering the loop.

Also we need to make sure to not repeatedly peel the loop via such 
mechanism.

[Bug fortran/79165] [7 Regression] 100% compile-time increase for polyhedron aermod by r244581

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Ok, so the reason for the slowness is that the Fortran frontend emits full
diagnostics to a temporary buffer for gfc_match_rvalue:

/* Match a function reference.  */
function0:
  m = gfc_match_actual_arglist (0, &actual_arglist);
  if (m == MATCH_NO)
{
  if (sym->attr.proc == PROC_ST_FUNCTION)
gfc_error ("Statement function %qs requires argument list at %C",
   sym->name);
  else
gfc_error ("Function %qs requires an argument list at %C",
   sym->name);

  m = MATCH_ERROR;
  break;
}

for aermod that's 18748 times.  And what slows down with the linemap mangling
is showing of the caret location (location_get_source_line/get_next_line
and thus the fcache I suppose).

Tentatively remembering an error like above is of course quite broken (read:
expensive).

So somehow with the tree.c hunk of the patch location_get_source_line
(inclusive callees) gets 90 times more expensive (when using callgrind on
aermod).

[Bug c++/79180] Nested lambda-capture causes segfault for parameter pack

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-23
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Simplified testcase:
void
foo (int a)
{
  if (a != 127)
__builtin_abort ();
}

template 
void
bar (Args &&... args)
{
  [&]() { [&]() { foo (args...); } (); } ();
}

int
main ()
{
  int x = 127;
  bar (x);
}

[Bug tree-optimization/79186] [7 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: Segmentation fault (in VRP)

[rguenth at gcc dot gnu.org]

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

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

[Bug tree-optimization/79187] [7 Regression] wrong code at -Os on x86_64-linux-gnu (generated code segfaults)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

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

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

[Bug testsuite/79126] FAIL: gcc.dg/tree-ssa/pr77445-2.c scan-tree-dump thread1 "Jumps threaded: 16"

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #2 from Christophe Lyon  ---
I don't think that's correct: I've noticed a new error message between r244739
and r244756, and you committed this in-between (r244746).

The error appears in gcc.sum:
  (DejaGnu) proc "1-9" does not exist.

[Bug testsuite/79126] FAIL: gcc.dg/tree-ssa/pr77445-2.c scan-tree-dump thread1 "Jumps threaded: 16"

[thopre01 at gcc dot gnu.org]

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

--- Comment #3 from Thomas Preud'homme  ---
(In reply to Christophe Lyon from comment #2)
> I don't think that's correct: I've noticed a new error message between
> r244739 and r244756, and you committed this in-between (r244746).
> 
> The error appears in gcc.sum:
>   (DejaGnu) proc "1-9" does not exist.

Some escaping seems to be missing. It should be \[1-9\].

[Bug c++/79180] Nested lambda-capture causes segfault for parameter pack

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||jason at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Seems there is a mismatch between what PARM_DECL is used.

E.g. -fdump-tree-omplower-all dump shows:
void bar(Args&& ...) [with Args = {int&}] (intD.9 & args#0D.2308)
{
  struct __lambda0D.2311 D.2341;
  typedef struct __lambda0D.2311 __lambda0D.2311;

  D.2341.__args#0D.2317 = args#0D.2339;
...

One args#0 PARM_DECL, with uid 2308 is created during:
#1  0x014689bf in copy_node_stat (node=)
at ../../gcc/tree.c:1157
#2  0x00823237 in tsubst_decl (t=,
args=, complain=0) at ../../gcc/cp/pt.c:12447
#3  0x00826de5 in tsubst (t=,
args=, complain=0, 
in_decl=) at ../../gcc/cp/pt.c:13272
#4  0x0082150e in tsubst_decl (t=,
args=, complain=0)
at ../../gcc/cp/pt.c:12273
#5  0x00826de5 in tsubst (t=,
args=, complain=0, 
in_decl=) at ../../gcc/cp/pt.c:13272
#6  0x00841d23 in instantiate_template_1 (tmpl=, orig_args=, complain=0)
at ../../gcc/cp/pt.c:18089
#7  0x0084231d in instantiate_template (tmpl=, orig_args=, complain=0)
at ../../gcc/cp/pt.c:18145
#8  0x00843683 in fn_type_unification (fn=, explicit_targs=, targs=, 
args=0x7fffc8a0, nargs=1, return_type=, strict=DEDUCE_CALL,
flags=1, explain_p=false, decltype_p=false)
at ../../gcc/cp/pt.c:18525
#9  0x0076f4c2 in add_template_candidate_real
(candidates=0x7fffcba0, tmpl=,
ctype=, 
explicit_targs=, first_arg=, arglist=0x7fffefc4a9d8,
return_type=, access_path=, 
conversion_path=, flags=1, obj=, strict=DEDUCE_CALL,
complain=3) at ../../gcc/cp/call.c:3164
#10 0x0076f91f in add_template_candidate (candidates=0x7fffcba0,
tmpl=, ctype=, 
explicit_targs=, first_arg=, arglist=0x7fffefc4a9d8,
return_type=, access_path=, 
conversion_path=, flags=1, strict=DEDUCE_CALL, complain=3) at
../../gcc/cp/call.c:3246
#11 0x00777c8b in add_candidates (fns=,
first_arg=, args=0x7fffefc4a9d8, return_type=, 
explicit_targs=, template_only=false, conversion_path=,
access_path=, flags=1, candidates=0x7fffcba0, 
complain=3) at ../../gcc/cp/call.c:5488
#12 0x00772af7 in perform_overload_resolution (fn=, args=0x7fffefc4a9d8, candidates=0x7fffcba0, 
any_viable_p=0x7fffcb9f, complain=3) at ../../gcc/cp/call.c:4142
#13 0x00772de4 in build_new_function_call (fn=, args=0x7fffcd20 = {...}, koenig_p=true, complain=3)
at ../../gcc/cp/call.c:4227
#14 0x009a7943 in finish_call_expr (fn=,
args=0x7fffcd20 = {...}, disallow_virtual=false, koenig_p=true, 
complain=3) at ../../gcc/cp/semantics.c:2441
#15 0x008e5475 in cp_parser_postfix_expression (parser=0x77ff5bd0,
address_p=false, cast_p=false, member_access_only_p=false, 
decltype_p=false, pidk_return=0x0) at ../../gcc/cp/parser.c:7019

i.e. on:
12273   DECL_ARGUMENTS (r) = tsubst (DECL_ARGUMENTS (t), args,
12274complain, t);

The other args#0 PARM_DECL is created during:
#1  0x014689bf in copy_node_stat (node=)
at ../../gcc/tree.c:1157
#2  0x00823237 in tsubst_decl (t=,
args=, complain=3) at ../../gcc/cp/pt.c:12447
#3  0x0081c3aa in tsubst_pack_expansion (t=, args=, complain=3, 
in_decl=) at ../../gcc/cp/pt.c:11313
#4  0x0083df90 in tsubst_copy_and_build (t=,
args=, complain=3, in_decl=, 
function_p=false, integral_constant_expression_p=false) at
../../gcc/cp/pt.c:17384
#5  0x0081a380 in instantiate_class_template_1 (type=) at ../../gcc/cp/pt.c:10691
#6  0x0081a685 in instantiate_class_template (type=) at ../../gcc/cp/pt.c:10749
#7  0x0093ebad in complete_type (type=) at ../../gcc/cp/typeck.c:133
#8  0x0084068f in tsubst_copy_and_build (t=, args=, complain=3, 
in_decl=, function_p=true,
integral_constant_expression_p=false) at ../../gcc/cp/pt.c:17800
#9  0x0083c0d0 in tsubst_copy_and_build (t=,
args=, complain=3, 
in_decl=, function_p=false,
integral_constant_expression_p=false) at ../../gcc/cp/pt.c:17077
#10 0x00838e48 in tsubst_expr (t=,
args=, complain=3, 
in_decl=,
integral_constant_expression_p=false) at ../../gcc/cp/pt.c:16403
#11 0x00833445 in tsubst_expr (t=,
args=, complain=3, 
in_decl=,
integral_constant_expression_p=false) at ../../gcc/cp/pt.c:15671
#12 0x0083332a in tsubst_expr (t=,
args=, complain=3, 
in_decl=,
integral_constant_expression_p=false) at ../../gcc/cp/pt.c:15657
#13 0x00834f77 in tsubst_expr (t=,
args=, complain=3, 
in_decl=,
integral_constant_expression_p=false) at ../../gcc/cp/pt

[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2017-01-23
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #18 from Jakub Jelinek  ---
The fix has been reverted.

[Bug libstdc++/79190] [7 Regression] ld: (Warning) Unsatisfied symbol "aligned_alloc"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
By fallback, do you mean just malloc of needed size + alignment + sizeof
(size_t)
or something similar and storing say the difference between the returned
pointer and what malloc returned into the size_t word before the returned
pointer and then not using free on the pointer with which aligned delete is
called, but subtracting the padding from that first?  If aligned new must be
always accompanied with aligned delete, then it could work, otherwise you'd
need to wrap all new and all deletes.

[Bug libstdc++/79190] [7 Regression] ld: (Warning) Unsatisfied symbol "aligned_alloc"

[glisse at gcc dot gnu.org]

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

--- Comment #6 from Marc Glisse  ---
(In reply to Jakub Jelinek from comment #5)
> If aligned new must be
> always accompanied with aligned delete, then it could work, otherwise you'd
> need to wrap all new and all deletes.

We are using _aligned_malloc / _aligned_free on Windows, so it has to be the
case that alignment matches in allocation and deallocation.

[Bug tree-optimization/79196] New: [7 Regression] Probably invalid folding of strstr(x, "foo") eq x to memcmp (x, "foo", strlen("foo")

[marxin at gcc dot gnu.org]

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

Bug ID: 79196
   Summary: [7 Regression] Probably invalid folding of strstr(x,
"foo") eq x to memcmp (x, "foo", strlen("foo")
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: prathamesh3492 at gcc dot gnu.org
  Target Milestone: ---

I found the problem in postgresql database, where:

$ cat /tmp/strcmp.c
#include 
#include 

int
__attribute__((noinline))
test(char *a)
{
  if (__builtin_strstr (a, "DROP CONVERSION") == a)
return 0;

  return 1;
}

int main(int argc, char **argv)
{
  return test ("x");
}

gcc /tmp/strcmp.c -O2 -fsanitize=address && ./a.out 
=
==28435==ERROR: AddressSanitizer: global-buffer-overflow on address
0x004008a2 at pc 0x7fc19460a229 bp 0x7ffe1e071c30 sp 0x7ffe1e0713e0
READ of size 15 at 0x004008a2 thread T0
#0 0x7fc19460a228 in __interceptor_memcmp
../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:626
#1 0x4007a2 in test (/tmp/a.out+0x4007a2)
#2 0x7fc1941dd290 in __libc_start_main (/lib64/libc.so.6+0x20290)
#3 0x4006d9 in _start (/tmp/a.out+0x4006d9)

0x004008a2 is located 0 bytes to the right of global variable '*.LC1'
defined in '/tmp/strcmp.c' (0x4008a0) of size 2
  '*.LC1' is ascii string 'x'
SUMMARY: AddressSanitizer: global-buffer-overflow
../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:626
in __interceptor_memcmp
Shadow bytes around the buggy address:
  0x800780c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x800780d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x800780e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x800780f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80078100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9
=>0x80078110: f9 f9 f9 f9[02]f9 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x80078120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80078130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80078140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80078150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80078160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

I guess one can't replace strstr where having a shorter first argument should
be valid usage as I've read documentation.
In that case, transforming to memcmp will cause invalid memory reads, as seen
by address sanitizer.

Started with r243633.

[Bug lto/69188] [5/6 Regression] ICE when linking objects at different optimization levels with LTO and profile generation enabled. (Works with 4.9.3.)

[ktkachov at gcc dot gnu.org]

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

--- Comment #22 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Mon Jan 23 11:22:54 2017
New Revision: 244779

URL: https://gcc.gnu.org/viewcvs?rev=244779&root=gcc&view=rev
Log:
[testsuite] Fix FAIL: gcc.dg/lto/pr69188 on bare-metal targets

PR lto/69188
* gcc.dg/lto/pr69188_0.c: Require profiling support for testcase.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/lto/pr69188_0.c

[Bug c++/79172] -Wunused-but-set-parameter gone nuts

[petschy at gmail dot com]

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

--- Comment #2 from petschy at gmail dot com ---
Created attachment 40563
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40563&action=edit
preprocessed source of the reduced test case

[Bug tree-optimization/79196] [7 Regression] Probably invalid folding of strstr(x, "foo") eq x to memcmp (x, "foo", strlen("foo"))

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |7.0
   Target Milestone|--- |7.0

[Bug c++/79172] -Wunused-but-set-parameter gone nuts

[petschy at gmail dot com]

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

--- Comment #3 from petschy at gmail dot com ---
$ g++-7.0.1 -pthread -Werror -Wall -Wextra
20170123-Wunused-but-set-parameter.cpp
20170123-Wunused-but-set-parameter.cpp: In constructor
‘CRSARC4Base::CRSARC4Base(unsigned int, unsigned int)’:
20170123-Wunused-but-set-parameter.cpp:100:39: error: parameter ‘msends_’ set
but not used [-Werror=unused-but-set-parameter]
 CRSARC4Base::CRSARC4Base(unsigned int msends_, unsigned int mrecvs_) :
   ^~~
20170123-Wunused-but-set-parameter.cpp:100:61: error: parameter ‘mrecvs_’ set
but not used [-Werror=unused-but-set-parameter]
 CRSARC4Base::CRSARC4Base(unsigned int msends_, unsigned int mrecvs_) :
 ^~~
$ g++-7.0.1 -v
Using built-in specs.
COLLECT_GCC=g++-7.0.1
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --disable-multilib
--program-suffix=-7.0.1 --disable-bootstrap --enable-checking=release
CFLAGS='-O2 -march=native' CXXFLAGS='-O2 -march=native'
Thread model: posix
gcc version 7.0.1 20170120 (experimental) (GCC) 

Tested on 64bit Debian Jessie, CPU is AMD FX-8150.

[Bug tree-optimization/79196] [7 Regression] Probably invalid folding of strstr(x, "foo") eq x to memcmp (x, "foo", strlen("foo"))

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
I suppose you could use strncmp instead.

[Bug tree-optimization/79196] [7 Regression] Probably invalid folding of strstr(x, "foo") eq x to memcmp (x, "foo", strlen("foo"))

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
(In reply to Richard Biener from comment #1)
> I suppose you could use strncmp instead.

Yep, hope it's still better, I'll prepare patch for that.

[Bug sanitizer/79168] [7 Regression] libtsan fails to link when cross compiling GCC tip for Aarch64 target

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 40564
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40564&action=edit
gcc7-pr79168.patch

Does the attached untested patch help?  All I've noticed is that on some files
the 2nd and 3rd line from compiler-rt original has been removed during the
merge when it shouldn't, and in case ot tsan_rtl_aarch64.S it ate the .section
.bss
directive.

[Bug libstdc++/79195] make_array should not ask for common_type when the type is explicitly specified

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug tree-optimization/79196] [7 Regression] Probably invalid folding of strstr(x, "foo") eq x to memcmp (x, "foo", strlen("foo"))

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Created attachment 40565
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40565&action=edit
Untested patch

[Bug testsuite/78421] [7 Regression] vect-strided-a-u8-i2-gap.c fails on armeb

[nickc at gcc dot gnu.org]

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

--- Comment #2 from Nick Clifton  ---
Author: nickc
Date: Mon Jan 23 12:24:35 2017
New Revision: 244796

URL: https://gcc.gnu.org/viewcvs?rev=244796&root=gcc&view=rev
Log:
PR testsuite/78421
* lib/target-supports.exp (check_effective_target_vect_hw_misalign):
If the target is ARM return the result of the
check_effective_target_arm_vect_no_misalign proc.
* gcc.dg/vect/vect-strided-a-u8-i2-gap.c: If the target does not
support unaligned vectors then only expect one of the loops to be
unrolled.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/vect-strided-a-u8-i2-gap.c
trunk/gcc/testsuite/lib/target-supports.exp

[Bug lto/69188] [5/6 Regression] ICE when linking objects at different optimization levels with LTO and profile generation enabled. (Works with 4.9.3.)

[marxin at gcc dot gnu.org]

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

--- Comment #23 from Martin Liška  ---
Author: marxin
Date: Mon Jan 23 12:24:54 2017
New Revision: 244797

URL: https://gcc.gnu.org/viewcvs?rev=244797&root=gcc&view=rev
Log:
Do not declare artificial variables in tree-profile.c to have a definition (PR
lto/69188).

2017-01-23  Martin Liska  

Backport from mainline
2017-01-20  Martin Liska  

PR lto/69188
* tree-profile.c (init_ic_make_global_vars): Do not call
finalize_decl.
(gimple_init_gcov_profiler): Likewise.
2017-01-23  Martin Liska  

Backport from mainline
2017-01-20  Martin Liska  

PR lto/69188
* gcc.dg/lto/pr69188_0.c: New test.
* gcc.dg/lto/pr69188_1.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/lto/pr69188_0.c
branches/gcc-5-branch/gcc/testsuite/gcc.dg/lto/pr69188_1.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/tree-profile.c

[Bug testsuite/78421] [7 Regression] vect-strided-a-u8-i2-gap.c fails on armeb

[nickc at gcc dot gnu.org]

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

Nick Clifton  changed:

   What|Removed |Added

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

--- Comment #3 from Nick Clifton  ---
Patch applied.

[Bug lto/69188] [5/6 Regression] ICE when linking objects at different optimization levels with LTO and profile generation enabled. (Works with 4.9.3.)

[marxin at gcc dot gnu.org]

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

--- Comment #24 from Martin Liška  ---
Author: marxin
Date: Mon Jan 23 12:26:05 2017
New Revision: 244799

URL: https://gcc.gnu.org/viewcvs?rev=244799&root=gcc&view=rev
Log:
Do not declare artificial variables in tree-profile.c to have a definition (PR
lto/69188).

2017-01-23  Martin Liska  

Backport from mainline
2017-01-20  Martin Liska  

PR lto/69188
* tree-profile.c (init_ic_make_global_vars): Do not call
finalize_decl.
(gimple_init_gcov_profiler): Likewise.
2017-01-23  Martin Liska  

Backport from mainline
2017-01-20  Martin Liska  

PR lto/69188
* gcc.dg/lto/pr69188_0.c: New test.
* gcc.dg/lto/pr69188_1.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/lto/pr69188_0.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/lto/pr69188_1.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-profile.c

[Bug middle-end/56727] Recursive call goes through the PLT unnecessarily

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #6 from Alexander Monakov  ---
Note that even without symbol aliases, such calls are not necessarily
self-recursive when 'f' is first called via dlsym with RTLD_NEXT or a specific
module as the first argument.  In that case the result of dlsym won't
necessarily be the prevailing definition of 'f' placed into the PLT.

[Bug lto/69188] ICE when linking objects at different optimization levels with LTO and profile generation enabled. (Works with 4.9.3.)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
Summary|[5/6 Regression] ICE when   |ICE when linking objects at
   |linking objects at  |different optimization
   |different optimization  |levels with LTO and profile
   |levels with LTO and profile |generation enabled. (Works
   |generation enabled. (Works  |with 4.9.3.)
   |with 4.9.3.)|

--- Comment #25 from Martin Liška  ---
Fixed on all active branches.

[Bug c/48091] No warning when given function arguments mismatch earlier function definition which GCC assumes to be K&R, even with --std=c99 -pedantic

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-23
 Ever confirmed|0   |1

--- Comment #5 from Jonathan Wakely  ---
A better example, which doesn't get any diagnostic even with -Wpedantic, is

void f() { }

int main()
{
  f(1, 2, 3);
}

C11 seems clear:

"An empty list in a function declarator that is part of a definition of that
function specifies that the function has no parameters."

[Bug ipa/79108] [7 Regression] ICE on some fortran code with -flto -Ofast

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor  ---
Author: jamborm
Date: Mon Jan 23 13:01:31 2017
New Revision: 244802

URL: https://gcc.gnu.org/viewcvs?rev=244802&root=gcc&view=rev
Log:
[PR 79108] Put ipa_node_params to GC memory

2017-01-23  Martin Jambor  

PR ipa/79108
* ipa-prop.h (ipa_param_descriptor): Anotate with with GTY(()).
(ipa_node_params): Annotate with GTY((for_user)).  Make descriptors
field a pointer to garbage collected vector, mark lattices and
ipcp_orig_node with GTY((skip)).
(ipa_get_param_count): Adjust to descriptors being a pointer.
(ipa_get_param): Likewise.
(ipa_get_type): Likewise.
(ipa_get_param_move_cost): Likewise.
(ipa_set_param_used): Likewise.
(ipa_get_controlled_uses): Likewise.
(ipa_set_controlled_uses): Likewise.
(ipa_is_param_used): Likewise.
(ipa_node_params_t): Move into garbage collector.  New methods insert
and remove.
(ipa_node_params_sum): Annotate wth GTY(()).
(ipa_check_create_node_params): Adjust to ipa_node_params_sum being
garbage collected.
(ipa_load_from_parm_agg): Adjust declaration.
* ipa-icf.c (param_used_p): Adjust to descriptors being a pointer.
* ipa-profile.c (ipa_profile): Likewise.
* ipa-prop.c (ipa_get_param_decl_index_1): Likewise.
(ipa_populate_param_decls): Make descriptors parameter garbage
collected.
(ipa_dump_param): Adjust to descriptors being a pointer.
(ipa_alloc_node_params): Likewise.
(ipa_initialize_node_params): Likewise.
(load_from_param_1): Make descriptors parameter garbage collected.
(load_from_unmodified_param): Likewise.
(load_from_param): Likewise.
(ipa_load_from_parm_agg): Likewise.
(ipa_node_params::~ipa_node_params): Removed.
(ipa_free_all_node_params): Remove call to delete operator.
(ipa_node_params_t::insert): New.
(ipa_node_params_t::remove): Likewise.
(ipa_node_params_t::duplicate): Adjust to descriptors being a pointer,
copy known_csts and known_contexts vectors.
(ipa_read_node_info): Adjust to descriptors being a pointer.
(ipcp_modif_dom_walker): Make m_descriptors field garbage
collected.
(ipcp_transform_function): Make descriptors variable garbage
collected.

testsuite/
* gfortran.dg/lto/pr79108_0.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/lto/pr79108_0.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-icf.c
trunk/gcc/ipa-profile.c
trunk/gcc/ipa-prop.c
trunk/gcc/ipa-prop.h
trunk/gcc/testsuite/ChangeLog

[Bug c/79082] -Wformat-truncation inconsistent behaviour

[sirl at gcc dot gnu.org]

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

--- Comment #6 from Franz Sirl  ---
Created attachment 40566
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40566&action=edit
extended testcase

Hmm, looks like there is an off-by-one bug lurking here?
To clarify my setup, here are the warnings for the attached testcase on
Linux/x86-64 (SLES12SP2) with a bootstrapped r244773 compiler.

First, gcc-trunk -c -Wformat-truncation test-snprintf-2.c -O0:
test-snprintf-2.c: In function 'test':
test-snprintf-2.c:6:23: warning: '%2d' directive output may be truncated
writing between 2 and 11 bytes into a region of size 3 [-Wformat-truncation=]
  snprintf(buffer, 3, "%2d", val % 100); /* 1 */ /* should warn */
   ^~~
test-snprintf-2.c:6:22: note: using the range [1, -2147483648] for directive
argument
  snprintf(buffer, 3, "%2d", val % 100); /* 1 */ /* should warn */
  ^
test-snprintf-2.c:6:2: note: format output between 3 and 12 bytes into a
destination of size 3
  snprintf(buffer, 3, "%2d", val % 100); /* 1 */ /* should warn */
  ^
test-snprintf-2.c:7:23: warning: '%2hhd' directive output may be truncated
writing between 2 and 4 bytes into a region of size 3 [-Wformat-truncation=]
  snprintf(buffer, 3, "%2hhd", val % 100); /* 2 */ /* should warn */
   ^
test-snprintf-2.c:7:22: note: using the range [1, -128] for directive argument
  snprintf(buffer, 3, "%2hhd", val % 100); /* 2 */ /* should warn */
  ^~~
test-snprintf-2.c:7:2: note: format output between 3 and 5 bytes into a
destination of size 3
  snprintf(buffer, 3, "%2hhd", val % 100); /* 2 */ /* should warn */
  ^~~
test-snprintf-2.c:9:23: warning: '%2d' directive output may be truncated
writing between 2 and 11 bytes into a region of size 3 [-Wformat-truncation=]
  snprintf(buffer, 3, "%2d", (val < 0) ? -(val % 100): val % 100); /* 3 */ /*
should not warn */
   ^~~
test-snprintf-2.c:9:22: note: using the range [1, -2147483648] for directive
argument
  snprintf(buffer, 3, "%2d", (val < 0) ? -(val % 100): val % 100); /* 3 */ /*
should not warn */
  ^
test-snprintf-2.c:9:2: note: format output between 3 and 12 bytes into a
destination of size 3
  snprintf(buffer, 3, "%2d", (val < 0) ? -(val % 100): val % 100); /* 3 */ /*
should not warn */
  ^~~
test-snprintf-2.c:10:23: warning: '%2d' directive output may be truncated
writing between 2 and 11 bytes into a region of size 3 [-Wformat-truncation=]
  snprintf(buffer, 3, "%2d", __builtin_abs(val % 100)); /* 4 */ /* should not
warn */
   ^~~
test-snprintf-2.c:10:22: note: using the range [1, -2147483648] for directive
argument
  snprintf(buffer, 3, "%2d", __builtin_abs(val % 100)); /* 4 */ /* should not
warn */
  ^
test-snprintf-2.c:10:2: note: format output between 3 and 12 bytes into a
destination of size 3
  snprintf(buffer, 3, "%2d", __builtin_abs(val % 100)); /* 4 */ /* should not
warn */
  ^~~~
test-snprintf-2.c:12:23: warning: '%2x' directive output may be truncated
writing between 2 and 8 bytes into a region of size 3 [-Wformat-truncation=]
  snprintf(buffer, 3, "%2x", val & 0xff); /* 5 */ /* should not warn */
   ^~~
test-snprintf-2.c:12:22: note: using the range [1, 4294967295] for directive
argument
  snprintf(buffer, 3, "%2x", val & 0xff); /* 5 */ /* should not warn */
  ^
test-snprintf-2.c:12:2: note: format output between 3 and 9 bytes into a
destination of size 3
  snprintf(buffer, 3, "%2x", val & 0xff); /* 5 */ /* should not warn */
  ^~
test-snprintf-2.c:13:23: warning: '%03x' directive output may be truncated
writing between 3 and 8 bytes into a region of size 4 [-Wformat-truncation=]
  snprintf(buffer, 4, "%03x", val & 0xfff); /* 6 */ /* should not warn */
   ^~~~
test-snprintf-2.c:13:22: note: using the range [1, 4294967295] for directive
argument
  snprintf(buffer, 4, "%03x", val & 0xfff); /* 6 */ /* should not warn */
  ^~
test-snprintf-2.c:13:2: note: format output between 4 and 9 bytes into a
destination of size 4
  snprintf(buffer, 4, "%03x", val & 0xfff); /* 6 */ /* should not warn */
  ^~~~

No idea why 8 (and maybe 7?) does not warn on my machine, certainly the buffer
is too small for anything >= 0x1000.


Second, gcc-trunk -c -Wformat-truncation test-snprintf-2.c -O2:
test-snprintf-2.c: In function 'test':
test-snprintf-2.c:6:26: warning: output may be truncated before the last format
character [-Wformat-truncation=]
  snprintf(buffer, 3, "%2d", val % 100); /* 1 */ /* should warn */
   ~~~^
test-snprintf-2.c:6:2: note: format output between 3 and 4 bytes

[Bug tree-optimization/79186] [7 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: Segmentation fault (in VRP)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/79186] [7 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: Segmentation fault (in VRP)

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Mon Jan 23 13:08:44 2017
New Revision: 244804

URL: https://gcc.gnu.org/viewcvs?rev=244804&root=gcc&view=rev
Log:
2017-01-23  Richard Biener  

PR tree-optimization/79186
* tree-vrp.c (register_new_assert_for): Make sure we've seen
both incoming edges before moving an assert.

* gcc.dg/torture/pr79186.c: New testcase.
* gcc.dg/torture/pr79187.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr79186.c
trunk/gcc/testsuite/gcc.dg/torture/pr79187.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c

[Bug c/48091] No warning when given function arguments mismatch earlier function definition which GCC assumes to be K&R, even with --std=c99 -pedantic

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Even if it's not invalid we should warn when we know the function has no
parameters and it's called with arguments.

[Bug c++/72764] [5/6/7 Regression] ICE on invalid C++11 code instantiating an alias template: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in typedef_variant_p, at tree.c:12660

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #5 from Paolo Carlini  ---
Mine.

[Bug c/79153] -Wimplicit-fallthrough missed warning

[sirl at gcc dot gnu.org]

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

--- Comment #6 from Franz Sirl  ---
I see. If you really close it as WONTFIX, could this small deficiency at least
be documented in the manual? I guess the non-warning case happens only when the
switch-statement directly (no other statements in between) precedes the
case-statement?

[Bug target/79197] New: [7 Regression] ICE in extract_insn in gcc/recog.c:2311

[marxin at gcc dot gnu.org]

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

Bug ID: 79197
   Summary: [7 Regression] ICE in extract_insn in gcc/recog.c:2311
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: wschmidt at gcc dot gnu.org
  Target Milestone: ---

$ ./xgcc -v
Configured with: ../configure --enable-languages=c,c++
--prefix=/home/marxin/bin/gcc2 --disable-multilib --disable-bootstrap
--target=powerpc64le-suse-linux


$ cat /tmp/dt_arith.i
unsigned a;
fn1 () { a = *(double *) 0; }

$ ./xgcc -B. /tmp/dt_arith.i 
/tmp/dt_arith.i:2:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
 fn1 () { a = *(double *) 0; }
 ^~~
/tmp/dt_arith.i: In function ‘fn1’:
/tmp/dt_arith.i:2:1: error: unrecognizable insn:
(insn 7 6 8 2 (set (reg:DI 160)
(unsigned_fix:DI (reg:DF 156 [ _2 ]))) "/tmp/dt_arith.i":2 -1
 (nil))
/tmp/dt_arith.i:2:1: internal compiler error: in extract_insn, at recog.c:2311
0xaec368 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/rtl-error.c:108
0xaec399 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/rtl-error.c:116
0xabdcc1 extract_insn(rtx_insn*)
../../gcc/recog.c:2311
0x88cd93 instantiate_virtual_regs_in_insn
../../gcc/function.c:1589
0x88cd93 instantiate_virtual_regs
../../gcc/function.c:1957
0x88cd93 execute
../../gcc/function.c:2006

[Bug target/79197] [7 Regression] ICE in extract_insn in gcc/recog.c:2311

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |7.0
   Target Milestone|--- |7.0

[Bug bootstrap/79198] New: [7 Regression] r244802 causes out of memory during PGO bootstrap

[trippels at gcc dot gnu.org]

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

Bug ID: 79198
   Summary: [7 Regression] r244802 causes out of memory during PGO
bootstrap
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: jamborm at gcc dot gnu.org
  Target Milestone: ---

Since r244802 I run out of memory when compiling bitmap.c
during stagefeedback (PGO bootstrap).

ipa_node_params_t::duplicate keeps allocating memory until the OOM killer kicks
in.

[Bug tree-optimization/78384] [7 Regression] ICE: verify_flow_info failed (error: wrong outgoing edge flags at end of bb 15)

[matz at gcc dot gnu.org]

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

--- Comment #5 from Michael Matz  ---
Author: matz
Date: Mon Jan 23 13:57:31 2017
New Revision: 244811

URL: https://gcc.gnu.org/viewcvs?rev=244811&root=gcc&view=rev
Log:
fix pr78384

PR tree-optimization/78384
* tree-ssa-loop-split.c (patch_loop_exit): Use correct edge.

testsuite/
PR tree-optimization/78384
* gcc.dg/pr78384.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr78384.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-split.c

[Bug tree-optimization/78384] [7 Regression] ICE: verify_flow_info failed (error: wrong outgoing edge flags at end of bb 15)

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

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

--- Comment #6 from Michael Matz  ---
fixed.

[Bug tree-optimization/79159] [7 regression] spurious array-bounds warning

[amker at gcc dot gnu.org]

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

--- Comment #4 from amker at gcc dot gnu.org ---
Discussed with richi, and conclusion is that vrp issue is hard to fix at the
moment.  Easy way out is to investigate why cunrolli peels one additional
iteration than necessary.  Note cunrolli computes unrolling number using niter
information, which in turn is inferred from local array bound for this case :
"tmpCorr[9][9]".  
The problem is in function record_nonwrapping_iv, as below code:
  wide_int min, max;
  extreme = fold_convert (unsigned_type, high);
  if (TREE_CODE (orig_base) == SSA_NAME
  && TREE_CODE (low) == INTEGER_CST
  && INTEGRAL_TYPE_P (TREE_TYPE (orig_base))
  && get_range_info (orig_base, &min, &max) == VR_RANGE
  && wi::gts_p (min, low))
base = wide_int_to_tree (unsigned_type, min);
  else if (TREE_CODE (base) != INTEGER_CST
   && dominated_by_p (CDI_DOMINATORS,
  loop->latch, gimple_bb (stmt)))
base = fold_convert (unsigned_type, low);
  delta = fold_build2 (MINUS_EXPR, unsigned_type, extreme, base);

When analyzing "tmpCorr[i_3][j_4]" in below dump:

   [15.00%]:
  j_11 = i_3 + 1;

   [100.00%]:
  # j_4 = PHI 
  if (_1 <= j_4)
goto ; [15.00%]
  else
goto ; [85.00%]

   [15.00%]:
  goto ; [100.00%]

   [85.00%]:
  _2 = tmpCorr[i_3][j_4];
  bar = _2;
  j_13 = j_4 + 1;
  goto ; [100.00%]

The SCEV for j_4 in loop_2 is {j_11, 1}_2, aforementioned code fails to check
that j_11 is larger than 0, instead it uses "low = 0" as starting iteration,
resulting in peeling one additional iteration.

There are two possible fixes here. One is to investigate why evrp doesn't
compute correct range for j_11:

_1: VARYING
_3: VARYING
i_4: [0, +INF]
j_5: [j_13, +INF]
n_12(D): ~[0, 0]
j_13: VARYING   

[Bug rtl-optimization/77770] [5/6/7 Regression] Internal compiler error on source which compiles with earlier versions.

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

   Last reconfirmed|2016-09-28 00:00:00 |2017-1-23
 CC||vmakarov at redhat dot com
  Component|target  |rtl-optimization

--- Comment #5 from Richard Earnshaw  ---
Original testcase is now latent on Trunk.  However, the simplified testcase in
comment 3 still triggers the bug.

[Bug tree-optimization/79159] [7 regression] spurious array-bounds warning

[amker at gcc dot gnu.org]

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

--- Comment #5 from amker at gcc dot gnu.org ---
(In reply to amker from comment #4)
> Discussed with richi, and conclusion is that vrp issue is hard to fix at the
> moment.  Easy way out is to investigate why cunrolli peels one additional
> 
> There are two possible fixes here. One is to investigate why evrp doesn't
> compute correct range for j_11:
> 
> _1: VARYING
> _3: VARYING
> i_4: [0, +INF]
> j_5: [j_13, +INF]
> n_12(D): ~[0, 0]
> j_13: VARYING    j_15: [-2147483647, +INF]
> 
Looks like evrp only computes vrp for parameters or like?

[Bug c++/71710] [7 Regression] ICE on valid C++11 code with decltype and alias template: in lookup_member, at cp/search.c:1255

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug bootstrap/79198] [7 Regression] r244802 causes out of memory during PGO bootstrap

[trippels at gcc dot gnu.org]

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

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

Here is a testcase:

 g++ -fno-PIE -c -march=amdfam10 -O3 -pipe -fprofile-use -fno-exceptions
-fno-rtti gimple-ssa-backprop.ii

[Bug bootstrap/79198] [7 Regression] r244802 causes out of memory during PGO bootstrap

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

[Bug bootstrap/79198] [7 Regression] r244802 causes out of memory during PGO bootstrap

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Jambor  ---
The revision number suggests this is mine.

[Bug c/79199] New: ICE with -Wduplicated-branches

[sirl at gcc dot gnu.org]

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

Bug ID: 79199
   Summary: ICE with -Wduplicated-branches
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

This creduce'd testcase crashes with -Wduplicated-branches (trunk r244773).

unsigned int a, b, c, d, e;
void fn1(void) {
  if (0) {
if (d > 4294967293)
  (void) 5;
c = d;
b = e | a;
  } else {
if (d > 4294967293)
  (void) 5;
c = d;
b = e | a;
  }
}

# gcc-trunk -S -fpreprocessed -Wduplicated-branches -xc testcase.i -W -Wall
testcase.i: In function 'fn1':
testcase.i:14:1: internal compiler error: Segmentation fault
 }
 ^
0x9d70af crash_signal
../../gcc/toplev.c:333
0x6d6bda operand_equal_p(tree_node const*, tree_node const*, unsigned int)
../../gcc/fold-const.c:2761
0x6d9332 operand_equal_p(tree_node const*, tree_node const*, unsigned int)
../../gcc/fold-const.c:3150
0x6d6e17 operand_equal_p(tree_node const*, tree_node const*, unsigned int)
../../gcc/fold-const.c:2743
0x6d7880 operand_equal_p(tree_node const*, tree_node const*, unsigned int)
../../gcc/fold-const.c:3307
0x6d6e17 operand_equal_p(tree_node const*, tree_node const*, unsigned int)
../../gcc/fold-const.c:2743
0x554251 do_warn_duplicated_branches
../../gcc/c-family/c-warn.c:2270
0x554251 do_warn_duplicated_branches_r(tree_node**, int*, void*)
../../gcc/c-family/c-warn.c:2287
0xc99343 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc/tree.c:11795
0xc98e90 walk_tree_without_duplicates_1(tree_node**, tree_node*
(*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*))
../../gcc/tree.c:12138
0x517d12 c_genericize(tree_node*)
../../gcc/c-family/c-gimplify.c:129
0x450ebc finish_function()
../../gcc/c/c-decl.c:9361
0x4bf0fa c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2110
0x4c6fb3 c_parser_external_declaration
../../gcc/c/c-parser.c:1463
0x4c7a29 c_parser_translation_unit
../../gcc/c/c-parser.c:1344
0x4c7a29 c_parse_file()
../../gcc/c/c-parser.c:18156
0x524bb3 c_common_parse_file()
../../gcc/c-family/c-opts.c:1107
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/79182] when use openmp and link static libgfortran,open function cause SIGSEGV

[hwliu11 at hotmail dot com]

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

--- Comment #3 from hwliu11 at hotmail dot com ---
(In reply to Jakub Jelinek from comment #2)
> That is a libc issue, statically linking only parts of -lpthread often
> results in broken programs, unless libpthread.a ensures all of libpthread is
> linked when linking statically (e.g. what is done in some distributions
> where libpthread.a contains only libpthread.o - result of ld -r).  If your
> distro isn't doing this, I'm afraid you need to use -static
> --Wl,--whole-archive -lpthread -Wl,--no-whole-archive.


Thank you very much,It works!So it's not a bug?please close this issuse

[Bug fortran/79182] when use openmp and link static libgfortran,open function cause SIGSEGV

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
It is a glibc bug which is fixed in various distros, but apparently not in
Ubuntu.

[Bug c/79199] ICE with -Wduplicated-branches

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Mine, thanks for the report.

[Bug lto/69188] ICE when linking objects at different optimization levels with LTO and profile generation enabled. (Works with 4.9.3.)

[anthonyfk at gmail dot com]

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

--- Comment #26 from anthonyfk at gmail dot com ---
Thank you very much for the fix! I've tried the patch as applied to
gcc-6-branch with an otherwise fresh tarball of gcc 6.3.0. When compiling
lapack-3.6.1 I no longer get the original bug, but I do get:

lto1: internal compiler error: resolution sub id 0x7485cad21ad62861 not in
object file
0x54e61b lto_resolution_read
/tmp/solido-build-20170120/gcc-6.3.0/gcc/lto/lto.c:1929
0x54e61b lto_file_read
/tmp/solido-build-20170120/gcc-6.3.0/gcc/lto/lto.c:2092
0x54e61b read_cgraph_and_symbols
/tmp/solido-build-20170120/gcc-6.3.0/gcc/lto/lto.c:2806
0xc9045a lto_main()
/tmp/solido-build-20170120/gcc-6.3.0/gcc/lto/lto.c:3310
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: /usr/local/solido/tools/20170120/bin/gfortran
returned 1 exit status
compilation terminated.
/usr/local/solido/tools/20170120/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:129: ../xeigtsts] Error 1

I tried searching the bug tracker to see if this was fixed already but didn't
have any luck. I'll try to put together a reduced test case in the next week,
but it's unfortunately a busy time of year for me so that may take longer. At
the very least, I can try with the latest tarball from the 6 branch easily.

[Bug tree-optimization/79196] [7 Regression] Probably invalid folding of strstr(x, "foo") eq x to memcmp (x, "foo", strlen("foo"))

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Author: marxin
Date: Mon Jan 23 14:57:43 2017
New Revision: 244812

URL: https://gcc.gnu.org/viewcvs?rev=244812&root=gcc&view=rev
Log:
Fix strstr folding (PR tree-optimization/79196).

2017-01-23  Martin Liska  

PR tree-optimization/79196
* tree-ssa-strlen.c (fold_strstr_to_memcmp): Rename to ...
(fold_strstr_to_strncmp): ... this.  Fold the pattern to strncmp
instead of memcmp.
(strlen_optimize_stmt): Call the renamed function.
2017-01-23  Martin Liska  

PR tree-optimization/79196
* gcc.dg/asan/pr79196.c: New test.
* gcc.dg/strlenopt-30.c: Update scanned pattern.

Added:
trunk/gcc/testsuite/gcc.dg/asan/pr79196.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/strlenopt-30.c
trunk/gcc/tree-ssa-strlen.c

[Bug tree-optimization/79196] Probably invalid folding of strstr(x, "foo") eq x to memcmp (x, "foo", strlen("foo"))

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
Summary|[7 Regression] Probably |Probably invalid folding of
   |invalid folding of  |strstr(x, "foo") eq x to
   |strstr(x, "foo") eq x to|memcmp (x, "foo",
   |memcmp (x, "foo",   |strlen("foo"))
   |strlen("foo"))  |

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

[Bug lto/69188] ICE when linking objects at different optimization levels with LTO and profile generation enabled. (Works with 4.9.3.)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #27 from Martin Liška  ---
(In reply to anthonyfk from comment #26)
> Thank you very much for the fix! I've tried the patch as applied to
> gcc-6-branch with an otherwise fresh tarball of gcc 6.3.0. When compiling
> lapack-3.6.1 I no longer get the original bug, but I do get:
> 
> lto1: internal compiler error: resolution sub id 0x7485cad21ad62861 not in
> object file
> 0x54e61b lto_resolution_read
>   /tmp/solido-build-20170120/gcc-6.3.0/gcc/lto/lto.c:1929
> 0x54e61b lto_file_read
>   /tmp/solido-build-20170120/gcc-6.3.0/gcc/lto/lto.c:2092
> 0x54e61b read_cgraph_and_symbols
>   /tmp/solido-build-20170120/gcc-6.3.0/gcc/lto/lto.c:2806
> 0xc9045a lto_main()
>   /tmp/solido-build-20170120/gcc-6.3.0/gcc/lto/lto.c:3310
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> lto-wrapper: fatal error: /usr/local/solido/tools/20170120/bin/gfortran
> returned 1 exit status
> compilation terminated.
> /usr/local/solido/tools/20170120/bin/ld: error: lto-wrapper failed
> collect2: error: ld returned 1 exit status
> make[2]: *** [Makefile:129: ../xeigtsts] Error 1
> 
> I tried searching the bug tracker to see if this was fixed already but
> didn't have any luck. I'll try to put together a reduced test case in the
> next week, but it's unfortunately a busy time of year for me so that may
> take longer. At the very least, I can try with the latest tarball from the 6
> branch easily.

Reduce test-case would be handy. Can you please re-test that also on trunk?

Thanks

[Bug fortran/79165] [7 Regression] 100% compile-time increase for polyhedron aermod by r244581

[dmalcolm at gcc dot gnu.org]

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

--- Comment #8 from David Malcolm  ---
https://gcc.opensuse.org/c++bench-czerny/pb11/ has this link:

 
http://www.polyhedron.com/fortran-compiler-comparisons/polyhedron-benchmark-suite

which is a 404.

An updated link seems to be:
 
http://www.fortran.uk/fortran-compiler-comparisons-2015/the-polyhedron-solutions-benchmark-suite/

from which a zipfile containing aermod.f90 can be seen (am looking at it now).

[Bug rtl-optimization/56069] [5/6/7 Regression] RA pessimization

[bernds at gcc dot gnu.org]

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

--- Comment #16 from Bernd Schmidt  ---
I retested again with a few different combinations of things. With an older
gdb, I can still reproduce the issue that sra-1 becomes UNSUPPORTED (presumably
through a gdb crash). With gdb-7.12 installed the patch now causes sra-1.c to
fail (apparently a value becomes optimized out). If we consider the guality
testsuite in some way meaningful we still can't apply this patch.
Also, Vlad's reasoning for waiting until gcc-7 last time now holds for waiting
until gcc-8.

[Bug sanitizer/79200] New: Race-Condition in Address Santitizer

[tommapson at gmx dot de]

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

Bug ID: 79200
   Summary: Race-Condition in Address Santitizer
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tommapson at gmx dot de
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: ---

Multiple concurrent executables hang when being built by gcc-6.3.0 (as well as
gcc-5.3.0) with -fsanitize=address.

To reproduce this bug, you may use the following trivial C program:

- main.c 
int main(int ac, char** av)
{
  return 0;
}
-

Compile with
  gcc -fsanitize=address main.c -o main

Run multiple instances concurrently (bash on Debian Wheezy or Jessie):
  for i in $(seq 2) ; do ( ./main >/dev/null 2>&1 & ) ; done ; echo
"SLEEPING..." ; sleep 120

Some of the executables hang as can be seen using ps or top. The processes are
reported to have state "T" (stopped, either by a job control signal or because
it is being traced).

If compiled without -fsanitize=address, the above loop does not cause any of
the processes to hang.

[Bug libstdc++/79195] make_array should not ask for common_type when the type is explicitly specified

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Mon Jan 23 15:56:05 2017
New Revision: 244813

URL: https://gcc.gnu.org/viewcvs?rev=244813&root=gcc&view=rev
Log:
PR libstdc++/79195 fix make_array type deduction

PR libstdc++/79195
* include/experimental/array (__make_array_elem): New class template
and partial specialization.
(__is_reference_wrapper): Move into __make_array_elem specialization.
(make_array): Use __make_array_elem to determine element type and move
static assertion into specialization. Qualify std::forward call.
(to_array): Add exception specifiation.
* testsuite/experimental/array/make_array.cc: Test argument types
without a common type.
* testsuite/experimental/array/neg.cc: Adjust expected error message.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/experimental/array
trunk/libstdc++-v3/testsuite/experimental/array/make_array.cc
trunk/libstdc++-v3/testsuite/experimental/array/neg.cc

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

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

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

--- Comment #2 from Bernd Schmidt  ---
Oh well, guess I know how to fix those by now.

[Bug target/78945] [arm] libatomic inline asm is not compatible with armv7-m

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-23
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Ramana Radhakrishnan  ---
A simple patch would be to check for __ARM_FEATURE_SAT in all those macros in
exch_n.c along with HAVE_STREXB etc .. 

Confirmed by code inspection.

A fix to the macro is pre-approved for all release branches with appropriate
testing.

[Bug tree-optimization/70754] [5/6/7 Regression] ICE during predictive commoning

[amker at gcc dot gnu.org]

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

--- Comment #10 from amker at gcc dot gnu.org ---
Author: amker
Date: Mon Jan 23 15:59:19 2017
New Revision: 244815

URL: https://gcc.gnu.org/viewcvs?rev=244815&root=gcc&view=rev
Log:
PR tree-optimization/70754
* tree-predcom.c (stmt_combining_refs): New parameter INSERT_BEFORE.
(reassociate_to_the_same_stmt): New parameter INSERT_BEFORE.  Insert
combined stmt before it if not NULL.
(combine_chains): Process refs reversely and compute dominance point
for root ref.

gcc/testsuite
PR tree-optimization/70754
* gfortran.dg/pr70754.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr70754.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-predcom.c

[Bug libstdc++/79195] make_array should not ask for common_type when the type is explicitly specified

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug bootstrap/79198] [7 Regression] r244802 causes out of memory during PGO bootstrap

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org

--- Comment #3 from David Edelsohn  ---
This revision causes out of memory when bootstrapping on AIX without PGO.

[Bug rtl-optimization/78634] [7 Regression] 30% performance drop after r242832.

[bernds at gcc dot gnu.org]

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

--- Comment #2 from Bernd Schmidt  ---
Author: bernds
Date: Mon Jan 23 16:17:33 2017
New Revision: 244816

URL: https://gcc.gnu.org/viewcvs?rev=244816&root=gcc&view=rev
Log:
PR rtl-optimization/78634
* config/i386/i386.c (ix86_max_noce_ifcvt_seq_cost): New function.
(TARGET_MAX_NOCE_IFCVT_SEQ_COST): Define.
* ifcvt.c (noce_try_cmove): Add missing cost check.

testsuite/
PR rtl-optimization/78634
* gcc.target/i386/funcspec-11.c: Also pass -mtune=i686.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/ifcvt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/funcspec-11.c

[Bug c/48091] No warning when given function arguments mismatch earlier function definition which GCC assumes to be K&R, even with --std=c99 -pedantic

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

   Keywords|accepts-invalid |

--- Comment #7 from Joseph S. Myers  ---
This is valid code (or at least the version with the call inside if (0) or
otherwise not known to be executed unconditionally for all executions of the
program is).  See what I said in bug 64526 and DR#317 linked therefrom.

[Bug rtl-optimization/78634] [7 Regression] 30% performance drop after r242832.

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

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

--- Comment #3 from Bernd Schmidt  ---
Fixed.

[Bug rtl-optimization/71724] [5/6/7 Regression] ICE: Segmentation fault, deep recursion between combine_simplify_rtx and subst

[bernds at gcc dot gnu.org]

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

--- Comment #7 from Bernd Schmidt  ---
Author: bernds
Date: Mon Jan 23 16:30:55 2017
New Revision: 244817

URL: https://gcc.gnu.org/viewcvs?rev=244817&root=gcc&view=rev
Log:
PR rtl-optimization/71724
* combine.c (if_then_else_cond): Look for situations where it is
beneficial to undo the work of one of the recursive calls.

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

[Bug ipa/79108] [7 Regression] ICE on some fortran code with -flto -Ofast

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #5 from Jeffrey A. Law  ---
Verified Martin's patch fixes the problem.

[Bug tree-optimization/70754] [5/6/7 Regression] ICE during predictive commoning

[pthaugen at gcc dot gnu.org]

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

--- Comment #11 from Pat Haugen  ---
(In reply to amker from comment #10)
> Author: amker
> Date: Mon Jan 23 15:59:19 2017
> New Revision: 244815

This fixes the problem on powerpc.

[Bug fortran/79165] [7 Regression] 100% compile-time increase for polyhedron aermod by r244581

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
The tree.c hunk has been reverted, so can we close this PR (the other PR has
been reopened)?

[Bug c/48091] No warning when given function arguments mismatch earlier function definition which GCC assumes to be K&R, even with --std=c99 -pedantic

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
OK, but as the reporter of 64526 said, we should warn at least. We know the
number of parameters (even if there isn't a prototype) and we know the number
of arguments doesn't match it. That warrants a warning.

[Bug tree-optimization/70754] [5/6 Regression] ICE during predictive commoning

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
Summary|[5/6/7 Regression] ICE  |[5/6 Regression] ICE during
   |during predictive commoning |predictive commoning

--- Comment #12 from Jeffrey A. Law  ---
Confirmed Bin's patch fixes the regression on the trunk, so removing gcc-7
regression marker.

[Bug target/79197] [5/6/7 Regression] ICE in extract_insn in gcc/recog.c:2311

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-23
 CC||jakub at gcc dot gnu.org
   Target Milestone|7.0 |5.5
Summary|[7 Regression] ICE in   |[5/6/7 Regression] ICE in
   |extract_insn in |extract_insn in
   |gcc/recog.c:2311|gcc/recog.c:2311
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r217590 (with -mcpu=power8).

[Bug fortran/79165] 100% compile-time increase for polyhedron aermod by r244581

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
 Blocks||79061
Summary|[7 Regression] 100% |100% compile-time increase
   |compile-time increase for   |for polyhedron aermod by
   |polyhedron aermod by|r244581
   |r244581 |

--- Comment #10 from Jeffrey A. Law  ---
I think we should keep this open and have 79061 depend on it.  We should remove
the regression marker though.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061
[Bug 79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with
"AddressSanitizer: initialization-order-fiasco"

[Bug libstdc++/79190] [7 Regression] ld: (Warning) Unsatisfied symbol "aligned_alloc"

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
The C++17 draft requires aligned-delete to be used for memory obtained from
aligned-new (and not otherwise):

"Requires: If the alignment parameter is not present, ptr shall have been
returned by an allocation function without an alignment parameter. If present,
the alignment argument shall equal the alignment argument passed to the
allocation function that returned ptr."

So for aligned-new we can over-allocate and return a suitably aligned pointer
within the allocated region, storing a cookie before that pointer that tells us
the address originally obtained from malloc. For aligned-delete we read the
cookie.

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #25 from Jeffrey A. Law  ---
Sorry, I thought all the issues had been fixed.  Reopening.

[Bug rtl-optimization/56069] [5/6/7 Regression] RA pessimization

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Target Milestone|7.0 |8.0

[Bug target/70012] test case gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #2 from Bill Schmidt  ---
For POWER8 or later, this test isn't useful as we just go ahead and vectorize
the loop.  In these processors we have better performance of misaligned vector
loads and stores, so we are more aggressive under the cost model.  At a minimum
we need to skip this test when TARGET_EFFICIENT_UNALIGNED_VSX = 1.

I note from the automated testers that we fail this test on POWER7 BE also,
though, so there must be more to it than that.  I'll go poke at that next.

Confirmed, btw.

[Bug tree-optimization/56049] [7 Regression] Simplification to constants not done

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #19 from Jeffrey A. Law  ---
OK.  Changing milestone to gcc-8.  I think we can reasonably allow guality to
regress here.  Waiting until gcc-8 also gives the updated gdb more time to get
deployed in the wild.

[Bug rtl-optimization/71724] [5/6 Regression] ICE: Segmentation fault, deep recursion between combine_simplify_rtx and subst

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
Summary|[5/6/7 Regression] ICE: |[5/6 Regression] ICE:
   |Segmentation fault, deep|Segmentation fault, deep
   |recursion between   |recursion between
   |combine_simplify_rtx and|combine_simplify_rtx and
   |subst   |subst

--- Comment #8 from Jeffrey A. Law  ---
So I believe the consensus was we want both patches, or variants thereof, so
I'm leaving this open, but removing the regression marker.

[Bug tree-optimization/79159] [7 regression] spurious array-bounds warning

[amker at gcc dot gnu.org]

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

--- Comment #6 from amker at gcc dot gnu.org ---
(In reply to amker from comment #5)
> (In reply to amker from comment #4)
> > Discussed with richi, and conclusion is that vrp issue is hard to fix at the
> > moment.  Easy way out is to investigate why cunrolli peels one additional
> > 
> > There are two possible fixes here. One is to investigate why evrp doesn't
> > compute correct range for j_11:
> > 
> > _1: VARYING
> > _3: VARYING
> > i_4: [0, +INF]
> > j_5: [j_13, +INF]
> > n_12(D): ~[0, 0]
> > j_13: VARYING    > j_15: [-2147483647, +INF]
> > 
> Looks like evrp only computes vrp for parameters or like?

Testing a patch in tree-ssa-loop-niter.c.

[Bug c/79201] New: issed optimization: gcc fails to cut out unnecessary loop.

[drraph at gmail dot com]

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

Bug ID: 79201
   Summary: issed optimization: gcc fails to cut out unnecessary
loop.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: drraph at gmail dot com
  Target Milestone: ---

Consider this code:

int f(int n) {
  int i,j=0;
  for (i = 0; i < 32; i++) {
j = __builtin_ffs(i);
  }
  return j;
}

With gcc -O3 you get

f:
xor eax, eax
xor edx, edx
mov ecx, -1
jmp .L3
.L5:
bsf eax, edx
cmove   eax, ecx
add eax, 1
.L3:
add edx, 1
cmp edx, 32
jne .L5
rep ret


However with clang you get

f:  # @f
mov eax, 1
ret


A similar difference occurs if you replace the limit 32 with the variable n.

gcc is unable to detect that the loop can be omitted.