[Bug go/91035] [10 Regression] gotools fails to build on s390x-linux-gnu

[ian at airs dot com]

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

--- Comment #5 from Ian Lance Taylor  ---
It's hard to see how this could be a bug in the Go frontend.  At first glance
this looks like a problem with the split-stack support on S/390.

[Bug ipa/91468] New: Suspicious codes in ipa-prop.c and ipa-cp.c

[fxue at os dot amperecomputing.com]

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

Bug ID: 91468
   Summary: Suspicious codes in ipa-prop.c and ipa-cp.c
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxue at os dot amperecomputing.com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Some might be a bug, and some might be redundant.

ipa-prop.c:

In function ipcp_modif_dom_walker::before_dom_children(),

  vce = false;
  t = rhs;
  while (handled_component_p (t))
{
  /* V_C_E can do things like convert an array of integers to one
 bigger integer and similar things we do not handle below.  */
  if (TREE_CODE (rhs) == VIEW_CONVERT_EXPR)
{
  vce = true;
  break;
}
  t = TREE_OPERAND (t, 0);
}
  if (vce)
continue;

Should "rhs" in "if (TREE_CODE (rhs) == VIEW_CONVERT_EXPR)" be "t"?


In function update_jump_functions_after_inlining(),

  if (dst->type == IPA_JF_ANCESTOR)
{
  ..

  if (src->type == IPA_JF_PASS_THROUGH
  && src->value.pass_through.operation == NOP_EXPR)
{
   ..
}
  else if (src->type == IPA_JF_PASS_THROUGH
   && TREE_CODE_CLASS (src->value.pass_through.operation) ==
tcc_unary)
{
  dst->value.ancestor.formal_id =
src->value.pass_through.formal_id;
  dst->value.ancestor.agg_preserved = false;
}
  ..   
}

If we suppose pass_through operation is "negate_expr" (while it is not a
reasonable operation on pointer type), the code might be incorrect. It's better
to specify expected unary operations here.


In function compute_complex_assign_jump_func(),

case GIMPLE_UNARY_RHS:
  if (is_gimple_assign (stmt)
  && gimple_assign_rhs_class (stmt) == GIMPLE_UNARY_RHS
  && ! CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (stmt)))
ipa_set_jf_unary_pass_through (jfunc, index,
   gimple_assign_rhs_code (stmt));

The condition "is_gimple_assign (stmt)
  && gimple_assign_rhs_class (stmt) == GIMPLE_UNARY_RHS" seems to
be redundant, might be omit.


ipa-cp.c:

In function merge_agg_lats_step(), 

  if (**aglat && (**aglat)->offset == offset)
{
  if ((**aglat)->size != val_size
  || ((**aglat)->next 
  && (**aglat)->next->offset < offset + val_size))
{
  set_agg_lats_to_bottom (dest_plats);
  return false;
}
  gcc_checking_assert (!(**aglat)->next
   || (**aglat)->next->offset >= offset + val_size);
  return true;
}

The condition "|| ((**aglat)->next && (**aglat)->next->offset < offset +
val_size))" seems to be always false, because the next item should not be
overlapped with its prev, this is what merge_agg_lats_step() tries to ensure.

[Bug ipa/91089] IPA-cp does not setup proper cost model for switch default case in function versioning

[fxue at os dot amperecomputing.com]

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

--- Comment #2 from Feng Xue  ---
I've already created a patch under review. Please give some comments. Here it
is: https://gcc.gnu.org/ml/gcc-patches/2019-07/msg00937.html

[Bug ipa/91088] IPA-cp cost evaluation is too conservative for "if (f(param) cmp const_val)" condition

[fxue at os dot amperecomputing.com]

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

--- Comment #3 from Feng Xue  ---
I've already created a patch under review. Please give some comments. Here it
is: https://gcc.gnu.org/ml/gcc-patches/2019-07/msg00959.html

[Bug rtl-optimization/91347] [7/8/9/10 Regression] pointer_string in linux vsprintf.c is miscompiled when sibling calls are optimized

[dave.anglin at bell dot net]

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

--- Comment #4 from dave.anglin at bell dot net ---
If DSE bug can't be fixed, the attached patch appears to work around the issue
by disabling
tail calls on pa when an argument is passed on stack.

[Bug c++/89179] compiler error: in ggc_set_mark, at ggc-page.c:1532

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #15 from Marek Polacek  ---
Those 0xa5 come from poison_pages in ggc-page.c, this call in particular:
 memset (object, 0xa5, size);

[Bug c++/91467] New: [concepts] ICE: in tsubst_copy, at cp/pt.c:15545

[frederik.engels24 at gmail dot com]

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

Bug ID: 91467
   Summary: [concepts] ICE: in tsubst_copy, at cp/pt.c:15545
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frederik.engels24 at gmail dot com
  Target Milestone: ---

Run with "g++ (Compiler-Explorer-Build) 10.0.0 20190814 (experimental)"
and options "-std=c++2a -fconcepts"

source code: https://godbolt.org/z/tOIbPZ
~~~
template
struct foo {
T t;

template
void set(U&& u) requires requires { { static_cast(u)} -> T; }
{
t = static_cast(u);
}
};

int main()
{
auto w = foo{5};
w.set(5.0f);
}
~~
resulting in
~~
: In function 'int main()':

:15:15: internal compiler error: in tsubst_copy, at cp/pt.c:15545

   15 | w.set(5.0f);

  |   ^

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

Compiler returned: 1
~

[Bug c++/89179] compiler error: in ggc_set_mark, at ggc-page.c:1532

[sje at gcc dot gnu.org]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at gcc dot gnu.org

--- Comment #14 from Steve Ellcey  ---
I think I may be seeing this same bug on aarch64 when building the RAJA library
based on where I am dying in ggc_set_mark.  I have not been able to create a
preprocessed test case because when I compile the preprocessed sources the bug
does not happen.  Here is my segfault dump:

min.cpp:191:1: internal compiler error: Segmentation fault
  191 | } 
  | ^ 
0xf03b5f crash_signal
../../gcc/gcc/toplev.c:326
0x9cc86c lookup_page_table_entry
../../gcc/gcc/ggc-page.c:632
0x9cc86c ggc_set_mark(void const*)
../../gcc/gcc/ggc-page.c:1531
0xc6fe47 gt_ggc_mx_symtab_node(void*)
/home/sellcey/gcc-raja/obj-gcc/gcc/gtype-desc.c:1302
0xe17503 gt_ggc_ma_order
./gt-passes.h:31
0xbe44f3 ggc_mark_root_tab
../../gcc/gcc/ggc-common.c:77
0xbe4813 ggc_mark_roots()
../../gcc/gcc/ggc-common.c:94
0x9cd1fb ggc_collect()
../../gcc/gcc/ggc-page.c:2201
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

When I look at gt_ggc_mx_symtab_node, the initial x_p pointer
that comes in is reasonable (0xa020c210) but after

xlimit = ((*xlimit).next);

The value of xlimit becomes 0xa5a5a5a5a5a5a5a5.  That looks
like a bogus value something might have put into memory
to poison it but I didn't see that specific string in
the GCC source tree anywhere.

[Bug c++/91466] New: [concepts] indicates "used in its own initializer" when not, constraint order change passes compilation.

[frederik.engels24 at gmail dot com]

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

Bug ID: 91466
   Summary: [concepts] indicates "used in its own initializer"
when not, constraint order change passes compilation.
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frederik.engels24 at gmail dot com
  Target Milestone: ---

Run using "g++ (Compiler-Explorer-Build) 10.0.0 20190814 (experimental)" with
options "-std=c++2a -fconcepts"
and source code: https://godbolt.org/z/aGw2d0

~`
#include 
#include 

template
concept integral_constant_ = std::is_empty_v && std::is_trivial_v &&
requires
{
typename T::value_type;
requires std::is_integral_v;
{ T::value } -> typename T::value_type;
};

struct sz_fn
{
template requires requires(R&& r) { {static_cast(r).size()} ->
integral_constant_; }
constexpr auto operator()(R&& r) {
return static_cast(r).size();
}
};

constexpr auto sz = sz_fn{};


int main()
{
auto arr = std::array{1, 2, 3, 4, 5};

return !std::is_invocable_v;
}
~~~

results in:
~~~~
In file included from :1:

/opt/compiler-explorer/gcc-trunk-20190815/include/c++/10.0.0/type_traits: In
substitution of 'template static
std::__result_of_success()((declval<_Args>)()...)),
std::__invoke_other> std::__result_of_other_impl::_S_test(int) [with _Fn =
const sz_fn; _Args = {std::array}]':

/opt/compiler-explorer/gcc-trunk-20190815/include/c++/10.0.0/type_traits:2563:55:
  required from 'struct std::__result_of_impl >'

/opt/compiler-explorer/gcc-trunk-20190815/include/c++/10.0.0/type_traits:2976:12:
  recursively required by substitution of 'template
struct std::__is_invocable_impl<_Result, _Ret, std::__void_t > [with _Result = std::__invoke_result >; _Ret = void]'

/opt/compiler-explorer/gcc-trunk-20190815/include/c++/10.0.0/type_traits:2976:12:
  required from 'struct std::is_invocable >'

/opt/compiler-explorer/gcc-trunk-20190815/include/c++/10.0.0/type_traits:3021:27:
  required from 'constexpr const bool std::is_invocable_v >'

:28:18:   required from here

/opt/compiler-explorer/gcc-trunk-20190815/include/c++/10.0.0/type_traits:2552:26:
error: the value of 'std::is_empty_v' is not usable in a
constant expression

 2552 |   std::declval<_Fn>()(std::declval<_Args>()...)

  |   ~~~^~

/opt/compiler-explorer/gcc-trunk-20190815/include/c++/10.0.0/type_traits:3103:25:
note: 'std::is_empty_v' used in its own initializer

 3103 |   inline constexpr bool is_empty_v = is_empty<_Tp>::value;

  | ^~

/opt/compiler-explorer/gcc-trunk-20190815/include/c++/10.0.0/type_traits:2552:26:
error: the value of 'std::is_trivial_v' is not usable in a
constant expression

 2552 |   std::declval<_Fn>()(std::declval<_Args>()...)

  |   ~~~^~

/opt/compiler-explorer/gcc-trunk-20190815/include/c++/10.0.0/type_traits:3092:25:
note: 'std::is_trivial_v' used in its own initializer

 3092 |   inline constexpr bool is_trivial_v = is_trivial<_Tp>::value;

  | ^~~~

Compiler returned: 1


Changing

template
concept integral_constant_ = std::is_empty_v && std::is_trivial_v &&
requires
{
typename T::value_type;
requires std::is_integral_v;
{ T::value } -> typename T::value_type;
};
~`
to
~
template
concept integral_constant_ =
requires
{
typename T::value_type;
requires std::is_integral_v;
{ T::value } -> typename T::value_type;
} && std::is_empty_v && std::is_trivial_v;
~~~

Allows the program to compile successfully.

[Bug c++/91465] [9/10 Regression] unexpected expression of kind overload (ICE)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Keywords||ice-on-valid-code
   Last reconfirmed||2019-08-15
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1
Summary|unexpected expression of|[9/10 Regression]
   |kind overload  (ICE)|unexpected expression of
   ||kind overload  (ICE)
   Target Milestone|--- |9.3

--- Comment #1 from Marek Polacek  ---
Started with r268321 thus mine.

[Bug c++/91465] New: unexpected expression of kind overload (ICE)

[cuzdav at gmail dot com]

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

Bug ID: 91465
   Summary: unexpected expression of kind overload  (ICE)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cuzdav at gmail dot com
  Target Milestone: ---

This code results in an ICE:

