[Bug c++/89652] New: ICE during constexpr evaluation

[dimitri.gorokhovik at free dot fr]

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

Bug ID: 89652
   Summary: ICE during constexpr evaluation
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimitri.gorokhovik at free dot fr
  Target Milestone: ---

Created attachment 45930
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45930&action=edit
Preprocessed source file proviking  the crash

Hi,

recent trunk crashes during constexpr eval (g++ (GCC) 9.0.1 20190310
(experimental))

The source code is in attachment (sorry, couldn't simplify more fast enough).
To run: ccplus1 -std=c++17 -O3 bug.cpp

The backtrace is below. It seems that the searching the hash map brings back
nullptr which is dereferenced straight away without checking -- not sure
whether nullptr is illegal value at this place.

#0  0x008f2b3b in hash_table, tree_node*>
>::hash_entry, xcallocator>::remove_elt_with_hash (this=0x7fffd650,
comparable=@0x7fffd098: 0x753aaac0, hash=) at
../../srcdir/gcc/hash-table.h:939
#1  0x008eda3e in hash_map, tree_node*> >::remove (
k=@0x7fffd098: 0x753aaac0, this=) at
../../srcdir/gcc/cp/constexpr.c:4261
#2  cxx_eval_loop_expr(constexpr_ctx const*, tree_node*, bool*, bool*,
tree_node**) () at ../../srcdir/gcc/cp/constexpr.c:4261
#3  0x008e69e5 in cxx_eval_constant_expression(constexpr_ctx const*,
tree_node*, bool, bool*, bool*, tree_node**) ()
at ../../srcdir/gcc/cp/constexpr.c:5112
#4  0x008e7a60 in cxx_eval_statement_list (jump_target=0x7fffd430,
overflow_p=0x7fffd647, non_constant_p=0x7fffd646, t=, 
ctx=0x7fffd270) at ../../srcdir/gcc/cp/constexpr.c:4142
#5  cxx_eval_constant_expression(constexpr_ctx const*, tree_node*, bool, bool*,
bool*, tree_node**) () at ../../srcdir/gcc/cp/constexpr.c:5012
#6  0x008e781b in cxx_eval_constant_expression(constexpr_ctx const*,
tree_node*, bool, bool*, bool*, tree_node**) () at ../../srcdir/gcc/tree.h:3677
#7  0x008e5ca2 in cxx_eval_call_expression(constexpr_ctx const*,
tree_node*, bool, bool*, bool*) () at ../../srcdir/gcc/cp/constexpr.c:1839
#8  0x008e6f54 in cxx_eval_constant_expression(constexpr_ctx const*,
tree_node*, bool, bool*, bool*, tree_node**) ()
at ../../srcdir/gcc/cp/constexpr.c:4495
#9  0x008edcb7 in cxx_eval_outermost_constant_expr(tree_node*, bool,
bool, bool, tree_node*) () at ../../srcdir/gcc/cp/constexpr.c:5277
#10 0x008f1039 in maybe_constant_value(tree_node*, tree_node*, bool) ()
at ../../srcdir/gcc/cp/constexpr.c:5509
#11 0x00a8b05f in store_init_value(tree_node*, tree_node*,
vec**, int) () at
../../srcdir/gcc/cp/typeck2.c:843
#12 0x009193f3 in check_initializer(tree_node*, tree_node*, int,
vec**) () at ../../srcdir/gcc/cp/decl.c:6522
#13 0x00938c4d in cp_finish_decl(tree_node*, tree_node*, bool,
tree_node*, int) () at ../../srcdir/gcc/cp/decl.c:7196
#14 0x009d43c8 in cp_parser_init_declarator(cp_parser*, int,
cp_decl_specifier_seq*, vec*, bool,
bool, int, bool*, tree_node**, unsigned int*, tree_node**) () at
../../srcdir/gcc/cp/parser.c:20468
#15 0x009b7dff in cp_parser_simple_declaration(cp_parser*, bool,
tree_node**) () at ../../srcdir/gcc/cp/parser.c:13492
#16 0x009da7a1 in cp_parser_declaration(cp_parser*) () at
../../srcdir/gcc/cp/parser.c:13189
#17 0x009daf1d in cp_parser_translation_unit (parser=0x77ff6ab0) at
../../srcdir/gcc/cp/parser.c:4698
#18 c_parse_file() () at ../../srcdir/gcc/cp/parser.c:41114
#19 0x00ae138c in c_common_parse_file () at
../../srcdir/gcc/c-family/c-opts.c:1155
#20 0x00f91cf0 in compile_file () at ../../srcdir/gcc/toplev.c:456
#21 0x008a3755 in do_compile () at ../../srcdir/gcc/toplev.c:2204
#22 toplev::main(int, char**) () at ../../srcdir/gcc/toplev.c:2339
#23 0x008a711f in main (argc=3, argv=0x7fffde08) at
../../srcdir/gcc/main.c:39

[Bug c++/89652] [9 Regression] ICE during constexpr evaluation

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-03-11
 CC||jakub at gcc dot gnu.org
Version|unknown |9.0
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |9.0
Summary|ICE during constexpr|[9 Regression] ICE during
   |evaluation  |constexpr evaluation
 Ever confirmed|0   |1

[Bug c++/89640] [9 Regression] g++ chokes on lambda with __attribute__

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Target Milestone|--- |9.0
Summary|g++ chokes on lambda with   |[9 Regression] g++ chokes
   |__attribute__   |on lambda with
   ||__attribute__

[Bug libstdc++/89641] [9 Regression] std::atomic no longer works

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |9.0
Summary|std::atomic no longer|[9 Regression]
   |works   |std::atomic no longer
   ||works

[Bug tree-optimization/89649] [9 Regression] r269458 FAILs g++.dg/pr80481.C, scan-assembler-not vmovaps

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/89650] [9 Regression] ICE in pre_and_rev_post_order_compute, at cfganal.c:1055 since r269119

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
There are unreachable blocks which are not allowed for
pre_and_rev_post_order_compute.  Somebody forgets to call cfg-cleanup here.

[Bug fortran/89651] OpenMP private array uninitialized warning with -O flag

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic, openmp,
   ||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-11
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  OMP expansion produces:

   :

   :
  D.3887 = .omp_data_i->t;
  D.3888 = D.3887->data;
  if (D.3888 != 0B)
goto ; [INV]
  else
goto ; [INV]

   :
  val.4 = 0.0;
  D.3891 = t.data;
  D.3892 = t.offset;
  D.3893 = t.dim[0].lbound;
  D.3894 = t.dim[0].ubound;
  S.5 = D.3893;

...
   :
  t.data = 0B;
  goto ; [INV]

somehow t is not localized?

[Bug fortran/89651] OpenMP private array uninitialized warning with -O flag

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=87143
 Blocks||24639

--- Comment #2 from Dominique d'Humieres  ---
Related to pr87143 and probably others.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

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

[marxin at gcc dot gnu.org]

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

--- Comment #25 from Martin Liška  ---
Author: marxin
Date: Mon Mar 11 09:37:41 2019
New Revision: 269570

URL: https://gcc.gnu.org/viewcvs?rev=269570&root=gcc&view=rev
Log:
Backport r268789

2019-03-11  Martin Liska  

Backport from mainline
2019-02-11  David Malcolm  

PR lto/88147
* input.c (selftest::test_line_offset_overflow): New selftest.
(selftest::input_c_tests): Call it.
2019-03-11  Martin Liska  

Backport from mainline
2019-02-11  Martin Liska  

PR lto/88147
* line-map.c (linemap_line_start): Don't reuse the existing line
map if the line offset is sufficiently large to cause overflow
when computing location_t values.

Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/input.c
branches/gcc-8-branch/libcpp/ChangeLog
branches/gcc-8-branch/libcpp/line-map.c

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

[marxin at gcc dot gnu.org]

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

--- Comment #24 from Martin Liška  ---
Author: marxin
Date: Mon Mar 11 09:38:06 2019
New Revision: 269572

URL: https://gcc.gnu.org/viewcvs?rev=269572&root=gcc&view=rev
Log:
Backport r269492

2019-03-11  Martin Liska  

Backport from mainline
2019-03-08  Martin Liska  

PR target/86952
* config/i386/i386.c (ix86_option_override_internal): Disable
jump tables when retpolines are used.
2019-03-11  Martin Liska  

Backport from mainline
2019-03-08  Martin Liska  

PR target/86952
* gcc.target/i386/indirect-thunk-7.c: Use jump tables to match
scanned pattern.
* gcc.target/i386/indirect-thunk-inline-7.c: Likewise.

Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/i386/i386.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/indirect-thunk-7.c
   
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/indirect-thunk-inline-7.c

[Bug c++/89383] [9 Regression] libcpp/line-map.c:748:15: runtime error: shift exponent 32 is too large for 32-bit type 'unsigned int'

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Author: marxin
Date: Mon Mar 11 09:37:52 2019
New Revision: 269571

URL: https://gcc.gnu.org/viewcvs?rev=269571&root=gcc&view=rev
Log:
Backport r268981

2019-03-11  Martin Liska  

Backport from mainline
2019-02-18  Martin Liska  

PR c++/89383
* line-map.c (linemap_line_start): Use 1UL in order
to not overflow.

Modified:
branches/gcc-8-branch/libcpp/ChangeLog
branches/gcc-8-branch/libcpp/line-map.c

[Bug target/84072] [meta-bug] -mindirect-branch=thunk issues

[marxin at gcc dot gnu.org]

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

Bug 86952 Summary: Avoid jump table for switch statement with 
-mindirect-branch=thunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86952

   What|Removed |Added

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

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||8.3.1
 Resolution|--- |FIXED
  Known to fail|8.3.0   |

--- Comment #25 from Martin Liška  ---
Fixed now.

[Bug c++/87571] [8/9 Regression] ICE in friend_accessible_p, accessing protected member of template friend inside template class

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  ---
This is fixed in trunk. I'm adding the testcase and removing the regression
marker.

[Bug c++/89653] New: Missing vectorization of loop containing std::min/std::max and temporary

[moritz.kreutzer at siemens dot com]

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

Bug ID: 89653
   Summary: Missing vectorization of loop containing
std::min/std::max and temporary
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: moritz.kreutzer at siemens dot com
  Target Milestone: ---

Godbolt worksheet: https://godbolt.org/z/F6m5hl

GCC (trunk and all earlier versions) fails to vectorize (SSE/AVX2/AVX-512) the
following loop because of a "complicated access pattern" (similarly for
std::max()):

== loop1 - FAIL 
for (int i = 0; i < end; ++i)
{
  vec[i] = std::min(vec[i], vec[i]/x);
}


If we don't use std::min(), but implement the same loop using a ternary
operator, the vectorization is successful:

== loop2 - OK ==
for (int i = 0; i < end; ++i)
{
  vec[i] = vec[i] < vec[i]/x ? vec[i] : vec[i]/x;
}


However, the problem does not seem to be that GCC is unable to vectorize
std::min() itself, because the following loop _does_ get vectorized (note the
different logic and the absence of an implicit temporary for vec[i]/x):

== loop3 - OK ==
for (int i = 0; i < end; ++i)
{
  vec[i] = std::min(vec[i], x);
}


The C++ standard prescribes that std::min() returns the result as a const
reference, so an implementation might look like this:

== std::min() ==
double const & min(double const &a, double const &b)
{
if (a

[Bug c++/89652] [9 Regression] ICE during constexpr evaluation

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Reduced testcase:

template  constexpr auto foo (T &e) { return e.foo (); }
template  constexpr auto bar (T &e) { return foo (e); }
template  struct A { typedef T a[N]; };
template  struct B {
  typedef T *b;
  typename A::a d;
  constexpr b foo () { return d; }
};
template  struct C { long m; };
struct D { long n; };
template  struct E {
  B, 1>::b p;
  constexpr D operator* () { return {p->m}; }
  constexpr E operator++ (int) { auto a{*this}; ++p; return a; }
};
template 
constexpr bool operator!= (E a, E) { return a.p; }
template 
constexpr auto baz (B s, B)
{
  B t{};
  auto q{foo (t)};
  using u = E;
  auto v = u{bar (s)};
  auto w = u{};
  while (v != w)
*q++ = *v++;
  return t;
}
constexpr auto a = B, 5>{};
auto b = B{};
auto c = baz (a, b);

[Bug target/89650] [9 Regression] ICE in pre_and_rev_post_order_compute, at cfganal.c:1055 since r269119

[crazylht at gmail dot com]

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

--- Comment #2 from 刘袋鼠  ---
(In reply to Richard Biener from comment #1)
> There are unreachable blocks which are not allowed for
> pre_and_rev_post_order_compute.  Somebody forgets to call cfg-cleanup here.

Yes, pass_split1 strip off REG_EH_REGION

before spilt1:
(insn 18 94 102 2 (set (reg:SF 88 [ _19 ])
(subreg:SF (reg:V4SF 115) 0)) "../partial.i":4:20 112 {*movsf_internal}
 (expr_list:REG_EH_REGION (const_int 2 [0x2])
(nil)))

after split1:
(insn 18 94 102 2 (set (reg:SF 88 [ _19 ])
(subreg:SF (reg:V4SF 115) 0)) "../partial.i":4:20 112 {*movsf_internal}
 (nil))

but didn't cleanup_cfg, It's said in recog.c:

3017  default_rtl_profile ();   
3018  if (changed)  
3019{   
3020  find_many_sub_basic_blocks (blocks);  
3021
3022  /* Splitting could drop an REG_EH_REGION if it potentially
3023 trapped in its original form, but does not in its split
3024 form.  Consider a FLOAT_TRUNCATE which splits into a memory
3025 store/load pair and -fnon-call-exceptions.  */ 
3026=>if (need_cfg_cleanup) 
3027cleanup_cfg (0);
3028}   
3029
3030  checking_verify_flow_info (); 
3031}

[Bug c++/87571] [8/9 Regression] ICE in friend_accessible_p, accessing protected member of template friend inside template class

[paolo at gcc dot gnu.org]

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

--- Comment #5 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Mar 11 10:30:24 2019
New Revision: 269575

URL: https://gcc.gnu.org/viewcvs?rev=269575&root=gcc&view=rev
Log:
2019-03-11  Paolo Carlini  

PR c++/87571
* g++.dg/template/memfriend18.C: New.

Added:
trunk/gcc/testsuite/g++.dg/template/memfriend18.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/87571] [8 Regression] ICE in friend_accessible_p, accessing protected member of template friend inside template class

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[8/9 Regression] ICE in |[8 Regression] ICE in
   |friend_accessible_p,|friend_accessible_p,
   |accessing protected member  |accessing protected member
   |of template friend inside   |of template friend inside
   |template class  |template class

--- Comment #6 from Paolo Carlini  ---
Done.

[Bug c++/86521] [8/9 Regression] GCC 8 selects incorrect overload of ref-qualified conversion operator template

[matthijsvanduin at gmail dot com]

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

Matthijs van Duin  changed:

   What|Removed |Added

 CC||matthijsvanduin at gmail dot 
com

--- Comment #3 from Matthijs van Duin  ---
First off, your example is more complicated than it needs to be. A more minimal
test case would be:

#include 

struct Dest {
Dest() = default;
Dest( Dest && ) = default;
Dest( Dest const & ) = delete;
};

struct Source {
Dest val;
operator Dest () && {
return std::move( val );
}
operator Dest const & () const & {
return val;
}
};

int main() {
Source x;
static_cast( std::move( x ) );
}


Second, notice that the two conversions are not really directly comparable
since one converts to directly Dest while the other converts to an expression
used to invoke a constructor of Dest. While it seems desirable for the former
to take preference over the latter, I'm not enough of a language lawyer to be
able to figure out what the C++ standard actually requires overload resolution
to do in this situation.

Replacing
operator Dest () && {
by
operator Dest && () && {
fixes the problem, and has the additional benefit of avoiding unnecessary
temporary materialization in situations like:

void foo( Dest && );
int main() {
Source x;
foo( std::move( x ) );
}

[Bug tree-optimization/89653] Missing vectorization of loop containing std::min/std::max and temporary

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-03-11
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
The issue is D.17094 appearantly introduced by the recip pass.

   [local count: 955630224]:
  # i_20 = PHI 
  _1 = (long unsigned int) i_20;
  _2 = _1 * 8;
  _3 = vec_11(D) + _2;
  _4 = *_3;
  _5 = reciptmp_8 * _4;
  D.17094 = _5;
  prephitmp_29 = MIN_EXPR <_4, _5>;
  *_3 = prephitmp_29;
  D.17094 ={v} {CLOBBER};
  i_16 = i_20 + 1;
  if (end_10(D) <= i_16)

[Bug tree-optimization/89653] Missing vectorization of loop containing std::min/std::max and temporary

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Oh, no.  It is present even in .original and we somehow fail to elide it (maybe
because of the clobber?!

;; Function void loop1(double*, double, int) (null)
;; enabled by -tree-original


{
  {
int i = 0;

<>;
while (1)
  {
if (i >= end) goto ;
< ((const double &) vec + (sizetype) ((long unsigned
int) i * 8), (const double &) &TARGET_EXPR )) >;
<>;
  }
:;
  }
}

[Bug tree-optimization/89653] Missing vectorization of loop containing std::min/std::max and temporary

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Ah, OK.  So our special pass to deal with std::min taking arguments by
reference
is "confused" enough by

  _4 = *_3;  // vec[i]
  D.17247 = _5;
  if (_4 > _5)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 324914276]:

   [local count: 955630225]:
  # _17 = PHI <_3(4), &D.17247(5)>
  _6 = *_17;

the pass tries to replace the dereference in BB6 but fails on the 4->6
edge where it thinks placing *_3 on it isn't profitable.

Only the if-conversion phase in the vectorizer will then recognize the
MIN_EXPR operation but it is too late to get rid of the "memory" temporary
involved here.

Note that PRE performs what the special phiprop could have done, but it
leaves the dead memory operation around, which the DCE that's there cannot
remove because D.17094 still appears to have its address taken.

  _5 = reciptmp_8 * _4;
  D.17094 = _5;
  if (_4 > _5)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 630715944]:

   [local count: 955630224]:
  # prephitmp_29 = PHI <_5(5), _4(6)>
  *_3 = prephitmp_29;
  D.17094 ={v} {CLOBBER};

there are plenty DCE passes between this and vectorization but no DSE
which would fix it up and also no update-address-taken.
Doing this after PRE is too early (the PHI with the address-taking is
still in the IL), doing it after each DCE might be a (somewhat costly) option.

I also have a patch to make the above catched in phiprop.

[Bug tree-optimization/89653] Missing vectorization of loop containing std::min/std::max and temporary

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Created attachment 45931
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45931&action=edit
untested phiprop patch

Patch making phiprop hoist the load through the PHI.

[Bug tree-optimization/89653] Missing vectorization of loop containing std::min/std::max and temporary

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Created attachment 45932
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45932&action=edit
untested DCE patch

Patch cleaning up after PRE via TODO_update_address_taken from (each) DCE.

[Bug rtl-optimization/89654] New: Invalid reload with -march=skylake -m32

[ubizjak at gmail dot com]

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

Bug ID: 89654
   Summary: Invalid reload with -march=skylake -m32
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

Following testcase:

--cut here--
unsigned long long
foo (unsigned long long i)
{
  return i << 3;
}
--cut here--

compiles with -O2 -march=skylake -m32 to:

subl$28, %esp
movl32(%esp), %eax
movl36(%esp), %edx
movl%eax, (%esp)
movl%edx, 4(%esp)
vmovdqa (%esp), %xmm1<--- here
addl$28, %esp
vpsllq  $3, %xmm1, %xmm0
vmovd   %xmm0, %eax
vpextrd $1, %xmm0, %edx
ret

Please note 128bit access to a 64bit stack slot, in addition to unnecessary
moves.

In _.ira, we have:

(insn 2 4 3 2 (set (reg/v:DI 83 [ i ])
(mem/c:DI (reg/f:SI 16 argp) [1 i+0 S8 A32])) "vshift.c":3:1 66
{*movdi_internal}
 (nil))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(insn 6 3 14 2 (set (subreg:V2DI (reg:DI 84) 0)
(ashift:V2DI (subreg:V2DI (reg/v:DI 83 [ i ]) 0)
(const_int 3 [0x3]))) "vshift.c":4:12 3353 {ashlv2di3}
 (expr_list:REG_DEAD (reg/v:DI 83 [ i ])
(nil)))
...

and in _.reload:

(insn 2 4 19 2 (set (reg/v:DI 0 ax [orig:83 i ] [83])
(mem/c:DI (plus:SI (reg/f:SI 7 sp)
(const_int 32 [0x20])) [1 i+0 S8 A32])) "vshift.c":3:1 66
{*movdi_internal}
 (nil))
(insn 19 2 3 2 (set (mem/c:DI (reg/f:SI 7 sp) [2 %sfp+-16 S8 A128])
(reg/v:DI 0 ax [orig:83 i ] [83])) "vshift.c":3:1 66 {*movdi_internal}
 (nil))
(note 3 19 20 2 NOTE_INSN_FUNCTION_BEG)
(insn 20 3 6 2 (set (reg:V2DI 21 xmm1 [89])
(mem/c:V2DI (reg/f:SI 7 sp) [2 %sfp+-16 S16 A128])) "vshift.c":4:12
1211 {movv2di_internal}
 (nil))
(insn 6 20 14 2 (set (reg:V2DI 20 xmm0 [84])
(ashift:V2DI (reg:V2DI 21 xmm1 [89])
(const_int 3 [0x3]))) "vshift.c":4:12 3353 {ashlv2di3}
 (nil))
...

Please note (insn 19) and (insn 20), where DImode value in a DImode stack slot
is loaded using V2DImode instruction.

Using -O2 -march=skylake-avx512 -m32, we get:

subl$28, %esp
movl32(%esp), %eax
movl36(%esp), %edx
movl%eax, (%esp)
movl%edx, 4(%esp)
vpsllq  $3, (%esp), %xmm0
addl$28, %esp
vmovd   %xmm0, %eax
vpextrd $1, %xmm0, %edx
ret

which is even more wrong, as V2DI move is propagated into the shift insn.

However, with -O2 -march=haswell -m32, everything works as expected:

vmovq   4(%esp), %xmm0
vpsllq  $3, %xmm0, %xmm0
vmovd   %xmm0, %eax
vpextrd $1, %xmm0, %edx
ret

[Bug c++/89383] [9 Regression] libcpp/line-map.c:748:15: runtime error: shift exponent 32 is too large for 32-bit type 'unsigned int'

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Mon Mar 11 11:18:22 2019
New Revision: 269577

URL: https://gcc.gnu.org/viewcvs?rev=269577&root=gcc&view=rev
Log:
Backport r268981

2019-03-11  Martin Liska  

Backport from mainline
2019-02-18  Martin Liska  

PR c++/89383
* line-map.c (linemap_line_start): Use 1UL in order
to not overflow.

Modified:
branches/gcc-7-branch/libcpp/ChangeLog
branches/gcc-7-branch/libcpp/line-map.c

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

[marxin at gcc dot gnu.org]

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

--- Comment #26 from Martin Liška  ---
Author: marxin
Date: Mon Mar 11 11:18:08 2019
New Revision: 269576

URL: https://gcc.gnu.org/viewcvs?rev=269576&root=gcc&view=rev
Log:
Backport r268789

2019-03-11  Martin Liska  

Backport from mainline
2019-02-11  David Malcolm  

PR lto/88147
* input.c (selftest::test_line_offset_overflow): New selftest.
(selftest::input_c_tests): Call it.
2019-03-11  Martin Liska  

Backport from mainline
2019-02-11  Martin Liska  

PR lto/88147
* line-map.c (linemap_line_start): Don't reuse the existing line
map if the line offset is sufficiently large to cause overflow
when computing location_t values.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/input.c
branches/gcc-7-branch/libcpp/ChangeLog
branches/gcc-7-branch/libcpp/line-map.c

[Bug c/85870] [LTO1] ICE in linemap_line_start, at libcpp/line-map.c:794

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||7.4.1
 Resolution|--- |FIXED
Summary|[7 Regression][LTO1] ICE in |[LTO1] ICE in
   |linemap_line_start, at  |linemap_line_start, at
   |libcpp/line-map.c:794   |libcpp/line-map.c:794
  Known to fail|7.4.0   |

--- Comment #18 from Martin Liška  ---
Fixed now.

[Bug tree-optimization/89649] [9 Regression] r269458 FAILs g++.dg/pr80481.C, scan-assembler-not vmovaps

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Mon Mar 11 11:31:05 2019
New Revision: 269578

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

PR tree-optimization/89649
* tree-vectorizer.h (vect_loop_versioning): Adjust prototype.
* tree-vect-loop-manip.c (vect_do_peeling): Unset force_vectorize
on the prolog and epilog loops.
(vect_loop_versioning): Return copy of loop.
* tree-vect-loop.c (vect_transform_loop): Unset force_vectorize
on the non-vectorized version of the loop.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-loop-manip.c
trunk/gcc/tree-vect-loop.c
trunk/gcc/tree-vectorizer.h

[Bug tree-optimization/89649] [9 Regression] r269458 FAILs g++.dg/pr80481.C, scan-assembler-not vmovaps

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/89618] Inner loop won't vectorize unless dummy statement is included

