[Bug c++/56251] no DW_AT_const_value for static const member of a template class

[chihin.ko at oracle dot com]

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

chihin ko  changed:

   What|Removed |Added

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

--- Comment #8 from chihin ko  ---
Verified on Solaris 11

[Bug debug/54773] no debug info generated for rvalue reference

[chihin.ko at oracle dot com]

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

chihin ko  changed:

   What|Removed |Added

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

--- Comment #4 from chihin ko  ---
g++ 5.4.0 on Solaris 11 does not have this problem.

[Bug libstdc++/80165] New: Constexpr tuple of variant doesn't work

[gcc-bugs at marehr dot dialup.fu-berlin.de]

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

Bug ID: 80165
   Summary: Constexpr tuple of variant doesn't work
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
  Target Milestone: ---

Created attachment 41038
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41038=edit
Example that a tuple of a variant can't be constructed

Hi gcc-team,

first of all, I'm not sure if this bug(?) should be filed here. If not please
move it to the correct component.

I currently was trying to create a constexpr tuple of a constexpr variant as
value, which apparently doesn't work, even though I can create a constexpr
variant.

I get the following error:

```
In file included from bug_gcc_constexpr_tuple_of_variant.cpp:2:0:
/usr/local/bin/gcc-7/include/c++/7.0.1/tuple: In function ‘int main()’:
bug_gcc_constexpr_tuple_of_variant.cpp:8:51:   in constexpr expansion of
‘std::make_tuple(_Elements&& ...) [with _Elements = {const std
::variant&}]()’
bug_gcc_constexpr_tuple_of_variant.cpp:8:51:   in constexpr expansion of
‘std::tuple(std::forward&>(__args#0))’
/usr/local/bin/gcc-7/include/c++/7.0.1/tuple:609:33:   in constexpr expansion
of ‘((std::tuple*)this)->std::tuple::.std::_Tuple_imp
l<0, std::variant
>::_Tuple_impl(__elements#0)’
/usr/local/bin/gcc-7/include/c++/7.0.1/tuple:361:21: error: ‘constexpr
std::_Head_base<_Idx, _Head, false>::_Head_base(const _Head&) [w
ith long unsigned int _Idx = 0; _Head = std::variant]’ called in a constant expression
   : _Base(__head) { }
 ^
/usr/local/bin/gcc-7/include/c++/7.0.1/tuple:125:17: note: ‘constexpr
std::_Head_base<_Idx, _Head, false>::_Head_base(const _Head&) [wi

th long unsigned int _Idx = 0; _Head = std::variant]’ is not usable as a constexpr fun
ction because:
   constexpr _Head_base(const _Head& __h)
 ^~
/usr/local/bin/gcc-7/include/c++/7.0.1/tuple:126:25: error: call to
non-constexpr function ‘std::variant<_Types>::variant(const std::va
riant<_Types>&) [with _Types = {unsigned char, short unsigned int, unsigned
int}]’
   : _M_head_impl(__h) { }
 ^
In file included from bug_gcc_constexpr_tuple_of_variant.cpp:3:0:
/usr/local/bin/gcc-7/include/c++/7.0.1/variant:932:7: note:
‘std::variant<_Types>::variant(const std::variant<_Types>&) [with _Types =
{unsigned char, short unsigned int, unsigned int}]’ is not usable as a
constexpr function because:
   variant(const variant&) = default;
   ^~~
/usr/local/bin/gcc-7/include/c++/7.0.1/variant:399:7: note: defaulted
constructor calls non-constexpr ‘std::__detail::__variant::_Varia
nt_base<_Types>::_Variant_base(const
std::__detail::__variant::_Variant_base<_Types>&) [with _Types = {unsigned
char, short unsigned in
t, unsigned int}]’
   _Variant_base(const _Variant_base& __rhs)
   ^
zsh: exit 1 g++-7 -std=c++1z -Wall -Wextra
bug_gcc_constexpr_tuple_of_variant.cpp
```

Maybe you can tell me what I'm doing wrong.

Best regards
marehr

[Bug fortran/79852] diagnostics should not end with exclamation mark

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
See also pr79840.

[Bug fortran/79840] Inconsistent exclamation mark in diagnostic

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-23
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
See also pr79852.

Patch at https://gcc.gnu.org/ml/fortran/2017-03/msg00064.html.

[Bug fortran/80164] ICE in gfc_format_decoder at gcc/fortran/error.c:933

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl  ---
On Thu, Mar 23, 2017 at 10:48:20PM +, dominiq at lps dot ens.fr wrote:
> 
> The additional errors are
> 
> /opt/gcc/_clean/gcc/testsuite/gfortran.dg/where_operator_assign_1.f90:82:69:
> 
>   pv((2_I4*i-1_I4):(2_I4*i))= iaef((/(2_I4*i-1_I4),(2_I4*i)/))
>  1
> Warning: Creating array temporary at (1) [-Warray-temporaries]
> 
> /opt/gcc/_clean/gcc/testsuite/gfortran.dg/where_operator_assign_2.f90:46:45:
> 
>x = (/a (0, 1),a (0, 2),a (0, 3),a (0, 4)/)
>  1
> 

These aren't errors.  These are warnings caused by the 
questionable addition of a specious warning option
wrecklessly added to the compiler options for testcases
that were never intended to be used in testing that
warning option.  gfortran created a temporary array
in these testcases.  So what?

[Bug fortran/68040] [5/6/7 Regression] Internal compiler error: Error reporting routines re-entered.

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #7 from Dominique d'Humieres  ---
This PR has been fixed between r246078 (2017-03-12, ICE) and r246216
(2017-03-17, compiles), likely r246203 (pr79886).

Closing.

[Bug fortran/80164] ICE in gfc_format_decoder at gcc/fortran/error.c:933

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
The patch in comment 2 fixes the failures

FAIL: gfortran.dg/where_operator_assign_2.f90   -O  (internal compiler error)
FAIL: gfortran.dg/where_operator_assign_3.f90   -O  (internal compiler error)
FAIL: gfortran.dg/where_operator_assign_1.f90   -O  (internal compiler error)

but not

FAIL: gfortran.dg/ieee/ieee_1.F90   -O*  (internal compiler error)
FAIL: gfortran.dg/ieee/large_3.F90   -O*  (internal compiler error)

The additional errors are

/opt/gcc/_clean/gcc/testsuite/gfortran.dg/where_operator_assign_1.f90:82:69:

  pv((2_I4*i-1_I4):(2_I4*i))= iaef((/(2_I4*i-1_I4),(2_I4*i)/))
 1
Warning: Creating array temporary at (1) [-Warray-temporaries]

/opt/gcc/_clean/gcc/testsuite/gfortran.dg/where_operator_assign_2.f90:46:45:

   x = (/a (0, 1),a (0, 2),a (0, 3),a (0, 4)/)
 1

Would it be possible to have a better location?

[Bug fortran/80164] ICE in gfc_format_decoder at gcc/fortran/error.c:933

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
*** Bug 79888 has been marked as a duplicate of this bug. ***

[Bug fortran/79888] ICE in gfc_warning with -Warray-temporaries

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Dominique d'Humieres  ---
Duplicate of pr80164.

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

[Bug c++/80150] [6 Regression] Internal compiler error when in in try_one_overload, at cp/pt.c:18903

[gordon at codeplay dot com]

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

--- Comment #5 from Gordon Brown  ---
That's great, thanks Jason.

[Bug fortran/57924] -Werror -Warray-temporaries -Wno-error=array-temporaries fails on array temporary warnings

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Dominique d'Humieres  ---
> I think this PR can be closed as FIXED.

Agreed!

[Bug fortran/57924] -Werror -Warray-temporaries -Wno-error=array-temporaries fails on array temporary warnings

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
(In reply to Dominique d'Humieres from comment #5)
 1
> Warning: Creating array temporary at (1) [-Warray-temporaries]
> 
> Am I correct to understand that it is the expected behavior?

Yes, this is how it should be.

I think this PR can be closed as FIXED.

[Bug fortran/80164] ICE in gfc_format_decoder at gcc/fortran/error.c:933

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
Index: trans-stmt.c
===
--- trans-stmt.c(revision 246099)
+++ trans-stmt.c(working copy)
@@ -452,7 +452,11 @@ gfc_trans_call (gfc_code * code, bool de
 subscripts.  This could be prevented in the elemental case
 as temporaries are handled separatedly
 (below in gfc_conv_elemental_dependencies).  */
-  gfc_conv_loop_setup (, >expr1->where);
+  if (code->expr1)
+   gfc_conv_loop_setup (, >expr1->where);
+  else
+   gfc_conv_loop_setup (, >loc);
+
   gfc_mark_ss_chain_used (ss, 1);

   /* Convert the arguments, checking for dependencies.  */

[Bug fortran/80164] ICE in gfc_format_decoder at gcc/fortran/error.c:933

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-03-23
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Duplicate of pr79888?

Regtesting with
RUNTESTFLAGS="--target_board=unix'{-m32/-Warray-temporaries,-m64/-Warray-temporaries}'",
I see

FAIL: gfortran.dg/where_operator_assign_2.f90   -O  (internal compiler error)
FAIL: gfortran.dg/where_operator_assign_3.f90   -O  (internal compiler error)
FAIL: gfortran.dg/where_operator_assign_1.f90   -O  (internal compiler error)
FAIL: gfortran.dg/ieee/ieee_1.F90   -O*  (internal compiler error)
FAIL: gfortran.dg/ieee/large_3.F90   -O*  (internal compiler error)

[Bug c++/80093] missed optimization opportunity with std::uniform_int_distribution

[trashyankes at wp dot pl]

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

--- Comment #2 from trashyankes at wp dot pl ---
```
#include 

int foo (std::mt19937* x)
{
  std::uniform_int_distribution k(0, 99);
  for (auto i = 0; i < 1'000'000'000; ++i)
  {
std::uniform_int_distribution y(0, 99);
volatile auto r = k(*x, k.param()); //change any of `k` to `y` simplify
code
  }
}
```

This `operator()` do not use any members fields of `k` directly, therefore `y`
should give exactly same results but it isn't. This function depends on `k`
even if do not need to do this.

[Bug fortran/57924] -Werror -Warray-temporaries -Wno-error=array-temporaries fails on array temporary warnings

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #5 from Dominique d'Humieres  ---
AFAICT this seems to be fixed since at least for 5.4.0:

[Book15] f90/bug% gfortran-fsf-5 pr57924.f90 -Warray-temporaries -Werror 
pr57924.f90:12:13:

 CALL foo(q)
 1
Error: Creating array temporary at (1) [-Werror=array-temporaries]
f951: all warnings being treated as errors
[Book15] f90/bug% gfortran-fsf-5 pr57924.f90 -Warray-temporaries -Werror
-Wno-error=array-temporaries
pr57924.f90:12:13:

 CALL foo(q)
 1
Warning: Creating array temporary at (1) [-Warray-temporaries]

Am I correct to understand that it is the expected behavior?

[Bug target/80148] [7 Regression] operand has impossible constraints

[vmakarov at gcc dot gnu.org]

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

--- Comment #5 from Vladimir Makarov  ---
The fix proposed by Bernd for PR80160 does not solve the problem.  So I am
continuing to work on the patch.

[Bug rtl-optimization/80159] [7 regression] gcc takes very long time with -Os

[vmakarov at gcc dot gnu.org]

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

--- Comment #3 from Vladimir Makarov  ---
Either patch proposed by Bernd for PR80160 or my patch on which I am working
for PR80148 will solve the problem.

[Bug target/80160] [7 regression] operand has impossible constraints

[vmakarov at gcc dot gnu.org]

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

--- Comment #5 from Vladimir Makarov  ---
(In reply to Bernd Schmidt from comment #4)
> Perhaps this.
> 
> Index: lra-assigns.c
> ===
> --- lra-assigns.c (revision 246226)
> +++ lra-assigns.c (working copy)
> @@ -908,7 +908,8 @@ must_not_spill_p (unsigned spill_regno)
>   does not solve the general case where existing reloads fully
>   cover a limited register class.  */
>if (!bitmap_bit_p (_reload_pseudos, spill_regno)
> -  && reg_class_size [reg_preferred_class (spill_regno)] == 1)
> +  && reg_class_size [reg_preferred_class (spill_regno)] == 1
> +  && reg_alternate_class (spill_regno) == NO_REGS)
>  return true;
>return false;
>  }

It looks OK to me.  Bernd, please, go ahead and commit it (of course after
successful testing).

Thanks for the fast response.

[Bug target/80161] const argument hidden from AVX intrinsics due to OpenMP outlining

[jeff.science at gmail dot com]

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

--- Comment #2 from Jeff Hammond  ---
Fair point, but the error is "error: the last argument must be scale 1, 2, 4,
8" and "const int scale = 1" sure seems like it should be interpreted by the
compiler as "1", given "scale" has local scope (the error persists even after I
move it inside the parallel region).

And if the compiler is enforcing the lack of const variables in C, should it
not do so consistently, and not just when OpenMP is used?  Why does OpenMP
prevent the compiler from seeing that scale=1, even if const is not there?

[Bug middle-end/80162] [5/6/7 Regression] ICE on invalid code (address of register variable)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-23
 CC||marxin at gcc dot gnu.org
Summary|ICE on invalid code |[5/6/7 Regression] ICE on
   |(address of register|invalid code (address of
   |variable)   |register variable)
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with 4.8.0, before that GCC reports:

pr80162.c:8:19: error: data type of ‘u’ isn’t suitable for a register

[Bug tree-optimization/78496] [7 Regression] Missed opportunities for jump threading

[law at redhat dot com]

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

--- Comment #6 from Jeffrey A. Law  ---
So I've got a hack that allows me to evaluate the effect of the last example
from c#5.  So let's look at how the number of realized jump threads is affected
by the various tweaks I'm playing with:


VRP1  DOM2DOM3   VRP2  thread{1,2,3,4}
base 6  9   0  0   0 
p1   27 9   3  0   0
p2   30 6   0 21   0
p3   51 6   0  0   0
p4   51 6   0  0   6

VRP/DOM/thread columns count the number of jump threads realized by that pass.



p1 defers simplification of conditionals until after VRP threading is done. 
It's clearly finding many previously missed jump threads and even exposes some
new opportunities for DOM3. 

p2 simplifies ASSERT_EXPRs from relational to equality tests.  It moves a small
number of jump threads from DOM into VRP1, and also picks up a ton of new jump
threads to VRP2. 

p3 catches the case in the last example of c#5.  It moves all those cases
exposed for VRP2 by patch #2 to occur in VRP1. 

p4 retunes the FSM threader slightly.  I'm still experimenting here, but it
does catch some stuff that was previously missed *and* exposes some new
opportunities.  Ie, it catches stuff in thread2 and exposes stuff for thread3.

It's pretty clear that the patches can significantly improve the jump threading
we're doing for this testcase and do so early in the pipeline, where they're
the most beneficial.


We don't have a good description of the primary effect we're looking for, but
I'll guess that we're finding partial redundancies for those edges with
constant PHI arguments.  Many of those should just go away completely.  If we
look at the pre dumps, we start with 278 partial redundancies.  The first patch
drops that to 73.  The second patch drops it further to 61 where it stabilizes.
 So we're certainly seeing a lot fewer partial redundancies.

[Bug c++/77339] [5/6/7 Regression] ICE on invalid C++ code on x86_64-linux-gnu: in cp_parser_type_name, at cp/parser.c:16532

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/80164] New: ICE in gfc_format_decoder at gcc/fortran/error.c:933