In member function 'Destination Bar::baz(Source)':

internal compiler error: unexpected expression 'foo' of kind overload
  return Destination{foo(aLowValue)};
^

// See it LIVE!  https://godbolt.org/z/42c_Ll
enum class Destination  {};
enum class Source  {};

Destination foo(Source value) { return Destination{}; }
Destination foo(double value) { return Destination{}; }

template 
struct Bar {
Destination baz(Source aLowValue) {
return Destination{foo(aLowValue)}; //  HERE
}
};


Bug appears in 9.1 in c++17 (and up) in all higher g++ versions as well.  OK if
c++14 or lower, and OK if older g++.

[Bug fortran/91443] -Wargument-mismatch does not catch mismatch for global procedure

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
Author: tkoenig
Date: Thu Aug 15 22:52:40 2019
New Revision: 274551

URL: https://gcc.gnu.org/viewcvs?rev=274551=gcc=rev
Log:
2019-08-15  Thomas Koenig  

PR fortran/91443
* frontend-passes.c (check_externals_expr): New function.
(check_externals_code): New function.
(gfc_check_externals): New function.
* gfortran.h (debug): Add prototypes for gfc_symbol * and
gfc_expr *.
(gfc_check_externals): Add prototype.
* interface.c (compare_actual_formal): Do not complain about
alternate returns if the formal argument is optional.
(gfc_procedure_use): Handle cases when an error has been issued
previously.  Break long line.
* parse.c (gfc_parse_file): Call gfc_check_externals for all
external procedures.
* resolve.c (resolve_global_procedure): Remove checking of
argument list.

2019-08-15  Thomas Koenig  

PR fortran/91443
* gfortran.dg/argument_checking_19.f90: New test.
* gfortran.dg/altreturn_10.f90: Change dg-warning to dg-error.
* gfortran.dg/dec_union_11.f90: Add -std=legacy.
* gfortran.dg/hollerith8.f90: Likewise. Remove warning for
Hollerith constant.
* gfortran.dg/integer_exponentiation_2.f90: New subroutine gee_i8;
use it to avoid type mismatches.
* gfortran.dg/pr41011.f: Add -std=legacy.
* gfortran.dg/whole_file_1.f90: Change warnings to errors.
* gfortran.dg/whole_file_2.f90: Likewise.


Added:
trunk/gcc/testsuite/gfortran.dg/argument_checking_19.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/altreturn_10.f90
trunk/gcc/testsuite/gfortran.dg/dec_union_11.f90
trunk/gcc/testsuite/gfortran.dg/hollerith8.f90
trunk/gcc/testsuite/gfortran.dg/integer_exponentiation_2.f90
trunk/gcc/testsuite/gfortran.dg/pr41011.f
trunk/gcc/testsuite/gfortran.dg/whole_file_1.f90
trunk/gcc/testsuite/gfortran.dg/whole_file_2.f90

[Bug c++/91464] C++ extern "C" namespace A {int value;}; is definition not declaration

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-15
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
The "2nd scenario" is:

extern "C" namespace A
{
int value;
}

int getValue ()
{
return A::value;
}

G++ only declares A::value, it doesn't define it.

[Bug c++/64372] [DR1560] Gratuitous lvalue-to-rvalue conversion in conditional-expression with throw-expression operand

[jason at gcc dot gnu.org]

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

--- Comment #14 from Jason Merrill  ---
Author: jason
Date: Thu Aug 15 21:55:19 2019
New Revision: 274550

URL: https://gcc.gnu.org/viewcvs?rev=274550=gcc=rev
Log:
PR c++/90393 - ICE with thow in ?:

My previous patch for 64372 was incomplete: it only stopped making the
non-throw argument into an rvalue, lvalue_kind still considered the ?:
expression to be an rvalue, leaving us worse than before.

PR c++/64372, DR 1560 - Gratuitous lvalue-to-rvalue conversion in ?:
* tree.c (lvalue_kind): Handle throw in one arm.
* typeck.c (rationalize_conditional_expr): Likewise.
(cp_build_modify_expr): Likewise.

Added:
trunk/gcc/testsuite/g++.dg/expr/cond15.C
trunk/gcc/testsuite/g++.dg/expr/cond16.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/g++.dg/abi/mangle53.C
trunk/gcc/testsuite/g++.old-deja/g++.eh/cond1.C
trunk/gcc/testsuite/g++.old-deja/g++.other/cond5.C

[Bug c++/90393] [9/10 Regression] ICE in return statement with a conditional operator, one of the second and third arguments is throw, and the other is a const variable of a class with a nontrivial co

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill  ---
Author: jason
Date: Thu Aug 15 21:55:19 2019
New Revision: 274550

URL: https://gcc.gnu.org/viewcvs?rev=274550=gcc=rev
Log:
PR c++/90393 - ICE with thow in ?:

My previous patch for 64372 was incomplete: it only stopped making the
non-throw argument into an rvalue, lvalue_kind still considered the ?:
expression to be an rvalue, leaving us worse than before.

PR c++/64372, DR 1560 - Gratuitous lvalue-to-rvalue conversion in ?:
* tree.c (lvalue_kind): Handle throw in one arm.
* typeck.c (rationalize_conditional_expr): Likewise.
(cp_build_modify_expr): Likewise.

Added:
trunk/gcc/testsuite/g++.dg/expr/cond15.C
trunk/gcc/testsuite/g++.dg/expr/cond16.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/g++.dg/abi/mangle53.C
trunk/gcc/testsuite/g++.old-deja/g++.eh/cond1.C
trunk/gcc/testsuite/g++.old-deja/g++.other/cond5.C

[Bug c++/91464] New: C++ extern "C" namespace A {int value;}; is definition not declaration

[dje at gcc dot gnu.org]

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

Bug ID: 91464
   Summary: C++ extern "C" namespace A {int value;}; is definition
not declaration
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jason at gcc dot gnu.org
  Target Milestone: ---

From Twitter

extern "C" namespace A
{
int value;
}

int getValue ()
{
return A::value;
}

Clang compiles correctly this first scenario:
https://godbolt.org/z/FjUGov

while GCC doesn't compile:
https://godbolt.org/z/Ohfsgi

Clang compiles correctly this 2nd scenario:
https://godbolt.org/z/LhzeOo

while GCC compiles it wrongly:
https://godbolt.org/z/Nsiy5_

[Bug middle-end/91463] missing -Warray-bounds accessing past the end of a statically initialized flexible array member

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Blocks||56456

--- Comment #1 from Martin Sebor  ---
This bug was never detected by GCC or other compilers (Clang or ICC).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds

[Bug middle-end/91463] New: missing -Warray-bounds accessing past the end of a statically initialized flexible array member

[msebor at gcc dot gnu.org]

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

Bug ID: 91463
   Summary: missing -Warray-bounds accessing past the end of a
statically initialized flexible array member
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The past the end write to the flexible array member in f() is not diagnosed. 
DECL_SIZE of the array is null but for variables with a non-empty DECL_INITIAL
the size can be determined from the CONSTRUCTOR, so it should be possible to
detect the out-of-bounds index that way.

$ cat x.c && gcc -O2 -S -Wall -fdump-tree-vrp=/dev/stdout x.c
struct S { int n, a[]; };

struct S s = { 2, { 1, 0 } };

void f (void)
{
  s.a[666] = 0;   // missing -Warray-bounds
}

;; Function f (f, funcdef_no=0, decl_uid=1912, cgraph_uid=1, symbol_order=1)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }

Value ranges after VRP:



f ()
{
   [local count: 1073741824]:
  s.a[666] = 0;
  return;

}



;; Function f (f, funcdef_no=0, decl_uid=1912, cgraph_uid=1, symbol_order=1)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }

Value ranges after VRP:



f ()
{
   [local count: 1073741824]:
  s.a[666] = 0;
  return;

}

[Bug fortran/82992] ICE in create_int_parameter_array, at fortran/module.c:6586

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

--- Comment #6 from kargl at gcc dot gnu.org ---
Patch submitted.

[Bug middle-end/91462] [8/9/10 Regression] missing -Warray-bounds writing to an empty flexible array member in a ctor

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Blocks||56456
Summary|missing -Warray-bounds  |[8/9/10 Regression] missing
   |writing to an empty |-Warray-bounds writing to
   |flexible array member in a  |an empty flexible array
   |ctor|member in a ctor

--- Comment #1 from Martin Sebor  ---
GCC 5 diagnoses both: https://gcc.godbolt.org/z/dW2U6d.  Neither Clang nor GCC
diagnoses either.

The regression was introduced in r158058 committed to fix PR
tree-optimization/43270.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds

[Bug middle-end/91462] New: missing -Warray-bounds writing to an empty flexible array member in a ctor

[msebor at gcc dot gnu.org]

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

Bug ID: 91462
   Summary: missing -Warray-bounds writing to an empty flexible
array member in a ctor
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In the test case below, the write to the empty flexible array member in Ax
isn't diagnosed even though the equivalent write in A0 is.

$ cat t.C && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout t.C
struct A0
{
  char n, a[0];

  A0 () { a[0] = 0; }   // -Warray-bounds (good)
};

void f (void*);

void g ()
{
  struct A0 a;
  f ();
}

struct Ax
{ 
  char n, a[];

  Ax () { a[0] = 0; }   // missing -Warray-bounds
};

void h ()
{
  struct Ax a;
  f ();
}

t.C: In function ‘void g()’:
t.C:5:14: warning: array subscript 0 is above array bounds of ‘char [0]’
[-Warray-bounds]
5 |   A0 () { a[0] = 0; }
  |   ~~~^

;; Function g (_Z1gv, funcdef_no=3, decl_uid=2317, cgraph_uid=4,
symbol_order=3)

g ()
{
  struct A0 a;

   [local count: 1073741824]:
  a ={v} {CLOBBER};
  a.a[0] = 0;
  f ();
  a ={v} {CLOBBER};
  return;

}



;; Function h (_Z1hv, funcdef_no=7, decl_uid=2362, cgraph_uid=8,
symbol_order=7)

h ()
{
  struct Ax a;

   [local count: 1073741824]:
  a ={v} {CLOBBER};
  a.a[0] = 0;
  f ();
  a ={v} {CLOBBER};
  return;

}

[Bug rtl-optimization/91460] gcc -mpreferred-vector-width=256 is slower than -mpreferred-vector-width=128 for some loops

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Target||i386
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-15
 Ever confirmed|0   |1

--- Comment #2 from H.J. Lu  ---
When loop trip count is known, vectorizer won't select 256-bit vector when
266-bit vector can't be used.  When loop trip count is unknown, 256-bit
vector can be slower than 128-bit vector, depending on workloads.  In
case of SPEC CPU 2017, 128-bit vector is much faster than 256-bit vector
for a couple benchmarks.  For most of benchmarks, there are no performance
differences between  128-bit vector and 256-bit vector.

[Bug rtl-optimization/91460] gcc -mpreferred-vector-width=256 is slower than -mpreferred-vector-width=128 for some loops

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #1 from H.J. Lu  ---
This testcase

---
int block[9][9][9];
void foo(int row, int k, int h)
{
  /* Variable nrow range from 4 to 9.  */
  int nrow = ((row - 1)/3 + 1)*3 + 1;

   for (int i = nrow; i < 9; i++)
 block[k][h][i] = block[k][h][i] - 10;
}
---

Since nrow range from 4 to 9, 256bit vector operation will never be
executed(vector elements always less than 8), so 256bit vector actually
equals no vectorization plus additional branch cost.  Even with epilogue
vectorization, 256bit vector still has more overhead.  When this is a hot
function, 256bit vector can reduce performance by 6%.