[rguenth at gcc dot gnu.org]

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

Bug 89649 Summary: [9 Regression] r269458 FAILs g++.dg/pr80481.C, 
scan-assembler-not vmovaps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89649

   What|Removed |Added

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

[Bug middle-end/89655] New: GCC crashes building linux kernel for arm 32-bit (culprit r269453)

[mkuvyrkov at gcc dot gnu.org]

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

Bug ID: 89655
   Summary: GCC crashes building linux kernel for arm 32-bit
(culprit r269453)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mkuvyrkov at gcc dot gnu.org
  Target Milestone: ---

Created attachment 45933
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45933&action=edit
Reproducer tarball

After r269453 GCC ICEs when building linux kernel for AArch32 in allmodconfig
and allyesconfig kernel configurations.

I've reduced the crash down to a single preprocessed file, but could not
eliminate all kernel plugins -- one plugin is still left.

The attached tarball has preprocessed source, binary plugin and GCC's
configuration string.

Culprit:

commit 791a496442cb02f7ab6b50e291e1f0669e09e99d
Author: rguenth 
Date:   Thu Mar 7 12:46:44 2019 +

   2019-03-07  Richard Biener  

PR tree-optimization/89595
* tree-ssa-dom.c (dom_opt_dom_walker::optimize_stmt): Take
stmt iterator as reference, take boolean output parameter to
indicate whether the stmt was removed and thus the iterator
already advanced.
(dom_opt_dom_walker::before_dom_children): Re-iterate over
stmts created by folding.

* gcc.dg/torture/pr89595.c: New testcase.


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


Reproduction instructions from Linaro TCWG's automated bisections (just in
case):
Reproduce builds:

mkdir investigate-gcc-791a496442cb02f7ab6b50e291e1f0669e09e99d
cd investigate-gcc-791a496442cb02f7ab6b50e291e1f0669e09e99d

git clone https://git.linaro.org/toolchain/jenkins-scripts

mkdir -p artifacts/manifests
curl -o artifacts/manifests/build-baseline.sh
https://ci.linaro.org/job/tcwg_kernel-bisect-gnu-master-arm-lts-allyesconfig/11/artifact/artifacts/manifests/build-baseline.sh
curl -o artifacts/manifests/build-parameters.sh
https://ci.linaro.org/job/tcwg_kernel-bisect-gnu-master-arm-lts-allyesconfig/11/artifact/artifacts/manifests/build-parameters.sh
curl -o artifacts/test.sh
https://ci.linaro.org/job/tcwg_kernel-bisect-gnu-master-arm-lts-allyesconfig/11/artifact/artifacts/test.sh
chmod +x artifacts/test.sh

# Reproduce the baseline build (build all pre-requisites)
./jenkins-scripts/tcwg_kernel-build.sh @@ artifacts/manifests/build-baseline.sh

cd gcc

# Reproduce first_bad build
git checkout --detach 791a496442cb02f7ab6b50e291e1f0669e09e99d
../artifacts/test.sh

# Reproduce last_good build
git checkout --detach 02a7fc594d3a0b1f2b2fc8d5fd8ea425ff45d418
../artifacts/test.sh

cd ..

[Bug middle-end/89655] GCC crashes building linux kernel for arm 32-bit (culprit r269453)

[mkuvyrkov at gcc dot gnu.org]

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

Maxim Kuvyrkov  changed:

   What|Removed |Added

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

--- Comment #1 from Maxim Kuvyrkov  ---
Hi Richi,

Would you please investigate?  Ping me on IRC (maximk) if you have problems
with reproducing the ICE.

[Bug tree-optimization/89653] Missing vectorization of loop containing std::min/std::max and temporary

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Created attachment 45934
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45934&action=edit
patch I am testing

And this one I am testing, executing update-address-taken from loop_init
(thus one time extra only).

[Bug rtl-optimization/89588] [8/9 Regression] ICE in unroll_loop_constant_iterations, at loop-unroll.c:498

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon Mar 11 11:37:46 2019
New Revision: 269579

URL: https://gcc.gnu.org/viewcvs?rev=269579&root=gcc&view=rev
Log:
PR rtl-optimization/89588
* loop-unroll.c (decide_unroll_constant_iterations): Make guard for
explicit unrolling factor more robust.

Added:
trunk/gcc/testsuite/c-c++-common/unroll-6.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/loop-unroll.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/89588] [8/9 Regression] ICE in unroll_loop_constant_iterations, at loop-unroll.c:498

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon Mar 11 11:40:11 2019
New Revision: 269580

URL: https://gcc.gnu.org/viewcvs?rev=269580&root=gcc&view=rev
Log:
PR rtl-optimization/89588
* loop-unroll.c (decide_unroll_constant_iterations): Make guard for
explicit unrolling factor more robust.

Added:
branches/gcc-8-branch/gcc/testsuite/c-c++-common/unroll-6.c
  - copied unchanged from r269579,
trunk/gcc/testsuite/c-c++-common/unroll-6.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/loop-unroll.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/89588] [8/9 Regression] ICE in unroll_loop_constant_iterations, at loop-unroll.c:498

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #8 from Eric Botcazou  ---
.

[Bug middle-end/89655] GCC crashes building linux kernel for arm 32-bit (culprit r269453)

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Can you provide the GCC ICE backtrace?  I suspect it's the same thing Jakub
sees.

[Bug libstdc++/89641] [9 Regression] std::atomic no longer works

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Mon Mar 11 11:49:13 2019
New Revision: 269582

URL: https://gcc.gnu.org/viewcvs?rev=269582&root=gcc&view=rev
Log:
PR libstdc++/89641
* include/std/atomic (atomic::store, atomic::load,
atomic::exchange, atomic::compare_exchange_weak,
atomic::compare_exchange_strong): Cast __m or __s and __f to int.
* include/bits/atomic_base.h (__atomic_base::operator++,
__atomic_base::operator--, __atomic_base::operator+=,
__atomic_base::operator-=, __atomic_base::operator&=,
__atomic_base::operator|=, __atomic_base::operator^=,
__atomic_base::operator++, __atomic_base::operator--,
__atomic_base::operator+=, __atomic_base::operator-=): Cast
memory_order_seq_cst to int.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/atomic_base.h
trunk/libstdc++-v3/include/std/atomic

[Bug middle-end/89655] GCC crashes building linux kernel for arm 32-bit (culprit r269453)

[mkuvyrkov at gcc dot gnu.org]

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

--- Comment #3 from Maxim Kuvyrkov  ---
ICE backtrace:
*** WARNING *** there are active plugins, do not report this as a bug unless
you can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_ATTRIBUTES| latent_entropy_plugin
PLUGIN_START_UNIT| latent_entropy_plugin
during GIMPLE pass: vrp
net/6lowpan/nhc.c: In function  lowpan_nhc_do_uncompression :
net/6lowpan/nhc.c:157:5: internal compiler error: in min_value, at
wide-int.cc:332
0xf4e9ee wi::min_value(unsigned int, signop)
   
/home/maxim.kuvyrkov/tcwg_kernel-gnu/abe/snapshots/gcc.git~master/gcc/wide-int.cc:332
0xe33c2c set_range_info(tree_node*, value_range_kind,
generic_wide_int > const&,
generic_wide_int > const&)
   
/home/maxim.kuvyrkov/tcwg_kernel-gnu/abe/snapshots/gcc.git~master/gcc/tree-ssanames.c:384
0xe34056 set_range_info(tree_node*, value_range_base const&)
   
/home/maxim.kuvyrkov/tcwg_kernel-gnu/abe/snapshots/gcc.git~master/gcc/tree-ssanames.c:408
0xeacb5a vrp_prop::vrp_finalize(bool)
   
/home/maxim.kuvyrkov/tcwg_kernel-gnu/abe/snapshots/gcc.git~master/gcc/tree-vrp.c:6692
0xebda8e execute_vrp
   
/home/maxim.kuvyrkov/tcwg_kernel-gnu/abe/snapshots/gcc.git~master/gcc/tree-vrp.c:6780
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug bootstrap/89656] New: [9 Regression] profiledbootstrap failure on aarch64-linux since r269453

[jakub at gcc dot gnu.org]

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

Bug ID: 89656
   Summary: [9 Regression] profiledbootstrap failure on
aarch64-linux since r269453
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