[marxin at gcc dot gnu.org]

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

Bug ID: 80164
   Summary: ICE in gfc_format_decoder at gcc/fortran/error.c:933
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

All releases I have do ICE on:

$ gfortran
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/where_operator_assign_3.f90
-Warray-temporaries

gfortran
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/where_operator_assign_3.f90
-Warray-temporaries

/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/where_operator_assign_3.f90:58:0:

   x = (/a (0, "one"),a (0, "two"),a (0, "three"),a (0, "four")/)

Segmentation fault
0xff34f2 crash_signal
../../gcc/toplev.c:337
0x838b8a gfc_format_decoder
../../gcc/fortran/error.c:933
0x1b66896 pp_format(pretty_printer*, text_info*)
../../gcc/pretty-print.c:679
0x1b5300c diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.c:961
0x8385f0 gfc_warning
../../gcc/fortran/error.c:792
0x83875a gfc_warning(int, char const*, ...)
../../gcc/fortran/error.c:823
0x9258ca gfc_trans_create_temp_array(stmtblock_t*, stmtblock_t*, gfc_ss*,
tree_node*, tree_node*, bool, bool, bool, locus*)
../../gcc/fortran/trans-array.c:1044
0x928fe6 trans_array_constructor
../../gcc/fortran/trans-array.c:2382
0x929a09 gfc_add_loop_ss_code
../../gcc/fortran/trans-array.c:2664
0x930404 gfc_conv_loop_setup(gfc_loopinfo*, locus*)
../../gcc/fortran/trans-array.c:4915
0x9c411f gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool)
../../gcc/fortran/trans-stmt.c:455
0x921eff trans_code
../../gcc/fortran/trans.c:1896
0x9222fe gfc_trans_code(gfc_code*)
../../gcc/fortran/trans.c:2128
0x95cf7d gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6332
0x922342 gfc_generate_code(gfc_namespace*)
../../gcc/fortran/trans.c:2145
0x8b46ff translate_all_program_units
../../gcc/fortran/parse.c:6074
0x8b4d0f gfc_parse_file()
../../gcc/fortran/parse.c:6274
0x90aedd gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug c/80163] New: ICE on hopefully valid code

[marxin at gcc dot gnu.org]

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

Bug ID: 80163
   Summary: ICE on hopefully valid code
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Following snippet ICEs:

$ cat ice.cpp
void
c ()
{
a:
b:;
  static __int128_t d = (long) & - (long) &
}

$ gcc ice.c
ice.c:7:1: internal compiler error: in assemble_integer, at varasm.c:2754
 }
 ^
0x130b70d assemble_integer(rtx_def*, unsigned int, unsigned int, int)
../../gcc/varasm.c:2754
0x131253f output_constant
../../gcc/varasm.c:4804
0x1309a39 assemble_variable_contents
../../gcc/varasm.c:2083
0x130a499 assemble_variable(tree_node*, int, int, int)
../../gcc/varasm.c:2259
0x13221a8 varpool_node::assemble_decl()
../../gcc/varpool.c:588
0x9ea9c4 output_in_order
../../gcc/cgraphunit.c:2285
0x9eb091 symbol_table::compile()
../../gcc/cgraphunit.c:2525
0x9eb2e6 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2621

All releases I have ICE (4.5.0+), both clang and ICC accept the code.

[Bug translation/79423] Translation of warnings breaks IDE parsing of output

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-23
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #4 from David Malcolm  ---
Discussion of this on the gcc mailing list:
  https://gcc.gnu.org/ml/gcc/2017-03/msg00108.html
which suggested that an environment variable would be better for IDE
integration:
  https://gcc.gnu.org/ml/gcc/2017-03/msg00127.html

[Bug middle-end/80162] New: ICE on invalid code (address of register variable)

[ienkovich at gcc dot gnu.org]

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

Bug ID: 80162
   Summary: ICE on invalid code (address of register variable)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ienkovich at gcc dot gnu.org
  Target Milestone: ---

Looking at PR79990 I found that we can ICE on register variable usage even when
no CHKP is used.

Here is a possible testcase:

typedef int v8 __attribute__ ((vector_size(8)));

struct U {
  v8 a;
  v8 b;
};

register struct U u asm ("xmm0");

int *
foo (int i)
{
  return [i];
}

$ gcc-build/bin/gcc pr79990-2.c -S
pr79990-2.c:8:19: warning: call-clobbered register used for global register
variable
 register struct U u asm ("xmm0");
   ^
pr79990-2.c: In function ‘foo’:
pr79990-2.c:13:10: internal compiler error: in expand_expr_addr_expr_1, at
expr.c:7790
   return [i];
  ^~~
0xab00d2 expand_expr_addr_expr_1
../../gcc/gcc/expr.c:7790
0xab04d9 expand_expr_addr_expr_1
../../gcc/gcc/expr.c:7828
0xab0984 expand_expr_addr_expr
../../gcc/gcc/expr.c:7904
0xabe143 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/gcc/expr.c:11047
0xab0df5 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../gcc/gcc/expr.c:8072
0xaa7ccd store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
../../gcc/gcc/expr.c:5552
0xaa6616 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/gcc/expr.c:5321
0x946a94 expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:3641
0x946e9c expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:3737
0x94e94d expand_gimple_basic_block
../../gcc/gcc/cfgexpand.c:5744
0x9503ff execute
../../gcc/gcc/cfgexpand.c:6357
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/80148] [7 Regression] operand has impossible constraints

[vmakarov at gcc dot gnu.org]

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

--- Comment #4 from Vladimir Makarov  ---
Thank you for reporting this.

Something is wrong with processing insns for reloads.  The asm-insn hash 2 the
same operands mem[r263+12].  R263 is spilled for a reload.  The mem becomes
invalid and r263 should be reloaded too.  Instead, LRA goes to a spill sub-pass
changing the operands on mem[mem[sp+offset]], then it generates 2 reloads for
the both operands:

p1=mem[sp+offset]
p2=mem[sp+offset]

LRA can not figure out that p1 and p2 do not conflict and should be the same
(in LRA it is done on pseudo bases).

So the solution would be a generation of reloads for R263 before the spill
sub-pass.

When I find why does not it happen, I could say how much time will it take to
fix.  If it is simple, the patch will be probably ready tomorrow.

[Bug libstdc++/80137] [6/7 Regression] std::generate_canonical calls its generator a non-constant number of times

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-23
  Known to work||5.4.0
Summary|std::generate_canonical |[6/7 Regression]
   |calls its generator a   |std::generate_canonical
   |non-constant number of  |calls its generator a
   |times   |non-constant number of
   ||times
 Ever confirmed|0   |1
  Known to fail||6.3.0, 7.0

[Bug c++/80150] [6 Regression] Internal compiler error when in in try_one_overload, at cp/pt.c:18903

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to work||7.0
Summary|[6/7 Regression] Internal   |[6 Regression] Internal
   |compiler error when in in   |compiler error when in in
   |try_one_overload, at|try_one_overload, at
   |cp/pt.c:18903   |cp/pt.c:18903

--- Comment #3 from Jason Merrill  ---
Fixed on trunk.

[Bug c++/80150] [6 Regression] Internal compiler error when in in try_one_overload, at cp/pt.c:18903

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Thu Mar 23 18:23:25 2017
New Revision: 246422

URL: https://gcc.gnu.org/viewcvs?rev=246422=gcc=rev
Log:
PR c++/80150 - ICE with overloaded variadic deduction.

* pt.c (try_one_overload): Remove asserts.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic-unify-3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug target/80160] [7 regression] operand has impossible constraints

[bernds at gcc dot gnu.org]

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

--- Comment #4 from Bernd Schmidt  ---
Perhaps this.

Index: lra-assigns.c
===
--- lra-assigns.c   (revision 246226)
+++ lra-assigns.c   (working copy)
@@ -908,7 +908,8 @@ must_not_spill_p (unsigned spill_regno)
  does not solve the general case where existing reloads fully
  cover a limited register class.  */
   if (!bitmap_bit_p (_reload_pseudos, spill_regno)
-  && reg_class_size [reg_preferred_class (spill_regno)] == 1)
+  && reg_class_size [reg_preferred_class (spill_regno)] == 1
+  && reg_alternate_class (spill_regno) == NO_REGS)
 return true;
   return false;
 }