[Bug target/91461] New: Don't turn on X86_TUNE_SSE_TYPELESS_STORES for AVX/AVX512

[hjl.tools at gmail dot com]

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

Bug ID: 91461
   Summary: Don't turn on X86_TUNE_SSE_TYPELESS_STORES for
AVX/AVX512
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com, skpgkp2 at gmail dot com
  Target Milestone: ---
Target: i386

We have

X86_TUNE_SSE_TYPELESS_STORES: Always movaps/movups for 128bit stores

since movaps/movups one byte shorter than movdaq/movdqu.  But it isn't
the case for AVX/AVX512.  There is no need to do it for AVX/AVX512.

[Bug c++/87519] -Wsign-conversion -Wconversion explicit cast fails to silence warning

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #14 from Marek Polacek  ---
Fixed in 9.3+.

[Bug c++/90473] gcc does not call function in comma operator for default argument

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #8 from Marek Polacek  ---
Fixed in 9.3 too.

[Bug c++/81429] maybe_unused attribute triggers syntax error when used on first argument to a constructor

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #12 from Marek Polacek  ---
Fixed for 9.3+.

[Bug c++/90884] Option `-Wctor-dtor-privacy' enables warning even for system headers

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
Author: mpolacek
Date: Thu Aug 15 18:35:07 2019
New Revision: 274547

URL: https://gcc.gnu.org/viewcvs?rev=274547=gcc=rev
Log:
PR c++/90884 - stray note with -Wctor-dtor-privacy.
* class.c (maybe_warn_about_overly_private_class): Guard the call to
inform.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/warn/ctor-dtor-privacy-4.C
branches/gcc-9-branch/gcc/testsuite/g++.dg/warn/ctor-dtor-privacy-4.h
Modified:
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/class.c

[Bug c++/90473] gcc does not call function in comma operator for default argument

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
Author: mpolacek
Date: Thu Aug 15 18:33:43 2019
New Revision: 274546

URL: https://gcc.gnu.org/viewcvs?rev=274546=gcc=rev
Log:
PR c++/90473 - wrong code with nullptr in default argument.
* call.c (null_ptr_cst_p): Update quote from the standard.
* decl.c (check_default_argument): Don't return nullptr when the arg
has side-effects.

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

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp0x/nullptr42.C
Modified:
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/call.c
branches/gcc-9-branch/gcc/cp/decl.c

[Bug c++/87519] -Wsign-conversion -Wconversion explicit cast fails to silence warning

[mpolacek at gcc dot gnu.org]

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

--- Comment #13 from Marek Polacek  ---
Author: mpolacek
Date: Thu Aug 15 18:32:33 2019
New Revision: 274545

URL: https://gcc.gnu.org/viewcvs?rev=274545=gcc=rev
Log:
PR c++/87519 - bogus warning with -Wsign-conversion.
* typeck.c (cp_build_binary_op): Use same_type_p instead of comparing
the types directly.

* g++.dg/warn/Wsign-conversion-5.C: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/warn/Wsign-conversion-5.C
Modified:
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/typeck.c

[Bug c++/81429] maybe_unused attribute triggers syntax error when used on first argument to a constructor

[mpolacek at gcc dot gnu.org]

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

--- Comment #11 from Marek Polacek  ---
Author: mpolacek
Date: Thu Aug 15 18:31:16 2019
New Revision: 274544

URL: https://gcc.gnu.org/viewcvs?rev=274544=gcc=rev
Log:
PR c++/81429 - wrong parsing of constructor with C++11 attribute.
* parser.c (cp_parser_constructor_declarator_p): Handle the scenario
when a parameter declaration begins with [[attribute]].

* g++.dg/cpp0x/gen-attrs-68.C: New test.
* g++.dg/cpp0x/gen-attrs-69.C: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp0x/gen-attrs-68.C
branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp0x/gen-attrs-69.C
Modified:
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/parser.c

[Bug target/90878] [8/9/10 Regression] integer -> SSE register move isn't generated

[hjl at gcc dot gnu.org]

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

--- Comment #7 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Thu Aug 15 18:15:33 2019
New Revision: 274543

URL: https://gcc.gnu.org/viewcvs?rev=274543=gcc=rev
Log:
i386: Separate costs of pseudo registers from hard registers

processor_costs has costs of RTL expressions with pseudo registers and
and costs of hard register moves:

1. Costs of RTL expressions are used to generate the most efficient RTL
operations with pseudo registers.

2. Costs of hard register moves are used by register allocator to
decide how to allocate and move hard registers.

Since relative costs of pseudo register load and store versus pseudo
register moves in RTL expressions can be different from relative costs
of hard registers, we should separate costs of RTL expressions with
pseudo registers from costs of hard registers so that register allocator
and RTL expressions can be improved independently.

This patch moves costs of hard register moves to the new hard_register
field and duplicates costs of moves which are also used for costs of RTL
expressions.

PR target/90878
* config/i386/i386.c (inline_memory_move_cost): Use hard_register
for costs of hard register moves.
(ix86_register_move_cost): Likewise.
* config/i386/i386.h (processor_costs): Move costs of hard
register moves to hard_register.  Add int_load, int_store,
xmm_move, ymm_move, zmm_move, sse_to_integer, integer_to_sse,
sse_load, sse_store, sse_unaligned_load and sse_unaligned_store
for costs of RTL expressions.
* config/i386/x86-tune-costs.h: Move costs of hard register
moves to hard_register.  Duplicate int_load, int_store,
xmm_move, ymm_move, zmm_move, sse_to_integer, integer_to_sse,
sse_load, sse_store for costs of RTL expressions.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.h
trunk/gcc/config/i386/x86-tune-costs.h

[Bug rtl-optimization/91460] New: gcc -mpreferred-vector-width=256 is slower than -mpreferred-vector-width=128 for some loops

[skpgkp2 at gmail dot com]

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

Bug ID: 91460
   Summary: gcc -mpreferred-vector-width=256 is slower than
-mpreferred-vector-width=128 for some loops
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skpgkp2 at gmail dot com
CC: hjl.tools at gmail dot com
  Target Milestone: ---

1 static inline void pixel_avg( uint8_t *dst,  int i_dst_stride,
2  uint8_t *src1, int i_src1_stride,
3  uint8_t *src2, int i_src2_stride,
4   int i_width, int i_height )
5 {
6 for( int y = 0; y < i_height; y++ )
7 {
8 for( int x = 0; x < i_width; x++ )
9 dst[x] = ( src1[x] + src2[x] + 1 ) >> 1;
10 dst  += i_dst_stride;
11 src1 += i_src1_stride;
12 src2 += i_src2_stride;
13 }
14 }

If above code is in hot loop.

if i_width value is between 16 and 32, -mprefer-vector-width=128 can provide
~6% performance improvement as compared to -mprefer-vector-width=256.

i_width value must be at least 16 to trigger 128 bit vectorization at line 8.

i_width value must be at least 32 to trigger 256 bit vectorization at line 8.

[Bug libstdc++/91456] std::function and std::is_invocable_r do not understand guaranteed elision

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Thu Aug 15 16:07:27 2019
New Revision: 274542

URL: https://gcc.gnu.org/viewcvs?rev=274542=gcc=rev
Log:
PR libstdc++/91456 make INVOKE work with uncopyable prvalues

In C++17 a function can return a prvalue of a type that cannot be moved
or copied. The current implementation of std::is_invocable_r uses
std::is_convertible to test the conversion to R required by INVOKE.
That fails for non-copyable prvalues, because std::is_convertible is
defined in terms of std::declval which uses std::add_rvalue_reference.
In C++17 conversion from R to R involves no copies and so is not the
same as conversion from R&& to R.

This commit changes std::is_invocable_r to check the conversion without
using std::is_convertible.

std::function also contains a similar check using std::is_convertible,
which can be fixed by simply reusing std::is_invocable_r (but because
std::is_invocable_r is not defined for C++11 it uses the underlying
std::__is_invocable_impl trait directly).

PR libstdc++/91456
* include/bits/std_function.h (__check_func_return_type): Remove.
(function::_Callable): Use std::__is_invocable_impl instead of
__check_func_return_type.
* include/std/type_traits (__is_invocable_impl): Add another defaulted
template parameter. Define a separate partial specialization for
INVOKE and INVOKE. For INVOKE replace is_convertible check
with a check that models delayed temporary materialization.
* testsuite/20_util/function/91456.cc: New test.
* testsuite/20_util/is_invocable/91456.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/20_util/function/91456.cc
trunk/libstdc++-v3/testsuite/20_util/is_invocable/91456.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/std_function.h
trunk/libstdc++-v3/include/std/type_traits

[Bug lto/91307] -flto causes binary to vary

[hubicka at gcc dot gnu.org]

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

--- Comment #9 from Jan Hubicka  ---
I am not 100% sure if hashing calle names works safely, since they will all be
something like "static construction" or so, so I guess one can construct two
different translation units that will end up with same hash. But perhaps we
could teach LTO FE to produce those names purely on symbols exported from the
LTO unit since those should be unique and use it everywhere (including the
lto_priv numbers)?
Of course unless we go the route of getting API to the plugin interface to
obtain full symbol name.

[Bug middle-end/91459] Tail-Call Optimization is not performed when return value is assumed.

[mike.k at digitalcarbide dot com]

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

--- Comment #1 from mike.k at digitalcarbide dot com ---
'foo3' in the assembly output should be 'foo2'. I'd changed the function name
in my test code and did not update the assembly. Apologies.

[Bug go/91035] [10 Regression] gotools fails to build on s390x-linux-gnu

[doko at debian dot org]

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

--- Comment #4 from Matthias Klose  ---
looks like .L34 should be referenced instead of of .L37.

[Bug middle-end/91459] New: Tail-Call Optimization is not performed when return value is assumed.

[mike.k at digitalcarbide dot com]

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

Bug ID: 91459
   Summary: Tail-Call Optimization is not performed when return
value is assumed.
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mike.k at digitalcarbide dot com
  Target Milestone: ---

In situations where a function either returns a specific value or does not
return at all, GCC fails to perform tail call optimizations. This appears to
occur on all GCC versions with -O1, -O2, -O3, and -Os. It occurs with both the
C and C++ front-ends.

Observe:

/* This function is guaranteed to only return the value '1', else it does not
return.
// This is meant to emulate a function such as 'exec'.
*/
extern int function_returns_only_1_or_doesnt_return(int, int);

int foo1(int a, int b) {
const int result = function_returns_only_1_or_doesnt_return(a, b);
if (result == 1) {
return result;
}
else {
__builtin_unreachable();
}
}

int foo2(int a, int b) {
return function_returns_only_1_or_doesnt_return(a, b);
}


This results in the following output for -O3 on x86-64:

foo1(int, int):
  push rax
  call function_returns_only_1_or_doesnt_return(int, int)
  mov eax, 1
  pop rdx
  ret
foo3(int, int):
  jmp function_returns_only_1_or_doesnt_return(int, int)

While the behavior is correct, the tail-call optimization is far more optimal
and preserves the same semantics.

The same behavior occurs with other architectures as well, so it does not
appear to be a back-end issue.

[Bug tree-optimization/91457] FAIL: g++.dg/warn/Warray-bounds-4.C -std=gnu++98 (test for warnings, line 25)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-15
 CC||msebor at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Confirmed.  Here's a slightly simplified/modified test case showing the
difference in output between an x86_64 native GCC and an hppa2.0w-hp-hpux11.11
cross.  Here too compute_objsize fails because it doesn't handle the ARRAY_REF
argument in the assignment a.a[0] = 0.

$ (set -x && cat t.C && gcc -O2 -S -Wall -fdump-tree-dom3=/dev/stdout t.C &&
/build/hppa2.0w-hp-hpux11.11/gcc-svn/gcc/xgcc -B
/build/hppa2.0w-hp-hpux11.11/gcc-svn/gcc -O2 -S -Wall
-fdump-tree-dom3=/dev/stdout t.C)
+ cat t.C
struct A
{
  char n, a[0];

  A () { a[0] = 0; }
};

void f (struct A*);

void g (void)
{
  struct A a;
  f ();
}
+ /build/gcc-svn/gcc/xgcc -B /build/gcc-svn/gcc -O2 -S -Wall
-fdump-tree-dom3=/dev/stdout t.C
t.C: In function ‘void g()’:
t.C:5:13: warning: array subscript 0 is above array bounds of ‘char [0]’
[-Warray-bounds]
5 |   A () { a[0] = 0; }
  |  ~~~^

;; Function g (_Z1gv, funcdef_no=3, decl_uid=2317, cgraph_uid=4,
symbol_order=3)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }
g ()
{
  struct A a;

   [local count: 1073741824]:
  a ={v} {CLOBBER};
  a.a[0] = 0;
  f ();
  a ={v} {CLOBBER};
  return;

}


+ /build/hppa2.0w-hp-hpux11.11/gcc-svn/gcc/xgcc -B
/build/hppa2.0w-hp-hpux11.11/gcc-svn/gcc -O2 -S -Wall
-fdump-tree-dom3=/dev/stdout t.C

;; Function g (_Z1gv, funcdef_no=3, decl_uid=1911, cgraph_uid=4,
symbol_order=3)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }
g ()
{
  struct A a;

   [local count: 1073741824]:
  MEM[(char *) + 1B] = 0;
  f ();
  a ={v} {CLOBBER};
  return;

}


In constructor ‘A::A()’,
inlined from ‘void g()’ at t.C:12:12:
t.C:5:15: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
5 |   A () { a[0] = 0; }
  |  ~^~~

[Bug tree-optimization/91457] FAIL: g++.dg/warn/Warray-bounds-4.C -std=gnu++98 (test for warnings, line 25)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from Martin Sebor  ---
Let me enhance the function.

[Bug c++/90884] Option `-Wctor-dtor-privacy' enables warning even for system headers

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
(In reply to Jonathan Wakely from comment #5)
> Marek, should this be backported to release branches too?

Ha, I'm just about to backport a few patches to 9.3, so I'll include this one
too.

[Bug c++/71484] Class with implicit public constructor triggers `-Wctor-dtor-privacy`

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-15
 Ever confirmed|0   |1
   Severity|minor   |normal

--- Comment #5 from Jonathan Wakely  ---
Here's a case where I think the warning is too noisy:

template
class trait
{
  template
static U get();

public:
  using type = decltype(get());
};

trait i;

When compiled with -Wctor-dtor-privacy this warns:

tr.cc:2:7: warning: all member functions in class 'trait' are private
[-Wctor-dtor-privacy]
2 | class trait
  |   ^

The member function is supposed to be private. It's used by the
typedef-declaration, but only the typedef needs to be public.

The documentation for the warning says "Also warn if there are no non-private
methods, and there's at least one private member function that isn't a
constructor or destructor." I think the warning should be suppressed if those
private member functions are used by a public typedef.

[Bug go/91035] [10 Regression] gotools fails to build on s390x-linux-gnu

[doko at debian dot org]

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

--- Comment #3 from Matthias Klose  ---
Created attachment 46718
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46718=edit
expvar assembler file

[Bug c++/90884] Option `-Wctor-dtor-privacy' enables warning even for system headers

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Marek, should this be backported to release branches too?

[Bug c++/71484] Class with implicit public constructor triggers `-Wctor-dtor-privacy`

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Olivier Kannengieser from comment #2)
> In GCC 8.1, 
> 
> #pragma GCC diagnostic ignored "-Wctor-dtor-privacy",
> does not fully disable the diagnostic message:
> 
> --> without ignored diagnostic:
> 
> test.cpp:2:8: warning: ‘struct S’ only defines private constructors
> and has no friends [-Wctor-dtor-privacy]
> struct S{
> ^
> test.cpp:4:3: note: ‘constexpr S::S(const S&)’ is public, but
> requires an existing ‘struct S’ object
> S(const S&) = default;
> 
> 
> ---> with ignored diagnostic:
> 
> test.cpp:4:3: note: ‘constexpr S::S(const S&)’ is public, but
> requires an existing ‘struct S’ object
> S(const S&) = default;

That was Bug 90884 and is now fixed.

[Bug c++/71484] Class with implicit public constructor triggers `-Wctor-dtor-privacy`

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Kyle J Strand from comment #0)
> A class whose only user-declared methods are `private`, but which *does*
> have an implicit public constructor, can trigger `-Wctor-dtor-privacy`.
> 
> See http://stackoverflow.com/q/33157248/1858225 for discussion and sample
> code.
> 
> The offending code is copied here for convenience:
> 
> struct foo
> {
>   private:
> static int test(void) { return 3; };
> };

That's by design, and is the documented behaviour of the warning. Nothing can
ever call that static function.

[Bug go/91035] [10 Regression] gotools fails to build on s390x-linux-gnu

[doko at debian dot org]

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

--- Comment #2 from Matthias Klose  ---
confirmed with trunk 20190815

build dir on
https://people.debian.org/~doko/tmp/tst-gotools.tar.xz

.L37 referenced in expvar.o

[Bug tree-optimization/88398] vectorization failure for a small loop to do byte comparison

[tnfchris at gcc dot gnu.org]

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

--- Comment #24 from Tamar Christina  ---
>   if (pb[len] != cur[len])

Ah sorry, it also access cur + len, so no, indeed I think only unrolling is
possible here. Unless cur was originally a static array and you can tell it's
size under LTO?

[Bug tree-optimization/88398] vectorization failure for a small loop to do byte comparison

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #23 from Tamar Christina  ---
? > The 'pb' pointer is the 'cur' pointer but moved back by 'delta'.
> > Presumably that means that all memory between 'pb' and 'delta' and could be
> > read in as wide a load as possible?
>
> A C language lawyer would agree with that.  But does it really help?
> The loop also accesses [cur + len, cur + len_limit].

Could we not emit a runtime check for this? Check if len <= delta and len +
len_limit <= delta, and if so emit a vectorized version and if not fall back to
the scalar unrolled code?

though if the iteration counts are so small as Wilco suggests then maybe it's
really not worth doing so.

[Bug tree-optimization/91458] New: FAIL: g++.dg/tree-ssa/pr19807.C -std=gnu++98 scan-tree-dump-times optimized "\\\\[\\\\(void .\\\\) \\\\+ 8B\\\\]" 3

[danglin at gcc dot gnu.org]

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

Bug ID: 91458
   Summary: FAIL: g++.dg/tree-ssa/pr19807.C  -std=gnu++98
scan-tree-dump-times optimized "[(void
.) + 8B]" 3
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

We have the following fails:

FAIL: g++.dg/tree-ssa/pr19807.C  -std=gnu++98  scan-tree-dump-times optimized
"[(void .) + 8B]" 3
FAIL: g++.dg/tree-ssa/pr19807.C  -std=gnu++14  scan-tree-dump-times optimized
"[(void .) + 8B]" 3
FAIL: g++.dg/tree-ssa/pr19807.C  -std=gnu++17  scan-tree-dump-times optimized
"[(void .) + 8B]" 3

spawn /test/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++
-B/test/gnu/gcc/objdir/gcc/testsuite/g++/../../
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/tree-ssa/pr19807.C
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -nostdinc++
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include
-I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98
-O -fdump-tree-optimized -S -o pr19807.s
PASS: g++.dg/tree-ssa/pr19807.C  -std=gnu++98 (test for excess errors)
g++.dg/tree-ssa/pr19807.C  -std=gnu++98 : pattern found 0 times
FAIL: g++.dg/tree-ssa/pr19807.C  -std=gnu++98  scan-tree-dump-times optimized
"\\[\\(void .\\) \\+ 8B\\]" 3

In tree dump, we have:

;; Function foo (_Z3foov, funcdef_no=0, decl_uid=1894, cgraph_uid=1,
symbol_orde
r=4)

foo ()
{
   [local count: 1073741824]:
  x =   [(void *) + 8B];
  y =   [(void *) + 8B];
  z =   [(void *) + 8B];
  return;

}

Similar fail:
FAIL: g++.dg/tree-ssa/ssa-dse-1.C   scan-tree-dump-times dse1
"MEM[(struct FixBuf *)& + [0-9]+B] = {}" 1

Here we have:
  MEM  [(struct FixBuf *)& + 28B] = {};

[Bug sanitizer/91455] [10 Regression] Revision r274426 breaks bootstrap on darwin

[iains at gcc dot gnu.org]

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

--- Comment #2 from Iain Sandoe  ---
Author: iains
Date: Thu Aug 15 14:13:10 2019
New Revision: 274538

URL: https://gcc.gnu.org/viewcvs?rev=274538=gcc=rev
Log:
[libsanitizer] Fix PR bootstrap/91455

If a target does not support libbacktrace, it might still the include
for $(top_srcdir).

Regenerate the built files using automake-1.15.1

libsanitizer/

2019-08-15  Iain Sandoe  

PR bootstrap/91455
* Makefile.in: Regenerated.
* aclocal.m4: Likewise.
* asan/Makefile.in: Likewise.
* configure: Likewise.
* interception/Makefile.in: Likewise.
* libbacktrace/Makefile.in: Likewise.
* lsan/Makefile.in: Likewise.
* sanitizer_common/Makefile.am: Include top_srcdir unconditionally.
* sanitizer_common/Makefile.in: Regenerated.
* tsan/Makefile.in: Likewise.
* ubsan/Makefile.in: Likewise.


Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/Makefile.in
trunk/libsanitizer/aclocal.m4
trunk/libsanitizer/asan/Makefile.in
trunk/libsanitizer/configure
trunk/libsanitizer/interception/Makefile.in
trunk/libsanitizer/libbacktrace/Makefile.in
trunk/libsanitizer/lsan/Makefile.in
trunk/libsanitizer/sanitizer_common/Makefile.am
trunk/libsanitizer/sanitizer_common/Makefile.in
trunk/libsanitizer/tsan/Makefile.in
trunk/libsanitizer/ubsan/Makefile.in

[Bug c++/91448] FAIL: g++.dg/opt/flifetime-dse2.C -std=gnu++98 execution test

[danglin at gcc dot gnu.org]

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

--- Comment #4 from John David Anglin  ---
Discussion on excess errors for g++.dg/warn/Warray-bounds-4.C move to Bug
91457:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91457

[Bug libstdc++/91371] std::bind and bind_front don't work with function with call convention

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
I haven't fully tested this idea yet, but ...

There are two kinds of function type we need to detect: referenceable
functions, and abominable functions.

A referenceable function type is a non-class type that can be converted from T&
to T* (by function-to-pointer conversion).

An abominable function type is a non-referenceable type that is not cv void.

So:

template
  struct is_referenceable : false_type { };

template
  struct is_referenceable> : true_type { };

template
  struct is_referenceable_function : false_type { };

template
  struct is_referenceable_function(std::declval()))>>
  : true_type { };

template
  struct is_abominable_function
  : __not_<__or_, is_void>>::type
  { };

template
  struct is_function
  : __or_, is_abominable_function>
  { };


The current definition of __is_referenceable depends on is_object which depends
on is_function, but I think we can simplify it as shown above, and reverse the
dependency.

[Bug tree-optimization/91457] FAIL: g++.dg/warn/Warray-bounds-4.C -std=gnu++98 (test for warnings, line 25)

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  ---
Martin Sebor wrote on 2019-08-14:

I don't know about the flifetime-dse2.C test but the Warray-bounds-4.C warning
is the result of a recent enhancement to the strlen optimization, either
r274486 or r273783.  On the hppa2.0w-hp-hpux11.11 target the warning newly
added in r273783 sees the following code:

  main ()
  {
const struct FixedString empty;

 [local count: 1073741824]:
MEM[(int (*) () * *)] =   [(void
*)&_ZTV11FixedStringILm0EE + 8B];
MEM[(char *) + 4B] = 0;
print_length ();   <<<
empty ={v} {CLOBBER};
empty ={v} {CLOBBER};
return 0;
  }

and diagnoses the invalid store at <<< before VRP gets to it and issues
-Warray-bounds.  On other targets like sparc-solaris2.11, the strlen pass sees
the following code:

main ()
{
  const struct FixedString empty;

   [local count: 1073741824]:
  MEM[(struct FixedString *)] ={v} {CLOBBER};
  MEM[(struct FixedString *)].D.2008._vptr.String =  
[(void *)&_ZTV11FixedStringILm0EE + 8B];
  MEM[(struct FixedString *)].contents[0] = 0;   <<<
  print_length ();
  empty ={v} {CLOBBER};
  empty ={v} {CLOBBER};
  return 0;

}

and it doesn't handle this form of the assignment (it doesn't know how to
determine the size of the referenced object).  Ideally, both kinds would be
handled and the same warning would be issued.  It means enhancing the object
size detection (compute_objsize in builtins.c).

[Bug tree-optimization/91457] New: FAIL: g++.dg/warn/Warray-bounds-4.C -std=gnu++98 (test for warnings, line 25)

[danglin at gcc dot gnu.org]

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

Bug ID: 91457
   Summary: FAIL: g++.dg/warn/Warray-bounds-4.C  -std=gnu++98
(test for warnings, line 25)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

I see the following fails:

FAIL: g++.dg/warn/Warray-bounds-4.C  -std=gnu++98  (test for warnings, line 25)
FAIL: g++.dg/warn/Warray-bounds-4.C  -std=gnu++98 (test for excess errors)
FAIL: g++.dg/warn/Warray-bounds-4.C  -std=gnu++14  (test for warnings, line 25)
FAIL: g++.dg/warn/Warray-bounds-4.C  -std=gnu++14 (test for excess errors)
FAIL: g++.dg/warn/Warray-bounds-4.C  -std=gnu++17  (test for warnings, line 25)
FAIL: g++.dg/warn/Warray-bounds-4.C  -std=gnu++17 (test for excess errors)

spawn /test/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++
-B/test/gnu/gcc/objdir/g
cc/testsuite/g++/../../
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/warn/Warray-bounds-4.C
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -nostdinc++
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include
-I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98
-O2 -Warray-bounds -S -o Warray-bounds-4.s
In constructor 'FixedString::FixedString() [with long unsigned int size =
0]',
inlined from 'int main()' at
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/warn/Warray-bounds-4.C:32:24:
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/warn/Warray-bounds-4.C:25:19: warning:
writing 1 byte into a region of size 0 [-Wstringop-overflow=]
output is:
In constructor 'FixedString::FixedString() [with long unsigned int size =
0]',
inlined from 'int main()' at
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/warn/Warray-bounds-4.C:32:24:
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/warn/Warray-bounds-4.C:25:19: warning:
writing 1 byte into a region of size 0 [-Wstringop-overflow=]

FAIL: g++.dg/warn/Warray-bounds-4.C  -std=gnu++98  (test for warnings, line 25)
FAIL: g++.dg/warn/Warray-bounds-4.C  -std=gnu++98 (test for excess errors)
Excess errors:
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/warn/Warray-bounds-4.C:25:19: warning:
writing 1 byte into a region of size 0 [-Wstringop-overflow=]

It looks like these fails may be related to fails on darwin:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91006

[tag] [reply] [−] Comment 2

[Bug ipa/91447] [10 Regression] FAIL: g++.dg/ipa/ipa-icf-4.C -std=gnu++98 scan-ipa-dump icf

[dave.anglin at bell dot net]

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

--- Comment #3 from dave.anglin at bell dot net ---
On 2019-08-15 3:32 a.m., marxin at gcc dot gnu.org wrote:
> Created attachment 46716
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46716=edit
> Patch candidate
>
> @John: Can you please test it for me?
This patch fixes the test.

Thanks,
Dave

[Bug target/91454] [10 Regression] ICE in get_attr_avx_partial_xmm_update, at config/i386/i386.md:1804 since r274481

[ubizjak at gmail dot com]

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

--- Comment #8 from Uroš Bizjak  ---
*** Bug 91453 has been marked as a duplicate of this bug. ***

[Bug target/91453] ICE in elimination_costs_in_insn at reload1.c:3547

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Uroš Bizjak  ---
Fixed by r274535.

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

[Bug sanitizer/91455] [10 Regression] Revision r274426 breaks bootstrap on darwin

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug target/91453] ICE in elimination_costs_in_insn at reload1.c:3547

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
Latest SVN creates the following RTX in _.ira dump:

(insn 144 12 145 2 (set (subreg:V2DI (reg:DI 161) 0)
(vec_merge:V2DI (vec_duplicate:V2DI (reg:DI 111 [ ubound.0 ]))
(const_vector:V2DI [
(const_int 0 [0]) repeated x2
])
(const_int 1 [0x1]))) "deferred_character_23.f90":27:0 -1
 (nil))

This is suspiciously close to PR91454. "-1" hints at unknown insn.

[Bug target/91453] ICE in elimination_costs_in_insn at reload1.c:3547

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
Are you sure? It compiles OK with gcc-9 for me.

[Bug libstdc++/91456] std::function and std::is_invocable_r do not understand guaranteed elision

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-15
Version|9.1.1   |10.0
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
There's a related problem in std::is_invocable_r:

// { dg-options "-std=gnu++17" }
// { dg-do compile { c++17 } }
#include 

struct Immovable {
  Immovable() = default;
  Immovable(const Immovable&) = delete;
  Immovable& operator=(const Immovable&) = delete;
};

static_assert(std::is_invocable_r_v);
static_assert(std::is_invocable_r_v);
static_assert(std::is_invocable_r_v);

The assertions fail because is_invocable_r uses is_convertible, which doesn't
know about guaranteed elision.

[Bug libstdc++/91456] New: std::function and std::is_invocable_r do not understand guaranteed elision

[redi at gcc dot gnu.org]

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

Bug ID: 91456
   Summary: std::function and std::is_invocable_r do not
understand guaranteed elision
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

// { dg-options "-std=gnu++17" }
// { dg-do compile { c++17 } }
#include 

struct Immovable {
  Immovable() = default;
  Immovable(const Immovable&) = delete;
  Immovable& operator=(const Immovable&) = delete;
};

Immovable get() { return {}; }
const Immovable i = get();  // OK
std::function f{};   // fails
const Immovable i2 = f();

It fails because std::function uses is_same || is_convertible to
check if the target function's return type can be converted to the
std::function return type. Immovable and const Immovable are not the same type,
and is_convertible checks whether construction or R2 from R1&& is well-formed,
so that fails too.

It should succeed in C++17, because guaranteed elision means there's no copy
from an rvalue.

[Bug target/91454] [10 Regression] ICE in get_attr_avx_partial_xmm_update, at config/i386/i386.md:1804 since r274481

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Thu Aug 15 12:44:23 2019
New Revision: 274535

URL: https://gcc.gnu.org/viewcvs?rev=274535=gcc=rev
Log:
2019-08-15  Richard Biener  

PR target/91454
* config/i386/i386-features.c (gen_gpr_to_xmm_move_src): New
helper.
(general_scalar_chain::make_vector_copies): Use it.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386-features.c

[Bug target/91454] [10 Regression] ICE in get_attr_avx_partial_xmm_update, at config/i386/i386.md:1804 since r274481

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug sanitizer/91455] [10 Regression] Revision r274426 breaks bootstrap on darwin

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||patch
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-15
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Should be fixed with:
https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01074.html

[Bug sanitizer/91455] New: [10 Regression] Revision r274426 breaks bootstrap on darwin

[dominiq at lps dot ens.fr]

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

Bug ID: 91455
   Summary: [10 Regression] Revision r274426 breaks bootstrap on
darwin
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
iains at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at 
gcc dot gnu.org,
marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin17
Target: x86_64-apple-darwin17
 Build: x86_64-apple-darwin17

Revision r274426 breaks bootstrap on darwin:

libtool: compile:  /opt/gcc/p_build/./gcc/xgcc -shared-libgcc
-B/opt/gcc/p_build/./gcc -nostdinc++
-L/opt/gcc/p_build/x86_64-apple-darwin17/libstdc++-v3/src
-L/opt/gcc/p_build/x86_64-apple-darwin17/libstdc++-v3/src/.libs
-L/opt/gcc/p_build/x86_64-apple-darwin17/libstdc++-v3/libsupc++/.libs
-B/opt/gcc/gcc10p-274518p1/x86_64-apple-darwin17/bin/
-B/opt/gcc/gcc10p-274518p1/x86_64-apple-darwin17/lib/ -isystem
/opt/gcc/gcc10p-274518p1/x86_64-apple-darwin17/include -isystem
/opt/gcc/gcc10p-274518p1/x86_64-apple-darwin17/sys-include -D_GNU_SOURCE
-D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-DHAVE_RPC_XDR_H=0 -DHAVE_TIRPC_RPC_XDR_H=0 -I.
-I../../../../p_work/libsanitizer/sanitizer_common -I.. -I
../../../../p_work/libsanitizer/include -isystem
../../../../p_work/libsanitizer/include/system -Wall -W -Wno-unused-parameter
-Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions
-fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden
-Wno-variadic-macros -I../../libstdc++-v3/include
-I../../libstdc++-v3/include/x86_64-apple-darwin17
-I../../../../p_work/libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++11 -g -O2
-MT sanitizer_stacktrace_libcdep.lo -MD -MP -MF
.deps/sanitizer_stacktrace_libcdep.Tpo -c
../../../../p_work/libsanitizer/sanitizer_common/sanitizer_stacktrace_libcdep.cpp
 -fno-common -DPIC -o .libs/sanitizer_stacktrace_libcdep.o
In file included from
../../../../p_work/libsanitizer/sanitizer_common/sanitizer_symbolizer.h:23,
 from
../../../../p_work/libsanitizer/sanitizer_common/sanitizer_stacktrace_printer.h:16,
 from
../../../../p_work/libsanitizer/sanitizer_common/sanitizer_stacktrace_libcdep.cpp:16:
../../../../p_work/libsanitizer/sanitizer_common/sanitizer_vector.h:18:10:
fatal error: sanitizer_common/sanitizer_allocator_internal.h: No such file or
directory
   18 | #include "sanitizer_common/sanitizer_allocator_internal.h"
  |  ^
compilation terminated.
make[4]: *** [sanitizer_stacktrace_libcdep.lo] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-target-libsanitizer] Error 2
make: *** [all] Error 2

[Bug lto/91307] -flto causes binary to vary

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
I wonder why we can't simply use .init_array and thus get away with a
local symbol on targets that support this.  Uh, so the symbol is already
local but we're keeping it in our stripping process it seems.  And
the name is fancy "for debugging purposes".  Not sure if gdb has special
breakpoints for ctors/dtors or if the user is expected to know the
mangling.

Btw, for !targetm.have_ctors_dtors we're appending "some randomness"
anyways so I wonder if we shouldn't simply pass down appropriate
deterministic randomness by producing it from the symbols of the individual
ctors/dtors we call here:

  /* Find the next batch of constructors/destructors with the same
 initialization priority.  */
  for (;i < j; i++)
{
  tree call;
  fn = cdtors[i];
  call = build_call_expr (fn, 0);
  if (ctor_p)
DECL_STATIC_CONSTRUCTOR (fn) = 0;
  else
DECL_STATIC_DESTRUCTOR (fn) = 0;
  /* We do not want to optimize away pure/const calls here.
 When optimizing, these should be already removed, when not
 optimizing, we want user to be able to breakpoint in them.  */
  TREE_SIDE_EFFECTS (call) = 1;
  append_to_statement_list (call, );
}

like

Index: gcc/ipa.c
===
--- gcc/ipa.c   (revision 274527)
+++ gcc/ipa.c   (working copy)
@@ -827,7 +827,7 @@ ipa_discover_variable_flags (void)
 static void
 cgraph_build_static_cdtor_1 (char which, tree body, int priority, bool final,
 tree optimization,
-tree target)
+tree target, hashval_t hstate)
 {
   static int counter = 0;
   char which_buf[16];
@@ -842,7 +842,7 @@ cgraph_build_static_cdtor_1 (char which,
   /* Proudce sane name but one not recognizable by collect2, just for the
  case we fail to inline the function.  */
 sprintf (which_buf, "sub_%c_%.5d_%d", which, priority, counter++);
-  name = get_file_function_name (which_buf);
+  name = get_file_function_name (which_buf, hstate);

   decl = build_decl (input_location, FUNCTION_DECL, name,
 build_function_type_list (void_type_node, NULL_TREE));
@@ -973,6 +973,7 @@ build_cdtor (bool ctor_p, const vec

[Bug other/89856] `ld: warning: direct access to global weak symbol means the weak symbol cannot be overridden at runtime` using LTO with optimization and -fprofile-generate

[zerolo at gmail dot com]

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

--- Comment #3 from Daniel Vollmer  ---
These linker warnings then also seem to result in actual address-sanitizer
errors (which may or may not be spurious):

(Output not from the provided example, but the shown
_GLOBAL__sub_I_00099_1_CommunicationBuffersBase.cpp refers to a templated
method with a static local variable like the BroadcastFromMaster example.

Process 40885 launched:
'/usr/local/Cellar/python@2/2.7.16/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python'
(x86_64)
==40885==The following global variable is not properly aligned.
==40885==This may happen if another global with the same name
==40885==resides in another non-instrumented module.
==40885==Or the global comes from a C file built w/o -fno-common.
==40885==In either case this is likely an ODR violation bug,
==40885==but AddressSanitizer can not provide more details.
=
==40885==ERROR: AddressSanitizer: odr-violation (0x00050083):
Process 40885 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x90186)
frame #0: 0x0001000e7169
libasan.4.dylib`__asan::PrintGlobalLocation(__sanitizer::InternalScopedString*,
__asan_global const&) + 25
libasan.4.dylib`__asan::PrintGlobalLocation:
->  0x1000e7169 <+25>: movq   (%rax), %rdx
0x1000e716c <+28>: testq  %rdx, %rdx
0x1000e716f <+31>: je 0x1000e71e0   ; <+144>
0x1000e7171 <+33>: leaq   0x79838(%rip), %rsi   ; "%s"
Target 0: (Python) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x90186)
  * frame #0: 0x0001000e7169
libasan.4.dylib`__asan::PrintGlobalLocation(__sanitizer::InternalScopedString*,
__asan_global const&) + 25
frame #1: 0x0001000df8bf
libasan.4.dylib`__asan::ErrorODRViolation::Print() + 191
frame #2: 0x00010013ba9c
libasan.4.dylib`__asan::ReportODRViolation(__asan_global const*, unsigned int,
__asan_global const*, unsigned int) + 1484
frame #3: 0x0001000e65ed
libasan.4.dylib`__asan_register_globals.part.11 + 1469
frame #4: 0x00010ae9df96
libFlis.dylib`_GLOBAL__sub_I_00099_1_CommunicationBuffersBase.cpp + 31
frame #5: 0x00010001c592
dyld`ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) +
506
frame #6: 0x00010001c798
dyld`ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40
frame #7: 0x000100017bea
dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&,
unsigned int, char const*, ImageLoader::InitializerTimingList&,
ImageLoader::UninitedUpwards&) + 362
frame #8: 0x000100017b80
dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&,
unsigned int, char const*, ImageLoader::InitializerTimingList&,
ImageLoader::UninitedUpwards&) + 256
frame #9: 0x000100017b80
dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&,
unsigned int, char const*, ImageLoader::InitializerTimingList&,
ImageLoader::UninitedUpwards&) + 256
frame #10: 0x000100016d73
dyld`ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned
int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 133
frame #11: 0x000100016e05
dyld`ImageLoader::runInitializers(ImageLoader::LinkContext const&,
ImageLoader::InitializerTimingList&) + 73
frame #12: 0x00019cb2 dyld`dyld::runInitializers(ImageLoader*) + 82
frame #13: 0x0001000133dc dyld`dlopen_internal + 607
frame #14: 0x7fff713dbd43 libdyld.dylib`dlopen + 200
frame #15: 0x0001000f4f9b libasan.4.dylib`wrap_dlopen.part.109 + 75
frame #16: 0x000100f1fef7 Python`_PyImport_GetDynLoadFunc + 306
frame #17: 0x000100f0b43a Python`_PyImport_LoadDynamicModule + 89
frame #18: 0x000100f0a209 Python`import_submodule + 273