aarch64-linux profiledbootstrap --enable-checking=release currently fails:
/builddir/build/BUILD/gcc-9.0.1-20190309/obj-aarch64-redhat-linux/./prev-gcc/xg++
-B/builddir/build/BUILD/gcc-9.0.1-20190309/obj-aarch64-redhat-linux/./prev-gcc/
-B/usr/aarch64-redhat-linux/bin/ -nostdinc++
-B/builddir/build/BUILD/gcc-9.0.1-20190309/obj-aarch64-redhat-linux/prev-aarch64-redhat-linux/libstdc++-v3/src/.libs
-B/builddir/build/BUILD/gcc-9.0.1-20190309/obj-aarch64-redhat-linux/prev-aarch64-redhat-linux/libstdc++-v3/libsupc++/.libs

-I/builddir/build/BUILD/gcc-9.0.1-20190309/obj-aarch64-redhat-linux/prev-aarch64-redhat-linux/libstdc++-v3/include/aarch64-redhat-linux

-I/builddir/build/BUILD/gcc-9.0.1-20190309/obj-aarch64-redhat-linux/prev-aarch64-redhat-linux/libstdc++-v3/include
 -I/builddir/build/BUILD/gcc-9.0.1-20190309/libstdc++-v3/libsupc++
-L/builddir/build/BUILD/gcc-9.0.1-20190309/obj-aarch64-redhat-linux/prev-aarch64-redhat-linux/libstdc++-v3/src/.libs
-L/builddir/build/BUILD/gcc-9.0.1-20190309/obj-aarch64-redhat-linux/prev-aarch64-redhat-linux/libstdc++-v3/libsupc++/.libs
-c   -O2 -g -Wall -Wformat-security -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
-fstack-protector-strong -grecord-gcc-switches -fasynchronous-unwind-tables
-fstack-clash-protection -fprofile-use -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-DGENERATOR_FILE -fno-PIE -I. -Ibuild -I../../gcc -I../../gcc/build
-I../../gcc/../include  -I../../gcc/../libcpp/include  \
-o build/genoutput.o ../../gcc/genoutput.c
virtual memory exhausted: Cannot allocate memory

The problem is that during dom when processing:
 [count: 0]:
# p0_9 = PHI <""(93)>
# DEBUG p0 => ""
# DEBUG BEGIN_STMT
# DEBUG D#80 => MEM[(struct operand_data *)d_28(D) + 72B].predicate
# DEBUG p1 => D#80
# DEBUG BEGIN_STMT
# DEBUG p1 => pretmp_83
# DEBUG BEGIN_STMT
_81 = strcmp (p0_9, pretmp_83);
if (_81 != 0)
  goto ; [42.83%]
else
  goto ; [57.17%]
we fold_stmt
_81 = strcmp (p0_9, pretmp_83);
into
_17 = MEM[(const unsigned char * {ref-all})pretmp_83];
_167 = (int) _17;
_81 = -_167;
but vr_values has been constructed with num_vr_values of 167 and when we try to
optimize_stmt the folded _167 = (int) _17, we first ask for value range of _167
and get:
  /* If we query the range for a new SSA name return an unmodifiable VARYING.
 We should get here at most from the substitute-and-fold stage which
 will never try to change values.  */
  if (ver >= num_vr_values)
return CONST_CAST (value_range *, &vr_const_varying);
and then update_value_range to the [0, 255] range derived from the stmt.  That
modifies the shared const vr_const_varying variable and all goes wrong from
there.

[Bug bootstrap/89656] [9 Regression] profiledbootstrap failure on aarch64-linux since r269453

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-03-11
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug bootstrap/89656] [9 Regression] profiledbootstrap failure on aarch64-linux since r269453

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug c++/89657] New: ICE when calling lambda returning requires-expression

[jason.e.cobb at gmail dot com]

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

Bug ID: 89657
   Summary: ICE when calling lambda returning requires-expression
   Product: gcc
   Version: c++-concepts
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason.e.cobb at gmail dot com
  Target Milestone: ---

In the code:
auto x = [](){
return requires() {
1;
};
}();

When compiling with trunk as of 2019-03-10, GCC fails with an internal compiler
error:
: In instantiation of ' [with int  = 0]':

:5:3:   required from here

:5:1: internal compiler error: tree check: expected tree that contains
'typed' structure, have 'simple_req' in copy_tree_body_r, at tree-inline.c:1325

5 | }();

  | ^

Show on Compiler Explorer: https://gcc.godbolt.org/z/jwasQ9

[Bug c++/89657] ICE when calling lambda returning requires-expression

[jason.e.cobb at gmail dot com]

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

--- Comment #1 from Jason Cobb  ---
(In reply to Jason Cobb from comment #0)
> In the code:
> auto x = [](){
> return requires() {
> 1;
> };
> }();
> 
> When compiling with trunk as of 2019-03-10, GCC fails with an internal
> compiler error:
> : In instantiation of ' [with int  = 0]':
> 
> :5:3:   required from here
> 
> :5:1: internal compiler error: tree check: expected tree that
> contains 'typed' structure, have 'simple_req' in copy_tree_body_r, at
> tree-inline.c:1325
> 
> 5 | }();
> 
>   | ^
> 
> Show on Compiler Explorer: https://gcc.godbolt.org/z/jwasQ9

Sorry, clarification: the contents of the requires-expression do not matter,
any requires-expression causes this issue.

[Bug middle-end/89655] GCC crashes building linux kernel for arm 32-bit (culprit r269453)

[dcb314 at hotmail dot com]

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

--- Comment #4 from David Binderman  ---
I can seen a similar ice when using -O3 on x86_64. It seems to go wrong 
between revisions 269450 and 269500. 

I've got a single file that demonstrates the problem.
Reducing now.

[Bug middle-end/89655] GCC crashes building linux kernel for arm 32-bit (culprit r269453)

[dcb314 at hotmail dot com]

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

--- Comment #5 from David Binderman  ---
a, b, d;
char *c;
e() {
  int f = a;
  for (;;) {
f = 0;
for (; f < (a > 3 ?: a); f++)
  b = c[f] ? c[(f + 2 > a - 1 ? a - 1 : 2) * d] : 0;
  }
}

$ ~/gcc/results/bin/gcc -c -O3 -w bug509.c
during GIMPLE pass: vrp
bug509.c: In function ‘e’:
bug509.c:3:1: internal compiler error: in min_value, at wide-int.cc:332
3 | e() {
  | ^
0x75094c wi::min_value(unsigned int, signop)
../../trunk/gcc/wide-int.cc:332
0x109bdeb set_range_info(tree_node*, value_range_kind,
generic_wide_int > const&,
generic_wide_int > const&)
../../trunk/gcc/tree-ssanames.c:384
0x109c2ea set_range_info(tree_node*, value_range_base const&)
../../trunk/gcc/tree-ssanames.c:408
0x1123bf2 vrp_prop::vrp_finalize(bool)
../../trunk/gcc/tree-vrp.c:6692
0x1130844 execute_vrp
../../trunk/gcc/tree-vrp.c:6780

[Bug go/89447] libgo largefile support is incomplete and inconsistent

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #6 from Ian Lance Taylor  ---
> I've committed a version of your patch, which I hope will fix all the 
> problems.
>  Please let me know if not.

I've just bootstrapped with your patch on i386-pc-solaris2.11 and
sparc-sun-solaris2.11: no regressions.  Besides, I've checked for calls
to libc functions with largefile equivalent in libgo: on i386 there's
only ftruncate and mkstemp (from libffi), here and on sparc there's also
mmap, as mentioned in the PR.  Given that they use the non-largefile
types, those should be fine.

> One change to your patch in particular was that we shouldn't need a C version
> of __go_openat64.  It should suffice to use just __go_openat, since the C code
> should call the right function anyhow.  The bug was that
> libgo/go/internal/syscall/unix/at.go was referring to openat when it should
> have been referring to __go_openat.

I hadn't thought that fully through indeed; that's why I just attached my
preliminary patch to the PR instead of just submitting it to gcc-patches.

Thanks for fixing things up.

Rainer

[Bug c++/89643] constexpr capture not working inside expression

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug c++/89640] [9 Regression] g++ chokes on lambda with __attribute__

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
This is accepted:

  []() [[gnu::noinline,gnu::cold]] 

but it warns that the attributes are ignored, which still isn't right.

[Bug libstdc++/89641] [9 Regression] std::atomic no longer works

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jakub Jelinek from comment #1)
> I think the following patch should fix it, but if these issues didn't show
> up (for all the changed spots) in some test when libstdc++ is tested in
> c++2a mode, then we need better testsuite coverage for this.

The testsuite isn't run in c++2a mode routinely, only when I remember to do it
(which hasn't happened since the std::memory_order changes went in).

[Bug middle-end/89655] GCC crashes building linux kernel for arm 32-bit (culprit r269453)

[mkuvyrkov at gcc dot gnu.org]

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

Maxim Kuvyrkov  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Maxim Kuvyrkov  ---
Jakub's patch in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89656 fixes ICE
on linux kernel for arm.

[Bug bootstrap/89656] [9 Regression] profiledbootstrap failure on aarch64-linux since r269453

[mkuvyrkov at gcc dot gnu.org]

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

Maxim Kuvyrkov  changed:

   What|Removed |Added

 CC||mkuvyrkov at gcc dot gnu.org

--- Comment #2 from Maxim Kuvyrkov  ---
Hi Jakub,

The above patch fixes ICE on building linux kernel for arm
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89655)

[Bug bootstrap/89656] [9 Regression] profiledbootstrap failure on aarch64-linux since r269453

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #45935|0   |1
is obsolete||

--- Comment #3 from Jakub Jelinek  ---
Created attachment 45936
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45936&action=edit
gcc9-pr89656.patch

Updated patch with the reduced testcase from PR89655.

[Bug libstdc++/89629] std::hash segfault for long strings

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Mon Mar 11 13:46:05 2019
New Revision: 269584

URL: https://gcc.gnu.org/viewcvs?rev=269584&root=gcc&view=rev
Log:
PR libstdc++/89629 fix _Hash_bytes for lengths > INT_MAX

PR libstdc++/89629
* libsupc++/hash_bytes.cc [__SIZEOF_SIZE_T__ == 8] (_Hash_bytes):
Use correct type for len_aligned.
* testsuite/20_util/hash/89629.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/20_util/hash/89629.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/libsupc++/hash_bytes.cc

[Bug target/87561] [9 Regression] 416.gamess is slower by ~10% starting from r264866 with -Ofast

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Re-checking today we reject AVX vectorization via the costmodel but do
SSE vectorization.  With versioning for alias we could also SLP vectorize this,
keeping the loop body smaller and avoiding an epilogue.  Esp. since we're
ending up without any vector load or store anyway.