[Bug libfortran/79612] missing space in diagnostic: Incorrect rank of return array in

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
Would something such as the following make sense (with a proper comment and the
commented lines removed)?

--- ../_clean/libgfortran/runtime/bounds.c  2017-01-01 17:39:08.0
+0100
+++ libgfortran/runtime/bounds.c2017-03-23 14:10:10.0 +0100
@@ -40,9 +40,10 @@ bounds_iforeach_return (array_t *retarra

   ret_rank = GFC_DESCRIPTOR_RANK (retarray);

-  if (ret_rank != 1)
-runtime_error ("Incorrect rank of return array in %s intrinsic:"
-  "is %ld, should be 1", name, (long int) ret_rank);
+  GFC_ASSERT(ret_rank == 1);
+  /* if (ret_rank != 1)
+runtime_error ("Incorrect rank of return array in %s intrinsic: "
+  "is %ld, should be 1", name, (long int) ret_rank); */

   rank = GFC_DESCRIPTOR_RANK (array);
   ret_extent = GFC_DESCRIPTOR_EXTENT(retarray,0);

[Bug tree-optimization/80153] ivopt generate wrong code

[amker at gcc dot gnu.org]

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

--- Comment #5 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #4)
> The reason for the tree-affine oddity is that IVO calls
> 
> #0  tree_to_aff_combination (expr=, 
> type=, comb=0x7fffd310)
> 
> that is, tree_to_aff_combination with a mismatched expr/type.  For example
> from
> alloc_iv:
> 
> 1174  tree_to_aff_combination (expr, TREE_TYPE (base), );
> 1175  base = fold_convert (TREE_TYPE (base), aff_combination_to_tree
> ());
> 
I think it doesn't matter if we use base's type or expr's type here.  I will
test using consistent types here.

> that's unexpected.  But the problematic case happens where IVO does right:
> 
> Breakpoint 7, tree_to_aff_combination (expr=, 
> type=, comb=0x7fffd4a0)
> 
> but tree_to_aff_combination calls STRIP_NOPS on expr which is (unsigned int)
> "oops!\n" and thus creates the above problematical case itself.
> 
> We can either avoid stripping the nops or deal with the appearant mismatch
> by converting back the elts we add to 'type'.  I think instrumenting to
> see whether we can assert tree_to_aff_combination gets matched types passed
> (so we can eliminate the type arg) would be nice - we certainly can't handle
> all kind of mismatches sanely.
> 
> Then using STRIP_SIGN_NOPS would be safe but IIRC removing sign conversions
> was intentional (though even that might be problematic).  tree-affine was
> really designed for addresses (so type would always be a pointer).
> 
> So sth like the following should better pass bootstrap / test (IVO will
> trigger
> the assert) but it might require adding some "safe" cases to not regress
> code quality (not sure if we have testcases):
> 
> Index: gcc/tree-affine.c
> ===
> --- gcc/tree-affine.c   (revision 246414)
> +++ gcc/tree-affine.c   (working copy)
> @@ -261,12 +261,21 @@ tree_to_aff_combination (tree expr, tree
>HOST_WIDE_INT bitpos, bitsize;
>machine_mode mode;
>int unsignedp, reversep, volatilep;
> +  tree exptype = TREE_TYPE (expr);
>  
> -  STRIP_NOPS (expr);
> +  gcc_checking_assert (tree_nop_conversion_p (type, exptype)
> +  && TYPE_UNSIGNED (type) == TYPE_UNSIGNED (exptype)
> +  && POINTER_TYPE_P (type) == POINTER_TYPE_P (exptype));
> +
> +  STRIP_SIGN_NOPS (expr);
>  
>code = TREE_CODE (expr);
>switch (code)
>  {
> +CASE_CONVERT:
> +  /* Add safe cases.  */
> +  break;
> +
>  case INTEGER_CST:
>aff_combination_const (comb, type, wi::to_widest (expr));
>return;

Seems there is an issue that tree-affine lacks ability differentiating between
(unsgined)(pointer + offset) and (unsigned)pointer + (unsigned)offset.

The current behavior of tree_to_aff_combination always folds type conversion
into operands, generating exact the same affines for above two expressions:

{
  type = unsigned int
  offset = 6
  elements = {
[0] = "oops!\n" * 1,
[1] = ivtmp.37_10 * 0x
  }
}

While converting affine back to tree, it takes the other way around, always
generating the latter expression: (unsgined)(pointer + offset).  This causes
problem.

IIUC, there are two possible fixes here.  First one is as you mentioned, we
work conservatively and don't fold type conversion into operands (by not
stripping nop).  I suspect this could causes serious code generation
regression.
The second one is the opposite, we always fold type conversion into operands,
by keeping strip_nops.  While converting affine back to tree, we generate
folded expression instead of trying to preserve pointer_plus expression as now.
I prefer the second one, and understand there is concern since tree affine is
used in code generation we could lose pointer arithmetic semantic information
like the pointer_plus expression never overflows/wraps.  But, I think we can
afford this, considering possible code generation regression in the other way. 
I think there shouldn't be fundamental difference in code generation given we
have or don't have the pointer_plus information.  More important, IMHO, tree
affine should (only?) be used when trying to explore as many CSE opportunities
as possible by breaking most association order issues, like in IVOPTs.  So,
customer of tree affine should (at least for most cases) use tree-affine in
code generation only when it finds out there is benefit to do so.  If there is
no benefit, IVOPT wouldn't choose the corresponding candidate.  Lastly, this
only affects type conversion of pointer_plus expressions (IVOPTs only because
it uses unsigned type in order to avoid overflow handling), a customer only
builds pointer type tree affine won't be affected.

Testing patch, let's see if there is any fallout.  Thanks

[Bug target/80161] const argument hidden from AVX intrinsics due to OpenMP outlining

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||openmp
  Component|c   |target

--- Comment #1 from Andrew Pinski  ---
Well in C, there is no such thing as a const variable which is considered a
constant integer expression (C++ has this notion though).

[Bug rtl-optimization/80159] [7 regression] gcc takes very long time with -Os

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||bernds at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Also started with r246059.

[Bug target/80148] [7 Regression] operand has impossible constraints

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-23
   Target Milestone|--- |7.0
Summary|operand has impossible  |[7 Regression] operand has
   |constraints |impossible constraints
 Ever confirmed|0   |1

[Bug target/80160] [7 regression] operand has impossible constraints

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug bootstrap/79255] [6/7 Regression] PGO bootstrap fails on x86_64/ppc64le building Ada

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Short C testcase that ICEs without the patch:
/* PR bootstrap/79255 */
/* { dg-do compile } */
/* { dg-options "-O2 -g -fno-toplevel-reorder -Wno-attributes" } */

static inline __attribute__((always_inline)) int foo (int x);

int
baz (void)
{
  return foo (3) + foo (6) + foo (9);
}

static inline __attribute__((always_inline)) int
foo (int x)
{
  auto inline int __attribute__((noinline)) bar (int x)
  {
return x + 3;
  }
  return bar (x) + bar (x + 2);
}

and succeeds with the patch.

[Bug c/80161] New: const argument hidden from AVX intrinsics due to OpenMP outlining

[jeff.science at gmail dot com]

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

Bug ID: 80161
   Summary: const argument hidden from AVX intrinsics due to
OpenMP outlining
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeff.science at gmail dot com
  Target Milestone: ---

I get "error: the last argument must be scale 1, 2, 4, 8" when the argument is
"const int scale = 1", only when OpenMP is active.

Having seen similar issues in other compilers, I suspect that the OpenMP
outlining creates an indirection in which the constant properties of "scale"
are lost and thus not visible to the pass that parses intrinsics.

I know that manually inlining and the preprocessor provide a way to solve this,
but neither of those meets other requirements.

# Source Code

$ cat gccbug.c
#include "emmintrin.h"
#include "immintrin.h"

void copy_vgatherdpd128(size_t n, const double * restrict a, double * restrict
b)
{
__m128i vindex = _mm_set_epi32(-1,-1,8,0);
const int scale = 1;
#ifdef _OPENMP
#pragma omp parallel for
#endif
for (size_t i=0; i<n; i+=2) {
__m128d t = _mm_i32gather_pd( &(a[i]), vindex, scale );
_mm_storel_pd( &(b[i  ]), t);
_mm_storeh_pd( &(b[i+1]), t);
}
}

# Build without OpenMP

[jrhammon@esgmonster simd-memtest]$ gcc-7 -O3 -march=core-avx2 -std=gnu11 -g3
-Wall -c gccbug.c -o gccbug.o

# Build with OpenMP

[jrhammon@esgmonster simd-memtest]$ gcc-7 -O3 -march=core-avx2 -std=gnu11 -g3
-Wall -fopenmp -c gccbug.c -o gccbug.o
In file included from
/opt/gcc/HEAD/lib/gcc/x86_64-pc-linux-gnu/7.0.1/include/immintrin.h:43:0,
 from gccbug.c:2:
/opt/gcc/HEAD/lib/gcc/x86_64-pc-linux-gnu/7.0.1/include/avx2intrin.h: In
function ‘copy_vgatherdpd128._omp_fn.0’:
/opt/gcc/HEAD/lib/gcc/x86_64-pc-linux-gnu/7.0.1/include/avx2intrin.h:1254:10:
error: the last argument must be scale 1, 2, 4, 8
   return (__m128d) __builtin_ia32_gathersiv2df (_mm_undefined_pd (),
  ^~~
   __base,
   ~~~
   (__v4si)__index,
   
   __mask,
   ~~~
   __scale);
   

# GCC details

I compiled GCC from Git HEAD today.

$ gcc-7 -v
Using built-in specs.
COLLECT_GCC=gcc-7
COLLECT_LTO_WRAPPER=/opt/gcc/HEAD/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /opt/gcc//git/configure --program-suffix=-7 --disable-multilib
--enable-threads=posix --enable-checking=release --with-system-zlib
--enable-__cxa_atexit --enable-languages=c,c++,fortran --with-tune=native
--enable-bootstrap --enable-lto --enable-gold=yes --enable-ld=yes
--prefix=/opt/gcc//HEAD
Thread model: posix
gcc version 7.0.1 20170323 (experimental) (GCC) 