[Bug c++/91445] [9 Regression] After memset, logical && operator produces false result, optimization level >=O1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||9.2.1
 Resolution|--- |FIXED

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

[Bug c++/91445] [9 Regression] After memset, logical && operator produces false result, optimization level >=O1

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Author: rguenth
Date: Thu Aug 15 12:05:31 2019
New Revision: 274533

URL: https://gcc.gnu.org/viewcvs?rev=274533=gcc=rev
Log:
2019-08-15  Richard Biener  

PR tree-optimization/91445
* gcc.dg/torture/pr91445.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr91445.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/91091] [missed optimization] Missing optimization in unaliased pointers

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Thu Aug 15 12:02:47 2019
New Revision: 274532

URL: https://gcc.gnu.org/viewcvs?rev=274532=gcc=rev
Log:
2019-08-15  Richard Biener  

PR tree-optimization/91445
* gcc.dg/torture/pr91445.c: New testcase.

Backport from mainline
2019-07-05  Richard Biener  

PR tree-optimization/91091
* tree-ssa-alias.h (get_continuation_for_phi): Add tbaa_p parameter.
(walk_non_aliased_vuses): Likewise.
* tree-ssa-alias.c (maybe_skip_until): Pass down tbaa_p.
(get_continuation_for_phi): New tbaa_p parameter and pass
it down.
(walk_non_aliased_vuses): Likewise.
* tree-ssa-pre.c (translate_vuse_through_block): Likewise.
* tree-ssa-scopedtables.c (avail_exprs_stack::lookup_avail_expr):
Likewise.
* tree-ssa-sccvn.c (struct vn_walk_cb_data): Add tbaa_p flag.
(vn_reference_lookup_3): Handle and pass down tbaa_p flag.
(vn_reference_lookup_pieces): Adjust.
(vn_reference_lookup): Remove alias-set altering, instead pass
down false as tbaa_p.