Of course SLP analysis requires a grouped store which we do not have since
we do not identify XPQKL(MPQ,MKL) and XPQKL(MRS,MKL) as such (they ain't
with MPQ == MRS but the runtime alias check ensures that's not the case).
That is, we miss "strided group" detection or in general SLP forming via
different mechanism.

That said, I have a hard time thinking of a heuristic aligning with reality
(it's of course possible to come up with a hack).

Generally we'd need to work towards doing the versioning / cost model checks
on outer loops but the better versioning condition thing would be a
prerequesite for this.

I'm out of ideas suitable for GCC 9 (besides reverting the patch, reverting
to bogus state).

Scalar inner loop assembly:

.L8:
vmulsd  (%rax,%rdi,8), %xmm3, %xmm0
incl%ecx
vfmadd231sd (%rax), %xmm4, %xmm0
vfmadd213sd (%rdx), %xmm6, %xmm0
vmovsd  %xmm0, (%rdx)
vmulsd  (%rax,%r8,8), %xmm1, %xmm0
vfmadd231sd (%rax,%r10,8), %xmm2, %xmm0
addq%r15, %rax
vfmadd213sd (%rdx,%rsi,8), %xmm5, %xmm0
vmovsd  %xmm0, (%rdx,%rsi,8)
addq%rbp, %rdx
cmpl%r9d, %ecx
jne .L8

vectorized inner loop assembly:

.L9:
vmovsd  (%r10,%rcx), %xmm13
vmovsd  (%rdx), %xmm0
incl%r14d
vmovhpd (%r10,%rsi), %xmm13, %xmm13
vmovhpd (%rdx,%r13), %xmm0, %xmm14
vmovsd  (%rdi,%rcx), %xmm0
vmulpd  %xmm9, %xmm13, %xmm13
vmovhpd (%rdi,%rsi), %xmm0, %xmm0
vfmadd132pd %xmm10, %xmm13, %xmm0
vfmadd132pd %xmm12, %xmm14, %xmm0
vmovlpd %xmm0, (%rdx)
vmovhpd %xmm0, (%rdx,%r13)
vmovsd  (%r8,%rcx), %xmm13
vmovsd  (%rax), %xmm0
addq%r11, %rdx
vmovhpd (%r8,%rsi), %xmm13, %xmm13
vmovhpd (%rax,%r13), %xmm0, %xmm14
vmovsd  (%r9,%rcx), %xmm0
addq%rbx, %rcx
vmulpd  %xmm7, %xmm13, %xmm13
vmovhpd (%r9,%rsi), %xmm0, %xmm0
addq%rbx, %rsi
vfmadd132pd %xmm8, %xmm13, %xmm0
vfmadd132pd %xmm11, %xmm14, %xmm0
vmovlpd %xmm0, (%rax)
vmovhpd %xmm0, (%rax,%r13)
addq%r11, %rax
cmpl%r14d, %r15d
jne .L9

only outer loop context and knowledge of low trip count makes this bad.

The cost modeling doesn't know the scalar loop can execute like if
vectorized given the CPUs plenty of resources (speculating
non-dependence), whereas the vector variant introduces more constraints
to the pipelining due to data dependences from using vectors.  But
even IACA doesn't tell us the differences are big.

[Bug c++/89640] [9 Regression] g++ chokes on lambda with __attribute__

[redbeard0531 at gmail dot com]

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

--- Comment #2 from Mathias Stearn  ---
Unfortunately the c++ attributes syntax applies to the lambda type rather than
the function, so the warning is correct. The old style __attribute__ syntax
seems to be the only way to annotate the lambda function, which is why we use
it here. We use something like this in a macro around code that builds error
messages on our error paths, which is why it needs to be on a lambda. It made a
notable shrink to the size of our primary .text section moving that stuff out
to the .text.cold section.

[Bug c++/86521] [8/9 Regression] GCC 8 selects incorrect overload of ref-qualified conversion operator template

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-03-11
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug libstdc++/89629] std::hash segfault for long strings

[redi at gcc dot gnu.org]

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

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

[Bug c++/89652] [9 Regression] ICE during constexpr evaluation

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 45937
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45937&action=edit
gcc9-pr89652.patch

IMHO either we need to do what this patch does, i.e. only remove SAVE_EXPRs
that are in new_ctx.values, or we should save_exprs.empty (); after:
  /* Forget saved values of SAVE_EXPRs.  */
  for (hash_set::iterator iter = save_exprs.begin();
   iter != save_exprs.end(); ++iter)
new_ctx.values->remove (*iter);
loop in cxx_eval_loop_expr.  Arguably my patch made things worse, in that there
is this loop and one at the end of function, on the other side before that it
was a latent thing, e.g. if some SAVE_EXPRs are encountered only during certain
iterations of a loop and not others, if we never remove anything from
save_exprs, we'll keep adding all SAVE_EXPRs ever encountered, but then try to
remove even those that were already removed.
Or, yet another option might be change save_exprs into a vec and always
truncate the vec after traversing it for removal from values.

[Bug rtl-optimization/89654] [8/9 Regression] Invalid reload with -march=skylake -m32

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-11
 CC||hjl.tools at gmail dot com,
   ||jakub at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
   Target Milestone|--- |8.4
Summary|Invalid reload with |[8/9 Regression] Invalid
   |-march=skylake -m32 |reload with -march=skylake
   ||-m32
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
7.x emits with -O2 -march=skylake -m32 following:
pushl   %ebx
movl8(%esp), %ecx
movl12(%esp), %ebx
movl%ecx, %eax
movl%ebx, %edx
sall$3, %eax
popl%ebx
shldl   $3, %ecx, %edx
ret
so seems to be fine.