$ gcc-7 --version
gcc-7 (GCC) 7.0.1 20170323 (experimental)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug testsuite/80092] Add effective-target keywords for unsupported nvptx features

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
(In reply to Thomas Schwinge from comment #2)
> (In reply to Tom de Vries from comment #0)
> > But it's better to introduce effective-target keywords for those features,
> > and mark the tests as such. That will reduce the noise rate because of
> > unsupported features being used or not due to code generation changes.
> 
> But that will be a rather huge effort to do -- and to keep up to date.  Is
> that really worth it?

The initial amount of tests to process will be large.

That would be a huge effort to do, if it would be done manually.

However, I would write a script parsing gcc.log or similar to generate those
changes.

Keeping things up-to-date once there's a script will require little effort, I
suppose.

[Bug bootstrap/79255] [6/7 Regression] PGO bootstrap fails on x86_64/ppc64le building Ada

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
So, what I see is:
#0  add_AT_unsigned (die=0x7fffedd374b0, attr_kind=DW_AT_inline,
unsigned_val=2) at ../../gcc/dwarf2out.c:4150
#1  0x00ea5d65 in gen_subprogram_die (decl=0x7fffee138600,
context_die=0x0) at ../../gcc/dwarf2out.c:22117
#2  0x00eaf43e in gen_decl_die (decl=0x7fffee138600, origin=0x0,
ctx=0x0, context_die=0x0) at ../../gcc/dwarf2out.c:25284
#3  0x00eb08d5 in dwarf2out_decl (decl=0x7fffee138600) at
../../gcc/dwarf2out.c:25793
#4  0x00ea4d08 in dwarf2out_abstract_function (decl=0x7fffee138600) at
../../gcc/dwarf2out.c:21656
#5  0x00eaf248 in gen_decl_die (decl=0x0, origin=0x7fffee138600,
ctx=0x0, context_die=0x7fffecb246e0) at ../../gcc/dwarf2out.c:25241
#6  0x00eadd68 in process_scope_var (stmt=0x7fffeddf3480, decl=0x0,
origin=0x7fffee138600, context_die=0x7fffecb246e0)
at ../../gcc/dwarf2out.c:24833
#7  0x00eadec7 in decls_for_scope (stmt=0x7fffeddf3480,
context_die=0x7fffecb246e0) at ../../gcc/dwarf2out.c:24865
#8  0x00ea9212 in gen_lexical_block_die (stmt=0x7fffeddf3480,
context_die=0x7fffecb245a0) at ../../gcc/dwarf2out.c:23207
#9  0x00eada71 in gen_block_die (stmt=0x7fffeddf3480,
context_die=0x7fffecb245a0) at ../../gcc/dwarf2out.c:24795
#10 0x00eadf13 in decls_for_scope (stmt=0x7fffeddf33c0,
context_die=0x7fffecb245a0) at ../../gcc/dwarf2out.c:24876
#11 0x00ea93b7 in gen_inlined_subroutine_die (stmt=0x7fffeddf33c0,
context_die=0x7fffedd34000) at ../../gcc/dwarf2out.c:23245
#12 0x00eada5c in gen_block_die (stmt=0x7fffeddf33c0,
context_die=0x7fffedd34000) at ../../gcc/dwarf2out.c:24792
#13 0x00eadf13 in decls_for_scope (stmt=0x7fffee11cf00,
context_die=0x7fffedd34000) at ../../gcc/dwarf2out.c:24876
#14 0x00eada86 in gen_block_die (stmt=0x7fffee11cf00,
context_die=0x7fffedd34000) at ../../gcc/dwarf2out.c:24798
#15 0x00eadf13 in decls_for_scope (stmt=0x7fffee11ce40,
context_die=0x7fffedd34000) at ../../gcc/dwarf2out.c:24876
#16 0x00ea6b1a in gen_subprogram_die (decl=0x7fffee2f8600,
context_die=0x7fffefcf3000) at ../../gcc/dwarf2out.c:22441
#17 0x00eaf43e in gen_decl_die (decl=0x7fffee2f8600, origin=0x0,
ctx=0x0, context_die=0x7fffefcf3000) at ../../gcc/dwarf2out.c:25284
#18 0x00eb08d5 in dwarf2out_decl (decl=0x7fffee2f8600) at
../../gcc/dwarf2out.c:25793
#19 0x00eb0934 in dwarf2out_function_decl (decl=0x7fffee2f8600) at
../../gcc/dwarf2out.c:25808
#20 0x00f401e7 in rest_of_handle_final () at ../../gcc/final.c:4520

It doesn't seem to me that
exp_ch5__expand_assign_with_target_names__replace_target_name
(the innermost decl) is actually inlined, the reason it is
dwarf2out_abstract_function is that it is present in some other inline
function's BLOCK_NONLOCALIZED_VARS and for those we do:
  if (! early_dwarf)
for (i = 0; i < BLOCK_NUM_NONLOCALIZED_VARS (stmt); i++)
  process_scope_var (stmt, NULL, BLOCK_NONLOCALIZED_VAR (stmt, i),
 context_die);