* gcc.dg/tree-ssa/pr91091-2.c: New testcase.

2019-07-04  Richard Biener  

* tree-ssa-sccvn.h (vn_reference_lookup): Add last_vuse_ptr
argument.
* tree-ssa-sccvn.c (last_vuse_ptr, vn_walk_kind): Move
globals into...
(struct vn_walk_cb_data): New callback data struct.
(vn_reference_lookup_2): Adjust.
(vn_reference_lookup_3): Likewise.
(vn_reference_lookup_pieces): Likewise.
(vn_reference_lookup): Likewise, get last_vuse_ptr argument.
(visit_reference_op_load): Adjust.

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91445.c
branches/gcc-9-branch/gcc/testsuite/gcc.dg/tree-ssa/pr91091-2.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/tree-ssa-alias.c
branches/gcc-9-branch/gcc/tree-ssa-alias.h
branches/gcc-9-branch/gcc/tree-ssa-pre.c
branches/gcc-9-branch/gcc/tree-ssa-sccvn.c
branches/gcc-9-branch/gcc/tree-ssa-sccvn.h
branches/gcc-9-branch/gcc/tree-ssa-scopedtables.c

[Bug c++/91445] [9 Regression] After memset, logical && operator produces false result, optimization level >=O1

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Thu Aug 15 12:02:47 2019
New Revision: 274532

