[Bug middle-end/85598] [7/8/9 Regression] Incorrect warning only at -O2 and -O3

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On Thu, 22 Nov 2018, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85598
> 
> --- Comment #10 from Jakub Jelinek  ---
> While it might look too specialized, it actually triggered (i.e. narrowed the
> range info) in 105473 cases during x86_64-linux bootstrap + regtest.
> --- gcc/tree-ssa-phiopt.c.jj2018-11-22 18:45:54.670669434 +0100
> +++ gcc/tree-ssa-phiopt.c   2018-11-22 18:49:01.225590302 +0100
> @@ -266,7 +266,14 @@ tree_ssa_phiopt_worker (bool do_store_el
> min2 = wi::add (min2, 1);
>   else
> max2 = wi::sub (max2, 1);
> +{
> +FILE *f = fopen ("/tmp/phiopt", "a");
> +fprintf (f, "@ %d %s %s\n", (int) BITS_PER_WORD, main_input_filename ?
> main_input_filename : "-", current_function_name ());
> +dump_ssaname_info_to_file (f, phi_lhs, 0);
>   set_range_info (phi_lhs, VR_RANGE, min2, max2);
> +dump_ssaname_info_to_file (f, phi_lhs, 0);
> +fclose (f);
> +}
> }
> }
> }
> hack is what I've used to gather this info.
> Thinking about it, it might be better to stick it somewhere else, where we 
> walk
> PHI arguments (it would be cheaper to look for all phi arguments constants
> except one SSA_NAME from edge that ends in GIMPLE_COND comparison of that
> against constant).
> That said, I'm not really familiar with the evrp analyzers and how expensive
> they are, ideally this should be kept as something super cheap.  And don't
> really understand how union_ would be helpful, what we want here is not union,
> but narrowing the range.  Recomputing the range from scratch is possible but 
> it
> would be still better to compare it against the already recorded range and 
> only
> narrow it, never extend.

You need to union the PHI argument ranges.  The result you can intersect
with the existing range info of the PHI result of course.  You basically
want to do to the PHI what [E]VRP does ...

It's phiopt2 where this is important for the testcase?  Or phiopt3
after loop?  Because after loop there's forwprop before and ccp
after phiopt both of which would be a better fit.  Late CCP probably
doesn't need to be the SSA-propagator-iterating variant but could
do with a simpler DOM-style approach and thus could be replaced
by EVRP if it weren't for that lacking the alignment/nonzero bits
computation...

So I fear any "proper" solution isn't for stage3 but still I'd go
with factoring (enough of) vr_values::extract_range_from_phi_node
plus the register_edge_asserts thing if we need to look at
dominating conditions.

I also wouldn't restrict it to the case of all-constant PHI args
but one that gets range info from a dominating condition but simply
re-process ranges for all PHIs.  That said, forwprop already
tracks copies and constants and walks PHI args so maybe you can
fit the logic there?