I wonder if we shouldn't do:
--- gcc/dwarf2out.c.jj  2017-03-22 17:51:56.0 +0100
+++ gcc/dwarf2out.c 2017-03-23 17:31:45.225862154 +0100
@@ -24861,8 +24861,13 @@ decls_for_scope (tree stmt, dw_die_ref c
 if we've done it once already.  */
   if (! early_dwarf)
for (i = 0; i < BLOCK_NUM_NONLOCALIZED_VARS (stmt); i++)
- process_scope_var (stmt, NULL, BLOCK_NONLOCALIZED_VAR (stmt, i),
-context_die);
+ {
+   decl = BLOCK_NONLOCALIZED_VAR (stmt, i);
+   if (TREE_CODE (decl) == FUNCTION_DECL)
+ process_scope_var (stmt, decl, NULL_TREE, context_die);
+   else
+ process_scope_var (stmt, NULL_TREE, decl, context_die);
+ }
 }

   /* Even if we're at -g1, we need to process the subblocks in order to get
which fixes the ICE, because then we really abstract only actually inlined
functions (those appearing in BLOCK_ABSTRACT_ORIGIN).

[Bug tree-optimization/80155] [7 regression] Performance regression with code hoisting enabled

[thopre01 at gcc dot gnu.org]

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

--- Comment #15 from Thomas Preud'homme  ---
(In reply to Thomas Preud'homme from comment #14)
> (In reply to rguent...@suse.de from comment #13)
> > On Thu, 23 Mar 2017, thopre01 at gcc dot gnu.org wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155
> > > 
> > > --- Comment #12 from Thomas Preud'homme  ---
> > > (In reply to Richard Biener from comment #9)
> > > > Ah, the patches do not fix the testcase because the testcase is _not_ 
> > > > the
> > > > PRE-creates-IV case.  It's indeed simply hoisting/PRE at work 
> > > > transforming
> > > > 
> > > >   # a_14 = PHI 
> > > >   if (!b)
> > > > a_8 = a_14 + 1;
> > > > 
> > > >   # a_2 = PHI 
> > > >   a_10 = a_2 + 1;
> > > >   ... = *(a_2 + 1);
> > > > 
> > > > to
> > > > 
> > > >   # a_14 = PHI 
> > > >   _4 = a_14 + 1;
> > > >   if (b)
> > > > _3 = _4 + 1;
> > > > 
> > > >   # a_2 = PHI 
> > > >   # prephitmp_12 = PHI <_4, _3>
> > > >   ... = *(a_2 + 1);
> > > > 
> > > > increasing register pressure mainly because nothing figures that a_2 + 1
> > > > in the dereference can be replaced by prephitmp_12 ...
> > > > 
> > > > So this is a missed SLSR opportunity or, in this simple form, a missed
> > > > PRE/CSE opportunity.  Fixing that with the following (otherwise 
> > > > untested)
> > > > restores good code generation for the testcase:
> > > > 
> > > > Index: gcc/tree-ssa-pre.c
> > > > ===
> > > > --- gcc/tree-ssa-pre.c  (revision 246414)
> > > > +++ gcc/tree-ssa-pre.c  (working copy)
> > > > @@ -4636,6 +4610,35 @@ eliminate_dom_walker::before_dom_childre
> > > > }
> > > > }
> > > >  
> > > > +  if (gimple_has_ops (stmt))
> > > > +   for (unsigned i = 0; i < gimple_num_ops (stmt); ++i)
> > > > + {
> > > > +   tree op = gimple_op (stmt, i);
> > > > +   if (op)
> > > > + op = get_base_address (op);
> > > > +   if (op
> > > > +   && TREE_CODE (op) == MEM_REF
> > > > +   && ! integer_zerop (TREE_OPERAND (op, 1)))
> > > > + {
> > > > +   tree ops[2];
> > > > +   vn_nary_op_t nary;
> > > > +   ops[0] = TREE_OPERAND (op, 0);
> > > > +   ops[1] = TREE_OPERAND (op, 1);
> > > > +   tree res = vn_nary_op_lookup_pieces (2, 
> > > > POINTER_PLUS_EXPR,
> > > > +TREE_TYPE (ops[0]),
> > > > +ops, );
> > > > +   if (res && TREE_CODE (res) == SSA_NAME)
> > > > + res = eliminate_avail (res);
> > > > +   if (res)
> > > > + {
> > > > +   TREE_OPERAND (op, 0) = res;
> > > > +   TREE_OPERAND (op, 1)
> > > > + = build_int_cst (TREE_TYPE (TREE_OPERAND (op, 
> > > > 1)), 0);
> > > > +   gimple_set_modified (stmt, true);
> > 
> > Add
> > 
> > if (TREE_CODE (res) == SSA_NAME
> > && !is_gimple_debug (stmt))
> >   gimple_set_plf (SSA_NAME_DEF_STMT (res),
> >   NECESSARY, true);
> > 
> > here.
> > 
> > > > + }
> > > > + }
> > > > + }
> > > > +
> > > >if (gimple_modified_p (stmt))
> > > > {
> > > >   /* If a formerly non-invariant ADDR_EXPR is turned into an
> > > > 
> > > > note that in general optimzing
> > > > 
> > > >q = p + 1;
> > > >  = ...*(p + 1);
> > > > 
> > > > "back" to *q will be undone by forwprop/stmt folding later but in this
> > > > case the feeding stmt is a PHI node and not a pointer-plus.  It still
> > > > means that the change might be a bit too disruptive at this point
> > > > (we could restricit it a bit by only handling the case where we don't
> > > > replace with a pointer-plus result).
> > > 
> > > Thanks for your work on this! Sadly GCC ICEs with this patch:
> > > 
> > > 0xd36f53 update_dep_bb
> > > gcc/tree-ssa-tail-merge.c:411
> > > 0xd38f54 stmt_update_dep_bb
> > > gcc/tree-ssa-tail-merge.c:429
> > > 0xd38f54 same_succ_hash
> > > gcc/tree-ssa-tail-merge.c:452
> > > 0xd38f54 find_same_succ_bb
> > > gcc/tree-ssa-tail-merge.c:717
> > > 0xd39927 find_same_succ
> > > gcc/tree-ssa-tail-merge.c:748
> > > 0xd39927 init_worklist
> > > gcc/tree-ssa-tail-merge.c:767
> > > 0xd39927 tail_merge_optimize(unsigned int)
> > > gcc/tree-ssa-tail-merge.c:1726
> > > 0xce2d6a execute
> > > gcc/tree-ssa-pre.c:5164
> > > 
> > >
> 
> There's progress. Performance is improved but not as much as disabling code
> hoisting. I'll try to reduce the testcase again with that patch to see if I
> can find a testcase that expose all issues.

Funnily this led back to the 

[Bug tree-optimization/80158] [7 Regression] ICE in all_phi_incrs_profitable

[wschmidt at gcc dot gnu.org]

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

--- Comment #17 from Bill Schmidt  ---
The following fixes the reduced test case.  Could you please test it on the
full 416.gamess build?  I'll regstrap it on x86-64 and ppc64le.

Index: gcc/gimple-ssa-strength-reduction.c
===
--- gcc/gimple-ssa-strength-reduction.c (revision 246419)
+++ gcc/gimple-ssa-strength-reduction.c (working copy)
@@ -2089,6 +2089,8 @@ replace_mult_candidate (slsr_cand_t c, tree basis_
  gimple_set_location (copy_stmt, gimple_location (c->cand_stmt));
  gsi_replace (, copy_stmt, false);
  c->cand_stmt = copy_stmt;
+ if (c->next_interp)
+   lookup_cand (c->next_interp)->cand_stmt = copy_stmt;
  if (dump_file && (dump_flags & TDF_DETAILS))
stmt_to_print = copy_stmt;
}
@@ -2118,6 +2120,8 @@ replace_mult_candidate (slsr_cand_t c, tree basis_
  basis_name, bump_tree);
  update_stmt (gsi_stmt (gsi));
   c->cand_stmt = gsi_stmt (gsi);
+ if (c->next_interp)
+   lookup_cand (c->next_interp)->cand_stmt = gsi_stmt (gsi);
  if (dump_file && (dump_flags & TDF_DETAILS))
stmt_to_print = gsi_stmt (gsi);
}
@@ -3405,6 +3409,8 @@ replace_rhs_if_not_dup (enum tree_code new_code, t
   gimple_assign_set_rhs_with_ops (, new_code, new_rhs1, new_rhs2);
   update_stmt (gsi_stmt (gsi));
   c->cand_stmt = gsi_stmt (gsi);
+  if (c->next_interp)
+   lookup_cand (c->next_interp)->cand_stmt = gsi_stmt (gsi);

   if (dump_file && (dump_flags & TDF_DETAILS))
return gsi_stmt (gsi);
@@ -3511,6 +3517,8 @@ replace_one_candidate (slsr_cand_t c, unsigned i,
  gimple_assign_set_rhs_with_ops (, MINUS_EXPR, basis_name, rhs2);
  update_stmt (gsi_stmt (gsi));
   c->cand_stmt = gsi_stmt (gsi);
+ if (c->next_interp)
+   lookup_cand (c->next_interp)->cand_stmt = gsi_stmt (gsi);

  if (dump_file && (dump_flags & TDF_DETAILS))
stmt_to_print = gsi_stmt (gsi);
@@ -3532,6 +3540,8 @@ replace_one_candidate (slsr_cand_t c, unsigned i,
  gimple_set_location (copy_stmt, gimple_location (c->cand_stmt));
  gsi_replace (, copy_stmt, false);
  c->cand_stmt = copy_stmt;
+ if (c->next_interp)
+   lookup_cand (c->next_interp)->cand_stmt = copy_stmt;

  if (dump_file && (dump_flags & TDF_DETAILS))
stmt_to_print = copy_stmt;
@@ -3543,6 +3553,8 @@ replace_one_candidate (slsr_cand_t c, unsigned i,
  gimple_set_location (cast_stmt, gimple_location (c->cand_stmt));
  gsi_replace (, cast_stmt, false);
  c->cand_stmt = cast_stmt;
+ if (c->next_interp)
+   lookup_cand (c->next_interp)->cand_stmt = cast_stmt;

  if (dump_file && (dump_flags & TDF_DETAILS))
stmt_to_print = cast_stmt;

[Bug testsuite/80092] Add effective-target keywords for unsupported nvptx features

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Target||nvptx
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-23
 Ever confirmed|0   |1

--- Comment #2 from Thomas Schwinge  ---
(In reply to Tom de Vries from comment #0)
> Atm, when running for target nvptx, we run into unsupported features in the
> tests.
> 
> F.i. in the g++ testsuite:
> ...
> $ grep -c "sorry, unimplemented:" g++.log 
> 12693
> ...

... a lot...

> more in detail:
> ...
> $ grep "sorry, unimplemented:" g++.log | sed 's/.*sorry, unimplemented://' |
> dos2unix | sort -u 
>  converting lambda which uses '...' to function pointer
>  global constructors not supported on this target
>  global destructors not supported on this target
>  indirect jumps are not available on this target
>  mangling __underlying_type
>  non-trivial designated initializers not supported
>  passing arguments to ellipsis of inherited constructor 'B::B(int, ...)
> [inherited from A]'
>  target cannot support alloca.
>  target cannot support nonlocal goto.
> ...
> 
> All those tests are FAILs, while they should be UNSUPPORTED.
> 
> In principle, having those as FAILs is not a problem when regression
> testing. We can compare tests results, and only look at changes.
> 
> But it's better to introduce effective-target keywords for those features,
> and mark the tests as such. That will reduce the noise rate because of
> unsupported features being used or not due to code generation changes.

But that will be a rather huge effort to do -- and to keep up to date.  Is that
really worth it?

[Bug tree-optimization/80158] [7 Regression] ICE in all_phi_incrs_profitable

[wschmidt at gcc dot gnu.org]

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

--- Comment #16 from Bill Schmidt  ---
Ah, that's not it at all.  This is much more subtle.  This has to do with
candidates that have alternate interpretations (as either a CAND_ADD or a
CAND_MULT).  We fix up the candidate that we replace, but not the alternate
interpretation, if any.  In this case the alternate interpretation is used as a
basis for another chain of expressions, and we run into trouble.  Should not be
too hard to fix.

[Bug ipa/79772] [6/7 Regression][CHKP] ICE on invalid code in chkp_process_stmt (tree-chkp.c:4034)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
This ICE is resolved by the patch for bug 79986.  Resolving as duplicate.

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

[Bug tree-optimization/80158] [7 Regression] ICE in all_phi_incrs_profitable

[wschmidt at gcc dot gnu.org]

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

--- Comment #15 from Bill Schmidt  ---
This is the only spot where we don't do an in-situ replacement.  Testing a
patch to fix that.

[Bug other/65530] [meta-bug] -mmpx -fcheck-pointer-bounds failures

[msebor at gcc dot gnu.org]

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

Bug 79772 Summary: [6/7 Regression][CHKP] ICE on invalid code in 
chkp_process_stmt (tree-chkp.c:4034)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79772

   What|Removed |Added

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

[Bug c++/79986] [6/7 Regression][CHKP] ICE in fold_convert_loc with a flexible array

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
*** Bug 79772 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/80155] [7 regression] Performance regression with code hoisting enabled

[thopre01 at gcc dot gnu.org]

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

--- Comment #14 from Thomas Preud'homme  ---
(In reply to rguent...@suse.de from comment #13)
> On Thu, 23 Mar 2017, thopre01 at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155
> > 
> > --- Comment #12 from Thomas Preud'homme  ---
> > (In reply to Richard Biener from comment #9)
> > > Ah, the patches do not fix the testcase because the testcase is _not_ the
> > > PRE-creates-IV case.  It's indeed simply hoisting/PRE at work transforming
> > > 
> > >   # a_14 = PHI 
> > >   if (!b)
> > > a_8 = a_14 + 1;
> > > 
> > >   # a_2 = PHI 
> > >   a_10 = a_2 + 1;
> > >   ... = *(a_2 + 1);
> > > 
> > > to
> > > 
> > >   # a_14 = PHI 
> > >   _4 = a_14 + 1;
> > >   if (b)
> > > _3 = _4 + 1;
> > > 
> > >   # a_2 = PHI 
> > >   # prephitmp_12 = PHI <_4, _3>
> > >   ... = *(a_2 + 1);
> > > 
> > > increasing register pressure mainly because nothing figures that a_2 + 1
> > > in the dereference can be replaced by prephitmp_12 ...
> > > 
> > > So this is a missed SLSR opportunity or, in this simple form, a missed
> > > PRE/CSE opportunity.  Fixing that with the following (otherwise untested)
> > > restores good code generation for the testcase:
> > > 
> > > Index: gcc/tree-ssa-pre.c
> > > ===
> > > --- gcc/tree-ssa-pre.c  (revision 246414)
> > > +++ gcc/tree-ssa-pre.c  (working copy)
> > > @@ -4636,6 +4610,35 @@ eliminate_dom_walker::before_dom_childre
> > > }
> > > }
> > >  
> > > +  if (gimple_has_ops (stmt))
> > > +   for (unsigned i = 0; i < gimple_num_ops (stmt); ++i)
> > > + {
> > > +   tree op = gimple_op (stmt, i);
> > > +   if (op)
> > > + op = get_base_address (op);
> > > +   if (op
> > > +   && TREE_CODE (op) == MEM_REF
> > > +   && ! integer_zerop (TREE_OPERAND (op, 1)))
> > > + {
> > > +   tree ops[2];
> > > +   vn_nary_op_t nary;
> > > +   ops[0] = TREE_OPERAND (op, 0);
> > > +   ops[1] = TREE_OPERAND (op, 1);
> > > +   tree res = vn_nary_op_lookup_pieces (2, POINTER_PLUS_EXPR,
> > > +TREE_TYPE (ops[0]),
> > > +ops, );
> > > +   if (res && TREE_CODE (res) == SSA_NAME)
> > > + res = eliminate_avail (res);
> > > +   if (res)
> > > + {
> > > +   TREE_OPERAND (op, 0) = res;
> > > +   TREE_OPERAND (op, 1)
> > > + = build_int_cst (TREE_TYPE (TREE_OPERAND (op, 1)), 
> > > 0);
> > > +   gimple_set_modified (stmt, true);
> 
> Add
> 
> if (TREE_CODE (res) == SSA_NAME
> && !is_gimple_debug (stmt))
>   gimple_set_plf (SSA_NAME_DEF_STMT (res),
>   NECESSARY, true);
> 
> here.
> 
> > > + }
> > > + }
> > > + }
> > > +
> > >if (gimple_modified_p (stmt))
> > > {
> > >   /* If a formerly non-invariant ADDR_EXPR is turned into an
> > > 
> > > note that in general optimzing
> > > 
> > >q = p + 1;
> > >  = ...*(p + 1);
> > > 
> > > "back" to *q will be undone by forwprop/stmt folding later but in this
> > > case the feeding stmt is a PHI node and not a pointer-plus.  It still
> > > means that the change might be a bit too disruptive at this point
> > > (we could restricit it a bit by only handling the case where we don't
> > > replace with a pointer-plus result).
> > 
> > Thanks for your work on this! Sadly GCC ICEs with this patch:
> > 
> > 0xd36f53 update_dep_bb
> > gcc/tree-ssa-tail-merge.c:411
> > 0xd38f54 stmt_update_dep_bb
> > gcc/tree-ssa-tail-merge.c:429
> > 0xd38f54 same_succ_hash
> > gcc/tree-ssa-tail-merge.c:452
> > 0xd38f54 find_same_succ_bb
> > gcc/tree-ssa-tail-merge.c:717
> > 0xd39927 find_same_succ
> > gcc/tree-ssa-tail-merge.c:748
> > 0xd39927 init_worklist
> > gcc/tree-ssa-tail-merge.c:767
> > 0xd39927 tail_merge_optimize(unsigned int)
> > gcc/tree-ssa-tail-merge.c:1726
> > 0xce2d6a execute
> > gcc/tree-ssa-pre.c:5164
> > 
> >

There's progress. Performance is improved but not as much as disabling code
hoisting. I'll try to reduce the testcase again with that patch to see if I can
find a testcase that expose all issues.

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[jvdelisle at gcc dot gnu.org]

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

--- Comment #11 from Jerry DeLisle  ---
I finally figured out what is happening. 

The parent READ begins with eating any leading spaces. If a non-space character
is found, rather than seek backward (which can't be done with some units) we
unget the character and save it in the dtp structure.

The dtp structure is not passed to the child procedure, only the unit structure
is passed. This means the first READ in the child procedure does not know that
first character even exists.

To fix it I will move the saved character to the unit structure rather than the
dtp structure (or something similar) so that it is seen by the child procedure.

Since the parent is list directed and the child is formatted I/O this does
create some complications since in our library, we have different next_char()
functions for formatted and list directed.

[Bug testsuite/80092] Add effective-target keywords for unsupported nvptx features

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
Submitted "[testsuite] Add missing dg-require-effective-target alloca to gcc
testsuite" ( https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01227.html )

[Bug target/80160] [7 regression] operand has impossible constraints

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Started with r246059.

[Bug tree-optimization/80158] [7 Regression] ICE in all_phi_incrs_profitable

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #14 from Bill Schmidt  ---
I can reproduce now, confirmed.

[Bug target/80160] [7 regression] operand has impossible constraints

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Reduced testcase with -O2 -fno-omit-frame-pointer -march=pentium-mmx -m32:

typedef struct { long long a; } a_t;
int *a, b;
a_t *e, c;
long long f;
void fn (int);
void fn2 (void);
int fn3 (a_t);
void fn4 (a_t);
a_t foo (long long val) { return (a_t){val}; }
static void
bar (int ka)
{
  unsigned i;
  for (i = 0; i < 512; i++) {
long d;
c = (a_t){d};
fn2 ();
  }
  fn (ka);
}
void
test (void)
{
  a_t g;
  a_t *h, j;
  h = e;
  j = *h;
  if (e == (a_t *) 1) {
a_t k = {fn3 (j)};
fn4 (j);
long l;
g = foo((long long)b << 2 | l);
k = g;
if (j.a != k.a) {
  a_t m = g;
  int n = m.a, o = m.a >> 32;
  asm ("" : "=m"(*a), "+A"(f) : "b"(n), "c"(o));
}
  }
  bar ((int) h);
}

[Bug tree-optimization/80158] [7 Regression] ICE in all_phi_incrs_profitable

[wschmidt at gcc dot gnu.org]

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

--- Comment #13 from Bill Schmidt  ---
OK, sure, that is quite possible.  Seems like something that should have popped
up before, but I guess the information gathered from the old cand->stmt must
have been harmless.

[Bug tree-optimization/80158] [7 Regression] ICE in all_phi_incrs_profitable

[rguenther at suse dot de]

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

--- Comment #12 from rguenther at suse dot de  ---
On Thu, 23 Mar 2017, wschmidt at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80158
> 
> --- Comment #10 from Bill Schmidt  ---
> Pretty certain the problem is in this chunk:
> 
>   if (bump == 0)
> {
>   tree lhs = gimple_assign_lhs (c->cand_stmt);
>   gassign *copy_stmt = gimple_build_assign (lhs, basis_name);
>   gimple_stmt_iterator gsi = gsi_for_stmt (c->cand_stmt);
>   gimple_set_location (copy_stmt, gimple_location (c->cand_stmt));
>   gsi_replace (, copy_stmt, false);
>   c->cand_stmt = copy_stmt;
>   if (dump_file && (dump_flags & TDF_DETAILS))
> stmt_to_print = copy_stmt;
> }
> 
> We need a gimple_set_bb (copy_stmt, gimple_bb (c->cand_stmt)) in here if we're
> going to rely on the BB information for dominators subsequently.  There may be
> other cases like this in the code.

But copy_stmt should have a BB as you did a gsi_replace on it.  The
stmt in question that causes the crash has none.

Instead I susepct somehwere we replace the affected stmt but keep a
dangling c->cand_stmt pointing to it around.

[Bug tree-optimization/80158] [7 Regression] ICE in all_phi_incrs_profitable

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek  ---
(In reply to Bill Schmidt from comment #10)
> Pretty certain the problem is in this chunk:
> 
>   if (bump == 0)
> {
>   tree lhs = gimple_assign_lhs (c->cand_stmt);
>   gassign *copy_stmt = gimple_build_assign (lhs, basis_name);
>   gimple_stmt_iterator gsi = gsi_for_stmt (c->cand_stmt);
>   gimple_set_location (copy_stmt, gimple_location (c->cand_stmt));
>   gsi_replace (, copy_stmt, false);
>   c->cand_stmt = copy_stmt;
>   if (dump_file && (dump_flags & TDF_DETAILS))
> stmt_to_print = copy_stmt;
>   }
> 
> We need a gimple_set_bb (copy_stmt, gimple_bb (c->cand_stmt)) in here if
> we're going to rely on the BB information for dominators subsequently. 
> There may be other cases like this in the code.

gsi_replace does
gimple_set_bb (stmt, gsi_bb (*gsi));
so I don't see why that would be needed.

[Bug tree-optimization/80158] [7 Regression] ICE in all_phi_incrs_profitable

[wschmidt at gcc dot gnu.org]

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

--- Comment #10 from Bill Schmidt  ---
Pretty certain the problem is in this chunk:

  if (bump == 0)
{
  tree lhs = gimple_assign_lhs (c->cand_stmt);
  gassign *copy_stmt = gimple_build_assign (lhs, basis_name);
  gimple_stmt_iterator gsi = gsi_for_stmt (c->cand_stmt);
  gimple_set_location (copy_stmt, gimple_location (c->cand_stmt));
  gsi_replace (, copy_stmt, false);
  c->cand_stmt = copy_stmt;
  if (dump_file && (dump_flags & TDF_DETAILS))
stmt_to_print = copy_stmt;
}

We need a gimple_set_bb (copy_stmt, gimple_bb (c->cand_stmt)) in here if we're
going to rely on the BB information for dominators subsequently.  There may be
other cases like this in the code.

[Bug target/80160] [7 regression] operand has impossible constraints

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Confirmed, bisecting and reducing.

[Bug target/71436] [7 Regression] Segmentation fault in arm_output_multireg_pop

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #16 from ktkachov at gcc dot gnu.org ---
Fixed.

[Bug target/71436] [7 Regression] Segmentation fault in arm_output_multireg_pop

[ktkachov at gcc dot gnu.org]

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

--- Comment #15 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Mar 23 14:55:48 2017
New Revision: 246419

URL: https://gcc.gnu.org/viewcvs?rev=246419=gcc=rev
Log:
[ARM] PR target/71436: Restrict *load_multiple pattern till after LRA

PR target/71436
* config/arm/arm.md (*load_multiple): Add reload_completed to
matching condition.

* gcc.c-torture/compile/pr71436.c: New test.


Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr71436.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.md
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/80158] [7 Regression] ICE in all_phi_incrs_profitable

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On Thu, 23 Mar 2017, wschmidt at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80158
> 
> --- Comment #5 from Bill Schmidt  ---
> OK, I will have to find an x86 box -- fortran cross is too challenging. 
> Meanwhile, could you please add -fdump-tree-reassoc2 and
> -fdump-tree-slsr-details and post the results?  Might be able to figure it out
> from that.

Attached.  Fortran cross should be easy enough as you just need f951,
so make all-gcc is enough.

[Bug rtl-optimization/80159] [7 regression] gcc takes very long time with -Os

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||compile-time-hog, ra
 Target||i?86-*-*
   Target Milestone|--- |7.0

[Bug tree-optimization/80158] [7 Regression] ICE in all_phi_incrs_profitable

[wschmidt at gcc dot gnu.org]

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

--- Comment #9 from Bill Schmidt  ---
Thanks, those dumps are very helpful.  I found an x86 box, just need to get set
up now.  The SLSR dump is truncated but it still tells me what it was working
on when it died, so should help me out.

[Bug target/80160] [7 regression] operand has impossible constraints

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
   Target Milestone|--- |7.0

[Bug libstdc++/80137] std::generate_canonical calls its generator a non-constant number of times

[john.salmon at deshaw dot com]

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

--- Comment #1 from John Salmon  ---
The misbehavior is observable by comparing an rng that is invoked directly with
one that is invoked via generate_canonical.

drdws0134$ cat skippy.cpp
#include 
#include 

int main()
{
std::mt19937 rng;

std::seed_seq sequence{0, 1, 2, 3, 4, 5, 6, 7, 8, 9};
rng.seed(sequence);
rng.discard(12 * 629143);
std::mt19937 rng2{rng};

for(int i=0; i<20; ++i)
{
// mt19937 produces more than 23 bits per invocation, so
// generate_canonical should invoke rng once.
(void)std::generate_canonical(rng);
// invoke rng2 once as well
(void)rng2();
// they should still be in sync
if( rng2 != rng )
{
std::cout << "Bug at 12* 629143 + " << i << "!\n";
return 1;
}
}

return 0;
}
drdws0134$ g++ -Wall -std=c++11 skippy.cpp
drdws0134$ ./a.out
Bug at 12* 629143 + 6!



drdws0134$ drdws0134$ g++ --version
g++ (GCC) 6.3.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

drdws0134$

[Bug tree-optimization/80158] [7 Regression] ICE in all_phi_incrs_profitable

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Created attachment 41037
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41037=edit
slsr dump

probably not too helpful as it crashes

[Bug tree-optimization/80158] [7 Regression] ICE in all_phi_incrs_profitable

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Created attachment 41036
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41036=edit
reassoc2 dump

[Bug target/78543] [6 Regression] ICE in push_reload, at reload.c:1349 on powerpc64le-linux-gnu

[meissner at gcc dot gnu.org]

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

--- Comment #18 from Michael Meissner  ---
Created attachment 41035
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41035=edit
Proposed patch to fix the problem

This patch does not allow SUBREG's in bswap functions, which confuses the
register allocators.  It has passed without regression on a little endian
power8 system, and I'm testing it on a big endian power8 system and big endian
power7 system.

I also will be testing the back port to gcc 6 (and later gcc 5).

[Bug middle-end/79990] [CHKP] ICE in expand_expr_addr_expr_1, at expr.c:7790

[aivchenk at gmail dot com]

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

--- Comment #2 from Alexander Ivchenko  ---
I proposed a fix for this:
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01222.html

[Bug tree-optimization/80155] [7 regression] Performance regression with code hoisting enabled

[rguenther at suse dot de]

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

--- Comment #13 from rguenther at suse dot de  ---
On Thu, 23 Mar 2017, thopre01 at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155
> 
> --- Comment #12 from Thomas Preud'homme  ---
> (In reply to Richard Biener from comment #9)
> > Ah, the patches do not fix the testcase because the testcase is _not_ the
> > PRE-creates-IV case.  It's indeed simply hoisting/PRE at work transforming
> > 
> >   # a_14 = PHI 
> >   if (!b)
> > a_8 = a_14 + 1;
> > 
> >   # a_2 = PHI 
> >   a_10 = a_2 + 1;
> >   ... = *(a_2 + 1);
> > 
> > to
> > 
> >   # a_14 = PHI 
> >   _4 = a_14 + 1;
> >   if (b)
> > _3 = _4 + 1;
> > 
> >   # a_2 = PHI 
> >   # prephitmp_12 = PHI <_4, _3>
> >   ... = *(a_2 + 1);
> > 
> > increasing register pressure mainly because nothing figures that a_2 + 1
> > in the dereference can be replaced by prephitmp_12 ...
> > 
> > So this is a missed SLSR opportunity or, in this simple form, a missed
> > PRE/CSE opportunity.  Fixing that with the following (otherwise untested)
> > restores good code generation for the testcase:
> > 
> > Index: gcc/tree-ssa-pre.c
> > ===
> > --- gcc/tree-ssa-pre.c  (revision 246414)
> > +++ gcc/tree-ssa-pre.c  (working copy)
> > @@ -4636,6 +4610,35 @@ eliminate_dom_walker::before_dom_childre
> > }
> > }
> >  
> > +  if (gimple_has_ops (stmt))
> > +   for (unsigned i = 0; i < gimple_num_ops (stmt); ++i)
> > + {
> > +   tree op = gimple_op (stmt, i);
> > +   if (op)
> > + op = get_base_address (op);
> > +   if (op
> > +   && TREE_CODE (op) == MEM_REF
> > +   && ! integer_zerop (TREE_OPERAND (op, 1)))
> > + {
> > +   tree ops[2];
> > +   vn_nary_op_t nary;
> > +   ops[0] = TREE_OPERAND (op, 0);
> > +   ops[1] = TREE_OPERAND (op, 1);
> > +   tree res = vn_nary_op_lookup_pieces (2, POINTER_PLUS_EXPR,
> > +TREE_TYPE (ops[0]),
> > +ops, );
> > +   if (res && TREE_CODE (res) == SSA_NAME)
> > + res = eliminate_avail (res);
> > +   if (res)
> > + {
> > +   TREE_OPERAND (op, 0) = res;
> > +   TREE_OPERAND (op, 1)
> > + = build_int_cst (TREE_TYPE (TREE_OPERAND (op, 1)), 0);
> > +   gimple_set_modified (stmt, true);

Add

if (TREE_CODE (res) == SSA_NAME
&& !is_gimple_debug (stmt))
  gimple_set_plf (SSA_NAME_DEF_STMT (res),
  NECESSARY, true);

here.

> > + }
> > + }
> > + }
> > +
> >if (gimple_modified_p (stmt))
> > {
> >   /* If a formerly non-invariant ADDR_EXPR is turned into an
> > 
> > note that in general optimzing
> > 
> >q = p + 1;
> >  = ...*(p + 1);
> > 
> > "back" to *q will be undone by forwprop/stmt folding later but in this
> > case the feeding stmt is a PHI node and not a pointer-plus.  It still
> > means that the change might be a bit too disruptive at this point
> > (we could restricit it a bit by only handling the case where we don't
> > replace with a pointer-plus result).
> 
> Thanks for your work on this! Sadly GCC ICEs with this patch:
> 
> 0xd36f53 update_dep_bb
> gcc/tree-ssa-tail-merge.c:411
> 0xd38f54 stmt_update_dep_bb
> gcc/tree-ssa-tail-merge.c:429
> 0xd38f54 same_succ_hash
> gcc/tree-ssa-tail-merge.c:452
> 0xd38f54 find_same_succ_bb
> gcc/tree-ssa-tail-merge.c:717
> 0xd39927 find_same_succ
> gcc/tree-ssa-tail-merge.c:748
> 0xd39927 init_worklist
> gcc/tree-ssa-tail-merge.c:767
> 0xd39927 tail_merge_optimize(unsigned int)
> gcc/tree-ssa-tail-merge.c:1726
> 0xce2d6a execute
> gcc/tree-ssa-pre.c:5164
> 
>

[Bug debug/80025] [5/6/7 Regression] ICE w/ -O2 (-O3, -Ofast) -g -ftracer (infinite recursion in rtx_equal_for_cselib_1)

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
(In reply to Bernd Schmidt from comment #12)
> That still doesn't seem to address the root cause though? Isn't the problem
> that this reversible mappings code can create cycles and we should avoid
> creating these in the first place?

They can create cycles, but we can't avoid creating them generally, they are
very important for the debug info quality; if there is no cycle, it isn't a
problem, and determining whether there is a cycle is hard, because the locs
lists aren't cast in stone, they actually can have further locs added or
removed as the cselib processing goes on; and rtx_equal_for_cselib_1 is used
while they are still in flux.  Furthermore, even if there is a cycle, the
comparison function might not run into the cycle.  With the cap the comparison
function might try to use some other location in another recursion level and be
successful.

[Bug tree-optimization/80158] [7 Regression] ICE in all_phi_incrs_profitable

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt  ---
OK, I will have to find an x86 box -- fortran cross is too challenging. 
Meanwhile, could you please add -fdump-tree-reassoc2 and
-fdump-tree-slsr-details and post the results?  Might be able to figure it out
from that.

[Bug debug/80025] [5/6/7 Regression] ICE w/ -O2 (-O3, -Ofast) -g -ftracer (infinite recursion in rtx_equal_for_cselib_1)

[bernds at gcc dot gnu.org]

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

--- Comment #12 from Bernd Schmidt  ---
That still doesn't seem to address the root cause though? Isn't the problem
that this reversible mappings code can create cycles and we should avoid
creating these in the first place?

[Bug debug/80025] [5/6/7 Regression] ICE w/ -O2 (-O3, -Ofast) -g -ftracer (infinite recursion in rtx_equal_for_cselib_1)

[jakub at gcc dot gnu.org]

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

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

Untested alternate patch.

[Bug tree-optimization/80158] [7 Regression] ICE in all_phi_incrs_profitable

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Thu, 23 Mar 2017, wschmidt at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80158
> 
> --- Comment #3 from Bill Schmidt  ---
> Richard, what flags are you using with the reduced test case?  Hoping I can
> reproduce this on ppc64le without a cross, but so far no luck.

-Ofast -m32 -march=bdver2

looks like vectorization is needed to trigger it

[Bug tree-optimization/80155] [7 regression] Performance regression with code hoisting enabled

[thopre01 at gcc dot gnu.org]

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

--- Comment #12 from Thomas Preud'homme  ---
(In reply to Richard Biener from comment #9)
> Ah, the patches do not fix the testcase because the testcase is _not_ the
> PRE-creates-IV case.  It's indeed simply hoisting/PRE at work transforming
> 
>   # a_14 = PHI 
>   if (!b)
> a_8 = a_14 + 1;
> 
>   # a_2 = PHI 
>   a_10 = a_2 + 1;
>   ... = *(a_2 + 1);
> 
> to
> 
>   # a_14 = PHI 
>   _4 = a_14 + 1;
>   if (b)
> _3 = _4 + 1;
> 
>   # a_2 = PHI 
>   # prephitmp_12 = PHI <_4, _3>
>   ... = *(a_2 + 1);
> 
> increasing register pressure mainly because nothing figures that a_2 + 1
> in the dereference can be replaced by prephitmp_12 ...
> 
> So this is a missed SLSR opportunity or, in this simple form, a missed
> PRE/CSE opportunity.  Fixing that with the following (otherwise untested)
> restores good code generation for the testcase:
> 
> Index: gcc/tree-ssa-pre.c
> ===
> --- gcc/tree-ssa-pre.c  (revision 246414)
> +++ gcc/tree-ssa-pre.c  (working copy)
> @@ -4636,6 +4610,35 @@ eliminate_dom_walker::before_dom_childre
> }
> }
>  
> +  if (gimple_has_ops (stmt))
> +   for (unsigned i = 0; i < gimple_num_ops (stmt); ++i)
> + {
> +   tree op = gimple_op (stmt, i);
> +   if (op)
> + op = get_base_address (op);
> +   if (op
> +   && TREE_CODE (op) == MEM_REF
> +   && ! integer_zerop (TREE_OPERAND (op, 1)))
> + {
> +   tree ops[2];
> +   vn_nary_op_t nary;
> +   ops[0] = TREE_OPERAND (op, 0);
> +   ops[1] = TREE_OPERAND (op, 1);
> +   tree res = vn_nary_op_lookup_pieces (2, POINTER_PLUS_EXPR,
> +TREE_TYPE (ops[0]),
> +ops, );
> +   if (res && TREE_CODE (res) == SSA_NAME)
> + res = eliminate_avail (res);
> +   if (res)
> + {
> +   TREE_OPERAND (op, 0) = res;
> +   TREE_OPERAND (op, 1)
> + = build_int_cst (TREE_TYPE (TREE_OPERAND (op, 1)), 0);
> +   gimple_set_modified (stmt, true);
> + }
> + }
> + }
> +
>if (gimple_modified_p (stmt))
> {
>   /* If a formerly non-invariant ADDR_EXPR is turned into an
> 
> note that in general optimzing
> 
>q = p + 1;
>  = ...*(p + 1);
> 
> "back" to *q will be undone by forwprop/stmt folding later but in this
> case the feeding stmt is a PHI node and not a pointer-plus.  It still
> means that the change might be a bit too disruptive at this point
> (we could restricit it a bit by only handling the case where we don't
> replace with a pointer-plus result).

Thanks for your work on this! Sadly GCC ICEs with this patch:

0xd36f53 update_dep_bb
gcc/tree-ssa-tail-merge.c:411
0xd38f54 stmt_update_dep_bb
gcc/tree-ssa-tail-merge.c:429
0xd38f54 same_succ_hash
gcc/tree-ssa-tail-merge.c:452
0xd38f54 find_same_succ_bb
gcc/tree-ssa-tail-merge.c:717
0xd39927 find_same_succ
gcc/tree-ssa-tail-merge.c:748
0xd39927 init_worklist
gcc/tree-ssa-tail-merge.c:767
0xd39927 tail_merge_optimize(unsigned int)
gcc/tree-ssa-tail-merge.c:1726
0xce2d6a execute
gcc/tree-ssa-pre.c:5164

[Bug target/80160] New: [7 regression] operand has impossible constraints

[arnd at linaro dot org]

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

Bug ID: 80160
   Summary: [7 regression] operand has impossible constraints
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

Created attachment 41033
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41033=edit
linux/arch/x86/mm/pageattr.c preprocessed and compressed

I ran into this one at the same time as pr80148, with almost the same symptom
but apparently a different root cause, as this one only shows up with very
recent gcc snapshots. Right now this shows up in two files in the kernel using
the set_64bit helper, this is one of them:

x86_64-linux-gcc-7.0.1 pageattr.i -O2 -Wall -Wno-pointer-sign -Wno-sign-compare
-Wno-unused  -fno-strict-aliasing -fno-omit-frame-pointer   -march=pentium-mmx 
-m32

In file included from /git/arm-soc/arch/x86/include/asm/cmpxchg.h:142:0,
 from /git/arm-soc/arch/x86/include/asm/atomic.h:7,
 from /git/arm-soc/arch/x86/include/asm/msr.h:66,
 from /git/arm-soc/arch/x86/include/asm/processor.h:20,
 from /git/arm-soc/arch/x86/include/asm/cpufeature.h:4,
 from /git/arm-soc/arch/x86/include/asm/thread_info.h:52,
 from /git/arm-soc/include/linux/thread_info.h:25,
 from /git/arm-soc/arch/x86/include/asm/preempt.h:6,
 from /git/arm-soc/include/linux/preempt.h:80,
 from /git/arm-soc/include/linux/spinlock.h:50,
 from /git/arm-soc/include/linux/wait.h:8,
 from /git/arm-soc/include/linux/fs.h:5,
 from /git/arm-soc/include/linux/highmem.h:4,
 from /git/arm-soc/arch/x86/mm/pageattr.c:5:
/git/arm-soc/arch/x86/mm/pageattr.c: In function '__change_page_attr_set_clr':
/git/arm-soc/arch/x86/include/asm/cmpxchg_32.h:29:2: error: 'asm' operand has
impossible constraints
  asm volatile("\n1:\t"
  ^~~

The inline assembly in question is defined as

static inline void set_64bit(volatile u64 *ptr, u64 value)
{
u32 low  = value;
u32 high = value >> 32;
u64 prev = *ptr;

asm volatile("\n1:\t"
 LOCK_PREFIX "cmpxchg8b %0\n\t"
 "jnz 1b"
 : "=m" (*ptr), "+A" (prev)
 : "b" (low), "c" (high)
 : "memory");
}

static inline __attribute__((always_inline, unused))
__attribute__((no_instrument_function)) void native_set_pte_atomic(pte_t *ptep,
pte_t pte)
{
 set_64bit((unsigned long long *)(ptep), native_pte_val(pte));
}

[Bug fortran/80156] [7 Regression] Generic DTIO interface reported missing if public statement preceeds the interface block

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
> My bisection shows r245596 as the start of the regression, r245764
> as well as r245768 fails, not passes.

You are right: testing the original code I found the range r245564 (compiles)
r245629 (error). Actually I tested r245767 with the variant which compiles.

[Bug tree-optimization/80158] [7 Regression] ICE in all_phi_incrs_profitable

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from Bill Schmidt  ---
Richard, what flags are you using with the reduced test case?  Hoping I can
reproduce this on ppc64le without a cross, but so far no luck.

[Bug tree-optimization/80136] [7 Regression] ICE in gimplify_modify_expr, at gimplify.c:5627

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #20 from Bill Schmidt  ---
Fixed.

[Bug tree-optimization/80136] [7 Regression] ICE in gimplify_modify_expr, at gimplify.c:5627

[wschmidt at gcc dot gnu.org]

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

Bug 79908 Summary: ICE in gimplify_expr (gimplify.c:12155) gimplification failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79908

   What|Removed |Added

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

[Bug tree-optimization/79908] ICE in gimplify_expr (gimplify.c:12155) gimplification failed

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #10 from Bill Schmidt  ---
Fixed now.

Note: I will be unavailable from 2017-03-24 to 2017-03-27, so if regressions
occur, please revert and I will review upon my return.

[Bug tree-optimization/79908] ICE in gimplify_expr (gimplify.c:12155) gimplification failed

[wschmidt at gcc dot gnu.org]

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

--- Comment #9 from Bill Schmidt  ---
Author: wschmidt
Date: Thu Mar 23 13:13:44 2017
New Revision: 246418

URL: https://gcc.gnu.org/viewcvs?rev=246418=gcc=rev
Log:
[gcc]

2017-03-23  Bill Schmidt  
Richard Biener  

PR tree-optimization/79908
PR tree-optimization/80136
* tree-stdarg.c (expand_ifn_va_arg_1): For a VA_ARG whose LHS has
been cast away, gimplify_and_add suffices.

[gcc/testsuite]

2017-03-23  Bill Schmidt  
Richard Biener  

PR tree-optimization/79908
PR tree-optimization/80136
* gcc.dg/torture/pr79908.c: New file.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/torture/pr79908.c
trunk/gcc/tree-stdarg.c

[Bug tree-optimization/80136] [7 Regression] ICE in gimplify_modify_expr, at gimplify.c:5627

[wschmidt at gcc dot gnu.org]

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

--- Comment #19 from Bill Schmidt  ---
Author: wschmidt
Date: Thu Mar 23 13:13:44 2017
New Revision: 246418

URL: https://gcc.gnu.org/viewcvs?rev=246418=gcc=rev
Log:
[gcc]

2017-03-23  Bill Schmidt  
Richard Biener  

PR tree-optimization/79908
PR tree-optimization/80136
* tree-stdarg.c (expand_ifn_va_arg_1): For a VA_ARG whose LHS has
been cast away, gimplify_and_add suffices.

[gcc/testsuite]

2017-03-23  Bill Schmidt  
Richard Biener  

PR tree-optimization/79908
PR tree-optimization/80136
* gcc.dg/torture/pr79908.c: New file.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/torture/pr79908.c
trunk/gcc/tree-stdarg.c

[Bug tree-optimization/80136] [7 Regression] ICE in gimplify_modify_expr, at gimplify.c:5627

[wschmidt at gcc dot gnu.org]

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

--- Comment #18 from Bill Schmidt  ---
Thanks, all.  I will commit the patch.

[Bug c++/80150] [6/7 Regression] Internal compiler error when in in try_one_overload, at cp/pt.c:18903

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug rtl-optimization/80159] [7 regression] gcc takes very long time with -Os

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-23
 CC||trippels at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
  Component|ipa |rtl-optimization
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Spins in lra_create_live_ranges_1().

[Bug c++/77563] [5/6 Regression] explicit constructor breaks narrowing conversion overload resolution

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[5/6/7 Regression] explicit |[5/6 Regression] explicit
   |constructor breaks  |constructor breaks
   |narrowing conversion|narrowing conversion
   |overload resolution |overload resolution
  Known to fail|7.0 |

--- Comment #7 from Jason Merrill  ---
Fixed on trunk.

[Bug rtl-optimization/80025] [5/6/7 Regression] ICE w/ -O2 (-O3, -Ofast) -g -ftracer (infinite recursion in rtx_equal_for_cselib_1)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
So the reason we get so weird locations is we have:
(debug_insn 20 19 21 3 (var_location:DI D#6 (xor:DI (xor:DI (reg:DI 0 ax
[orig:95 l3.6_9 ] [95])
(reg:DI 1 dx [103]))
(const_int 1 [0x1]))) "pr80025.c":22 -1
 (nil))
$110 = void
(gdb) p debug_rtx (insn->u.fld[1].rt_rtx)
(insn:TI 21 20 22 3 (parallel [
(set (reg:DI 0 ax [105])
(xor:DI (reg:DI 0 ax [orig:95 l3.6_9 ] [95])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) "pr80025.c":22 418 {*xordi_1}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))

and register dx contains (const_int 1).  ax before insn 21 change is value
19:19,
value 21:8705 is whatever we've created for the whole debug_insn 20 expression,
with
(xor:DI (xor:DI (value/u:DI 19:19 @0x2920a70/0x2844900)
(value/u:DI 13:4258 @0x29209e0/0x28447e0))
(const_int 1 [0x1]))
loc, where value 13:4258 is that of dx with const_int 1 in it.
The new value of ax after insn 21 is 22:4362, which has
(xor:DI (value/u:DI 19:19 @0x2920a70/0x2844900)
(const_int 1 [0x1]))
as its location.  Then as XOR is reversible, we try to create the reverse
mapping for that and for that attempt to permanently equate 19:19 to
(xor:DI (value:DI 22:4362 @0x2920ab8/0x2844990)
(const_int 1 [0x1]))
But during cselib lookup of that expression we find that value 21:8705 has the
same value and thus equate 19:19 to the loc from 21:8705, which is the
self-reference.

[Bug c++/77563] [5/6/7 Regression] explicit constructor breaks narrowing conversion overload resolution

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Thu Mar 23 12:50:55 2017
New Revision: 246417

URL: https://gcc.gnu.org/viewcvs?rev=246417=gcc=rev
Log:
PR c++/77563 - missing ambiguous conversion error.

* call.c (convert_like_real): Use LOOKUP_IMPLICIT.

Added:
trunk/gcc/testsuite/g++.dg/overload/ambig3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c

[Bug ipa/80159] New: [7 regression] gcc takes very link time with -Os

[arnd at linaro dot org]

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

Bug ID: 80159
   Summary: [7 regression] gcc takes very link time with -Os
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

Created attachment 41032
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41032=edit
linux/fs/eventpoll.c, preprocessed, compressed

After upgrading to r246365 and doing a few hundred linux kernel builds, I ran
into one file that apparently never completes the compilation. I've verified
the problem still exists on r246414. 

To reproduce with an x86 compiler:

cc1 -m32 -Os -Wall -fno-strict-aliasing -Wno-attributes -Wno-unused-parameter
-Wno-sign-compare -Wno-pointer-sign eventpoll.i

Compilation stops after this output:

Performing interprocedural optimizations
 <*free_lang_data>   

 
Assembling functions:
   ep_item_poll epi_rcu_free list_add_tail
ep_ptable_queue_proc __list_del_entry ep_wakeup_source ep_destroy_wakeup_source
ep_poll_wakeup_proc rcu_read_lock rcu_read_unlock clear_tfile_check_list
ep_unregister_pollwait.isra.14 ep_read_events_proc list_add ep_send_events_proc

[Bug tree-optimization/80155] [7 regression] Performance regression with code hoisting enabled

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Ok, the 2nd level opportunitues are important.  So the 2nd candidate remains
for the loop carried dependencies issue(s).  Regresses (on x86_64):

Running target unix/{,-m32}
FAIL: gcc.dg/store-motion-fgcse-sm.c scan-rtl-dump store_motion "STORE_MOTION
of f, .* basic blocks, 1 insns deleted, 1 insns created"
FAIL: gcc.dg/tree-ssa/loadpre10.c scan-tree-dump-times pre "Eliminated: 1" 1
FAIL: gcc.dg/tree-ssa/loadpre23.c scan-tree-dump-times pre "Eliminated: 1" 1
FAIL: gcc.dg/tree-ssa/loadpre24.c scan-tree-dump-times pre "Eliminated: 1" 1
FAIL: gcc.dg/tree-ssa/loadpre25.c scan-tree-dump-times pre "Eliminated: 1" 1
FAIL: gcc.dg/tree-ssa/loadpre4.c scan-tree-dump-times pre "Eliminated: 1" 1
FAIL: gcc.dg/tree-ssa/loadpre6.c scan-tree-dump-times pre "Eliminated: 1" 1
FAIL: gcc.dg/tree-ssa/pr21417.c scan-tree-dump-times thread4 "FSM jump thread"
1
FAIL: gcc.dg/tree-ssa/pr71347.c scan-tree-dump-not optimized ".* = MEM.*;"
FAIL: gcc.dg/tree-ssa/ssa-pre-23.c scan-tree-dump pre "Eliminated: 3"
FAIL: gcc.target/i386/pr49781-1.c scan-assembler-not lea[lq]?[
\\t]((%|)r[a-z0-9]*

most of them are expected and looking for the feature we disabled.  loadpre6,
pr21417.c and pr49781-1.c need a closer look.

[Bug c++/80145] [c++1y] ICE after failed return type deduction

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/80155] [7 regression] Performance regression with code hoisting enabled

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
asm difference -fno-code-hoisting (-) against patch (+) shows

--- t.s 2017-03-23 13:04:11.010514228 +0100
+++ t.s.ok  2017-03-23 13:04:05.882432743 +0100
@@ -26,9 +26,9 @@
ldrbr3, [r4]@ zero_extendqisi2
cbz r3, .L2
 .L4:
-   bl  fn2
-   ldrbr3, [r4, #1]@ zero_extendqisi2
addsr4, r4, #1
+   bl  fn2
+   ldrbr3, [r4]@ zero_extendqisi2
cmp r3, #0
bne .L4
 .L2:

which probably is better as it only keeps r4 live over the call?  but
it adds a dependence between the load from r4 and the add.

[Bug tree-optimization/80155] [7 regression] Performance regression with code hoisting enabled

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Ah, the patches do not fix the testcase because the testcase is _not_ the
PRE-creates-IV case.  It's indeed simply hoisting/PRE at work transforming

  # a_14 = PHI 
  if (!b)
a_8 = a_14 + 1;

  # a_2 = PHI 
  a_10 = a_2 + 1;
  ... = *(a_2 + 1);

to

  # a_14 = PHI 
  _4 = a_14 + 1;
  if (b)
_3 = _4 + 1;

  # a_2 = PHI 
  # prephitmp_12 = PHI <_4, _3>
  ... = *(a_2 + 1);

increasing register pressure mainly because nothing figures that a_2 + 1
in the dereference can be replaced by prephitmp_12 ...

So this is a missed SLSR opportunity or, in this simple form, a missed
PRE/CSE opportunity.  Fixing that with the following (otherwise untested)
restores good code generation for the testcase:

Index: gcc/tree-ssa-pre.c
===
--- gcc/tree-ssa-pre.c  (revision 246414)
+++ gcc/tree-ssa-pre.c  (working copy)
@@ -4636,6 +4610,35 @@ eliminate_dom_walker::before_dom_childre
}
}

+  if (gimple_has_ops (stmt))
+   for (unsigned i = 0; i < gimple_num_ops (stmt); ++i)
+ {
+   tree op = gimple_op (stmt, i);
+   if (op)
+ op = get_base_address (op);
+   if (op
+   && TREE_CODE (op) == MEM_REF
+   && ! integer_zerop (TREE_OPERAND (op, 1)))
+ {
+   tree ops[2];
+   vn_nary_op_t nary;
+   ops[0] = TREE_OPERAND (op, 0);
+   ops[1] = TREE_OPERAND (op, 1);
+   tree res = vn_nary_op_lookup_pieces (2, POINTER_PLUS_EXPR,
+TREE_TYPE (ops[0]),
+ops, );
+   if (res && TREE_CODE (res) == SSA_NAME)
+ res = eliminate_avail (res);
+   if (res)
+ {
+   TREE_OPERAND (op, 0) = res;
+   TREE_OPERAND (op, 1)
+ = build_int_cst (TREE_TYPE (TREE_OPERAND (op, 1)), 0);
+   gimple_set_modified (stmt, true);
+ }
+ }
+ }
+
   if (gimple_modified_p (stmt))
{
  /* If a formerly non-invariant ADDR_EXPR is turned into an

note that in general optimzing

   q = p + 1;
 = ...*(p + 1);

"back" to *q will be undone by forwprop/stmt folding later but in this
case the feeding stmt is a PHI node and not a pointer-plus.  It still
means that the change might be a bit too disruptive at this point
(we could restricit it a bit by only handling the case where we don't
replace with a pointer-plus result).

[Bug ada/80146] [7 regression] ICE in copy_to_mode_reg, at explow.c:612

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Blocks||67205
Summary|ICE in copy_to_mode_reg, at |[7 regression] ICE in
   |explow.c:612|copy_to_mode_reg, at
   ||explow.c:612

--- Comment #7 from Andreas Schwab  ---
84a95d7fd98a4c0601f2803fc0ab983797eb9ead is the first bad commit
commit 84a95d7fd98a4c0601f2803fc0ab983797eb9ead
Author: ebotcazou 
Date:   Tue Jan 17 18:02:55 2017 +

PR ada/67205
* config/aarch64/aarch64.c (TARGET_CUSTOM_FUNCTION_DESCRIPTORS):
Define


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


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67205
[Bug 67205] eliminate No_Implicit_Dynamic_Code restriction violations