URL: https://gcc.gnu.org/viewcvs?rev=274532=gcc=rev
Log:
2019-08-15  Richard Biener  

PR tree-optimization/91445
* gcc.dg/torture/pr91445.c: New testcase.

Backport from mainline
2019-07-05  Richard Biener  

PR tree-optimization/91091
* tree-ssa-alias.h (get_continuation_for_phi): Add tbaa_p parameter.
(walk_non_aliased_vuses): Likewise.
* tree-ssa-alias.c (maybe_skip_until): Pass down tbaa_p.
(get_continuation_for_phi): New tbaa_p parameter and pass
it down.
(walk_non_aliased_vuses): Likewise.
* tree-ssa-pre.c (translate_vuse_through_block): Likewise.
* tree-ssa-scopedtables.c (avail_exprs_stack::lookup_avail_expr):
Likewise.
* tree-ssa-sccvn.c (struct vn_walk_cb_data): Add tbaa_p flag.
(vn_reference_lookup_3): Handle and pass down tbaa_p flag.
(vn_reference_lookup_pieces): Adjust.
(vn_reference_lookup): Remove alias-set altering, instead pass
down false as tbaa_p.

* gcc.dg/tree-ssa/pr91091-2.c: New testcase.

2019-07-04  Richard Biener  

* tree-ssa-sccvn.h (vn_reference_lookup): Add last_vuse_ptr
argument.
* tree-ssa-sccvn.c (last_vuse_ptr, vn_walk_kind): Move
globals into...
(struct vn_walk_cb_data): New callback data struct.
(vn_reference_lookup_2): Adjust.
(vn_reference_lookup_3): Likewise.
(vn_reference_lookup_pieces): Likewise.
(vn_reference_lookup): Likewise, get last_vuse_ptr argument.
(visit_reference_op_load): Adjust.

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91445.c
branches/gcc-9-branch/gcc/testsuite/gcc.dg/tree-ssa/pr91091-2.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/tree-ssa-alias.c
branches/gcc-9-branch/gcc/tree-ssa-alias.h
branches/gcc-9-branch/gcc/tree-ssa-pre.c
branches/gcc-9-branch/gcc/tree-ssa-sccvn.c
branches/gcc-9-branch/gcc/tree-ssa-sccvn.h
branches/gcc-9-branch/gcc/tree-ssa-scopedtables.c

[Bug fortran/91390] treatment of extra parameter in a subroutine call

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
 Blocks||40976
 Depends on||91443
 Resolution|DUPLICATE   |---
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org

--- Comment #3 from Thomas Koenig  ---
Changed my mind :-)

It's the next logical step after the fix for 91443 goes in.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40976
[Bug 40976] Merge DECL of procedure call with DECL of gfc_get_function_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91443
[Bug 91443] -Wargument-mismatch does not catch mismatch for global procedure

[Bug fortran/40976] Merge DECL of procedure call with DECL of gfc_get_function_type

[tkoenig at gcc dot gnu.org]

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

Bug 91390 Summary: treatment of extra parameter in a subroutine call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91390

   What|Removed |Added

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