[Bug c++/79996] spurious -Wreturn-type on a function that calls a noreturn function

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
(In reply to Eric Gallager from comment #4)
> (In reply to Eric Gallager from comment #3)
> > Might want to revisit this now that -Wreturn-type is on by default
> 
> The other Martin did that; cc-ing him

Sorry, I'm not a C++ FE developer. Yes, I enabled the warning by default. What
is the question related to my person here?

[Bug lto/88140] [9 Regression] ICE: verify_gimple failed since r266325

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de  ---
On Thu, 22 Nov 2018, hubicka at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88140
> 
> --- Comment #2 from Jan Hubicka  ---
> I am testing:
> Index: tree-cfg.c
> ===
> --- tree-cfg.c  (revision 266382)
> +++ tree-cfg.c  (working copy)
> @@ -3196,8 +3196,8 @@ verify_types_in_gimple_reference (tree e
>   error ("invalid COMPONENT_REF offset operator");
>   return true;
> }
> - if (!useless_type_conversion_p (TREE_TYPE (expr),
> - TREE_TYPE (TREE_OPERAND (expr, 1
> + if (!useless_type_conversion_p (TREE_TYPE (TREE_OPERAND (expr, 1)),
> + TREE_TYPE (expr)))
> {
>   error ("type mismatch in component reference");
>   debug_generic_stmt (TREE_TYPE (expr));

That's broken.  I'd rather adjust useless_type_conversion_p.  We
have here  incomplete-X *[] vs. complete-X *[], right?  But
how does

174   && (!TYPE_SIZE (inner_type)
175   || TREE_CODE (TYPE_SIZE (inner_type)) != INTEGER_CST
176   || !tree_int_cst_equal (TYPE_SIZE (outer_type),
177   TYPE_SIZE (inner_type

anything differ here?  The sizes of the pointers are equal!?

Ah,

(gdb) p inner_type->type_common.size
$1 = 
(gdb) p outer_type->type_common.size
$2 = 

why's that?!  That's probably the issue.  For ARRAY_TYPEs you
have to avoid doing TYPE_SIZE() = NULL; since you only want to
make pointed-to types of elements incomplete.

[Bug tree-optimization/88153] sqrt() is not vectorized

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
We can't vectorize sqrt () here unless we know nobody looks at errno later.

[Bug target/88152] optimize SSE & AVX char compares with subsequent movmskb

[kretz at kde dot org]

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

--- Comment #2 from Matthias Kretz  ---
I just realized, the movmsk(x<0) => movmsk(x) transformation also applies to
float and double if -ffinite-math-only (i.e. no NaN, it's alright for inf) and
-fno-signed-zeros are active.

[Bug tree-optimization/88156] ftree-vrp elides sign condition on mingw

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-w64-mingw32
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-11-23
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Can you reproduce with the following C testcase?  Indeed on x86_64-linux I do
not see this issue.  Can you check what __WCHAR_TYPE__ expands to for you
(preprocess the testcase)?

int string_hash(const __WCHAR_TYPE__* data) {
  int h = 0;

  if (!data){
return 0;
  }

  while (*data != 0) {
h = (h * 7) ^ *data;
++data;
  }

  if (h < 0) {
h = -h;
  }

  return h;
}

int main(int argc, char *argv[])
{
  int hash = string_hash(L"PROBABILIT");
  __builtin_printf("hash=%d\n", hash);
  return 0;
}

[Bug tree-optimization/88149] [9 Regression] ICE in vect_transform_stmt since r265959

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Btw, the reduced testcase also fails before r265959.  It looks like the issue
is either very old or got introduced with making the SLP tree a graph.  Well,
let's see what tracking down the issue reveals.

[Bug tree-optimization/88149] [9 Regression] ICE in vect_transform_stmt since r265959

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
(In reply to Richard Biener from comment #6)
> Btw, the reduced testcase also fails before r265959.  It looks like the issue
> is either very old or got introduced with making the SLP tree a graph. 
> Well, let's see what tracking down the issue reveals.

Right, this reduced code started to fail with r264866.

[Bug tree-optimization/88149] [9 Regression] ICE in vect_transform_stmt since r265959

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
(In reply to Martin Liška from comment #7)
> (In reply to Richard Biener from comment #6)
> > Btw, the reduced testcase also fails before r265959.  It looks like the 
> > issue
> > is either very old or got introduced with making the SLP tree a graph. 
> > Well, let's see what tracking down the issue reveals.
> 
> Right, this reduced code started to fail with r264866.

Richi, are you interested in a reduced test-case that fails with r265959, but
not with r264866?

[Bug tree-optimization/88149] [9 Regression] ICE in vect_transform_stmt since r265959

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
So it's a very old issue.  We have

t.ii:54:24: note:   node 0x3d755c0
t.ii:54:24: note:   stmt 0 _32 = _12 unord _42 ? _34 : _42;
t.ii:54:24: note:   stmt 1 _7 = _12 unord _42 ? _36 : _12;
t.ii:54:24: note:   children 0x3d74f40 0x3d8a180 0x3d75580 0x3d8a3c0

t.ii:54:24: note:   node 0x3d8a180
t.ii:54:24: note:   stmt 0 _42 = _5 - _3;
t.ii:54:24: note:   stmt 1 _42 = _5 - _3;
t.ii:54:24: note:   children 0x3d74f80 0x3d8a140

t.ii:54:24: note:   node (external) 0x3d8a3c0
t.ii:54:24: note:   stmt 0 _42 = _5 - _3;
t.ii:54:24: note:   stmt 1 _12 = _38 + _46;

so you can see that the same scalar stmt _42 = _5 - _3 is used in two
SLP nodes (that's fine) but the two nodes have different DEF type.
That's only fine if they are not "live" at the same time...

Testing patch.

[Bug tree-optimization/88149] [9 Regression] ICE in vect_transform_stmt since r265959

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
(In reply to Martin Liška from comment #8)
> (In reply to Martin Liška from comment #7)
> > (In reply to Richard Biener from comment #6)
> > > Btw, the reduced testcase also fails before r265959.  It looks like the 
> > > issue
> > > is either very old or got introduced with making the SLP tree a graph. 
> > > Well, let's see what tracking down the issue reveals.
> > 
> > Right, this reduced code started to fail with r264866.
> 
> Richi, are you interested in a reduced test-case that fails with r265959,
> but not with r264866?

I might be interested in one that fails on the GCC 8 branch or earlier.

[Bug rtl-optimization/88163] [9 Regression] Maximum number of LRA assignment passes is achieved (30) since r266385

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-23
  Known to work||8.2.0
   Assignee|unassigned at gcc dot gnu.org  |vmakarov at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1
  Known to fail||9.0

[Bug rtl-optimization/88163] New: [9 Regression] Maximum number of LRA assignment passes is achieved (30) since r266385

[marxin at gcc dot gnu.org]

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

Bug ID: 88163
   Summary: [9 Regression] Maximum number of LRA assignment passes
is achieved (30) since r266385
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ra
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: i586-linux-gnu

I see ICE when building libgo run-time library on i586 target:

during RTL pass: reload
../../../libgo/go/encoding/gob/decode.go: In function
‘gob.decodeSlice..1encoding/gob.Decoder’:
../../../libgo/go/encoding/gob/decode.go:613:1: internal compiler error:
Maximum number of LRA assignment passes is achieved (30)

  613 | func (dec *Decoder) decodeSlice(state *decoderState, value
reflect.Value, elemOp decOp, ovfl error, helper decHelper) {
  | ^
0x88644d0 lra_assign(bool&)
../../gcc/lra-assigns.c:1669
0x885eb8a lra(_IO_FILE*)
../../gcc/lra.c:2508
0x8812f89 do_reload
../../gcc/ira.c:5469
0x8812f89 execute
../../gcc/ira.c:5653

[Bug tree-optimization/88149] [9 Regression] ICE in vect_transform_stmt since r265959

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška  ---
(In reply to Richard Biener from comment #10)
> (In reply to Martin Liška from comment #8)
> > (In reply to Martin Liška from comment #7)
> > > (In reply to Richard Biener from comment #6)
> > > > Btw, the reduced testcase also fails before r265959.  It looks like the 
> > > > issue
> > > > is either very old or got introduced with making the SLP tree a graph. 
> > > > Well, let's see what tracking down the issue reveals.
> > > 
> > > Right, this reduced code started to fail with r264866.
> > 
> > Richi, are you interested in a reduced test-case that fails with r265959,
> > but not with r264866?
> 
> I might be interested in one that fails on the GCC 8 branch or earlier.

So you need to help what to grep in opt-info because it's not ICEing in GCC 8
branch?

[Bug tree-optimization/88149] [9 Regression] ICE in vect_transform_stmt since r265959

[rguenther at suse dot de]

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

--- Comment #12 from rguenther at suse dot de  ---
On Fri, 23 Nov 2018, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88149
> 
> --- Comment #11 from Martin Liška  ---
> (In reply to Richard Biener from comment #10)
> > (In reply to Martin Liška from comment #8)
> > > (In reply to Martin Liška from comment #7)
> > > > (In reply to Richard Biener from comment #6)
> > > > > Btw, the reduced testcase also fails before r265959.  It looks like 
> > > > > the issue
> > > > > is either very old or got introduced with making the SLP tree a 
> > > > > graph. 
> > > > > Well, let's see what tracking down the issue reveals.
> > > > 
> > > > Right, this reduced code started to fail with r264866.
> > > 
> > > Richi, are you interested in a reduced test-case that fails with r265959,
> > > but not with r264866?
> > 
> > I might be interested in one that fails on the GCC 8 branch or earlier.
> 
> So you need to help what to grep in opt-info because it's not ICEing in GCC 8
> branch?

It seems to rely on __muldc3 inline expansion added for GCC 9.  One
would need to open-code that.  Similarly manually constructing the
case should be possible.

But let's not waste our time with all this... ;)

[Bug tree-optimization/86614] [9 Regression] duplicate -Warray-bounds for a strncpy call with out-of-bounds offset

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 23 09:12:16 2018
New Revision: 266403

URL: https://gcc.gnu.org/viewcvs?rev=266403&root=gcc&view=rev
Log:
PR tree-optimization/86614
* gimple-ssa-warn-restrict.c (maybe_diag_offset_bounds): Return early
if TREE_NO_WARNING is set on ref.ref.

* c-c++-common/Warray-bounds-2.c (wrap_strncpy_dstarray_diff_neg,
call_strncpy_dstarray_diff_neg): Don't expect late -Warray-bounds
warnings, just early ones from FE.  Remove dg-prune-output.
* c-c++-common/Warray-bounds-6.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/Warray-bounds-6.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-warn-restrict.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c

[Bug c++/88164] New: Copy initialization of function argument not performed inside lambda when the argument is a constexpr block scope variable.

[okannen at gmail dot com]

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

Bug ID: 88164
   Summary: Copy initialization of function argument not performed
inside lambda when the argument is a constexpr block
scope variable.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: okannen at gmail dot com
  Target Milestone: ---

In the code bellow the copy constructor of "a" should be called:

  struct A {
int x=12;
constexpr A(){}
A(const A& x);
};

  int f(A);

  // This function should not compile
  // And the generated code does not call the copy constructor of A
  int test() {
constexpr A a{};
auto lambda = []{
return f(a); // Unexpected: does not call the copy constructor, 
 // should not compile: a should be explicitly captured
};
return lambda();
}

The the call to the copy constructor does not appear in the generated assembly:
  test():
subq$24, %rsp
leaq12(%rsp), %rdi
movl$12, 12(%rsp)
callf(A)
addq$24, %rsp
ret

While without the lambda:

  int test_expect_assembly(){
constexpr A a{};
return f(a);
}

the copy constructor is called:

  test_expect_assembly():
subq$24, %rsp
leaq8(%rsp), %rsi
leaq12(%rsp), %rdi
movl$12, 8(%rsp)
callA::A(A const&)
leaq12(%rsp), %rdi
callf(A)
addq$24, %rsp
ret

This unexpected copy constructor elision
only happens for function arguments construction.
The code below produces the expected assembly
and GCC requires the explicit capture of "a":

  int test_copy_initialization() {
constexpr A a{};
auto lambda = [&a]{ // a must be captured
A b=a;
return a.x;
};
return lambda();
}


Moreover there is a related bug when the variable has global scope,
the copy constructor is called, nevertheless GCC should not implicitly captures
the variable because the variable is ODR used. 

The capture should be explicit, the code below should not compile:

  constexpr A n_a{};
  int test_ns() {
auto lambda = []{
return f(n_a);// call the copy constructor so odr use n_a
  // Unexpected: n_a should be explictly captured
};
return lambda();
}

[Bug rtl-optimization/88163] [9 Regression] Maximum number of LRA assignment passes is achieved (30) since r266385

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
dup

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

[Bug bootstrap/88157] [9 Regression] ICE when building libgo encoding/gob.lo starting with r266385

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

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

[Bug lto/88159] LTO seems to mishandle exceptions that're thrown from c-linkage functions

[rguenth at gcc dot gnu.org]

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

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

[Bug rtl-optimization/88163] [9 Regression] Maximum number of LRA assignment passes is achieved (30) since r266385

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
err

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

[Bug bootstrap/88157] [9 Regression] ICE when building libgo encoding/gob.lo starting with r266385

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/85598] [7/8/9 Regression] Incorrect warning only at -O2 and -O3

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
(In reply to rguent...@suse.de from comment #11)
> You need to union the PHI argument ranges.  The result you can intersect
> with the existing range info of the PHI result of course.  You basically
> want to do to the PHI what [E]VRP does ...

If I were to recompute the range from scratch, yes, I would.
The way it is written, it is able to optimize just the common case, where it
uses the existing computed range and removes a single constant from the range,
either the minimum or maximum, if it can prove the minimum (resp. maximum) will
never occur.  It does so by proving all PHI arguments but one are constants not
equal to that value and one is from the edge where there is GIMPLE_COND
comparison of the PHI arg SSA_NAME against that single constant.

Now, I guess we could somewhat generalize it e.g. by accepting SSA_NAMEs with
ranges instead of constants and just prove (perhaps through vr-values.h APIs)
that the chosen constant is not in those ranges.

> It's phiopt2 where this is important for the testcase?  Or phiopt3
> after loop?  Because after loop there's forwprop before and ccp
> after phiopt both of which would be a better fit.  Late CCP probably
> doesn't need to be the SSA-propagator-iterating variant but could
> do with a simpler DOM-style approach and thus could be replaced
> by EVRP if it weren't for that lacking the alignment/nonzero bits
> computation...

For this testcase it needs to be done I believe in between dce2 (vrp1 does the
jump threading and dce2 does the cleanup in which the PHI <0> is propagated
into the PHI argument) and printf-return-value2 which needs it.
In its current form it doesn't work in between cselim and dom2 because in
between those passes (which include phiopt2) there is a forwarder block added
and the code doesn't handle that (though, especially if it does the
optimization from walking the PHIs rather than from the GIMPLE_COND) it could
skip a single forwarder block too.
SO, before cselim and in dom2 dump we have:
   [local count: 1063004407]:
  # RANGE [0, 256] NONZERO 511
  # x_10 = PHI <0(2), x_5(3)>
  __builtin_snprintf (&temp, 4, "%%%02X", x_10);
  # RANGE [1, 256] NONZERO 511
  x_5 = x_10 + 1;
  if (x_5 != 256)
goto ; [98.99%]
  else
goto ; [1.01%]
which the patch can optimize, but in between those we have:
   [local count: 1063004407]:
  # RANGE [0, 256] NONZERO 511
  # x_10 = PHI <0(2), x_5(5)>
  __builtin_snprintf (&temp, 4, "%%%02X", x_10);
  # RANGE [1, 256] NONZERO 511
  x_5 = x_10 + 1;
  if (x_5 != 256)
goto ; [98.99%]
  else
goto ; [1.01%]

   [local count: 1052266994]:
  goto ; [100.00%]
which has the extra forwarder.  So, on this testcase it is in the end optimized
in phiopt3.  There is forwprop3 in between those passes.

> So I fear any "proper" solution isn't for stage3 but still I'd go
> with factoring (enough of) vr_values::extract_range_from_phi_node
> plus the register_edge_asserts thing if we need to look at
> dominating conditions.

Yes, I'm afraid this is just GCC 9 hack and I hope somebody (Aldy, Martin) will
do the right thing for GCC 10 and this hack can be removed.

[Bug lto/88049] [7/8/9 Regression] ICE in lto_symtab_prevailing_virtual_decl at gcc/lto/lto-symtab.c:1075 since r231671

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed|2018-11-15 00:00:00 |2018-11-23
 Ever confirmed|0   |1

[Bug lto/88081] [7/8/9 Regression] ICE in lto_varpool_replace_node, at lto/lto-symtab.c:109

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed|2018-11-19 00:00:00 |2018-11-23
 Ever confirmed|0   |1

[Bug target/87883] [ARM] ICE: Segmentation fault in arm_regno_class

[mihail.ionescu at arm dot com]

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

--- Comment #1 from Mihail Ionescu  ---
Hi Jozef,

The issue is indeed there on trunk/gcc-8/gcc-7, but it is expected. It is
caused by the fact that the "arm_active_target.isa" bitmap is not initialised
by the time "init_reg_sets" is called. This can be fixed by checking if it is
initialised or not in the arm backend, but it is not ideal, as arm_regno_class
(REGNO_REG_CLASS) is not supposed to be queried at that time.

What exactly is your patch trying to do? Is there any way of working around
this within your patch?


Best regards,
Mihail

[Bug lto/87501] lto1: error: Alias and target's section differs

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Honza, can you please take a look?

[Bug ipa/87264] missed optimization of std::find_if (predicate inlining)

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Jonathan, can you please take a look?

[Bug ipa/87264] missed optimization of std::find_if (predicate inlining)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug sanitizer/59067] libsanitizer doesn't build with binutils 2.17.50.0.6 on x86_64-unknown-linux-gnu

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||marxin at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #1 from Martin Liška  ---
5 years later, the binutils version is even more archaic.

[Bug sanitizer/78878] stacktrace engine can't use compressed/separated debug info for extracting symbols.

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Maxim, what's the status of the support?

[Bug ipa/83545] New: ICE at -O3 on x86_64-linux-gnu: in smallest_mode_for_size, at stor-layout.c:355

[marxin at gcc dot gnu.org]

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

Bug ID: 83545
   Summary: ICE at -O3 on x86_64-linux-gnu: in
smallest_mode_for_size, at stor-layout.c:355
   Product: gcc
   Version: unknown
Status: WAITING
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
CC: marxin at gcc dot gnu.org
  Target Milestone: ---
Status: WAITING
  Last reconfirmed: 2018-11-23
Ever confirmed: 1

$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20171222 (experimental) [trunk revision 255967] (GCC)
$
$ gcctk -O2 -c small.c
$ gcc-7.2.0 -O3 -c small.c
$
$ gcctk -O3 -c small.c
during RTL pass: dse1
small.c: In function ‘f’:
small.c:8:1: internal compiler error: in smallest_mode_for_size, at
stor-layout.c:355
 }
 ^
0xc760eb smallest_mode_for_size(poly_int<1u, unsigned long>, mode_class)
../../gcc-source-trunk/gcc/stor-layout.c:355
0x13ed0dd smallest_int_mode_for_size(poly_int<1u, unsigned long>)
../../gcc-source-trunk/gcc/machmode.h:737
0x13ed0dd find_shift_sequence
../../gcc-source-trunk/gcc/dse.c:1696
0x13ed0dd get_stored_val
../../gcc-source-trunk/gcc/dse.c:1842
0x13ef9af record_store
../../gcc-source-trunk/gcc/dse.c:1552
0x13f07f2 scan_insn
../../gcc-source-trunk/gcc/dse.c:2540
0x13f19e2 dse_step1
../../gcc-source-trunk/gcc/dse.c:2652
0x13f19e2 rest_of_handle_dse
../../gcc-source-trunk/gcc/dse.c:3569
0x13f19e2 execute
../../gcc-source-trunk/gcc/dse.c:3667
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$


-


int a, b, c[1][25];

void f ()
{ 
  for (a = 0; a < 5; a++)
for (b = 0; b < 5; b++)
  c[397][a * 5 + b] = 1;
}

--- Comment #1 from Martin Liška  ---
Can't reproduce, can you please recheck?

[Bug ipa/87264] missed optimization of std::find_if (predicate inlining)

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Martin Liška from comment #2)
> Jonathan, can you please take a look?

Seems like an optimizer bug, since Clang does much better on the same code.

[Bug middle-end/85598] [7/8/9 Regression] Incorrect warning only at -O2 and -O3

[rguenther at suse dot de]

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

--- Comment #13 from rguenther at suse dot de  ---
On Fri, 23 Nov 2018, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85598
> 
> --- Comment #12 from Jakub Jelinek  ---
> (In reply to rguent...@suse.de from comment #11)
> > You need to union the PHI argument ranges.  The result you can intersect
> > with the existing range info of the PHI result of course.  You basically
> > want to do to the PHI what [E]VRP does ...
> 
> If I were to recompute the range from scratch, yes, I would.
> The way it is written, it is able to optimize just the common case, where it
> uses the existing computed range and removes a single constant from the range,
> either the minimum or maximum, if it can prove the minimum (resp. maximum) 
> will
> never occur.  It does so by proving all PHI arguments but one are constants 
> not
> equal to that value and one is from the edge where there is GIMPLE_COND
> comparison of the PHI arg SSA_NAME against that single constant.
> 
> Now, I guess we could somewhat generalize it e.g. by accepting SSA_NAMEs with
> ranges instead of constants and just prove (perhaps through vr-values.h APIs)
> that the chosen constant is not in those ranges.
> 
> > It's phiopt2 where this is important for the testcase?  Or phiopt3
> > after loop?  Because after loop there's forwprop before and ccp
> > after phiopt both of which would be a better fit.  Late CCP probably
> > doesn't need to be the SSA-propagator-iterating variant but could
> > do with a simpler DOM-style approach and thus could be replaced
> > by EVRP if it weren't for that lacking the alignment/nonzero bits
> > computation...
> 
> For this testcase it needs to be done I believe in between dce2 (vrp1 does the
> jump threading and dce2 does the cleanup in which the PHI <0> is propagated
> into the PHI argument) and printf-return-value2 which needs it.
> In its current form it doesn't work in between cselim and dom2 because in
> between those passes (which include phiopt2) there is a forwarder block added

Note that dom after vrp1 should be able to adjust the value-ranges given
it uses EVRP to track ranges...  why doesn't that work?

> and the code doesn't handle that (though, especially if it does the
> optimization from walking the PHIs rather than from the GIMPLE_COND) it could
> skip a single forwarder block too.
> SO, before cselim and in dom2 dump we have:
>[local count: 1063004407]:
>   # RANGE [0, 256] NONZERO 511
>   # x_10 = PHI <0(2), x_5(3)>
>   __builtin_snprintf (&temp, 4, "%%%02X", x_10);
>   # RANGE [1, 256] NONZERO 511
>   x_5 = x_10 + 1;
>   if (x_5 != 256)
> goto ; [98.99%]
>   else
> goto ; [1.01%]
> which the patch can optimize, but in between those we have:
>[local count: 1063004407]:
>   # RANGE [0, 256] NONZERO 511
>   # x_10 = PHI <0(2), x_5(5)>
>   __builtin_snprintf (&temp, 4, "%%%02X", x_10);
>   # RANGE [1, 256] NONZERO 511
>   x_5 = x_10 + 1;
>   if (x_5 != 256)
> goto ; [98.99%]
>   else
> goto ; [1.01%]
> 
>[local count: 1052266994]:
>   goto ; [100.00%]
> which has the extra forwarder.  So, on this testcase it is in the end 
> optimized
> in phiopt3.  There is forwprop3 in between those passes.
> 
> > So I fear any "proper" solution isn't for stage3 but still I'd go
> > with factoring (enough of) vr_values::extract_range_from_phi_node
> > plus the register_edge_asserts thing if we need to look at
> > dominating conditions.
> 
> Yes, I'm afraid this is just GCC 9 hack and I hope somebody (Aldy, Martin) 
> will
> do the right thing for GCC 10 and this hack can be removed.
> 
>

[Bug ipa/87264] missed optimization of std::find_if (predicate inlining)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   See Also|https://gcc.gnu.org/bugzill |
   |a/show_bug.cgi?id=84170 |
 CC||barannikov88 at gmail dot com

--- Comment #4 from Jonathan Wakely  ---
*** Bug 84170 has been marked as a duplicate of this bug. ***

[Bug libstdc++/84170] std::find_if performance issues

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   See Also|https://gcc.gnu.org/bugzill |
   |a/show_bug.cgi?id=87264 |
 Resolution|--- |DUPLICATE

--- Comment #2 from Jonathan Wakely  ---
PR 87264 has numbers and benchmarks, so let's close this as a dup of that one.

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

[Bug tree-optimization/88156] ftree-vrp elides sign condition on mingw

[xantares09 at hotmail dot com]

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

--- Comment #2 from xantares09 at hotmail dot com ---
Thanks for the quick reply.

On mingw __WCHAR_TYPE__ expands to short unsigned int:

$ x86_64-w64-mingw32-gcc -E main.c
...
# 3 "main.cxx"
int string_hash(const short unsigned int* data) {


On x86_64-linux it expands to int:
$ gcc -E main.c
...
# 3 "main.c"
int string_hash(const int* data) {

[Bug tree-optimization/88156] ftree-vrp elides sign condition on mingw

[xantares09 at hotmail dot com]

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

--- Comment #3 from xantares09 at hotmail dot com ---
Add yes, your C testcase leads to the same results.

[Bug ipa/87957] [9 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘identifier_node’ in warn_odr, at ipa-devirt.c:1051 since r265519

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||ro at gcc dot gnu.org
 Resolution|FIXED   |---

--- Comment #12 from Rainer Orth  ---
Your patch most likely caused a regression:

+FAIL: gnat.dg/lto8.adb (test for excess errors)
+FAIL: gnat.dg/lto8.adb 3 blank line(s) in output
+UNRESOLVED: gnat.dg/lto8.adb compilation failed to produce executable

+===GNAT BUG DETECTED==+
| 9.0.0 20181122 (experimental) [trunk revision 266382] (i386-pc-solaris2.11)
GCC error:|
| in fld_incomplete_type_of, at tree.c:5300|
| Error detected around
/var/gcc/regression/trunk/11-gcc-gas/build/i386-pc-solaris2.11/./libada/adainclude/s-atacco.ads:39:16|

Seen on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (32 and 64-bit,
gcc-testresults
reports also on aarch64-suse-linux-gnu, arm-unknown-linux-gnueabihf,
s390x-ibm-linux-gnu default

[Bug middle-end/85598] [7/8/9 Regression] Incorrect warning only at -O2 and -O3

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
(In reply to rguent...@suse.de from comment #13)
> Note that dom after vrp1 should be able to adjust the value-ranges given
> it uses EVRP to track ranges...  why doesn't that work?

>From what I see, dom never calls record_ranges_from_phis, but even if it would,
it wouldn't handle the relevant case here, which is to interset the range of
the SSA_NAME phi arg with the edge condition (as if there was an assertion
registered).

I think I'm able to implement this in forwprop using with using the
get_range_info (const_tree, value_range_base &),
value_range::{deep_copy,intersect,union} APIs, or defer to somebody familiar
with  dom and evrp range analyzer to do it in dom (Jeff, Aldy).

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

[Umesh Kalappa]

Hi Richard,

for the subjected issue , we found few suggestions to handle the issue like

 1. be more conservative(target specific) and defining the peephole in
the md file to handle the patterns like add,shl and movl to "shlq and
movl"
 2. like you mentioned  in fwprop/combiner .

we would like to know your inputs /suggestions before we go ahead with
the patch.

Thank you
~Umesh

[Bug tree-optimization/88156] ftree-vrp elides sign condition on mingw

[xantares09 at hotmail dot com]

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

--- Comment #4 from xantares09 at hotmail dot com ---
I found this in stddef.h:

#ifndef __WCHAR_TYPE__
/* wchar_t is unsigned short for compatibility with MS runtime */
#define __WCHAR_TYPE__ unsigned short
#endif

[Bug tree-optimization/88156] ftree-vrp elides sign condition on mingw

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/88156] ftree-vrp elides sign condition on mingw

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On Fri, 23 Nov 2018, xantares09 at hotmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88156
> 
> --- Comment #2 from xantares09 at hotmail dot com ---
> Thanks for the quick reply.
> 
> On mingw __WCHAR_TYPE__ expands to short unsigned int:
> 
> $ x86_64-w64-mingw32-gcc -E main.c
> ...
> # 3 "main.cxx"
> int string_hash(const short unsigned int* data) {
> 
> 
> On x86_64-linux it expands to int:
> $ gcc -E main.c
> ...
> # 3 "main.c"
> int string_hash(const int* data) {

Ok, but then we have

h = (h * 7) ^ *data;

which is on mingw

  h = (h * 7) ^ (int)*data

zero-extending *data.  This means the XOR can never change
the sign of h.  Likewise h * 7 can never make h negative
because h is initially zero and the operation would need to
overflow to become negative but that would invoke undefined
behavior.

Thus the bug is INVALID.

You can use -fwrapv or make h unsigned int to fix this
(and adjust the h < 0 test to (int)h < 0).

[Bug sanitizer/78878] stacktrace engine can't use compressed/separated debug info for extracting symbols.

[chefmax at gcc dot gnu.org]

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

--- Comment #2 from chefmax at gcc dot gnu.org ---
Should be fixed, I guess, by:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67165
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77631

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[jakub at gcc dot gnu.org]

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

Bug 86614 Summary: [9 Regression] duplicate -Warray-bounds for a strncpy  call 
with out-of-bounds offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86614

   What|Removed |Added

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

[Bug tree-optimization/86614] [9 Regression] duplicate -Warray-bounds for a strncpy call with out-of-bounds offset

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

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

[Bug bootstrap/62009] Bootstrap failure in vec.h::splice

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #3 from Arseny Solokha  ---
Is it still an issue?

[Bug c/28233] internal compiler error: in make_decl_rtl, at varasm.c:752

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #10 from Arseny Solokha  ---
Is it still an issue?

[Bug middle-end/85598] [7/8/9 Regression] Incorrect warning only at -O2 and -O3

[rguenther at suse dot de]

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

--- Comment #15 from rguenther at suse dot de  ---
On Fri, 23 Nov 2018, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85598
> 
> --- Comment #14 from Jakub Jelinek  ---
> (In reply to rguent...@suse.de from comment #13)
> > Note that dom after vrp1 should be able to adjust the value-ranges given
> > it uses EVRP to track ranges...  why doesn't that work?
> 
> From what I see, dom never calls record_ranges_from_phis, but even if it 
> would,
> it wouldn't handle the relevant case here, which is to interset the range of
> the SSA_NAME phi arg with the edge condition (as if there was an assertion
> registered).

It records ranges from incoming edges though via evrp_range_analyzer.enter
(dom_opt_dom_walker::before_dom_children).

Yeah, it then just does

  /* Create equivalences from redundant PHIs.  PHIs are only truly
 redundant when they exist in the same block, so push another
 marker and unwind right afterwards.  */
  m_avail_exprs_stack->push_marker ();
  for (gsi = gsi_start_phis (bb); !gsi_end_p (gsi); gsi_next (&gsi))
eliminate_redundant_computations (&gsi, m_const_and_copies,
  m_avail_exprs_stack);

this is where it would need to call into evrp_range_analyzer.  I guess
simply doing

  evrp_range_analyzer.record_ranges_from_stmt (gsi_stmt (gsi), false);

there would work?

> I think I'm able to implement this in forwprop using with using the
> get_range_info (const_tree, value_range_base &),
> value_range::{deep_copy,intersect,union} APIs, or defer to somebody familiar
> with  dom and evrp range analyzer to do it in dom (Jeff, Aldy).
> 
>

[Bug sanitizer/78878] stacktrace engine can't use compressed/separated debug info for extracting symbols.

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Great, then let's close it.

[Bug target/71958] x86_64-w64-mingw32, ICE when '-mx32' is used

[daniel.santos at pobox dot com]

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

--- Comment #6 from Daniel Santos  ---
(In reply to Martin Liška from comment #5)
> Dansan: Can you please update Known to work?

Hi Martin,

I don't have bugzilla admin access.  I'm actually missing my gcc git repo due
to a faulty backup when i created my new system, so I can't verify it right now
but I believe it was fixed in 8.1.

[Bug middle-end/82918] No aliasing is possible on non equal pointers

[antoshkka at gmail dot com]

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

--- Comment #2 from Antony Polukhin  ---
The example from above now produces optimal assembly on GCC-9 (trunk).

However, swapping first two lines still produces suboptimal result:

struct array {
int data[3];
};

void foo2(array& value, const array& value2) {
if (&value == &value2) return;
value.data[1] = value2.data[0];
value.data[0] = value2.data[0];
value.data[2] = value2.data[0];
}

Outputs:

_Z4foo2R5arrayRKS_:
  cmp rdi, rsi
  je .L1
  mov eax, DWORD PTR [rsi]
  mov DWORD PTR [rdi+4], eax
  mov DWORD PTR [rdi], eax
  mov eax, DWORD PTR [rsi]  <=== This is not required
  mov DWORD PTR [rdi+8], eax
.L1:
  ret

[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek  ---
Tried again, this time on real hw (i9-7960X) and still can't reproduce, tried
current trunk, current 8 branch and r263070 (i.e. trunk from the time this PR
has been filed), none of this reproduces it.

[Bug target/71958] x86_64-w64-mingw32, ICE when '-mx32' is used

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Liška  ---
(In reply to Daniel Santos from comment #6)
> (In reply to Martin Liška from comment #5)
> > Dansan: Can you please update Known to work?
> 
> Hi Martin,
> 
> I don't have bugzilla admin access.  I'm actually missing my gcc git repo
> due to a faulty backup when i created my new system, so I can't verify it
> right now but I believe it was fixed in 8.1.

I see, so let's close it then.

[Bug target/86828] [7 Regression] wrong-code bug with "-march=knl -Ofast" (invalid memory reference)

[janus at gcc dot gnu.org]

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

--- Comment #13 from janus at gcc dot gnu.org ---
(In reply to H.J. Lu from comment #12)
> Which glibc are you using?

Same as reported in PR86735:
* Ubuntu 18.04, kernel 4.15.0
* Intel(R) Core(TM) i9-7980XE CPU
* glibc 2.27, binutils 2.30

[Bug target/87883] [ARM] ICE: Segmentation fault in arm_regno_class

[jozef.l at mittosystems dot com]

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

--- Comment #2 from Jozef Lawrynowicz  ---
Created attachment 45074
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45074&action=edit
reg class checking patch

Hi Mihail,

Thanks for the info.

I fixed a bug for msp430-elf caused by REGNO_REG_CLASS and REG_CLASS_CONTENTS
being out of sync i.e. REGNO_REG_CLASS[reg] reported one class, but the bit for
that reg in that class was not set in REG_CLASS_CONTENTS.

So I was trying to add some generic warning to the middle-end which would catch
these cases for other targets (see attached patch). However, there were some
other issues with my proposal so I've parked it for now.

Given that I'm not going to proceed with my patch in its current state, it's up
to you whether to close this PR or not.

Kind regards,
Jozef

[Bug target/71958] x86_64-w64-mingw32, ICE when '-mx32' is used

[daniel.santos at pobox dot com]

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

--- Comment #8 from Daniel Santos  ---
Thank you!

[Bug target/86832] [8/9 Regression] GCC v8.2.0 tries to use native TLS with -fstack-protector-strong on Windows (mingw-w64)

[john at johnwarburton dot net]

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

--- Comment #11 from John Warburton  ---
On Thu, Nov 22, 2018 at 10:09 AM jakub at gcc dot gnu.org
 wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86832
>
> --- Comment #10 from Jakub Jelinek  ---
> Can somebody please test this on mingw (on the trunk)? Thanks.

I've started a compilation of the trunk on GNU/Linux outputting
x86_64-w64-mingw32-gcc etc., and will then cross-compile a fairly
complex program that uses the flag that caused trouble. Or, at least,
will try. I normally use gcc-8-branch, not trunk.

JW

[Bug middle-end/82918] No aliasing is possible on non equal pointers

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Probably fixed by r255093

2017-11-23  Richard Biener  

PR tree-optimization/23094
* tree-ssa-sccvn.c (vuse_ssa_val): Handle VN_TOP when we
come here from walking over backedges in the first iteration.
(vn_reference_lookup_3): Skip clobbers that store the same value.

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

because we now see that we at most store the same value to value.data[0].

  _1 = value2_6(D)->data[0];
  value_5(D)->data[0] = _1;
  _2 = value2_6(D)->data[0];

But the handling is quite simplistic so

value.data[0] = value2.data[0]+1;
value.data[1] = value2.data[0]+1;
value.data[2] = value2.data[0]+1;

isn't handled.  We also do not walk which is why the swapped case isn't
handled either.

[Bug c++/88165] New: error: default member initializer for 'A::B::m' required before the end of its enclosing class

[leanid.chaika at gmail dot com]

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

Bug ID: 88165
   Summary: error: default member initializer for 'A::B::m'
required before the end of its enclosing class
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: leanid.chaika at gmail dot com
  Target Milestone: ---

The following compiles with MSVC2017 and not with gcc8.2. This bug was reported
first on stackoverflow
(https://stackoverflow.com/questions/53408962/try-to-understand-compiler-error-message-default-member-initializer-required-be)

minimum code example:
-prog.cc-
#include 
class A
{
   public:
  class B
  {
 public:
explicit B() = default;
~B() = default;

 private:
double m = std::numeric_limits::max();
  };

   void f(double d, const B &b = B{}) {}
};

int main()
{
   A a{};
   a.f(0.);
}

compile command:
g++ prog.cc -std=c++17 

error message:
prog.cc:15:36: error: default member initializer for 'A::B::m' required before
the end of its enclosing class
void f(double d, const B &b = B{}) {}
^
prog.cc:12:22: note: defined here
 double m = std::numeric_limits::max();
  ^

[Bug tree-optimization/88156] ftree-vrp elides sign condition on mingw

[xantares09 at hotmail dot com]

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

xantares09 at hotmail dot com changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #7 from xantares09 at hotmail dot com ---
Ok, thank you.

[Bug tree-optimization/88156] ftree-vrp elides sign condition on mingw

[xantares09 at hotmail dot com]

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

xantares09 at hotmail dot com changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #8 from xantares09 at hotmail dot com ---
Ok, thank you.

[Bug c++/88165] error: default member initializer for 'A::B::m' required before the end of its enclosing class

[leanid.chaika at gmail dot com]

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

--- Comment #1 from leanid  ---
minim code:
---
struct A
{
  struct B
  {
double m = 0.;
  };

   void f(double d, const B &b = B{}) {}
};

int main()
{
}
---

[Bug sanitizer/86229] ASAN Reports "alloc-dealloc mismatch" intsead of "attempted delete without new"

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-23
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, very interesting problem. I hope I have a patch, I'll try to
upstream it.

[Bug target/84711] AArch32 big-endian fails when taking subreg of a vector mode to a scalar mode.

[tnfchris at gcc dot gnu.org]

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

--- Comment #20 from Tamar Christina  ---
Author: tnfchris
Date: Fri Nov 23 12:20:20 2018
New Revision: 266405

URL: https://gcc.gnu.org/viewcvs?rev=266405&root=gcc&view=rev
Log:
Arm: Fix subreg crash when FP16 and big-endian

The original issue comes from the fact that the code does

... foo (... bar)
{
  return bar;
}

The expansion of the return statement causes GCC to try to return the value in
a register.  GCC will try to emit the move then, from MEM to REG (due to the
SSA
temporary.).  It checks for a mov optab for this which isn't available and
then tries to do the move in bits using emit_move_multi_word.

emit_move_multi_word will split the move into sub parts, but then needs to get
the sub parts and does this using subregs, but it's told it can't do subregs!

The compiler is now stuck in an infinite loop.

The way this is worked around in the back-end is that we have move patterns in
neon.md that usually just force the register instead of checking with the
back-end. This prevents emit_move_multi_word from being needed.  However the
pattern for V4HF and V8HF were guarded by TARGET_NEON && TARGET_FP16.

I don't believe the TARGET_FP16 guard to be needed, because the pattern doesn't
actually generate code and requires another pattern for that, and a reg to reg
move
should always be possible anyway. So allowing the force to register here is
safe
and it allows the compiler to generate a correct error instead of ICEing in an
infinite loop.

Regtested on armeb-none-eabi and no regressions.
Bootstrapped on arm-none-linux-gnueabihf and no issues.

Thanks,
Tamar

gcc/
2018-11-23  Tamar Christina  

Backported from mainline.
2018-08-16  Tamar Christina  

PR target/84711
* config/arm/neon.md (movv4hf, movv8hf): Refactored to..
(mov): ..this and enable unconditionally.


Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/arm/neon.md

[Bug sanitizer/86229] ASAN Reports "alloc-dealloc mismatch" intsead of "attempted delete without new"

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

URL||https://reviews.llvm.org/D5
   ||4856

--- Comment #2 from Martin Liška  ---
I proposed upstream fix, let's see what will they say.

[Bug target/84711] AArch32 big-endian fails when taking subreg of a vector mode to a scalar mode.

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #21 from Tamar Christina  ---
closed with backport to GCC8

[Bug lto/88147] [9 Regression] ICE in linemap_line_start, at libcpp/line-map.c:781 starting from r265875

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Can't reduce that, not a surprise.

[Bug libstdc++/59075] python pretty printer does not work at OS X

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Tom, do you know why the types might be shown differently on OS X and
GNU/Linux? (see comments 7 and 8).

Is that because of something different in the DWARF? Is that expected for OS X,
or is it a GCC bug?

[Bug libstdc++/59075] python pretty printer does not work at OS X

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|trivial |normal

[Bug libstdc++/87308] pretty printer for std::any fails with: Python Exception Unknown manager function in std::any

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-23
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug sanitizer/82109] False positive when using pthread_cleanup_push() and pthread_cancel()

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Confirmed, note that when a cleanup_routine is executed, it has following
back-trace:

(gdb) bt
#0  cleanup_routine (arg=0x0) at asan_pthread_cancel.c:9
#1  0x004014ed in start_routine (arg=0x7fffdae0) at
asan_pthread_cancel.c:24
#2  0x76df7554 in start_thread (arg=) at
pthread_create.c:463
#3  0x76b2accf in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

So it's a longjmp probably. The test-case is very trick, probably not fixable
easy. Note that you should not do a fancy stuff in a pthread cleanup function.

[Bug sanitizer/82109] False positive when using pthread_cleanup_push() and pthread_cancel()

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug web/63873] target links in Concepts Index in gccint do not work

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-11-23
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Looks it's fixed now. Can you please recheck?

[Bug target/86828] [7 Regression] wrong-code bug with "-march=knl -Ofast" (invalid memory reference)

[hjl.tools at gmail dot com]

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

--- Comment #14 from H.J. Lu  ---
(In reply to janus from comment #13)
> (In reply to H.J. Lu from comment #12)
> > Which glibc are you using?
> 
> Same as reported in PR86735:
> * Ubuntu 18.04, kernel 4.15.0
> * Intel(R) Core(TM) i9-7980XE CPU
> * glibc 2.27, binutils 2.30

Please try kernel 4.17.xx or above.

[Bug tree-optimization/88149] [7/8/9 Regression] ICE in vect_transform_stmt since r265959

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|9.0 |7.4
Summary|[9 Regression] ICE in   |[7/8/9 Regression] ICE in
   |vect_transform_stmt since   |vect_transform_stmt since
   |r265959 |r265959

--- Comment #13 from Richard Biener  ---
Fixed on trunk.  I'm going to backport since the issue is latent.

[Bug tree-optimization/88149] [7/8/9 Regression] ICE in vect_transform_stmt since r265959

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
Author: rguenth
Date: Fri Nov 23 12:53:39 2018
New Revision: 266406

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

PR tree-optimization/88149
* tree-vect-slp.c (vect_slp_analyze_node_operations): Detect
the case where there are two different def types for the
same operand at different operand position in the same stmt.

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

Added:
trunk/gcc/testsuite/g++.dg/torture/pr88149.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-slp.c

[Bug c++/88166] New: Inconsistent placement of cv-quals and ptr-declarator in debuginfo

[redi at gcc dot gnu.org]

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

Bug ID: 88166
   Summary: Inconsistent placement of cv-quals and ptr-declarator
in debuginfo
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

Given:

struct any {

  enum Op { E };

  struct Arg { char c; };

  template
struct Manager
{
  static void manage(Op, const any*, Arg*) { }
};
};

int main()
{
  auto lambda = [](){};
  auto f1 = &any::Manager::manage;
  auto f2 = &any::Manager::manage;
  return 0;
}

g++ -g any.cc
gdb -q -ex start -ex "n 2" -ex "p f1" -ex "p f2" -ex cont -ex q a.out
Reading symbols from a.out...done.
Temporary breakpoint 1 at 0x4004ab: file any.cc, line 15.
Starting program: /tmp/a.out 

Temporary breakpoint 1, main () at any.cc:15
15auto f1 = &any::Manager::manage;
17return 0;
$1 = (void (*)(const any *, any::Arg *)) 0x4004d1
::manage(any const*, any::Arg*)>
$2 = (void (*)(const any *, any::Arg *)) 0x4004c2
 >::manage(const any *, any::Arg *)>
Continuing.
[Inferior 1 (process 29483) exited normally]

Note that the first function parameter-list is (any const*, any::Arg*) and the
second is (const any *, any::Arg *).

This breaks the python pretty printers for std::any (see Bug 87308).

Why the inconsistency?

[Bug c++/88166] Inconsistent placement of cv-quals and ptr-declarator in debuginfo

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Oops, I simplified the testcase, but didn't update it in bugzilla before
submitting the form. The output above corresponds to this code:

struct any {

  struct Arg { char c; };

  template
struct Manager
{
  static void manage(const any*, Arg*) { }
};
};

int main()
{
  auto lambda = [](){};
  auto f1 = &any::Manager::manage;
  auto f2 = &any::Manager::manage;
  return 0;
}

[Bug libstdc++/59075] python pretty printer does not work at OS X

[iains at gcc dot gnu.org]

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

--- Comment #11 from Iain Sandoe  ---
(In reply to Jonathan Wakely from comment #10)
> Tom, do you know why the types might be shown differently on OS X and
> GNU/Linux? (see comments 7 and 8).
> 
> Is that because of something different in the DWARF? Is that expected for OS
> X, or is it a GCC bug?

Can we check that this is still current on trunk after the fix for 70694 was
applied - since that alters visibility of some symbols (maybe a long shot).

It's not expected that Darwin will do anything differently modulo (1) it
doesn't use .cfi_xxx at present, (2) it's generally limited to DWARF2 [a
historical issue with older versions of dsymutil, see below], although I hope
to lift that restriction soon, since we now have a DWARF4-capable dsymutil

However .. the status quo is:

Darwin has the following strategy for debug.
 1. the static linker ignores DWARF but writes a table of object file locations
into the executable.
 2a.  the executable + the object files can be consumed by a debug client (e.g.
GDB)
- the table in the exe tells the client where to find the objects and it
can read/link the DWARF from them directly.  This often makes sense for a
developer who is doing a lot of compile/edit/debug loops.  GDB understands this
approach (last i tried),

 2b.  if one doesn't want to keep the objects around; the executable + the
objects can be consumed by "dsymutil" this is Darwin's debug linker, which
produces a monolithic debug object (which can be consumed alongside the actual
executable to provide the debug data).  For whatever reason, the design wraps
this linked debug object in a macOS package structure thus:
  .dSYM/
Contents/
  Resources/
   DWARF/
 exename

This applies to any DSO, so shlibs are the same (for libstdc++ the 'exename'
would be libstdc++.dlib).

  - I'm not 100% sure whether upstream GDB still (or ever did) understands the
packaged version, Apple's GDB did - but that's long out of date.

==

As for reading Mach-O DWARF, binutils works for x86_64-apple-darwin last I
tried (you have to point it at the actual linked DWARF tho, I don't think any
of the tools understand the .dSYM package layout).

Alternately, the llvm binutils look-alikes are getting more compatible and
consume Mach-O.

Caveat, I've, but not built/tested binutils / GDB for at least 6 months on
Darwin, so my comments might be out of date.

[Bug c/28233] internal compiler error: in make_decl_rtl, at varasm.c:752

[jphartmann at gmail dot com]

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

--- Comment #11 from jphartmann at gmail dot com  
---
I certainly haven't been waiting for a fix these last ten years, so by all
means close.

[Bug target/88167] New: [ARM] Function __builtin_return_address returns invalid address

[mihail.ionescu at arm dot com]

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

Bug ID: 88167
   Summary: [ARM] Function __builtin_return_address returns
invalid address
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mihail.ionescu at arm dot com
  Target Milestone: ---

Used compiler options are: -mcpu=cortex-m0 -mthumb -O2.

Consider the following code:

__attribute__((used))
void *retaddr;

__attribute__((noinline))
void test(void) {
  retaddr = __builtin_return_address(0);

  /* Used for enforcing registers stacking.*/
  asm volatile("" : : : "r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7",
"r8", "r9", "r10", "r11", "r12");
}

It produces the following asm:

 8001940: b5f0 push {r4, r5, r6, r7, lr}
 8001942: 46de mov lr, fp <=== HERE LR is used as a scratchpad
 8001944: 4657 mov r7, sl
 8001946: 464e mov r6, r9
 8001948: 4645 mov r5, r8
 800194a: 4672 mov r2, lr <=== HERE LR is accessed for return address
 800194c: 4b04 ldr r3, [pc, #16] ; (8001960 )
 800194e: b5e0 push {r5, r6, r7, lr}
 8001950: 601a str r2, [r3, #0]
 8001952: bc3c pop {r2, r3, r4, r5}
 8001954: 4690 mov r8, r2
 8001956: 4699 mov r9, r3
 8001958: 46a2 mov sl, r4
 800195a: 46ab mov fp, r5
 800195c: bdf0 pop {r4, r5, r6, r7, pc}

The problem is in the function entry code, where callee-saved registers are
stacked. LR is used as scratchpad @8001942 before the return address is taken
@800194a.

This problem broke the ChibiOS port for Cortex-M0 using the latest compilers,
the builtin is used for enforcing context switch after nested ISRs execution, a
very critical bit of code, there is no easy way to workaround this.

[Bug libstdc++/87308] pretty printer for std::any fails with: Python Exception Unknown manager function in std::any

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Jeff Garrett from comment #0)
> Note that both a1 and a2 are interpreted as holding type main::{lambda()#2},
> but a1 actually holds main::{lambda()#1}.

I can fix the regex to work for lambdas, but I'm not sure what to do about that
part.

The debuginfo for the manager just shows the type as "main()::" which
doesn't uniquely identify the type. The function's gdb.Symbol.linkage_name
property (which is supposed to be the mangled name) is the same as its
gdb.Symbol.name, so that doesn't help.

The problem isn't specific to lambdas, but to any local type:

#include 
int main()
{
  std::any a3, a4;

  {
struct local { } l;
a3 = l;
  }

  {
struct local { int i = 2; } l2;
a4 = l2;
  }

  __builtin_trap();
}

g++ -std=c++17 87308.cc && gdb -q -ex r -ex "p a3" -ex "p a4" -ex qq a.out
Reading symbols from a.out...done.
Starting program: /tmp/a.out 

Program received signal SIGILL, Illegal instruction.
main () at 87308.cc:16
16__builtin_trap();
$1 = std::any containing local = {[contained value] = {i = 0}}
$2 = std::any containing local = {[contained value] = {i = 2}}

[Bug c++/88166] Inconsistent placement of cv-quals and ptr-declarator in debuginfo

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
This isn't specific to lambdas, it happens for any local type:

struct Arg { char c; };

struct any
{
  template
struct Manager
{
  static void manage(const any*, Arg*) { }
};
};

struct global_type { };

int main()
{
  struct local_type { };
  auto f1 = &any::Manager::manage;
  auto f2 = &any::Manager::manage;
  return 0;
}

(gdb) p f1
$1 = (void (*)(const any *, Arg *)) 0x4004d1
::manage(any const*, Arg*)>
(gdb) p f2
$2 = (void (*)(const any *, Arg *)) 0x4004c2
::manage(const any *, Arg *)>

[Bug middle-end/85598] [7/8/9 Regression] Incorrect warning only at -O2 and -O3

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
So, evrp_range_analyzer.enter (bb); even calls record_ranges_from_phis, but
that does nothing here, as only one of the preds is BB_VISITED and the other is
not when this is called, so we end up with has_unvisited_preds and so
extract_range_from_phi_node isn't called.  Could we just drop the
has_unvisited_preds stuff and instead in extract_range_from_phi_node for the
edges from non-visited bbs solely use get_range_info?
Plus, we'd need for both the visited and unvisited add the range intersection
with the guarding condition of the edge if it uses the same SSA_NAME (or
perhaps later extend it to be as smart as tree-vrp.c assertion handling is, it
handles even some more complex cases).  Or is it that in evrp code we never
want to look at recorded SSA_NAME_RANGE_INFO?

And lastly, even if all this is done, I believe dom just computes ranges, but
doesn't every adjust (narrow) recorded SSA_NAME_RANGE_INFO if it computes
something more precise for some SSA_NAME.  Can it do that?

[Bug target/87288] [8 Regression] Segfault after const_cast with "-O2 -ftree-loop-vectorize" but _without_ "-mavx"

[jorrit at jorrit dot de]

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

--- Comment #12 from Jö  ---
Thanks a lot, I can confirm that this is fixed for us with the snapshot from
https://gcc.gnu.org/pub/gcc/snapshots/9-20181118/gcc-9-20181118.tar.xz.  Still,
a fix for 8 would be appreciated, as that would let us re-enable the test that
triggers the issue for that branch again.

[Bug target/87883] [ARM] ICE: Segmentation fault in arm_regno_class

[mihail.ionescu at arm dot com]

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

Mihail Ionescu  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Mihail Ionescu  ---
Hi Jozeph,

I will close it for now.
I had a look at your patch and even if the segfault is fixed, it won't work
unless arm_active_target.isa is initialised beforehand which does not seem to
be possible without making some major changes.

Best regards,
Mihail

[Bug middle-end/85598] [7/8/9 Regression] Incorrect warning only at -O2 and -O3

[rguenther at suse dot de]

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

--- Comment #17 from rguenther at suse dot de  ---
On Fri, 23 Nov 2018, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85598
> 
> --- Comment #16 from Jakub Jelinek  ---
> So, evrp_range_analyzer.enter (bb); even calls record_ranges_from_phis, but
> that does nothing here, as only one of the preds is BB_VISITED and the other 
> is
> not when this is called, so we end up with has_unvisited_preds and so
> extract_range_from_phi_node isn't called.  Could we just drop the
> has_unvisited_preds stuff and instead in extract_range_from_phi_node for the
> edges from non-visited bbs solely use get_range_info?

We could do that, yes.

> Plus, we'd need for both the visited and unvisited add the range intersection
> with the guarding condition of the edge if it uses the same SSA_NAME (or
> perhaps later extend it to be as smart as tree-vrp.c assertion handling is, it
> handles even some more complex cases).  Or is it that in evrp code we never
> want to look at recorded SSA_NAME_RANGE_INFO?

EVRP already factors this in.  Thus record_ranges_from_incoming_edge is
assumed to adjust the range info in the (temporary) lattice.

> And lastly, even if all this is done, I believe dom just computes ranges, but
> doesn't every adjust (narrow) recorded SSA_NAME_RANGE_INFO if it computes
> something more precise for some SSA_NAME.  Can it do that?

The EVRP analysis code does so.  But yes, if DOM simplifies sth
the range code isn't re-done.  IIRC I once tried switching
the two calls in

  edge taken_edge = NULL;
  for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
{
  evrp_range_analyzer.record_ranges_from_stmt (gsi_stmt (gsi), false);
  taken_edge = this->optimize_stmt (bb, gsi);
}

or I even did?

[Bug rtl-optimization/88168] New: -fno-jump-tables still generates jump table

[hjl.tools at gmail dot com]

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

Bug ID: 88168
   Summary: -fno-jump-tables still generates jump table
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

[hjl@gnu-cfl-1 microbenchmark]$ cat switch.c
int
foo (int i)
{
  int j;
  switch (i)
{
case 0:
  j = 3;
  break;
case 2:
  j = 9;
  break;
case 3:
  j = 23;
  break;
case 8:
  j = 43;
  break;
default:
  j = 31;
  break;
}
  return j;
}
[hjl@gnu-cfl-1 microbenchmark]$ /usr/gcc-8.1.1-x32/bin/gcc -S -O2 switch.c
-fno-jump-tables
[hjl@gnu-cfl-1 microbenchmark]$ cat switch.s
.file   "switch.c"
.text
.p2align 4,,15
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
movl$31, %eax
cmpl$8, %edi
ja  .L1
movl%edi, %edi
movlCSWTCH.0(,%rdi,4), %eax
.L1:
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo
.section.rodata
.align 32
.type   CSWTCH.0, @object
.size   CSWTCH.0, 36
CSWTCH.0:
.long   3
.long   31
.long   9
.long   23
.long   31
.long   31
.long   31
.long   31
.long   43
.ident  "GCC: (GNU) 8.1.1 20180521"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-1 microbenchmark]$

[Bug rtl-optimization/88168] -fno-jump-tables still generates jump table

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #1 from H.J. Lu  ---
This isn't a jump table.

[Bug middle-end/85598] [7/8/9 Regression] Incorrect warning only at -O2 and -O3

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  ---
record_ranges_from_incoming_edge does nothing here, pred_e =
single_pred_edge_ignoring_loop_edges (bb, false) is NULL.

[Bug rtl-optimization/46925] Can't optimize degenerate table jumps

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||8.2.0
 Resolution|--- |FIXED
   Target Milestone|--- |8.2

--- Comment #1 from H.J. Lu  ---
GCC 8.2 generates:

.file   "x.c"
.text
.p2align 4,,15
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
cmpl$4, %edi
ja  .L3
movq(%rsi), %rax
ret
.p2align 4,,10
.p2align 3
.L3:
xorl%eax, %eax
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo
.ident  "GCC: (GNU) 8.2.1 20181105 (Red Hat 8.2.1-5)"
.section.note.GNU-stack,"",@progbits

[Bug c++/88166] Inconsistent placement of cv-quals and ptr-declarator in debuginfo

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Richard Biener  ---
That's a consumer (gdb) issue.  Both are exactly the same dwarf DIE...

[Bug c++/88166] Inconsistent placement of cv-quals and ptr-declarator in debuginfo

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #4 from Jonathan Wakely  ---
Ah ok, thanks.

There seems to be yet another format, which includes the enum-key and class-key
for the types:

$15 = {_M_manager = 0x10006cd0
::_S_manage(enum std::any::_Op,
const std::any *, union std::any::_Arg *)>, _M_storage = {_M_ptr = 0x63,
_M_buffer = {__data = "c\000\000\000\000\000\000", __align = {

[Bug d/87788] Support D on x86_64-apple-darwin*

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|9.0 |---
Summary|[9 Regression] Bootstrap|Support D on
   |fails for   |x86_64-apple-darwin*
   |x86_64-apple-darwin* with   |
   |default languages selection |
   |after D addition.   |

--- Comment #17 from Jakub Jelinek  ---
Dropping the regression flag as from what I understand based on above comments
the bootstrap issue is resolved already.

[Bug rtl-optimization/87727] [9 regression] gcc.target/sparc/overflow-2.c FAILs

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
Note, the PR87718 changes don't help here.

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[gary_mills at fastmail dot fm]

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

--- Comment #19 from Gary Mills  ---
The reason that OI-SPARC uses the native assembler is the same as in Fiddler
on the Roof: tradition.  Actually, there are some kernel files written in SPARC
assembly language.  These only compile with the native assembler.  Hence, gcc
is
built to use the native assembler.

On OI-x86, the native assembler is not necessary and therefore not used.

It's entirely possible that the assembler is an old version.  OI does not have
source for the assembler, only the binary that came from Opensolaris.  The one
I use on my T2000 has this version string:

as: Sun Compiler Common 12 SunOS_sparc snv_121 08/03/2009

I'm in the midst of tracking down the origin of that null pointer that causes
the ICE.  With gdb, breakpoints seem not to work, but I can use it to analyze
core files.

[Bug target/86952] Avoid jump table for switch statement with -mindirect-branch=thunk

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
(In reply to Martin Liška from comment #4)
> (In reply to H.J. Lu from comment #3)
> > (In reply to Martin Liška from comment #2)
> > > H.J. I can write a patch for it. Do you expect more expensive costs when
> > > retpolines are enabled?
> > 
> > retpoline is more expensive than 4 branches.
> 
> Can you please make a microbenchmark that will expose how exactly is that
> expensive? Based on that I can tune current costs.

Is there a testcase where GCC generates a jump table for a five-entry
switch statement?

[Bug testsuite/87304] [9 regression] gcc.dg/vect/bb-slp-over-widen-1.c fails starting with r262371

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
The difference is:
bb-slp-over-widen-1.c:33:1: note:   Vectorizing an unaligned access.
in -mcpu=power8 or on e.g. x86_64 vs.
bb-slp-over-widen-1.c:33:1: missed:   not vectorized: unsupported unaligned
store: *a_116(D)
bb-slp-over-widen-1.c:33:1: missed:   not vectorized: bad data alignment in
basic block.
bb-slp-over-widen-1.c:33:1: note:  removing SLP instance operations starting
from: *a_116(D) = _7;
with -mcpu=power7 or earlier.  So, shall we:
--- gcc/testsuite/gcc.dg/vect/bb-slp-over-widen-1.c.jj  2018-11-23
15:42:50.345052674 +0100
+++ gcc/testsuite/gcc.dg/vect/bb-slp-over-widen-1.c 2018-11-23
15:53:41.438334280 +0100
@@ -64,4 +64,4 @@ main (void)
 /* { dg-final { scan-tree-dump "demoting int to signed short" "slp2" { target
{ ! vect_widen_shift } } } } */
 /* { dg-final { scan-tree-dump "demoting int to unsigned short" "slp2" {
target { ! vect_widen_shift } } } } */
 /* { dg-final { scan-tree-dump {\.AVG_FLOOR} "slp2" { target vect_avg_qi } } }
*/
-/* { dg-final { scan-tree-dump-times "basic block vectorized" 2 "slp2" } } */
+/* { dg-final { scan-tree-dump-times "basic block vectorized" 2 "slp2" {
target vect_hw_misalign } } } */