[Bug sanitizer/85777] [7/8/9 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
That is not true, automake is highly customizable, you can e.g. override
COMPILE/LTCOMPILE variables in Makefile.am or something similar.

[Bug c/89658] New: __BASE_FILE__ is not preserved when using -fdirectives-only

[jpewhacker at gmail dot com]

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

Bug ID: 89658
   Summary: __BASE_FILE__ is not preserved when using
-fdirectives-only
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jpewhacker at gmail dot com
  Target Milestone: ---

Created attachment 45938
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45938&action=edit
test.c

When using "-E -fdirectives-only" to preprocess a file, then compiling it later
with "-fprocessed -fdirectives-only", __BASE_FILE__ is not correctly preserved.
__FILE__ is preserved due to file and line number directives in the
preprocessed output, but __BASE_FILE__ gets lost.

The attached source program can demonstrate this behaviour as follows:

 $ gcc -o preprocess.c -E test.c -fdirectives-only && gcc -o test -xc
preprocess.c -fpreprocessed -fdirectives-only && ./test
 __BASE_FILE__ = preprocess.c
 __FILE__ = test.c

As can be seen, __FILE__ is correctly set from the original input file, but
__BASE_FILE__ picks up the name of the preprocessed intermediate file (and
doesn't match the initial __FILE__ as expected).


Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-libmpx
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --enable-cet --with-tune=generic
--with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 8.2.1 20181215 (Red Hat 8.2.1-6) (GCC)

[Bug rtl-optimization/89654] [8/9 Regression] Invalid reload with -march=skylake -m32

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
Without STV, there are too many moves. -O2 -m32 -mno-stv should generate
something like:

movl4(%esp), %eax
movl8(%esp), %edx
shldl   $3, %eax, %edx
shll$3, %eax
retl

[Bug c++/89642] gcc rejects valid implicit typename context in cast

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
clang++ also rejects this but icc accepts it.

[Bug fortran/89651] OpenMP private array uninitialized warning with -O flag

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
t is privatized and the emitted code looks just fine to me.

The standard says for privatization clauses:
For a list item or the subobject of a list item with the ALLOCATABLE attribute:
- if the allocation status is “not currently allocated”, the new list item or
the subobject of the new list item will have an initial allocation status of
"not currently allocated".
- if the allocation status is “currently allocated”, the new list item or the
subobject of the new list item will have an initial allocation status of
"currently allocated".
- If the new list item or the subobject of the new list item is an array, its
bounds will be the same as those of the original list item or the subobject of
the original list item.

and that is what GCC implements.  If you e.g. look at omplower dump, there is:
D.3953 = .omp_data_i->t;
D.3954 = D.3953->data;
if (D.3954 != 0B) goto ; else goto ;
:
D.3953 = .omp_data_i->t;
t = *D.3953;
D.3957 = t.dim[0].ubound;
D.3958 = t.dim[0].lbound;
D.3959 = D.3957 - D.3958;
D.3960 = D.3959 + 1;
D.3961 = D.3960 * 4;
D.3951 = (unsigned long) D.3961;
D.3962 = MAX_EXPR ;
D.3952 = __builtin_malloc (D.3962);
D.3963 = D.3952 == 0B;
D.3964 = (integer(kind=8)) D.3963;
D.3965 = .BUILTIN_EXPECT (D.3964, 0, 42);
D.3966 = (logical(kind=1)) D.3965;
if (D.3966 != 0) goto ; else goto ;
:
_gfortran_os_error (&"Allocation would exceed memory
limit"[1]{lb: 1 sz: 1});
:
t.data = D.3952;
goto ;
:
t.data = 0B;
:
where *.omp_data_i->t is the descriptor of the original t and t being assigned
is the privatized t.  If the original t is not allocated, then we only clear
t.data and leave the rest uninitialized, exactly like if in the testcase
you comment out the allocate and !$omp lines.  If t is allocated, then
everything is copied and new array allocated.

To shut up the warning, we could e.g. do:
  D.3953 = .omp_data_i->t;
  t = *D.3953;
unconditionally instead of conditionally, but it would be a wasteful at runtime
for the case when the original var is not allocated, copying 64 bytes that
won't be really needed.

Another option (best) would be to propagate from the outer to inner outlined
OpenMP regions information like that .omp_data_i->t.data is non-NULL etc.;
while we should improve the IPA opts on the boundary of OpenMP regions and pass
stuff like VRP info etc. down, I'm afraid because this is a pointer inside a
large struct and we don't really do VRP or bitwise ccp, alignment info etc. for
aggregate elts unless SRA optimized, this won't happen any time soon.

So yet another option would be to set TREE_NO_WARNING here on the privatized
variable.

[Bug c++/89652] [9 Regression] ICE during constexpr evaluation

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
The ICE on this testcase started with my r269078.

[Bug sanitizer/85777] [7/8/9 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear

[vincent-gcc at vinc17 dot net]

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

--- Comment #10 from Vincent Lefèvre  ---
(In reply to Jakub Jelinek from comment #9)
> That is not true, automake is highly customizable, you can e.g. override
> COMPILE/LTCOMPILE variables in Makefile.am or something similar.

The issue is that what COMPILE/LTCOMPILE should contain is not specified, so
that it is impossible to write a replacement that will be guaranteed to work in
a portable way.

For instance, the following is generated:

LTCOMPILE = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
$(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) \
$(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \
$(AM_CFLAGS) $(CFLAGS)

but the AM_V_lt variable is nowhere documented. Thus replacing
COMPILE/LTCOMPILE would require the developer to use obscure internals. I will
never do that!

Anyway, this would not be these variables that one would need to change, but
the Make rules that invoke the compiler, like:

.c.o:
$(AM_V_CC)depbase=`echo $@ | sed 's|[^/]*$$|$(DEPDIR)/&|;s|\.o$$||'`;\
$(COMPILE) -MT $@ -MD -MP -MF $$depbase.Tpo -c -o $@ $< &&\
$(am__mv) $$depbase.Tpo $$depbase.Po
#   $(AM_V_CC)source='$<' object='$@' libtool=no \
#   DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) \
#   $(AM_V_CC_no)$(COMPILE) -c -o $@ $<

But this is even worse: more internals, more code that is platform-dependent...

[Bug target/89659] New: [microblaze] unrecognizable insn at floating point conversion

[ra_gcc_bugzilla at hotmail dot com]

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

Bug ID: 89659
   Summary: [microblaze] unrecognizable insn at floating point
conversion
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ra_gcc_bugzilla at hotmail dot com
  Target Milestone: ---

Created attachment 45939
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45939&action=edit
The preprocessed source file

Compiling the attached test case results in an unrecognizable insn internal
compiler error. The test case was reduced from the PARSEC Benchmark Suite,
fluidanimate, pthreads.cpp:344. The compiler used is the one shipped with
Vivado 2018.3, running on Windows 10. -O2 is necessary for the error to occur,
but I was not able to identify the exact optimization flag.

$ mb-gcc -v -save-temps -O2 -mhard-float -mxl-float-convert "test_case.c"

Using built-in specs.
COLLECT_GCC=mb-gcc
COLLECT_LTO_WRAPPER=c:/xilinx/sdk/2018.3/gnu/microblaze/nt/bin/../libexec/gcc/microblaze-xilinx-elf/7.3.1/lto-wrapper.exe
Target: microblaze-xilinx-elf
Configured with:
/proj/sdk/gnu/microblaze/builds/HEAD/nightly/2018_11_29/rdi_scripts/../build/nt/ctng_bld/target_build/src/gcc-custom/configure
--build=x86_64-build_unknown-linux-gnu --host=x86_64-host_w64-mingw32
--target=microblaze-xilinx-elf
--prefix=/proj/sdk/gnu/microblaze/builds/HEAD/nightly/2018_11_29/rdi_scripts/../build/nt/ctng_output
--with-local-prefix=/proj/sdk/gnu/microblaze/builds/HEAD/nightly/2018_11_29/rdi_scripts/../build/nt/ctng_output/microblaze-xilinx-elf/sysroot
--disable-libmudflap
--with-sysroot=/proj/sdk/gnu/microblaze/builds/HEAD/nightly/2018_11_29/rdi_scripts/../build/nt/ctng_output/microblaze-xilinx-elf/sysroot
--with-newlib --enable-threads=no --disable-shared
--with-pkgversion='crosstool-NG 1.20.0' --disable-__cxa_atexit
--with-gmp=/proj/sdk/gnu/microblaze/builds/HEAD/nightly/2018_11_29/rdi_scripts/../build/nt/ctng_bld/target_build/microblaze-xilinx-elf/buildtools/complibs-host
--with-mpfr=/proj/sdk/gnu/microblaze/builds/HEAD/nightly/2018_11_29/rdi_scripts/../build/nt/ctng_bld/target_build/microblaze-xilinx-elf/buildtools/complibs-host
--with-mpc=/proj/sdk/gnu/microblaze/builds/HEAD/nightly/2018_11_29/rdi_scripts/../build/nt/ctng_bld/target_build/microblaze-xilinx-elf/buildtools/complibs-host
--with-ppl=no --with-isl=no --with-cloog=no
--with-libelf=/proj/sdk/gnu/microblaze/builds/HEAD/nightly/2018_11_29/rdi_scripts/../build/nt/ctng_bld/target_build/microblaze-xilinx-elf/buildtools/complibs-host
--enable-lto --enable-target-optspace --without-long-double-128
--disable-libgomp --disable-libmudflap --disable-nls --disable-libstdcxx-pch
--enable-languages=c,c++
Thread model: single
gcc version 7.3.1 20180425 (crosstool-NG 1.20.0)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-mhard-float'
'-mxl-float-convert'

c:/xilinx/sdk/2018.3/gnu/microblaze/nt/bin/../libexec/gcc/microblaze-xilinx-elf/7.3.1/cc1.exe
-E -quiet -v -iprefix
c:\xilinx\sdk\2018.3\gnu\microblaze\nt\bin\../lib/gcc/microblaze-xilinx-elf/7.3.1/
test_case.c -mhard-float -mxl-float-convert -O2 -fpch-preprocess -o test_case.i
ignoring duplicate directory
"c:/xilinx/sdk/2018.3/gnu/microblaze/nt/lib/gcc/../../lib/gcc/microblaze-xilinx-elf/7.3.1/include"
ignoring nonexistent directory
"/proj/sdk/gnu/microblaze/builds/HEAD/nightly/2018_11_29/rdi_scripts/../build/nt/ctng_output/microblaze-xilinx-elf/sysroot/proj/sdk/gnu/microblaze/builds/HEAD/nightly/2018_11_29/rdi_scripts/../build/nt/ctng_output/lib/gcc/microblaze-xilinx-elf/7.3.1/../../../../include"
ignoring duplicate directory
"c:/xilinx/sdk/2018.3/gnu/microblaze/nt/lib/gcc/../../lib/gcc/microblaze-xilinx-elf/7.3.1/include-fixed"
ignoring duplicate directory
"c:/xilinx/sdk/2018.3/gnu/microblaze/nt/lib/gcc/../../lib/gcc/microblaze-xilinx-elf/7.3.1/../../../../microblaze-xilinx-elf/include"
ignoring nonexistent directory
"/proj/sdk/gnu/microblaze/builds/HEAD/nightly/2018_11_29/rdi_scripts/../build/nt/ctng_output/microblaze-xilinx-elf/sysroot/usr/include"
#include "..." search starts here:
#include <...> search starts here:

c:\xilinx\sdk\2018.3\gnu\microblaze\nt\bin\../lib/gcc/microblaze-xilinx-elf/7.3.1/include

c:\xilinx\sdk\2018.3\gnu\microblaze\nt\bin\../lib/gcc/microblaze-xilinx-elf/7.3.1/include-fixed

c:\xilinx\sdk\2018.3\gnu\microblaze\nt\bin\../lib/gcc/microblaze-xilinx-elf/7.3.1/../../../../microblaze-xilinx-elf/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-mhard-float'
'-mxl-float-convert'

c:/xilinx/sdk/2018.3/gnu/microblaze/nt/bin/../libexec/gcc/microblaze-xilinx-elf/7.3.1/cc1.exe
-fpreprocessed test_case.i -quiet -dumpbase test_case.c -mhard-float
-mxl-float-convert -auxbase test_case -O2 -version -o test_case.s
GNU C11 (crosstool-NG 1.20.0) version 7.3.1 20180425 (microblaze-xilinx-elf)
compiled by GNU C version 4.8.0 20

[Bug c++/89642] gcc rejects valid implicit typename context in cast

[blitzrakete at gmail dot com]

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

--- Comment #2 from Nicolas Lesser  ---
Sorry, I forgot the most important part of the bug report: This is C++20. clang
doesn't implement this feature (yet), so it would naturally reject it as is
valid in pre C++20. icc has a bug since it accepts it.

[Bug c++/89660] [9 Regression] Rejects-valid error with -Wredundant-move starting with r269427

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-11
 CC||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug c++/89660] New: [9 Regression] Rejects-valid error with -Wredundant-move starting with r269427

[jakub at gcc dot gnu.org]

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

Bug ID: 89660
   Summary: [9 Regression] Rejects-valid error with
-Wredundant-move starting with r269427
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

enum A { B };
namespace std {
template  T &&move(T &&);
}
struct C;
template  struct D;
struct C { using f = int *; };
template  struct D {
  template  D (D x) : k(&x.foo ()) {}
  S &foo ();
  typename V::f k;
};
struct E {
  D bar ();
};
struct F {
  E e;
  D baz () {
D f = e.bar ();
return std::move (*reinterpret_cast *> (&f));
  }
};

is rejected with -Wredundant-move but accepted with -Wno-redundant-move,
starting with r269427.  Before it has been accepted regardless of whether
-W{,no-}redundant-move has been specified or not (but warned about a redundant
move).

[Bug c++/89660] [9 Regression] Rejects-valid error with -Wredundant-move starting with r269427

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug libstdc++/89460] FAIL: experimental/net/headers.cc (test for excess errors)

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Mon Mar 11 16:28:11 2019
New Revision: 269588

URL: https://gcc.gnu.org/viewcvs?rev=269588&root=gcc&view=rev
Log:
PR libstdc++/89460 Fix Networking TS test failures on HP-UX

Check for availability of POSIX sockatmark before using it.

Rename _S_ntoh overloads that are ambiguous when passed an integral type
that is neither uint16_t nor uint32_t.

PR libstdc++/89460
* configure.ac: Check for sockatmark.
* crossconfig.m4: Check for sockatmark.
* config.h.in: Regenerate.
* configure: Regenerate.
* include/experimental/internet (address_v4::_S_hton): Rename
overloaded functions to _S_hton_16 and _S_ntoh_16.
(address_v4::_S_ntoh): Rename to _S_ntoh_16 and _S_ntoh_32.
(basic_endpoint): Adjust calls to _S_hton and _S_ntoh.
* include/experimental/socket (basic_socket::at_mark): Check
_GLIBCXX_HAVE_SOCKATMARK.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config.h.in
trunk/libstdc++-v3/configure
trunk/libstdc++-v3/configure.ac
trunk/libstdc++-v3/crossconfig.m4
trunk/libstdc++-v3/include/experimental/internet
trunk/libstdc++-v3/include/experimental/socket

[Bug libstdc++/89460] FAIL: experimental/net/headers.cc (test for excess errors)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
Should be fixed on trunk now.

[Bug fortran/89661] New: FAIL: gfortran.dg/class_61.f90 -O (internal compiler error)

[danglin at gcc dot gnu.org]

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

Bug ID: 89661
   Summary: FAIL: gfortran.dg/class_61.f90   -O  (internal
compiler error)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  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

spawn /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B/test/gnu/gcc
/objdir/gcc/testsuite/gfortran/../../
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.
11/./libgfortran/ /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/class_61.f90
-fno-
diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=ne
ver -O -pedantic-errors -S -o class_61.s
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/class_61.f90:9:30: Error: Pointer
ar
ray component of structure at (1) must have a deferred shape
f951: internal compiler error: Segmentation fault
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
compiler exited with status 1
output is:
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/class_61.f90:9:30: Error: Pointer
ar
ray component of structure at (1) must have a deferred shape
f951: internal compiler error: Segmentation fault
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

FAIL: gfortran.dg/class_61.f90   -O  (internal compiler error)
PASS: gfortran.dg/class_61.f90   -O   (test for errors, line 9)
FAIL: gfortran.dg/class_61.f90   -O  (test for excess errors)

[Bug c++/89640] [9 Regression] g++ chokes on lambda with __attribute__

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
This changed with r265787 aka PR60503 fix and from that it seems it was
completely intentional.

[Bug fortran/89651] OpenMP private array uninitialized warning with -O flag

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
On the other side, the testcase is invalid, because you are summing
uninitialized data.  It is like if you did:
program pr89651
  integer :: n
  real, allocatable :: t(:)
  n = 10
  allocate (t(n))
  print *, sum (t)
end program pr89651
but it is true gfortran doesn't warn here either.  And we do warn even with
firstprivate(t) when it is not undefined.

[Bug libstdc++/77691] [7/8/9 regression] experimental/memory_resource/resource_adaptor.cc FAILs

[redi at gcc dot gnu.org]

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

--- Comment #30 from Jonathan Wakely  ---
Created attachment 45940
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45940&action=edit
Patch to fix resource_adaptor failures due to max_align_t bugs

Could you please try this patch on Soalris and HP-UX?

Commit log:

Remove the hardcoded whitelist of allocators expected to return memory
aligned to alignof(max_align_t), because that doesn't work when the
platform's malloc() and GCC's max_align_t do not agree what the largest
fundamental alignment is.

Instead use a hardcoded list of fundamental types that will definitely
be supported by the platform malloc, and use a copy of the allocator
rebound to the first type that matches the requested alignment.

This means allocations for alignof(__float128) might use additional
memory to store the token, because we can't assume the platform malloc
will return memory aligned to alignof(__float128). Ideally we'd be able
to add __float128 to the list of fundamental types when we know it works
for a given target.

[Bug c/89662] New: [9 Regression] ICE in contains_struct_check, at tree.h:3545

[gs...@t-online.de]

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

Bug ID: 89662
   Summary: [9 Regression] ICE in contains_struct_check, at
tree.h:3545
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20180708 and 20180722,
with option -Wall or -Warray-bounds :


$ cat z1.c
void *f (void *c)
{
  return c;
}
void g ()
{
  int n = 1;
  char c[n];
  h (f(c) - 1);
}


$ gcc-9-20190310 -c z1.c -O2 -Wall
z1.c: In function 'g':
z1.c:9:3: warning: implicit declaration of function 'h'
[-Wimplicit-function-declaration]
9 |   h (f(c) - 1);
  |   ^
during GIMPLE pass: vrp
z1.c:5:6: internal compiler error: Segmentation fault
5 | void g ()
  |  ^
0xc2668f crash_signal
../../gcc/toplev.c:326
0x8661a7 contains_struct_check(tree_node const*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/tree.h:3545
0x8661a7 wi::extended_tree<128>::extended_tree(tree_node const*)
../../gcc/tree.h:5629
0xeeebe6 generic_wide_int >::generic_wide_int(tree_node const* const&)
../../gcc/wide-int.h:780
0xeeebe6 wi::to_offset(tree_node const*)
../../gcc/tree.h:5581
0xeeebe6 vrp_prop::check_mem_ref(unsigned int, tree_node*, bool)
../../gcc/tree-vrp.c:4726
0xeef466 vrp_prop::search_for_addr_array(tree_node*, unsigned int)
../../gcc/tree-vrp.c:4785
0xeef629 check_array_bounds
../../gcc/tree-vrp.c:4884
0xf223c3 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc/tree.c:12108
0x95d9f0 walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:253
0xed9ef1 check_array_bounds_dom_walker::before_dom_children(basic_block_def*)
../../gcc/tree-vrp.c:4934
0x1486517 dom_walker::walk(basic_block_def*)
../../gcc/domwalk.c:353
0xede54c vrp_prop::check_all_array_refs()
../../gcc/tree-vrp.c:4951
0xedfee5 vrp_prop::vrp_finalize(bool)
../../gcc/tree-vrp.c:6712
0xeeff2e execute_vrp
../../gcc/tree-vrp.c:6780

[Bug fortran/89661] FAIL: gfortran.dg/class_61.f90 -O (internal compiler error)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
On x86_64-apple-darwin18 and an instrumented GCC9 (r269205) I get

% gfcg /opt/gcc/_clean/gcc/testsuite/gfortran.dg/class_61.f90 -O
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/class_61.f90:9:30:

9 | class(t2), pointer :: q(2)  ! { dg-error "must have a deferred
shape" }
  |  1
Error: Pointer array component of structure at (1) must have a deferred shape
=
==32481==ERROR: AddressSanitizer: heap-use-after-free on address 0x61303900
at pc 0x0001003efd9b bp 0x7ffeefbfe2b0 sp 0x7ffeefbfe2a8
READ of size 8 at 0x61303900 thread T0
#0 0x1003efd9a in resolve_component(gfc_component*, gfc_symbol*)
resolve.c:13828
#1 0x1003f5eec in resolve_fl_derived0(gfc_symbol*) resolve.c:14282
#2 0x1003f72d8 in resolve_fl_derived(gfc_symbol*) resolve.c:14411
#3 0x1003e45c3 in resolve_symbol(gfc_symbol*) resolve.c:14785
#4 0x1004d43fb in do_traverse_symtree(gfc_symtree*, void (*)(gfc_symtree*),
void (*)(gfc_symbol*)) symbol.c:4156
#5 0x1004f22e0 in gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*))
symbol.c:4181
#6 0x10044e99d in resolve_types(gfc_namespace*) resolve.c:16697
#7 0x1003dfbe0 in gfc_resolve(gfc_namespace*) resolve.c:16811
#8 0x1003422f8 in resolve_all_program_units(gfc_namespace*) parse.c:6073
#9 0x1003629f3 in gfc_parse_file() parse.c:6321
#10 0x10053d40b in gfc_be_parse_file() f95-lang.c:204
#11 0x1063b24e8 in compile_file() toplev.c:456
#12 0x1063be87e in do_compile() toplev.c:2204
#13 0x109550717 in toplev::main(int, char**) toplev.c:2339
#14 0x1099c9345 in main main.c:39
#15 0x7fff7512bed8 in start (libdyld.dylib:x86_64+0x16ed8)

0x61303900 is located 192 bytes inside of 344-byte region
[0x61303840,0x61303998)
freed by thread T0 here:
#0 0x1599d18ff in wrap_free.part.0 sanitizer_malloc_mac.inc:121
#1 0x1004f1a17 in gfc_free_symbol(gfc_symbol*) symbol.c:3086
#2 0x1004f1d63 in gfc_release_symbol(gfc_symbol*) symbol.c:3113
#3 0x100501a1d in gfc_restore_last_undo_checkpoint() symbol.c:3706
#4 0x100502946 in gfc_undo_symbols() symbol.c:3737
#5 0x1003438c8 in reject_statement() parse.c:2576
#6 0x100343a0e in match_word(char const*, match (*)(), locus*) parse.c:70
#7 0x100350471 in decode_statement() parse.c:376
#8 0x100352bac in next_free() parse.c:1241
#9 0x10035357a in next_statement() parse.c:1473
#10 0x100358682 in parse_derived() parse.c:3285
#11 0x10035a077 in parse_spec(gfc_statement) parse.c:3825
#12 0x100360637 in parse_progunit(gfc_statement) parse.c:5680
#13 0x1003629b5 in gfc_parse_file() parse.c:6220
#14 0x10053d40b in gfc_be_parse_file() f95-lang.c:204
#15 0x1063b24e8 in compile_file() toplev.c:456
#16 0x1063be87e in do_compile() toplev.c:2204
#17 0x109550717 in toplev::main(int, char**) toplev.c:2339
#18 0x1099c9345 in main main.c:39
#19 0x7fff7512bed8 in start (libdyld.dylib:x86_64+0x16ed8)

previously allocated by thread T0 here:
#0 0x1599d0de2 in wrap_calloc sanitizer_malloc_mac.inc:132
#1 0x108a1d5c7 in xcalloc xmalloc.c:162
#2 0x1004e916b in gfc_new_symbol(char const*, gfc_namespace*) symbol.c:3122
#3 0x1004eb6de in gfc_get_sym_tree(char const*, gfc_namespace*,
gfc_symtree**, bool) symbol.c:3374
#4 0x1004eccfd in gfc_get_symbol(char const*, gfc_namespace*, gfc_symbol**)
symbol.c:3424
#5 0x1000eb431 in gfc_match_decl_type_spec(gfc_typespec*, int) decl.c:4337
#6 0x1000fac2f in gfc_match_data_decl() decl.c:5949
#7 0x10034399f in match_word(char const*, match (*)(), locus*) parse.c:65
#8 0x100350471 in decode_statement() parse.c:376
#9 0x100352bac in next_free() parse.c:1241
#10 0x10035357a in next_statement() parse.c:1473
#11 0x100358682 in parse_derived() parse.c:3285
#12 0x10035a077 in parse_spec(gfc_statement) parse.c:3825
#13 0x100360637 in parse_progunit(gfc_statement) parse.c:5680
#14 0x1003629b5 in gfc_parse_file() parse.c:6220
#15 0x10053d40b in gfc_be_parse_file() f95-lang.c:204
#16 0x1063b24e8 in compile_file() toplev.c:456
#17 0x1063be87e in do_compile() toplev.c:2204
#18 0x109550717 in toplev::main(int, char**) toplev.c:2339
#19 0x1099c9345 in main main.c:39
#20 0x7fff7512bed8 in start (libdyld.dylib:x86_64+0x16ed8)

SUMMARY: AddressSanitizer: heap-use-after-free resolve.c:13828 in
resolve_component(gfc_component*, gfc_symbol*)
Shadow bytes around the buggy address:
  0x1c2606d0: fd fd fd fd fd fd fd fd fd fd fd fd fd f

[Bug c/89663] New: ICE in expand_builtin_int_roundingfn_2, at builtins.c:2831

[gs...@t-online.de]

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

Bug ID: 89663
   Summary: ICE in expand_builtin_int_roundingfn_2, at
builtins.c:2831
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Follow-up of pr89520 and pr89521 :


$ cat z1.c
long long llrint ();
long f ()
{
  return llrint(1);
}


$ cat z2.c
long long llrint (x);
void f ()
{
  return llrint(1);
}


$ cat z3.c
long lround ();
long f ()
{
  return lround(1);
}


$ cat z4.c
long lround (x);
long f ()
{
  return lround(1);
}


$ gcc-9-20190310 -c z1.c -O2
z1.c: In function 'f':
z1.c:4:17: warning: 'llrint' argument 1 type is 'int' where 'double' is
expected in a call to built-in function declared without prototype
[-Wbuiltin-declaration-mismatch]
4 |   return llrint(1);
  | ^
z1.c:1:11: note: built-in 'llrint' declared here
1 | long long llrint ();
  |   ^~
during RTL pass: expand
z1.c:4:10: internal compiler error: in expand_builtin_int_roundingfn_2, at
builtins.c:2831
4 |   return llrint(1);
  |  ^
0x73832c expand_builtin_int_roundingfn_2
../../gcc/builtins.c:2831
0x74eb27 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../gcc/builtins.c:7341
0x8ac4a6 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:11029
0x8b8256 store_expr(tree_node*, rtx_def*, int, bool, bool)
../../gcc/expr.c:5673
0x8b9b48 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5436
0x7748c2 expand_call_stmt
../../gcc/cfgexpand.c:2722
0x7748c2 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3691
0x7748c2 expand_gimple_stmt
../../gcc/cfgexpand.c:3850
0x777488 expand_gimple_tailcall
../../gcc/cfgexpand.c:3897
0x777488 expand_gimple_basic_block
../../gcc/cfgexpand.c:5863
0x77d38e execute
../../gcc/cfgexpand.c:6509

[Bug tree-optimization/89664] New: [8/9 Regression] ICE in free_bb, at tree-ssa-math-opts.c:522

[gs...@t-online.de]

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

Bug ID: 89664
   Summary: [8/9 Regression] ICE in free_bb, at
tree-ssa-math-opts.c:522
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with gcc-8 in combination with option -Ofast :


$ cat z1.f90
subroutine s (x)
   real :: x
   call sub (x)
end
subroutine sub (x)
   real :: x, y
   logical :: a, b
   integer :: f1, f2, f3, f4
   y = f1()
   a = .false.
   if ( f2() > f3() ) a = .true.
   b = .false.
   if ( f2() > f4() ) b = .true.
   if ( a ) then
  x = 1.0
   else if ( b ) then
  x = 1.0/y**2
   else
  x = 1.0/y - y**2
   end if
end


$ gcc-7  -c z1.f90 -Ofast
$ gcc-9-20190310 -c z1.f90 -O3
$
$ gcc-9-20190310 -c z1.f90 -Ofast
during GIMPLE pass: recip
z1.f90:1:0:

1 | subroutine s (x)
  |
internal compiler error: Segmentation fault
0xb369df crash_signal
../../gcc/toplev.c:326
0xc638b9 free_bb
../../gcc/tree-ssa-math-opts.c:522
0xc66597 execute_cse_reciprocals_1
../../gcc/tree-ssa-math-opts.c:846
0xc69e99 execute
../../gcc/tree-ssa-math-opts.c:956

[Bug tree-optimization/89664] [8/9 Regression] ICE in free_bb, at tree-ssa-math-opts.c:522

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Target||x86_64-pc-linux-gnu

--- Comment #1 from G. Steinmetz  ---

With type real functions :


$ cat z2.f90
subroutine s (x)
   real :: x
   call sub (x)
end
subroutine sub (x)
   real :: x, y
   logical :: a, b
   real :: f1, f2, f3, f4
   y = f1()
   a = .false.
   if ( f2() > f3() ) a = .true.
   b = .false.
   if ( f2() > f4() ) b = .true.
   if ( a ) then
  x = 1.0
   else if ( b ) then
  x = 1.0/y**2
   else
  x = 1.0/y - y**2
   end if
end


$ gcc-7  -c z2.f90 -Ofast
$ gcc-9-20190310 -c z2.f90 -O3
$
$ gcc-9-20190310 -c z2.f90 -Ofast
during GIMPLE pass: recip
z2.f90:1:0:

1 | subroutine s (x)
  |
internal compiler error: Segmentation fault
0xb369df crash_signal
../../gcc/toplev.c:326
0x7f4f6f nearest_common_dominator(cdi_direction, basic_block_def*,
basic_block_def*)
../../gcc/dominance.c:1015
0xc64147 insert_bb
../../gcc/tree-ssa-math-opts.c:230
0xc66380 register_division_in
../../gcc/tree-ssa-math-opts.c:293
0xc66380 execute_cse_reciprocals_1
../../gcc/tree-ssa-math-opts.c:790
0xc69e99 execute
../../gcc/tree-ssa-math-opts.c:956

[Bug tree-optimization/89644] False-positive -Warray-bounds diagnostic on strncpy

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-11
 Ever confirmed|0   |1
  Known to fail||8.3.0, 9.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  Looks like a bug in handle_builtin_stxncpy which doesn't take the
strncpy bound into consideration when computing the number of characters the
function writes.

[Bug tree-optimization/89644] False-positive -Warray-bounds diagnostic on strncpy

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

[Bug rtl-optimization/89654] [8/9 Regression] Invalid reload with -march=skylake -m32

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Apparently started with r253934:

foo:
.LFB0:
.cfi_startproc
vmovq   4(%esp), %xmm0
vpsllq  $3, %xmm0, %xmm0
vmovd   %xmm0, %eax
vpextrd $1, %xmm0, %edx
ret
.cfi_endproc

while the previous revision generates:

foo:
.LFB0:
.cfi_startproc
pushl   %ebx
.cfi_def_cfa_offset 8
.cfi_offset 3, -8
movl8(%esp), %ecx
movl12(%esp), %ebx
movl%ecx, %eax
movl%ebx, %edx
sall$3, %eax
popl%ebx
.cfi_restore 3
.cfi_def_cfa_offset 4
shldl   $3, %ecx, %edx
ret
.cfi_endproc

[Bug tree-optimization/89662] [9 Regression] -Warray-bounds ICE in contains_struct_check, at tree.h:3545

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-11
 CC||msebor at gcc dot gnu.org
  Component|c   |tree-optimization
Summary|[9 Regression] ICE in   |[9 Regression]
   |contains_struct_check, at   |-Warray-bounds ICE in
   |tree.h:3545 |contains_struct_check, at
   ||tree.h:3545
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  Introduced by my r262893:

r262893 | msebor | 2018-07-19 19:36:34 -0400 (Thu, 19 Jul 2018) | 20 lines

PR tree-optimization/84047 - missing -Warray-bounds on an out-of-bounds index
into an array
PR tree-optimization/83776 - missing -Warray-bounds indexing past the end of a
string literal

gcc/ChangeLog:

PR tree-optimization/84047
PR tree-optimization/83776
* tree-vrp.c (vrp_prop::check_mem_ref): New function.
(check_array_bounds): Call it.

[Bug tree-optimization/89664] [8/9 Regression] ICE in free_bb, at tree-ssa-math-opts.c:522

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-11
  Known to work||7.4.0
 Ever confirmed|0   |1
  Known to fail||8.3.0, 9.0

--- Comment #2 from Dominique d'Humieres  ---
Revision r254940 (2017-11-19) is OK, the compiler hangs with r255143, and gives
an ICE with r255620 (2017-11-24).

[Bug preprocessor/89665] New: inconsistent macro expansion

[gciofono at gmail dot com]

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

Bug ID: 89665
   Summary: inconsistent macro expansion
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gciofono at gmail dot com
  Target Milestone: ---

Created attachment 45941
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45941&action=edit
hellomacro.c shows the inconsistent macro expansion of gcc.

The preprocessing of the macros follows a lazy-expansion algorithm that is not
entirely satisfying, nor exactly matching the description of the gcc guide,
paragraph 3.10.6 Argument Prescan.

I find that an argument should be expanded each time it is used, or
(suboptimal) each time it is declared, but the gcc preprocessor does none.

My full gcc version with Ubuntu 18.04 is:
   gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0


please compile with (includes only stdio.h but it is unavoidable to see the
output):
   gcc -v -save-temps -o hm hellomacro.c

the commented result of execution is:

$ ./hm
0-1-2-3-4<< 5 times expansion of __COUNTER__, as expected
x<< INCONSISTENCY: no expansion to __COUNTER__, because not used
direcly
5-5-5-5-5<< inconsistency: 1 expansion of counter. 5 times would have been
better
x<< inconsistency: 1 expansion of counter, because of it indirect
use, but finally discarded like two lines above
7-7-7-7-7<< output of the current counter (6 is skipped).

[Bug tree-optimization/89662] [9 Regression] -Warray-bounds ICE in contains_struct_check, at tree.h:3545

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

[Bug c/89573] -fexcess-precision=standard doesn't work for conversion to integer of multiplication

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
On Mon, 4 Mar 2019, rguenth at gcc dot gnu.org wrote:

> where the first result is off.  The IL looks like
> 
> int r = (int) ((long double) log (p) * (long double) inv_log_of_base);
> 
> where possibly the missing cast to (double) is elided by bogus optimization
> (didn't try to track down the issue yet).

What missing cast to double?

I wouldn't expect such a cast to be generated on the result of the 
multiplication; I'd expect long double to be converted directly to int.  
There is, indeed, a test of that (see test_cast in 
gcc.target/i386/excess-precision-1.c).

You could argue about whether the result of log should be converted to 
double (the GCC IR is unable to represent that a function might return a 
result with excess range and precision, as far as it's concerned the 
return value of log is always representable in double) - but if the issue 
is with the return value of log, that would be a glibc issue, where maybe 
glibc should avoid excess precision in return values (currently it only 
does so for functions with exactly determined IEEE results, and otherwise 
acts to avoid excess range but not excess precision in return values).  In 
the presence of Annex F a function defined by the user cannot return with 
excess range or precision, but that may not apply to standard library 
functions which don't need to behave as if written in standard C.

convert_to_real_1 has a detailed check for when conversions can be removed 
(see the "Sometimes this transformation is safe" comment), but that 
shouldn't be relevant here (it's cases like (float)((double)float * 
(double)float) where removing conversions is safe).

[Bug c/89663] [7/8/9 Regression] ICE in expand_builtin_int_roundingfn_2, at builtins.c:2831

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-11
 CC||msebor at gcc dot gnu.org
Summary|ICE in  |[7/8/9 Regression] ICE in
   |expand_builtin_int_rounding |expand_builtin_int_rounding
   |fn_2, at builtins.c:2831|fn_2, at builtins.c:2831
 Ever confirmed|0   |1
  Known to fail||4.8.5, 4.9.4, 5.4.0, 6.4.0,
   ||7.3.0, 8.2.0, 9.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  Bisection points to r185431 (GCC 4.8):

r185431 | jakub | 2012-03-15 09:30:04 -0400 (Thu, 15 Mar 2012) | 7 lines

PR middle-end/52592
* builtins.c (expand_builtin_int_roundingfn_2): If expanding
BUILT_IN_IR{INT,OUND}* using optab fails, emit lr{int,ound}*
calls instead of __builtin_ir{int,ound}*.

[Bug preprocessor/89665] inconsistent macro expansion

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
The question here is does it match what the C standard says it should be
instead.

[Bug c++/89640] [9 Regression] g++ chokes on lambda with __attribute__

[redbeard0531 at gmail dot com]

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

--- Comment #4 from Mathias Stearn  ---
@Jakub, This code doesn't have either mutable or noexcept, so the "wrong place
in the grammer" issue doesn't apply. That part of the fix seems correct and
useful.

While it seems correct to fix what the c++11-syle [[attribute]] appertains to
to match the standard, it would be unfortunate to do the same to
__attribute__(()) style attributes which are already outside of the standard.
Until the standard provides some way to have an attribute that appertains to
the lambda function, this part of the "fix" is breaking useful functionality
that has existed since GCC-5 without offering any replacement.

[Bug ipa/89666] New: FAIL: gcc.dg/ipa/ipa-icf-39.c scan-ipa-dump-times icf "Unified;" 2

[danglin at gcc dot gnu.org]

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

Bug ID: 89666
   Summary: FAIL: gcc.dg/ipa/ipa-icf-39.c scan-ipa-dump-times icf
"Unified;" 2
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
CC: marxin 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

spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/test/gnu/gcc/gc
c/gcc/testsuite/gcc.dg/ipa/ipa-icf-39.c -fno-diagnostics-show-caret
-fno-diagnos
tics-show-line-numbers -fdiagnostics-color=never -O2 -fdump-ipa-icf
-fmerge-all-
constants -fdbg-cnt=merged_ipa_icf:1:3 -S -o ipa-icf-39.s
dbg_cnt 'merged_ipa_icf' set to 1-3
output is:
dbg_cnt 'merged_ipa_icf' set to 1-3

PASS: gcc.dg/ipa/ipa-icf-39.c (test for excess errors)
gcc.dg/ipa/ipa-icf-39.c: pattern found 0 times
FAIL: gcc.dg/ipa/ipa-icf-39.c scan-ipa-dump-times icf "Unified;" 2

[Bug ipa/89666] FAIL: gcc.dg/ipa/ipa-icf-39.c scan-ipa-dump-times icf "Unified;" 2

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  ---
Created attachment 45942
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45942&action=edit
ICF

[Bug ipa/89666] FAIL: gcc.dg/ipa/ipa-icf-39.c scan-ipa-dump-times icf "Unified;" 2

[danglin at gcc dot gnu.org]

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

--- Comment #2 from John David Anglin  ---
Looks like test needs:
/* { dg-require-alias "" } */

[Bug c++/89660] [9 Regression] Rejects-valid error with -Wredundant-move starting with r269427

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
Slightly reduced:

namespace std {
  template  T &&move(T &&);
}

template  struct D {
  template  D (D x) : k(&x.foo ()) {}
  S &foo ();
  int *k;
};

D bar ();

struct F {
  D baz () {
D f = bar ();
return std::move (*reinterpret_cast *> (&f));
  }
};