[Bug other/89856] `ld: warning: direct access to global weak symbol means the weak symbol cannot be overridden at runtime` using LTO with optimization and -fprofile-generate

[zerolo at gmail dot com]

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

--- Comment #2 from Daniel Vollmer  ---
I'm seeing the same warning in a similar context when using the
address-sanitizer, e.g.

> cat lib.cpp
#include 
#include 

inline const std::string ()
{
  static const std::string str = "abc";
  return str;
}

void func2()
{
  const auto str = func1();
  std::cout << str << std::endl;
}

> g++-7 -fsanitize=address -std=c++14 -shared lib.cpp -o lib.dylib
ld: warning: direct access in function '__GLOBAL__sub_D_00099_0_lib.cpp' from
file '/var/folders/02/yl3m8d4d0397mk6dxn6dpcqwgp/T//ccEl2k3C.o' to global
weak symbol 'guard variable for func1[abi:cxx11]()::str' from file
'/var/folders/02/yl3m8d4d0397mk6dxn6dpcqwgp/T//ccEl2k3C.o' means the weak
symbol cannot be overridden at runtime. This was likely caused by different
translation units being compiled with different visibility settings.
ld: warning: direct access in function '__GLOBAL__sub_I_00099_1_lib.cpp' from
file '/var/folders/02/yl3m8d4d0397mk6dxn6dpcqwgp/T//ccEl2k3C.o' to global
weak symbol 'guard variable for func1[abi:cxx11]()::str' from file
'/var/folders/02/yl3m8d4d0397mk6dxn6dpcqwgp/T//ccEl2k3C.o' means the weak
symbol cannot be overridden at runtime. This was likely caused by different
translation units being compiled with different visibility settings.


(Same with g++-9.1)

[Bug c++/91436] Confusing suggestion to include

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Konstantin Kharlamov from comment #0)
> When the reason for an undefined function is too low c++ standard, g++ still
> suggests to include the header where it's supposed to be.

N.B. this isn't true in general, it was true only for std::make_unique and the
namespace std::complex_literals. In general it should tell you the problem is
the -std option, and that's what happens for your example now:

91436.cc: In function 'int main()':
91436.cc:4:21: error: 'make_unique' is not a member of 'std'
 auto foo = std::make_unique();
 ^~~
91436.cc:4:21: note: 'std::make_unique' is only available from C++14 onwards
91436.cc:4:33: error: expected primary-expression before 'char'
 auto foo = std::make_unique();
 ^~~~

[Bug c++/91436] Confusing suggestion to include

[Hi-Angel at yandex dot ru]

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

--- Comment #6 from Konstantin Kharlamov  ---
Thank you!

[Bug c++/91436] Confusing suggestion to include

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.4

--- Comment #5 from Jonathan Wakely  ---
Fixed for 8.4 and 9.3

[Bug c++/91436] Confusing suggestion to include

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Thu Aug 15 11:35:58 2019
New Revision: 274530

URL: https://gcc.gnu.org/viewcvs?rev=274530=gcc=rev
Log:
PR c++/91436 fix C++ dialect for std::make_unique fix-it hint

The std::make_unique function wasn't added until C++14, and neither was
the std::complex_literals namespace.

Backport from mainline.
2019-08-14  Jonathan Wakely  

gcc/cp:

PR c++/91436
* name-lookup.c (get_std_name_hint): Fix min_dialect field for
complex_literals and make_unique entries.

gcc/testsuite:

PR c++/91436
* g++.dg/lookup/missing-std-include-5.C: Limit test to C++14 and up.
* g++.dg/lookup/missing-std-include-6.C: Don't check make_unique in
test that runs for C++11.
* g++.dg/lookup/missing-std-include-8.C: Check make_unique here.

Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/name-lookup.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/g++.dg/lookup/missing-std-include-5.C
branches/gcc-8-branch/gcc/testsuite/g++.dg/lookup/missing-std-include-6.C
branches/gcc-8-branch/gcc/testsuite/g++.dg/lookup/missing-std-include-8.C

[Bug debug/28834] [4.0/4.1/4.2/4.3 Regression] -g crashes sometimes when using may_alias and structs (ICE in splice_child_die)

[contacts at buymore dot pro]

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

nicbrown  changed:

   What|Removed |Added

 CC||contacts at buymore dot pro

--- Comment #33 from nicbrown  ---
Created attachment 46717
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46717=edit
true

[Bug ipa/91088] IPA-cp cost evaluation is too conservative for "if (f(param) cmp const_val)" condition

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-15
 CC||tnfchris at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |tnfchris at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Tamar Christina  ---
I'll assign this to myself for now since the engineer investigating this
doesn't have a bugzilla account yet.

[Bug ipa/91089] IPA-cp does not setup proper cost model for switch default case in function versioning

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-15
 CC||tnfchris at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |tnfchris at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Tamar Christina  ---
I'll assign this to myself for now since the engineer investigating this
doesn't have a bugzilla account yet.

[Bug target/91454] [10 Regression] ICE in get_attr_avx_partial_xmm_update, at config/i386/i386.md:1804 since r274481

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
(In reply to Richard Biener from comment #4)
> Btw, remove_partial_avx_dependency suggests the VEC_MERGE/DUPLICATE form
> is canonical for V2DFmode ... (is it?).

Not according to

typedef double v2di __attribute__((vector_size(16)));

v2di foo (double x)
{
  return (v2di) { x, 0. };
}

which produces

(insn 6 3 7 2 (set (reg:V2DF 85)
(vec_concat:V2DF (reg/v:DF 83 [ x ])
(const_double:DF 0.0 [0x0.0p+0]))) "t.c":5:10 3056 {vec_concatv2df}
 (nil))

but maybe the merge/duplicate pattern also exists.

[Bug target/91454] [10 Regression] ICE in get_attr_avx_partial_xmm_update, at config/i386/i386.md:1804 since r274481

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Btw, remove_partial_avx_dependency suggests the VEC_MERGE/DUPLICATE form
is canonical for V2DFmode ... (is it?).

Otherwise untested fix:

Index: gcc/config/i386/i386-features.c
===
--- gcc/config/i386/i386-features.c (revision 274504)
+++ gcc/config/i386/i386-features.c (working copy)
@@ -658,6 +658,25 @@ scalar_chain::emit_conversion_insns (rtx
   emit_insn_after (insns, BB_HEAD (new_bb));
 }

+/* Generate the canonical SET_SRC to move GPR to a VMODE vector register,
+   zeroing the upper parts.  */
+
+static rtx
+gen_gpr_to_xmm_move_src (enum machine_mode vmode, rtx gpr)
+{
+  switch (GET_MODE_NUNITS (vmode))
+{
+case 1:
+  return gen_rtx_SUBREG (vmode, gpr, 0);
+case 2:
+  return gen_rtx_VEC_CONCAT (vmode, gpr,
+CONST0_RTX (GET_MODE_INNER (vmode)));
+default:
+  return gen_rtx_VEC_MERGE (vmode, gen_rtx_VEC_DUPLICATE (vmode, gpr),
+   CONST0_RTX (vmode), GEN_INT
(HOST_WIDE_INT_1U));
+}
+}
+
 /* Make vector copies for all register REGNO definitions
and replace its uses in a chain.  */

@@ -684,13 +703,8 @@ general_scalar_chain::make_vector_copies
  }
else
  emit_move_insn (tmp, reg);
-   emit_insn (gen_rtx_SET
-   (gen_rtx_SUBREG (vmode, vreg, 0),
-gen_rtx_VEC_MERGE (vmode,
-   gen_rtx_VEC_DUPLICATE (vmode,
-  tmp),
-   CONST0_RTX (vmode),
-   GEN_INT (HOST_WIDE_INT_1U;
+   emit_insn (gen_rtx_SET (gen_rtx_SUBREG (vmode, vreg, 0),
+   gen_gpr_to_xmm_move_src (vmode, tmp)));
  }
else if (!TARGET_64BIT && smode == DImode)
  {
@@ -720,13 +734,8 @@ general_scalar_chain::make_vector_copies
  }
  }
else
- emit_insn (gen_rtx_SET
-  (gen_rtx_SUBREG (vmode, vreg, 0),
-   gen_rtx_VEC_MERGE (vmode,
-  gen_rtx_VEC_DUPLICATE (vmode,
- reg),
-  CONST0_RTX (vmode),
-  GEN_INT (HOST_WIDE_INT_1U;
+ emit_insn (gen_rtx_SET (gen_rtx_SUBREG (vmode, vreg, 0),
+ gen_gpr_to_xmm_move_src (vmode, reg)));
rtx_insn *seq = get_insns ();
end_sequence ();
rtx_insn *insn = DF_REF_INSN (ref);

[Bug tree-optimization/91444] [10 regression] Many ICEs starting with r274404

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Should be fixed now -- please reopen if not.

[Bug tree-optimization/91444] [10 regression] Many ICEs starting with r274404

[rsandifo at gcc dot gnu.org]

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Thu Aug 15 09:23:06 2019
New Revision: 274524

URL: https://gcc.gnu.org/viewcvs?rev=274524=gcc=rev
Log:
Add missing check for BUILT_IN_MD (PR 91444)

In this PR we were passing an ordinary non-built-in function to
targetm.vectorize.builtin_md_vectorized_function, which is only
supposed to handle BUILT_IN_MD.

2019-08-15  Richard Sandiford  

gcc/
PR middle-end/91444
* tree-vect-stmts.c (vectorizable_call): Check that the function
is a BUILT_IN_MD function before passing it to
targetm.vectorize.builtin_md_vectorized_function.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-stmts.c

[Bug target/91454] [10 Regression] ICE in get_attr_avx_partial_xmm_update, at config/i386/i386.md:1804 since r274481

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug target/91454] [10 Regression] ICE in get_attr_avx_partial_xmm_update, at config/i386/i386.md:1804 since r274481

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Instead we seem to use

(insn 6 3 7 2 (set (reg:V2DI 85)
(vec_concat:V2DI (reg/v:DI 83 [ x ])
(const_int 0 [0]))) "t.c":5:10 4212 {*vec_concatv2di_0}
 (nil))

bah.  Is there a helper abstracting the canonical forms for this?

[Bug target/91454] [10 Regression] ICE in get_attr_avx_partial_xmm_update, at config/i386/i386.md:1804 since r274481

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Looks like we miss a pattern for

(insn 162 16 163 2 (set (subreg:V2DI (reg:DI 169) 0)
(vec_merge:V2DI (vec_duplicate:V2DI (reg:DI 101 [ ubound.0 ]))
(const_vector:V2DI [
(const_int 0 [0]) repeated x2
])
(const_int 1 [0x1]))) "t.f90":8:0 -1
 (nil))

?  I expected that this canonical form for movq gpr, %xmm is handled?

[Bug c++/91445] [9 Regression] After memset, logical && operator produces false result, optimization level >=O1

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
On trunk the following hunk "fixed" it.

@@ -2054,7 +2088,9 @@ vn_reference_lookup_3 (ao_ref *ref, tree
}
 }

-  if (*disambiguate_only)
+  /* If we are looking for redundant stores do not create new hashtable
+ entries from aliasing defs with made up alias-sets.  */
+  if (*disambiguate_only || !data->tbaa_p)
 return (void *)-1;

   /* If we cannot constrain the size of the reference we cannot

[Bug tree-optimization/91444] [10 regression] Many ICEs starting with r274404

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Mine.

Looks like a latent problem.  The vectoriser doesn't check
whether the function actually is a target-specific built-in
function before passing it to
targetm.vectorize.builtin_md_vectorized_function.

[Bug target/82328] x86 rdrand: flags not used directly when branching on success/failure

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-15
 CC||hjl.tools at gmail dot com,
   ||uros at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug target/91446] Wrong cost for scalar_load/scalar_store of vector type

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Index: gcc/config/i386/x86-tune-costs.h
===
--- gcc/config/i386/x86-tune-costs.h(revision 274422)
+++ gcc/config/i386/x86-tune-costs.h(working copy)
@@ -1442,7 +1442,7 @@ struct processor_costs skylake_cost = {
   {4, 4, 4},   /* cost of loading integer registers
   in QImode, HImode and SImode.
   Relative to reg-reg move (2).  */
-  {6, 6, 3},   /* cost of storing integer registers */
+  {6, 6, 6},   /* cost of storing integer registers */
   2,   /* cost of reg,reg fld/fst */
   {6, 6, 8},   /* cost of loading fp registers
   in SFmode, DFmode and XFmode */

produces

foo:
.LFB0:
.cfi_startproc
vmovq   %rdi, %xmm1
subq$40, %rsp
.cfi_def_cfa_offset 48
vpinsrq $1, %rsi, %xmm1, %xmm0
vmovq   %rdx, %xmm2
vmovaps %xmm0, (%rsp)
movq%rsp, %rdi
vpinsrq $1, %rcx, %xmm2, %xmm0
vmovaps %xmm0, 16(%rsp)
callbar
addq$40, %rsp
.cfi_def_cfa_offset 8
ret

it may appear odd that we don't use AVX256, this is because of

t.i:17:3: note:   === vect_analyze_data_ref_accesses ===
t.i:17:3: note:   Detected interleaving store t.width and t.height
t.i:17:3: note:   Detected interleaving store t.x and t.y
t.i:17:3: note:   Detected interleaving store of size 2
t.i:17:3: note: t.width = width_2(D);
t.i:17:3: note: t.height = height_4(D);
t.i:17:3: note:   Detected interleaving store of size 2
t.i:17:3: note: t.x = x_6(D);
t.i:17:3: note: t.y = y_8(D);

and thus we are "confused" about the different sign of the fields which
ultimatively yields to different vector types which would make a difference
if there is sign-dependent arithmetic performed, but not in this particular
case.  On GIMPLE we'd also need nop-conversions to make the IL checker happy.
On this ground the bug would be valid but not about costs (you may want
to open a separate bug for this issue).

[Bug ipa/91447] FAIL: g++.dg/ipa/ipa-icf-4.C -std=gnu++98 scan-ipa-dump icf "(Unified; Variable alias has been created)|(Symbol aliases are not supported by target)"

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Created attachment 46716
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46716=edit
Patch candidate

@John: Can you please test it for me?

[Bug target/91446] Wrong cost for scalar_load/scalar_store of vector type

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Not sure what you are after, we are costing for the scalar cost

0x4ad73f0 width_2(D) 1 times scalar_store costs 6 in body
0x4ad73f0 height_4(D) 1 times scalar_store costs 6 in body
0x4ad73f0 x_6(D) 1 times scalar_store costs 6 in body
0x4ad73f0 y_8(D) 1 times scalar_store costs 6 in body

and for the vectorized cost

0x4bd8330 width_2(D) 1 times vec_construct costs 8 in prologue
0x4bd8330 width_2(D) 1 times vector_store costs 16 in body
0x4bd8330 x_6(D) 1 times vec_construct costs 8 in prologue
0x4bd8330 x_6(D) 1 times vector_store costs 16 in body

t.i:17:3: note:  Cost model analysis:
  Vector inside of basic block cost: 32
  Vector prologue cost: 16
  Vector epilogue cost: 0
  Scalar cost of basic block: 24
t.i:17:3: missed:  not vectorized: vectorization is not profitable.

I assume skylake-avx512 uses skylake_cost.  The only issue I see is fixed
use of [0]/[2] (SImode/SFmode) also because the cost tables do not have
entries for DImode int_load/store.

Skylake costs are odd here:

  {4, 4, 4},/* cost of loading integer registers
   in QImode, HImode and SImode.
   Relative to reg-reg move (2).  */
  {6, 6, 3},/* cost of storing integer registers */

Why is SImode store cost 3?  (looks like "benchmark" random-number generator?)

 {6, 6, 6, 10, 20},/* cost of loading SSE registers
   in 32,64,128,256 and 512-bit */
  {6, 6, 6, 10, 20},/* cost of unaligned loads.  */
  {8, 8, 8, 12, 24},/* cost of storing SSE registers
   in 32,64,128,256 and 512-bit */
  {8, 8, 8, 8, 16}, /* cost of unaligned stores.  */

again, unaligned SSE stores are cheaper than aligned ones for 256 and 512
bits?!

In the end the scalar code is not vectorized because of vector construction
cost and because the vector store cost is higher than the scalar store cost
which oddly is too cheap (3 vs. expected 6).

So - INVALID?

[Bug ipa/91447] FAIL: g++.dg/ipa/ipa-icf-4.C -std=gnu++98 scan-ipa-dump icf "(Unified; Variable alias has been created)|(Symbol aliases are not supported by target)"

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-15
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Mine.

[Bug tree-optimization/91444] [10 regression] Many ICEs starting with r274404

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
(In reply to Martin Liška from comment #1)
> Confirmed, UBSAN says:
> 
> $ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr48616.c -c
> -c
> ../../gcc/config/rs6000/rs6000.c:5566:13: runtime error: shift exponent 64
> is too large for 64-bit type 'long int'
> #0 0x29e7953 in num_insns_constant_multi
> ../../gcc/config/rs6000/rs6000.c:5566
> #1 0x29e908e in num_insns_constant(rtx_def*, machine_mode)
> ../../gcc/config/rs6000/rs6000.c:5654
> #2 0x2a0de5d in rs6000_emit_move(rtx_def*, rtx_def*, machine_mode)
> ../../gcc/config/rs6000/rs6000.c:9712
> #3 0x310242a in gen_movdi(rtx_def*, rtx_def*)
> ../../gcc/config/rs6000/rs6000.md:7135
> #4 0x118f287 in insn_gen_fn::operator()(rtx_def*, rtx_def*) const
> ../../gcc/recog.h:318
> #5 0x11399b8 in emit_move_insn_1(rtx_def*, rtx_def*)
> ../../gcc/expr.c:3695
> #6 0x113abf0 in emit_move_insn(rtx_def*, rtx_def*) ../../gcc/expr.c:3791
> #7 0x1116251 in convert_move(rtx_def*, rtx_def*, int)
> ../../gcc/expr.c:246
> #8 0x114982d in store_expr(tree_node*, rtx_def*, int, bool, bool)
> ../../gcc/expr.c:5615
> #9 0x1146fc8 in expand_assignment(tree_node*, tree_node*, bool)
> ../../gcc/expr.c:5441
> #10 0xcec66c in expand_gimple_stmt_1 ../../gcc/cfgexpand.c:3777
> #11 0xcece92 in expand_gimple_stmt ../../gcc/cfgexpand.c:3875
> #12 0xd0061e in expand_gimple_basic_block ../../gcc/cfgexpand.c:5915
> #13 0xd05228 in execute ../../gcc/cfgexpand.c:6538
> #14 0x1ad73cb in execute_one_pass(opt_pass*) ../../gcc/passes.c:2494
> #15 0x1ad7c63 in execute_pass_list_1 ../../gcc/passes.c:2580
> #16 0x1ad7db7 in execute_pass_list(function*, opt_pass*)
> ../../gcc/passes.c:2591
> #17 0xdfa021 in cgraph_node::expand() ../../gcc/cgraphunit.c:2194
> #18 0xdfc6b2 in output_in_order ../../gcc/cgraphunit.c:2438
> #19 0xdfdd01 in symbol_table::compile() ../../gcc/cgraphunit.c:2685
> #20 0xdfe78c in symbol_table::finalize_compilation_unit()
> ../../gcc/cgraphunit.c:2868
> #21 0x1ed4dac in compile_file ../../gcc/toplev.c:481
> #22 0x1edc9ae in do_compile ../../gcc/toplev.c:2190
> #23 0x1edcfdd in toplev::main(int, char**) ../../gcc/toplev.c:2325
> #24 0x3bf5469 in main ../../gcc/main.c:39
> #25 0x7fac4289fbca in __libc_start_main ../csu/libc-start.c:308
> #26 0x832969 in _start
> (/home/marxin/Programming/gcc2/objdir/gcc/cc1+0x832969)

Which is probably an unrelated issue.

[Bug c++/91445] [9 Regression] After memset, logical && operator produces false result, optimization level >=O1

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||marxin at gcc dot gnu.org

--- Comment #7 from Martin Liška  ---
Looking at the test-case #1, the issue started with r260318 and was fixed with
r273135.

[Bug tree-optimization/91444] [10 regression] Many ICEs starting with r274404

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-15
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, UBSAN says:

$ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr48616.c -c -c
../../gcc/config/rs6000/rs6000.c:5566:13: runtime error: shift exponent 64 is
too large for 64-bit type 'long int'
#0 0x29e7953 in num_insns_constant_multi
../../gcc/config/rs6000/rs6000.c:5566
#1 0x29e908e in num_insns_constant(rtx_def*, machine_mode)
../../gcc/config/rs6000/rs6000.c:5654
#2 0x2a0de5d in rs6000_emit_move(rtx_def*, rtx_def*, machine_mode)
../../gcc/config/rs6000/rs6000.c:9712
#3 0x310242a in gen_movdi(rtx_def*, rtx_def*)
../../gcc/config/rs6000/rs6000.md:7135
#4 0x118f287 in insn_gen_fn::operator()(rtx_def*, rtx_def*) const
../../gcc/recog.h:318
#5 0x11399b8 in emit_move_insn_1(rtx_def*, rtx_def*) ../../gcc/expr.c:3695
#6 0x113abf0 in emit_move_insn(rtx_def*, rtx_def*) ../../gcc/expr.c:3791
#7 0x1116251 in convert_move(rtx_def*, rtx_def*, int) ../../gcc/expr.c:246
#8 0x114982d in store_expr(tree_node*, rtx_def*, int, bool, bool)
../../gcc/expr.c:5615
#9 0x1146fc8 in expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5441
#10 0xcec66c in expand_gimple_stmt_1 ../../gcc/cfgexpand.c:3777
#11 0xcece92 in expand_gimple_stmt ../../gcc/cfgexpand.c:3875
#12 0xd0061e in expand_gimple_basic_block ../../gcc/cfgexpand.c:5915
#13 0xd05228 in execute ../../gcc/cfgexpand.c:6538
#14 0x1ad73cb in execute_one_pass(opt_pass*) ../../gcc/passes.c:2494
#15 0x1ad7c63 in execute_pass_list_1 ../../gcc/passes.c:2580
#16 0x1ad7db7 in execute_pass_list(function*, opt_pass*)
../../gcc/passes.c:2591
#17 0xdfa021 in cgraph_node::expand() ../../gcc/cgraphunit.c:2194
#18 0xdfc6b2 in output_in_order ../../gcc/cgraphunit.c:2438
#19 0xdfdd01 in symbol_table::compile() ../../gcc/cgraphunit.c:2685
#20 0xdfe78c in symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2868
#21 0x1ed4dac in compile_file ../../gcc/toplev.c:481
#22 0x1edc9ae in do_compile ../../gcc/toplev.c:2190
#23 0x1edcfdd in toplev::main(int, char**) ../../gcc/toplev.c:2325
#24 0x3bf5469 in main ../../gcc/main.c:39
#25 0x7fac4289fbca in __libc_start_main ../csu/libc-start.c:308
#26 0x832969 in _start
(/home/marxin/Programming/gcc2/objdir/gcc/cc1+0x832969)