[Bug c/84903] internal compiler error: in convert_move, at expr.c:229

[marcin.krotkiewski at gmail dot com]

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

--- Comment #2 from Marcin Krotkiewski  ---
Great, the trunk works for both the test, and the production code. Thanks!

[Bug middle-end/70359] [6/7/8 Regression] Code size increase for x86/ARM/others compared to gcc-5.3.0

[rguenther at suse dot de]

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

--- Comment #43 from rguenther at suse dot de  ---
On Mon, 19 Mar 2018, aldyh at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359
> 
> --- Comment #42 from Aldy Hernandez  ---
> (In reply to Jeffrey A. Law from comment #36)
> > WRT the division removal.  That seems so profitable that a slight increase
> > in codesize is warranted.  So if we fix the other issue  and the source of
> > the remaining codesize regressions is the removal of the division, I would
> > consider this BZ resolved.
> 
> Richi.  Jeff.
> 
> Limiting the single_use with optimize_size as well may give us the best of 
> both
> worlds.  Would you like me to post the [untested] patch below upstream?  With
> this patch code size is even smaller than GCC 5.3.
> 
> I really don't care.  Actually, I'd prefer to do nothing and close the PR 
> ;-). 
> Up to y'all.

I don't like to see plain optimize_size uses in match.pd, so yeah,
just close the PR.

Disclaimer: if we ever need to do sth like that we should wrap it
in sth like optimize_pattern_for_size () to be able to eventually
pick up local profiling info.

> diff --git a/gcc/match.pd b/gcc/match.pd
> index f61c4d7440a..5d29bf62dc9 100644
> --- a/gcc/match.pd
> +++ b/gcc/match.pd
> @@ -1290,11 +1290,12 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>  /* X / C1 op C2 into a simple range test.  */
>  (for cmp (simple_comparison)
>   (simplify
> -  (cmp (trunc_div:s @0 INTEGER_CST@1) INTEGER_CST@2)
> +  (cmp (trunc_div:s@3 @0 INTEGER_CST@1) INTEGER_CST@2)
>(if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
> && integer_nonzerop (@1)
> && !TREE_OVERFLOW (@1)
> -   && !TREE_OVERFLOW (@2))
> +   && !TREE_OVERFLOW (@2)
> +   && (!optimize_size || single_use (@3)))
> (with { tree lo, hi; bool neg_overflow;
>enum tree_code code = fold_div_compare (cmp, @1, @2, &lo, &hi,
>&neg_overflow); }
> @@ -1456,9 +1457,10 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>  (for cmp (eq ne)
>   ocmp (lt ge)
>   (simplify
> -  (cmp (trunc_div @0 @1) integer_zerop)
> +  (cmp (trunc_div@2 @0 @1) integer_zerop)
>(if (TYPE_UNSIGNED (TREE_TYPE (@0))
> -   && (VECTOR_TYPE_P (type) || !VECTOR_TYPE_P (TREE_TYPE (@0
> +   && (VECTOR_TYPE_P (type) || !VECTOR_TYPE_P (TREE_TYPE (@0)))
> +   && (!optimize_size || single_use (@2)))
> (ocmp @0 @1
> 
>  /* X == C - X can never be true if C is odd.  */
> 
>

[Bug c/84953] [6/7/8 Regression] misleading warning from strpbrk(x,"")

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar 20 07:55:41 2018
New Revision: 258671

URL: https://gcc.gnu.org/viewcvs?rev=258671&root=gcc&view=rev
Log:
PR c/84953
* builtins.c (fold_builtin_strpbrk): For strpbrk(x, "") use type
instead of TREE_TYPE (s1) for the return value.

* gcc.dg/pr84953.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr84953.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog

[Bug c/84953] [6/7 Regression] misleading warning from strpbrk(x,"")

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7/8 Regression]  |[6/7 Regression] misleading
   |misleading warning from |warning from strpbrk(x,"")
   |strpbrk(x,"")   |

--- Comment #9 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug target/81647] inconsistent LTGT behavior at different optimization levels on AArch64.

[clyon at gcc dot gnu.org]

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

--- Comment #10 from Christophe Lyon  ---
Author: clyon
Date: Tue Mar 20 08:11:35 2018
New Revision: 258672

URL: https://gcc.gnu.org/viewcvs?rev=258672&root=gcc&view=rev
Log:
PR target/81647: Fix testcase.

2018-03-20  Christophe Lyon  

PR target/81647
* gcc.target/aarch64/pr81647.c: Require fenv_exceptions.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/aarch64/pr81647.c

[Bug target/84986] New: Performance regression: loop no longer vectorized (x86-64)

[gergo.barany at inria dot fr]

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

Bug ID: 84986
   Summary: Performance regression: loop no longer vectorized
(x86-64)
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gergo.barany at inria dot fr
  Target Milestone: ---

Created attachment 43713
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43713&action=edit
input function showing performance regression

For context: I throw randomly generated code at compilers and look at
differences in how they optimize; see
https://github.com/gergo-/missed-optimizations for details if interested. The
test case below is entirely artificial, I do *not* have any real-world
application that depends on this.

The attached test.c file contains a function with a simple loop:

int N;
long fn1(void) {
  short i;
  long a;
  i = a = 0;
  while (i < N)
a -= i++;
  return a;
}

Until recently, this loop used to be vectorized on x86-64, with the core loop
(if I understand the code correctly) looking something like this, as generated
by GCC trunk from 20180206 (with -O3):

  40:   66 0f 6f ce movdqa %xmm6,%xmm1
  44:   66 0f 6f e3 movdqa %xmm3,%xmm4
  48:   66 0f 6f d3 movdqa %xmm3,%xmm2
  4c:   83 c0 01add$0x1,%eax
  4f:   66 0f 65 cb pcmpgtw %xmm3,%xmm1
  53:   66 0f fd df paddw  %xmm7,%xmm3
  57:   66 0f 69 e1 punpckhwd %xmm1,%xmm4
  5b:   66 0f 61 d1 punpcklwd %xmm1,%xmm2
  5f:   66 0f 6f cc movdqa %xmm4,%xmm1
  63:   66 0f 6f e5 movdqa %xmm5,%xmm4
  67:   66 44 0f 6f c2  movdqa %xmm2,%xmm8
  6c:   66 0f 66 e2 pcmpgtd %xmm2,%xmm4
  70:   66 44 0f 62 c4  punpckldq %xmm4,%xmm8
  75:   66 0f 6a d4 punpckhdq %xmm4,%xmm2
  79:   66 0f 6f e1 movdqa %xmm1,%xmm4
  7d:   66 41 0f fb c0  psubq  %xmm8,%xmm0
  82:   66 0f fb c2 psubq  %xmm2,%xmm0
  86:   66 0f 6f d5 movdqa %xmm5,%xmm2
  8a:   66 0f 66 d1 pcmpgtd %xmm1,%xmm2
  8e:   66 0f 62 e2 punpckldq %xmm2,%xmm4
  92:   66 0f 6a ca punpckhdq %xmm2,%xmm1
  96:   66 0f fb c4 psubq  %xmm4,%xmm0
  9a:   66 0f fb c1 psubq  %xmm1,%xmm0
  9e:   39 c1   cmp%eax,%ecx
  a0:   77 9e   ja 40 

(I'm sorry this comes from objdump, I didn't keep that GCC version around to
generate a nicer assembly listing.)

With a version from 20180319 (r258665), this is no longer the case:

.L3:
movswq  %dx, %rcx
addl$1, %edx
subq%rcx, %rax
movswl  %dx, %ecx
cmpl%esi, %ecx
jl  .L3

Linking the two versions against a driver program, which simply calls this
function many times after setting N to SHRT_MAX, shows a slowdown of about
1.8x:

$ time ./test.20180206 ; time ./test.20180319 
32767 elements in 0.09 sec on average, result = -53682176100

real0m8.875s
user0m8.844s
sys 0m0.028s
32767 elements in 0.16 sec on average, result = -53682176100

real0m15.691s
user0m15.688s
sys 0m0.000s

Target: x86_64-pc-linux-gnu
Configured with: ../../src/gcc/configure
--prefix=/home/gergo/optcheck/compilers/install --enable-languages=c
--with-newlib --without-headers --disable-bootstrap --disable-nls
--disable-shared --disable-multilib --disable-decimal-float --disable-threads
--disable-libatomic --disable-libgomp --disable-libmpx --disable-libquadmath
--disable-libssp --disable-libvtv --disable-libstdcxx
--program-prefix=optcheck-x86- --target=x86_64-pc-linux-gnu
Thread model: single

This is under Linux on a machine whose CPU identifies itself as Intel(R)
Core(TM) i7-4712HQ CPU @ 2.30GHz.


For whatever it's worth, Clang goes the opposite way, vectorizes very
aggressively, and ends up slower:

$ time ./test.clang 
32767 elements in 0.19 sec on average, result = -53682176100

real0m18.930s
user0m18.928s
sys 0m0.000s

With the previous version, GCC was about 2.1x faster than Clang, this seems to
have regressed to "only" 1.2x faster.

[Bug target/84945] [8 Regression] UBSAN: gcc/config/i386/i386.c:33312:22: runtime error: shift exponent 32 is too large for 32-bit type 'int'

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar 20 08:14:42 2018
New Revision: 258673

URL: https://gcc.gnu.org/viewcvs?rev=258673&root=gcc&view=rev
Log:
PR target/84945
* config/i386/i386.c (fold_builtin_cpu): For features above 31
use __cpu_features2 variable instead of __cpu_model.__cpu_features[0].
Use 1U instead of 1.  Formatting fixes.

* gcc.target/i386/pr84945.c: New test.

* config/i386/cpuinfo.h (__cpu_features2): Declare.
* config/i386/cpuinfo.c (__cpu_features2): New variable for
ifndef SHARED only.
(set_feature): Define.
(get_available_features): Use set_feature macro.  Set __cpu_features2
to the second word of features ifndef SHARED.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr84945.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog
trunk/libgcc/ChangeLog
trunk/libgcc/config/i386/cpuinfo.c
trunk/libgcc/config/i386/cpuinfo.h

[Bug target/84986] Performance regression: loop no longer vectorized (x86-64)

[gergo.barany at inria dot fr]

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

--- Comment #1 from Gergö Barany  ---
Created attachment 43714
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43714&action=edit
test driver

[Bug c++/84959] internal compiler error: in store_binding, at cp/name-lookup.c:6549 (store_binding()/store_class_binding())

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-20
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, all releases I have ICE (4.5.0).

[Bug c++/84960] [8 Regression] ICE in GIMPLE pass: isolate-paths

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-20
 CC||law at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
  Known to work||7.3.0
   Target Milestone|--- |8.0
Summary|internal compiler error:|[8 Regression] ICE in
   |verify_flow_info failed |GIMPLE pass: isolate-paths
 Ever confirmed|0   |1
  Known to fail||8.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r255387.

[Bug middle-end/70359] [6/7/8 Regression] Code size increase for x86/ARM/others compared to gcc-5.3.0

[aldyh at gcc dot gnu.org]

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

--- Comment #44 from Aldy Hernandez  ---
(In reply to rguent...@suse.de from comment #43)

> I don't like to see plain optimize_size uses in match.pd, so yeah,
> just close the PR.

Excellent.

> 
> Disclaimer: if we ever need to do sth like that we should wrap it
> in sth like optimize_pattern_for_size () to be able to eventually
> pick up local profiling info.

Noted.

Thanks for all your help on this.

[Bug c++/84961] [7/8 Regression] ICE error: SSA_NAME_DEF_STMT is wrong

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-20
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Known to work||6.4.0
   Target Milestone|--- |7.4
Summary|internal compiler error:|[7/8 Regression] ICE error:
   |verify_ssa failed   |SSA_NAME_DEF_STMT is wrong
 Ever confirmed|0   |1
  Known to fail||7.3.0, 8.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r235817.

[Bug c++/84962] [8 Regression] ICE in get_fns, at cp/tree.c:2505

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-20
 CC||marxin at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org
  Known to work||7.3.0
   Target Milestone|--- |8.0
Summary|internal compiler error: in |[8 Regression] ICE in
   |get_fns, at cp/tree.c:2505  |get_fns, at cp/tree.c:2505
 Ever confirmed|0   |1
  Known to fail||8.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r250413.

[Bug target/84986] [8 Regression] Performance regression: loop no longer vectorized (x86-64)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-20
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |8.0
Summary|Performance regression: |[8 Regression] Performance
   |loop no longer vectorized   |regression: loop no longer
   |(x86-64)|vectorized (x86-64)
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Started with r258036.

[Bug fortran/84963] [8 Regression] ICE in get_constraint_for_ssa_var, at tree-ssa-structalias.c:2955

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
  Known to work||7.3.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2018-03-20
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |8.0
  Known to fail||8.0

--- Comment #1 from Martin Liška  ---
Mine, starting with r258480.

[Bug middle-end/84955] [7/8 Regression] ICE in substitute_and_fold_dom_walker, at tree-ssa-propagate.c:1089

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||openacc, wrong-code
   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-20
  Component|fortran |middle-end
   Target Milestone|--- |7.4
 Ever confirmed|0   |1

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

;;   basic block 11, loop depth 0
;;pred:   22
;;23
  .offset.14 = (unsigned int) .offset.12;
  .iter.1 = 0 + .offset.14;
  D.3838 = .iter.1 / 10;
  D.3839 = .iter.1 % 10;
  D.3840 = (integer(kind=4)) D.3839;
...
  .e_range.15 = MIN_EXPR ;
  .e_offset.17 = GOACC_LOOP (OFFSET, 1, .e_range.15, .element_s.9, 0, -1, 0);
  .e_bound.16 = GOACC_LOOP (BOUND, 1, .e_range.15, .element_s.9, 0, -1,
.e_offset.17);
  .e_step.18 = GOACC_LOOP (STEP, 1, .e_range.15, .element_s.9, 0, -1);
  if (.e_offset.17 < .e_bound.16)
;;succ:   23

notice we only have a single successor after a GIMPLE_COND.  Looks like this
already after ompexp.

[Bug c++/84964] [8 Regression] ICE in expand_call, at calls.c:4540

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-20
 CC||marxin at gcc dot gnu.org,
   ||rdsandiford at googlemail dot 
com
  Known to work||7.3.0
Summary|internal compiler error: in |[8 Regression] ICE in
   |expand_call, at |expand_call, at
   |calls.c:4540|calls.c:4540
 Ever confirmed|0   |1
  Known to fail||8.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r255921.

Before that:

pr84964.cpp:3:14: warning: width of ‘a::b’ exceeds its type
   short b : -1ULL;
  ^~~~
pr84964.cpp: In function ‘void c(...)’:
pr84964.cpp:5:16: sorry, unimplemented: passing too large argument on stack
 void c(...) { c(a()); }
   ~^

[Bug target/84826] ICE in extract_insn, at recog.c:2304 on arm-linux-gnueabi

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
> So I looked into this. Turns out the actual issue is that USE_RETURN_INSN
> (FALSE) changes its value and becomes false after pass ce3.
> 
> According to what I can see, arm_r3_live_at_start_p() starts to return true
> after ce3.

Right and I think that we can live that.

> My question is:
> 1) Is there any easy way to avoid the false positives from
> arm_r3_live_at_start_p()

I don't think so.

> 2) Why is r3 still live at IN of BB2 when there is no reaching definition of
> it? I mean also there will never be any reaching definition at IN of BB2.

Because r3 is an argument register so it has got an artifical def on entry:

;;  entry block defs 0 [r0] 1 [r1] 2 [r2] 3 [r3] 12 [ip] 13 [sp] 14 [lr]


IMO the issue is that arm_compute_static_chain_stack_bytes changes its value
and this doesn't make sense since whether or not the static chain is pushed
onto the stack is decided once for all at prologue time.  So the fix is
probably to cache the value of the function in the machine_function structure
and return this cached value after prologue/epilogue generation (e.g.
epilogue_completed == 1).

[Bug tree-optimization/84956] ICE in replace_block_by, at tree-ssa-tail-merge.c:1546

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-20
 CC||rguenth at gcc dot gnu.org,
   ||vries at gcc dot gnu.org
  Component|c   |tree-optimization
 Ever confirmed|0   |1
  Known to fail||6.4.1, 7.3.1, 8.0

--- Comment #1 from Richard Biener  ---
Confirmed.  It tries to redirect an abnormal edge 5 -> 7 to 6 where there is
already an abnormal edge from 5 -> 6.

[Bug inline-asm/84966] internal compiler error: verify_gimple failed (verify_gimple_in_cfg())

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-20
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
All releases I have do ICE (4.5.0+).

[Bug fortran/84957] [8 Regression] ICE in gfc_sym_type, at fortran/trans-types.c:2255

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |8.0

[Bug c++/84965] internal compiler error: unexpected expression '__alignof__ (({...}))' of kind alignof_expr

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-20
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, with -std=c++14 all releases 4.9.0+ ICE.

[Bug c++/84960] [8 Regression] ICE in GIMPLE pass: isolate-paths

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug inline-asm/84985] [6/7/8 Regression] internal compiler error: in match_reload, at lra-constraints.c:1068

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-20
 CC||jakub at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
   Target Milestone|--- |6.5
Summary|internal compiler error: in |[6/7/8 Regression] internal
   |match_reload, at|compiler error: in
   |lra-constraints.c:1068  |match_reload, at
   ||lra-constraints.c:1068
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r192719.
Before that it has been rejected with:
pr84985.c: In function ‘main’:
pr84985.c:3:3: error: ‘asm’ operand has impossible constraints
   asm("" : "=d"(a) : "0"(a), "0ae"(&a));
   ^
Only ICEs with -O0, at -O2 it passes.
ICEs even with int a = 1; instead of just int a;, so there is no uninitialized
use.
int main() {
  int a = 1;
  asm("" : "=d"(a) : "0"(a), "0r"(&a));
}
ICEs too, but "=r" or "=a" instead does not.
I don't see anything invalid on it, unless it is just "0"(a), "0"(&a) which is
of course impossible to reload and is properly diagnosed:
pr84985.c: In function ‘main’:
pr84985.c:3:3: error: inconsistent operand constraints in an ‘asm’
   asm("" : "=d"(a) : "0"(a), "0"(&a));
   ^~~

[Bug fortran/84957] [8 Regression] ICE in gfc_sym_type, at fortran/trans-types.c:2255

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-20
 CC||marxin at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
  Known to work||7.3.0
 Ever confirmed|0   |1
  Known to fail||8.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r255094.

[Bug c++/84967] internal compiler error: in process_init_constructor_array, at cp/typeck2.c:1324

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-20
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
With -std=c++14 all starting from 4.9.0+ ICE.

[Bug c++/84968] [8 Regression] ICE in strip_typedefs_expr, at cp/tree.c:1792

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-20
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
  Known to work||7.3.0
   Target Milestone|--- |8.0
Summary|internal compiler error: in |[8 Regression] ICE in
   |strip_typedefs_expr, at |strip_typedefs_expr, at
   |cp/tree.c:1792  |cp/tree.c:1792
 Ever confirmed|0   |1
  Known to fail||8.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r257713.

[Bug jit/84288] Support jit on Solaris

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #6 from David Malcolm  ---
> I'm not sure if r258388 fixes the linker issue on Solaris, but it should make
> it much easier to fix; e.g. to apply your patch here:
>   https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00835.html
> (currently reported as untested)

It did indeed, as I've now found out:

https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00925.html

There are a couple more issues to address, but we're getting there :-)

Thanks.
Rainer

[Bug c++/84970] [8 Regression] ICE in tsubst_copy, at cp/pt.c:15085

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-20
 CC||marxin at gcc dot gnu.org
  Known to work||7.3.0
   Target Milestone|--- |8.0
Summary|internal compiler error: in |[8 Regression] ICE in
   |tsubst_copy, at |tsubst_copy, at
   |cp/pt.c:15085   |cp/pt.c:15085
 Ever confirmed|0   |1
  Known to fail||8.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r248250.

[Bug c++/84971] ICE in build_non_dependent_expr, at cp/pt.c:25367

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-20
 CC||marxin at gcc dot gnu.org
Summary|internal compiler error: in |ICE in
   |build_non_dependent_expr,   |build_non_dependent_expr,
   |at cp/pt.c:25367|at cp/pt.c:25367
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, all starting from 4.7.0+ ICE.

[Bug tree-optimization/84969] [8 Regression] Wrong code with -ftree-loop-distribute-patterns

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed|2018-03-19 00:00:00 |2018-03-20
 Ever confirmed|0   |1

[Bug target/84945] [8 Regression] UBSAN: gcc/config/i386/i386.c:33312:22: runtime error: shift exponent 32 is too large for 32-bit type 'int'

[dcb314 at hotmail dot com]

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

--- Comment #9 from David Binderman  ---

It might be worthwhile putting in some code to detect when the number
of features goes over 64. Maybe a simple assert would be enough.

I suspect there is no need yet to have code to handle the over 64 case.

Just an idea.

[Bug c++/84972] [6/7/8 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in extended_tree, at tree.h:5545

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-20
 CC||marxin at gcc dot gnu.org,
   ||paolo.carlini at oracle dot com
  Known to work||4.9.4
   Target Milestone|--- |6.5
Summary|internal compiler error:|[6/7/8 Regression] ICE:
   |tree check: expected class  |tree check: expected class
   |'type', have 'exceptional'  |'type', have 'exceptional'
   |(error_mark) in |(error_mark) in
   |extended_tree, at   |extended_tree, at
   |tree.h:5545 |tree.h:5545
 Ever confirmed|0   |1
  Known to fail||5.5.0, 6.4.0, 7.3.0

--- Comment #1 from Martin Liška  ---
Confirmed, with -std=c++11 started with r211248.

[Bug c++/84973] [8 Regression] ICE: Segmentation fault (tree_check()/ultimate_transparent_alias_target())

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-20
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
  Known to work||7.3.0
   Target Milestone|--- |8.0
Summary|internal compiler error:|[8 Regression] ICE:
   |Segmentation fault  |Segmentation fault
   |(tree_check()/ultimate_tran |(tree_check()/ultimate_tran
   |sparent_alias_target()) |sparent_alias_target())
 Ever confirmed|0   |1
  Known to fail||8.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r251438.

[Bug c++/84974] [8 Regression] ICE: Segmentation fault (ovl_first()/location_of())

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-20
 CC||marxin at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org
  Known to work||7.3.0
Summary|internal compiler error:|[8 Regression] ICE:
   |Segmentation fault  |Segmentation fault
   |(ovl_first()/location_of()) |(ovl_first()/location_of())
 Ever confirmed|0   |1
  Known to fail||8.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r248250.

[Bug c++/84974] [8 Regression] ICE: Segmentation fault (ovl_first()/location_of())

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug c++/84975] ICE: Segmentation fault (outer_binding()/lookup_name_real_1())

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-20
 CC||marxin at gcc dot gnu.org
Summary|internal compiler error:|ICE: Segmentation fault
   |Segmentation fault  |(outer_binding()/lookup_nam
   |(outer_binding()/lookup_nam |e_real_1())
   |e_real_1()) |
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
With -std=c++11 ICE starting from 4.7.0.

[Bug c++/84977] ICE: Segmentation fault (build_x_unary_op())

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-20
 CC||marxin at gcc dot gnu.org
Summary|internal compiler error:|ICE: Segmentation fault
   |Segmentation fault  |(build_x_unary_op())
   |(build_x_unary_op())|
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, ICE with 4.9.0+.

[Bug c++/84976] ICE: Segmentation fault (cp_build_modify_expr())

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-20
 CC||marxin at gcc dot gnu.org
Summary|internal compiler error:|ICE: Segmentation fault
   |Segmentation fault  |(cp_build_modify_expr())
   |(cp_build_modify_expr())|
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, with -std=c++14 ICE on 4.9.0+.

[Bug target/84945] [8 Regression] UBSAN: gcc/config/i386/i386.c:33312:22: runtime error: shift exponent 32 is too large for 32-bit type 'int'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

[jakub at gcc dot gnu.org]

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

Bug 84945 Summary: [8 Regression] UBSAN: gcc/config/i386/i386.c:33312:22: 
runtime error: shift exponent 32 is too large for 32-bit type 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84945

   What|Removed |Added

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

[Bug c++/84961] [7/8 Regression] ICE error: SSA_NAME_DEF_STMT is wrong

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |ice-on-valid-code
   Priority|P3  |P2
 Status|NEW |ASSIGNED
 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
So we do

  tret = gimplify_expr (&TREE_VALUE (link), pre_p, post_p,
is_inout ? is_gimple_min_lval : is_gimple_lvalue,
fb_lvalue | fb_mayfail);

and gimplify b = (double) a to _3 with is_gimple_lvalue.  Which it isn't
here (the predicate returns true though).

With a similar

int main()
{
  int a,b,c;
  (b = c) = a;
}

the FE already replaces this with <> so it doesn't reach
gimplification.  It seems it expects the gimplifier to do this here.

Note the C FE complains:

t.c: In function ‘c’:
t.c:3:12: error: lvalue required in asm statement
 void c() { asm("" : "=a"(b = a)); }
^~~

but still throws the invalid asm at the gimplifier.  The C++ FE fails to
complain, but I guess (b = a) is an lvalue for C++?  In which case the
testcase would be valid C++ but invalid C?  G++ 6 accepts it.

The above testcase is genericized to

  <;

but the asm stays

<>;

I think the C++ FE should help us here by genericizing to b = (double) a; b?

[Bug c++/84962] [8 Regression] ICE in get_fns, at cp/tree.c:2505

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug fortran/84615] [8 Regression] Executable Segfault for some tests compiled with -m32 after r256284

[jb at gcc dot gnu.org]

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

--- Comment #16 from Janne Blomqvist  ---
The following patch regtests cleanly on x86_64-pc-linux-gnu, i686-pc-linux-gnu,
and successfully passes the #c5 testcase on i686 with -fdefault-real8, and the
#c8 testcase on i686 (I didn't test other testcases).

diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 54bda1d..bf19ac3 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -5974,8 +5974,9 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
  gfc_add_block_to_block (&se->post, &parmse.post);
  tmp = parmse.expr;
  tmp = fold_build2_loc (input_location, MAX_EXPR,
-TREE_TYPE (tmp), tmp,
-build_zero_cst (TREE_TYPE (tmp)));
+gfc_charlen_type_node,
+fold_convert (gfc_charlen_type_node, tmp),
+build_zero_cst (gfc_charlen_type_node));
  cl.backend_decl = tmp;
}

Dominique, can you check whether it also fixes the other -fdefault-real-8 -m32
issues caused by r256284?

[Bug c++/84984] ICE: in build2, at tree.c:4686

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-20
 CC||marxin at gcc dot gnu.org
Summary|internal compiler error: in |ICE: in build2, at
   |build2, at tree.c:4686  |tree.c:4686
 Ever confirmed|0   |1
  Known to fail||8.0

--- Comment #1 from Martin Liška  ---
Confirmed on trunk, however I can't bisect that.

[Bug inline-asm/84985] ICE in match_reload, at lra-constraints.c:1068

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
   Target Milestone|6.5 |---
Summary|[6/7/8 Regression] internal |ICE in match_reload, at
   |compiler error: in  |lra-constraints.c:1068
   |match_reload, at|
   |lra-constraints.c:1068  |

--- Comment #2 from Martin Liška  ---
With -std=c++14 ICE on 4.9.0+.

[Bug c++/71638] [6/7/8 Regression] ICE on invalid C++ code on x86_64-linux-gnu with -Wall (internal compiler error: non-constant element in constant CONSTRUCTOR)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/84964] [8 Regression] ICE in expand_call, at calls.c:4540

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||error-recovery
   Priority|P3  |P4
   Target Milestone|--- |8.0

--- Comment #2 from Richard Biener  ---
I think sorry () triggers error-recovery

[Bug fortran/84963] [8 Regression] ICE in get_constraint_for_ssa_var, at tree-ssa-structalias.c:2955

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
We run into

2949  /* Canonicalize the PT uid of all aliases to the ultimate
target.
2950 ???  Hopefully the set of aliases can't change in a way
that
2951 changes the ultimate alias target.  */
2952  gcc_assert ((! DECL_PT_UID_SET_P (node->decl)
2953   || DECL_PT_UID (node->decl) == DECL_UID
(node->decl))
2954  && (! DECL_PT_UID_SET_P (t)
2955  || DECL_PT_UID (t) == DECL_UID
(node->decl)));

-fno-ipa-icf fixes it.

[Bug c++/84978] [8 Regression] ICE in cxx_eval_constant_expression at gcc/cp/constexpr.c:4109

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
  Known to work||7.3.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2018-03-20
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ice in  |[8 Regression] ICE in
   |cxx_eval_constant_expressio |cxx_eval_constant_expressio
   |n at|n at
   |gcc/cp/constexpr.c:4109 |gcc/cp/constexpr.c:4109
   Target Milestone|--- |8.0
  Known to fail||8.0

--- Comment #2 from Martin Liška  ---
Confirmed, started with r258592.

[Bug c++/84968] [8 Regression] ICE in strip_typedefs_expr, at cp/tree.c:1792

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug c++/84980] [concepts] ICE with missing typename in concept

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-20
 CC||marxin at gcc dot gnu.org
Summary|[concepts] ICE with missing |[concepts] ICE with missing
   |typename in cocept  |typename in concept
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Confirmed.

[Bug c++/84979] [6/7/8 Regression] ICE with auto as template parameter and -fconcepts

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-20
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug c++/84972] [6/7/8 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in extended_tree, at tree.h:5545

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||error-recovery
   Priority|P3  |P4

[Bug c++/84970] [8 Regression] ICE in tsubst_copy, at cp/pt.c:15085

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||error-recovery
   Priority|P3  |P4

[Bug c++/84974] [8 Regression] ICE: Segmentation fault (ovl_first()/location_of())

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||error-recovery
   Priority|P3  |P4

[Bug c++/84973] [8 Regression] ICE: Segmentation fault (tree_check()/ultimate_transparent_alias_target())

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug c++/84979] [6/7/8 Regression] ICE with auto as template parameter and -fconcepts

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |6.5

[Bug tree-optimization/84935] FAIL: gcc.dg/tree-ssa/pr84512.c scan-tree-dump optimized "return 285;"

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||ebotcazou at gcc dot gnu.org

--- Comment #7 from Eric Botcazou  ---
> Similar as with nvptx.  Yes, DOM doesn't handle this while FRE would.

Same on SPARC too.

[Bug c++/84961] [7/8 Regression] ICE error: SSA_NAME_DEF_STMT is wrong

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Doesn't ICE with C, where it is rejected with:
pr84961.c: In function ‘foo’:
pr84961.c:3:15: error: lvalue required in asm statement
 void foo () { asm("" : "=a"(b = a)); }
   ^~~
pr84961.c:3:15: error: invalid lvalue in asm output 0
But in C++ b = a seems to be considered as lvalue.
Let me have a look...

[Bug tree-optimization/84982] [8 Regression] logically inverting bools into local array results in bitwise negation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Keywords||wrong-code
   Last reconfirmed||2018-03-20
  Component|c   |tree-optimization
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|logically inverting bools   |[8 Regression] logically
   |into local array results in |inverting bools into local
   |bitwise negation|array results in bitwise
   ||negation
   Target Milestone|--- |8.0

--- Comment #1 from Richard Biener  ---
Confirmed.  store-merging at play.

@@ -8,14 +12,17 @@
   _Bool _2;
   _Bool _3;
   _Bool _4;
+  unsigned short _11;
+  unsigned short _12;

[local count: 1073741825]:
   _1 = t_6(D)->a;
   _2 = ~_1;
-  flags[0] = _2;
   _3 = t_6(D)->b;
   _4 = ~_3;
-  flags[1] = _4;
+  _11 = MEM[(_Bool *)t_6(D)];
+  _12 = ~_11;
+  MEM[(_Bool *)&flags] = _12;

[Bug target/84986] [8 Regression] Performance regression: loop no longer vectorized (x86-64)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

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

[Bug inline-asm/84985] [6/7/8 Regression] ICE in match_reload, at lra-constraints.c:1068

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |6.5

[Bug target/84954] [nvptx] prevent_branch_around_nothing doesn't trigger often enough

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries  ---
Author: vries
Date: Tue Mar 20 09:14:07 2018
New Revision: 258674

URL: https://gcc.gnu.org/viewcvs?rev=258674&root=gcc&view=rev
Log:
[nvptx] Fix prevent_branch_around_nothing

2018-03-20  Tom de Vries  

PR target/84954
* config/nvptx/nvptx.c (prevent_branch_around_nothing): Also update
seen_label if seen_label is already set.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/nvptx/nvptx.c

[Bug c++/84964] [8 Regression] ICE in expand_call, at calls.c:4540

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||rsandifo at gcc dot gnu.org

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

[Bug tree-optimization/84982] [8 Regression] logically inverting bools into local array results in bitwise negation

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug target/84954] [nvptx] prevent_branch_around_nothing doesn't trigger often enough

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org
   Target Milestone|--- |8.0

--- Comment #3 from Tom de Vries  ---
Patch committed, marking resolved-fixed.

[Bug target/84954] [nvptx] prevent_branch_around_nothing doesn't trigger often enough

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #4 from Tom de Vries  ---
> marking resolved-fixed.

And ... done.

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #65 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #62 from Richard Biener  ---
> Waiting for Solaris engineer input...  (or a machine to be able to debug this

I'll send it along shortly: just didn't manage to in time before my vacation.

> directly - is there one on the CF?).

Not yet: I do have two Solaris 11 zones (both sparc and x86) that are
meant to either be included in the CF or at least mimic closely how that
is setup.  Just need to figure out how to deal with account management
and some sort of AUP acceptance required by university regulations.  The
latter requirement (and the amount of control ceded to CF admins) may
well forbid full inclusion, though.

Rainer

[Bug c/84987] New: ice in vectorizable_reduction with -O3

[dcb314 at hotmail dot com]

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

Bug ID: 84987
   Summary: ice in vectorizable_reduction with -O3
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 43715
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43715&action=edit
C source code

The attached C code seems to cause a crash with flag -O3:

$ ../results/bin/gcc -c -w -O3 bug423.c
during GIMPLE pass: vect
quvi.c: In function ‘main’:
quvi.c:1058:5: internal compiler error: Segmentation fault
0xdafbbf crash_signal
../../trunk/gcc/toplev.c:325
0x10b7566 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../trunk/gcc/tree.h:3134
0x10b7566 vectorizable_reduction(gimple*, gimple_stmt_iterator*, gimple**,
_slp_tree*, _slp_instance*)
../../trunk/gcc/tree-vect-loop.c:6858
0x10aba9d vect_analyze_stmt(gimple*, bool*, _slp_tree*, _slp_instance*)
../../trunk/gcc/tree-vect-stmts.c:9378

This seems to have been happening since sometime before revision 257549.

I'll have a go at reducing the code.

[Bug target/84986] [8 Regression] Performance regression: loop no longer vectorized (x86-64)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
So we now have

  Scalar iteration cost: 4

computed from

  _3 = (long int) i_15;
  a_10 = a_16 - _3;

and ix86_add_stmt_cost has

50464   case NOP_EXPR:
50465 stmt_cost = 0;
50466 break;

for the HImode -> DImode sign-extension.  The scalar codegen generates
movswl so that's definitely not zero cost.  Likewise it would cost
a float <-> double conversions as zero.  I think the only zero-cost
conversions are sign-conversions.  With that fixed we get

t.c:6:9: note: Cost model analysis:
  Vector inside of loop cost: 44
  Vector prologue cost: 64
  Vector epilogue cost: 44
  Scalar iteration cost: 8
  Scalar outside cost: 8
  Vector outside cost: 108
  prologue iterations: 0
  epilogue iterations: 4
  Calculated minimum iters for profitability: 32
t.c:6:9: note:   Runtime profitability threshold = 32
t.c:6:9: note:   Static estimate profitability threshold = 37

which is a worse estimate than from GCC7 which had

t.c:6:9: note: Cost model analysis:
  Vector inside of loop cost: 14
  Vector prologue cost: 14
  Vector epilogue cost: 23
  Scalar iteration cost: 5
  Scalar outside cost: 1
  Vector outside cost: 37
  prologue iterations: 0
  epilogue iterations: 4
  Calculated minimum iters for profitability: 9
t.c:6:9: note:   Runtime profitability threshold = 8
t.c:6:9: note:   Static estimate profitability threshold = 8

that's likely because of the relative increase of the prologue costs
of the vector constant loads and not accounting any costs for the
constants in the scalar code (x86 can handle constant operands in the
instructions for scalar code).

I am testing the following patch:

Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c  (revision 258674)
+++ gcc/config/i386/i386.c  (working copy)
@@ -50462,7 +50462,11 @@ ix86_add_stmt_cost (void *data, int coun
  }
  break;
case NOP_EXPR:
- stmt_cost = 0;
+ /* Only sign-conversions are free.  */
+ if (tree_nop_conversion_p
+   (TREE_TYPE (gimple_assign_lhs (stmt_info->stmt)),
+TREE_TYPE (gimple_assign_rhs1 (stmt_info->stmt
+   cost = 0;
  break;

case BIT_IOR_EXPR:

[Bug sanitizer/78651] Incorrect exception handling when catch clause uses local class and PIC and sanitizer are active

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #8 from ktkachov at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #7)
> Author: jakub
> Date: Mon Mar 19 20:48:39 2018
> New Revision: 258664
> 
> URL: https://gcc.gnu.org/viewcvs?rev=258664&root=gcc&view=rev
> Log:
>   PR sanitizer/78651
>   * dwarf2asm.c: Include fold-const.c.
>   (dw2_output_indirect_constant_1): Set DECL_INITIAL (decl) to ADDR_EXPR
>   of decl rather than decl itself.
> 
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/dwarf2asm.c

After this commit I'm seeing some ICEs on aarch64:
g++.dg/torture/stackalign/eh-inline-2.C
g++.dg/torture/stackalign/eh-global-1.C
g++.dg/torture/stackalign/eh-vararg-1.C
g++.dg/torture/stackalign/eh-vararg-2.C
g++.dg/torture/stackalign/eh-inline-1.C
g++.dg/torture/stackalign/eh-alloca-1.C
g++.dg/torture/pr49115.C

For example:
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (internal compiler error)

The ICEs are of the form:
lto1: internal compiler error: in assemble_variable, at varasm.c:2297
0xe75449 assemble_variable(tree_node*, int, int, int)
$SRC/gcc/varasm.c:2297
0x70bda6 dw2_output_indirect_constant_1
$SRC/gcc/dwarf2asm.c:976
0x70bda6 dw2_output_indirect_constants()
$SRC/gcc/dwarf2asm.c:999
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/84988] New: Compiler hang in chkp_type_bounds_count for large arrays

[rsandifo at gcc dot gnu.org]

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

Bug ID: 84988
   Summary: Compiler hang in chkp_type_bounds_count for large
arrays
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---

Trying a variation of PR84964, I noticed that:

struct a {
  int b[(1ULL << 60)];
};
void c(...) { c(a()); }

caused the compiler to loop "forever" (but not really) in
chkp_type_bounds_count on x86_64.  While that might not matter for test cases
like this, it seems like we might be doing unnecessary work in general.

[Bug c++/84978] [8 Regression] ICE in cxx_eval_constant_expression at gcc/cp/constexpr.c:4109

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Better test:

// PR c++/84978

struct S {
  void (*fn)(void);
  int i;
  long l;
};

S
foo ()
{
  S s;
  s.fn ();
  return s;
}

[Bug c++/84961] [7/8 Regression] ICE error: SSA_NAME_DEF_STMT is wrong

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Created attachment 43716
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43716&action=edit
gcc8-pr84961.patch

So like this?  Or of course the gimplifier could do it too.
The second testcase passed e.g. with 4.4, but fails already with 4.6, the first
one regressed later with the SSA_NAME gimplification.

[Bug target/84952] [nvptx] bar.sync generated in divergent code

[vries at gcc dot gnu.org]

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

--- Comment #9 from Tom de Vries  ---
Author: vries
Date: Tue Mar 20 10:31:23 2018
New Revision: 258676

URL: https://gcc.gnu.org/viewcvs?rev=258676&root=gcc&view=rev
Log:
[nvptx] Fix bar.sync position

2018-03-20  Tom de Vries  

PR target/84952
* config/nvptx/nvptx.c (nvptx_single): Don't neuter bar.sync.
(nvptx_process_pars): Emit bar.sync asap and alap.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/nvptx/nvptx.c

[Bug c++/84989] New: _mm512_broadcast_f32x4 triggers internal compiler bug

[m...@sven-woop.de]

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

Bug ID: 84989
   Summary: _mm512_broadcast_f32x4 triggers internal compiler bug
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m...@sven-woop.de
  Target Milestone: ---

Created attachment 43717
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43717&action=edit
reproducer

The following code produces an internal compiler error:

__m512 occluded(float a, float* b) {
  return _mm512_sub_ps(_mm512_broadcast_f32x4(_mm_load_ps(b)),  
   _mm512_broadcast_f32x4(_mm_set1_ps(a)));
}

[Bug c++/84961] [7/8 Regression] ICE error: SSA_NAME_DEF_STMT is wrong

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Tue, 20 Mar 2018, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84961
> 
> Jakub Jelinek  changed:
> 
>What|Removed |Added
> 
>  CC||jakub at gcc dot gnu.org
> 
> --- Comment #4 from Jakub Jelinek  ---
> Created attachment 43716
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43716&action=edit
> gcc8-pr84961.patch
> 
> So like this?

Yes.

> Or of course the gimplifier could do it too.

Sure, I tried and it looks somewhat awkward to teach it this.  Is
a MODIFY_EXPR in GENERIC considered an lvalue?  I think not.

> The second testcase passed e.g. with 4.4, but fails already with 4.6, the 
> first
> one regressed later with the SSA_NAME gimplification.

Yeah, I think pre SSA_NAME gimplification we'd just generate wrong-code
eventually and not notice.

[Bug c++/84964] [8 Regression] ICE in expand_call, at calls.c:4540

[rsandifo at gcc dot gnu.org]

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
I think the difference is that pending_stack_adjust and stack_pointer_delta
used to be int-based rather than HWI-based, so the size of the stack allocation
was previously truncated to from 1<<61 to 0.

[Bug c++/84962] [8 Regression] ICE in get_fns, at cp/tree.c:2505

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug c++/84970] [8 Regression] ICE in tsubst_copy, at cp/pt.c:15085

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug target/84990] New: [8 Regression] Boostrap broken with --enable-checking=release and Ada

[rguenth at gcc dot gnu.org]

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

Bug ID: 84990
   Summary: [8 Regression] Boostrap broken with
--enable-checking=release and Ada
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64le-linux, powerpc64-linux

[   59s] + ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go --enable-checking=release
--disable-werror --with-gxx-include-dir=/usr/include/c++/8 --enable-ssp
--disable-libssp --disable-libvtv --disable-libmpx --disable-cet
--disable-libcc1 --enable-plugin --with-bugurl=http://bugs.opensuse.org/
'--with-pkgversion=SUSE Linux' --with-slibdir=/lib64 --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-8 --without-system-libunwind --with-cpu-64=power4
--enable-secureplt --with-long-double-128 --build=powerpc64-suse-linux
--host=powerpc64-suse-linux
...
[ 1614s] +===GNAT BUG
DETECTED==
+
[ 1614s] | 8.0.1 20180320 (experimental) [trunk revision 258674]
(powerpc64-suse
-linux) GCC error:|
[ 1614s] | in assemble_variable, at varasm.c:2297   
|
[ 1614s] | Error detected around ../../gcc/ada/libgnat/s-rident.ads:75:16   
|
[ 1614s] | Please submit a bug report; see https://gcc.gnu.org/bugs/ .  
...
[ 1614s] raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:407
[ 1614s] make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:140: ada/ali.o] 
Error 1
[ 1614s] make[3]: *** Waiting for unfinished jobs

[Bug c++/84974] [8 Regression] ICE: Segmentation fault (ovl_first()/location_of())

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug target/84990] [8 Regression] Boostrap broken with --enable-checking=release and Ada

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |8.0

--- Comment #1 from Richard Biener  ---
See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78651#c8

[Bug target/84990] [8 Regression] Boostrap broken with --enable-checking=release and Ada

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Target|powerpc64le-linux,  |powerpc64*-*-*, aarch64-*-*
   |powerpc64-linux |

--- Comment #2 from Andreas Schwab  ---
Same error on aarch64.

[Bug target/82989] [6/7/8 regression] Inexplicable use of NEON for 64-bit math

[sudi at gcc dot gnu.org]

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

--- Comment #21 from sudi at gcc dot gnu.org ---
Author: sudi
Date: Tue Mar 20 10:54:42 2018
New Revision: 258677

URL: https://gcc.gnu.org/viewcvs?rev=258677&root=gcc&view=rev
Log:
[ARM][PR82989] Fix unexpected use of NEON instructions for shifts

This patch fixes PR82989 so that we avoid NEON instructions when
-mneon-for-64bits is not enabled. This is more of a short term fix
for the real deeper problem of making an early decision of choosing
or rejecting NEON instructions. There is now a new ticket PR84467 to
deal with the longer term solution.
(Please refer to the discussion in the bug report for more details).

Sudi

*** gcc/ChangeLog ***

2018-03-20  Sudakshina Das  

PR target/82989
* config/arm/neon.md (ashldi3_neon): Update ?s for constraints
to favor GPR over NEON registers.
(di3_neon): Likewise.

*** gcc/testsuite/ChangeLog ***

2018-03-20  Sudakshina Das  

PR target/82989
* gcc.target/arm/pr82989.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr82989.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/neon.md
trunk/gcc/testsuite/ChangeLog

[Bug target/84990] [8 Regression] Boostrap broken with --enable-checking=release and Ada

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

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

--- Comment #3 from Andreas Schwab  ---
And I didn't use --enable-checking=release on aarch64.

[Bug target/84845] [8 Regression] ICE: in extract_insn, at recog.c:2304: unrecognizable insn at -O2 and above at aarch64

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar 20 10:59:26 2018
New Revision: 258678

URL: https://gcc.gnu.org/viewcvs?rev=258678&root=gcc&view=rev
Log:
PR target/84845
* config/aarch64/aarch64.md (*aarch64_reg_3_neg_mask2): Rename
to ...
(*aarch64__reg_3_neg_mask2): ... this.  If pseudos can't
be created, use lowpart_subreg of operands[0] rather than operands[0]
itself.
(*aarch64_reg_3_minus_mask): Rename to ...
(*aarch64_ashl_reg_3_minus_mask): ... this.
(*aarch64__reg_di3_mask2): Use const_int_operand predicate
and n constraint instead of aarch64_shift_imm_di and Usd.
(*aarch64_reg__minus3): Rename to ...
(*aarch64__reg_minus3): ... this.

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

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr84845.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.md
trunk/gcc/testsuite/ChangeLog

[Bug c/84987] ice in vectorizable_reduction with -O3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #1 from Richard Biener  ---
Doesn't reproduce for me on trunk, maybe a dup of PR84913.

[Bug target/84990] [8 Regression] Boostrap broken with --enable-checking=release and Ada

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 43718
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43718&action=edit
gcc8-pr84990.patch

Can't reproduce with a cross, but just from the ICE line I guess this could fix
it.  There is no point to use section-anchors for these artificial variables,
and we weren't using them before either, just through a hack for the
DECL_INITIAL (decl) == decl which I've changed.

[Bug rtl-optimization/84989] _mm512_broadcast_f32x4 triggers ICE in simplify_const_unary_operation, at simplify-rtx.c:1731

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-20
  Component|c++ |rtl-optimization
Summary|_mm512_broadcast_f32x4  |_mm512_broadcast_f32x4
   |triggers internal compiler  |triggers ICE in
   |bug |simplify_const_unary_operat
   ||ion, at simplify-rtx.c:1731
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed with -O2 -mavx512f.

> ./cc1plus -quiet gcc_8_0_1_broadcast/bug.cpp  -I include -mavx512f -O2
during RTL pass: fwprop1
gcc_8_0_1_broadcast/bug.cpp: In function ‘__m512 occluded(float, float*)’:
gcc_8_0_1_broadcast/bug.cpp:5:1: internal compiler error: in
simplify_const_unary_operation, at simplify-rtx.c:1731
 }
 ^
0x1231bb7 simplify_const_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
/space/rguenther/src/svn/early-lto-debug/gcc/simplify-rtx.c:1731
0x122e5c7 simplify_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
/space/rguenther/src/svn/early-lto-debug/gcc/simplify-rtx.c:879
0x1231aad simplify_unary_operation_1
/space/rguenther/src/svn/early-lto-debug/gcc/simplify-rtx.c:1712
0x122e5eb simplify_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
/space/rguenther/src/svn/early-lto-debug/gcc/simplify-rtx.c:883
0x122cb51 simplify_gen_unary(rtx_code, machine_mode, rtx_def*, machine_mode)
/space/rguenther/src/svn/early-lto-debug/gcc/simplify-rtx.c:378
0x1dd616d propagate_rtx_1
/space/rguenther/src/svn/early-lto-debug/gcc/fwprop.c:497

[Bug rtl-optimization/84989] [8 Regression] _mm512_broadcast_f32x4 triggers ICE in simplify_const_unary_operation, at simplify-rtx.c:1731

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
  Known to work||7.3.1
   Target Milestone|--- |8.0
Summary|_mm512_broadcast_f32x4  |[8 Regression]
   |triggers ICE in |_mm512_broadcast_f32x4
   |simplify_const_unary_operat |triggers ICE in
   |ion, at simplify-rtx.c:1731 |simplify_const_unary_operat
   ||ion, at simplify-rtx.c:1731

--- Comment #2 from Richard Biener  ---
Happens to work on the branch.

[Bug tree-optimization/84913] ICE vectorising chained conditional reduction

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #4 from David Binderman  ---
*** Bug 84987 has been marked as a duplicate of this bug. ***

[Bug c/84987] ice in vectorizable_reduction with -O3

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

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

--- Comment #2 from David Binderman  ---
(In reply to Richard Biener from comment #1)
> Doesn't reproduce for me on trunk, maybe a dup of PR84913.

Agreed. Seems broken at 258623, but fixed at 258673.

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

[Bug target/84990] [8 Regression] Boostrap broken with --enable-checking=release and Ada

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Tue, 20 Mar 2018, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84990
> 
> --- Comment #4 from Jakub Jelinek  ---
> Created attachment 43718
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43718&action=edit
> gcc8-pr84990.patch
> 
> Can't reproduce with a cross, but just from the ICE line I guess this could 
> fix
> it.  There is no point to use section-anchors for these artificial variables,
> and we weren't using them before either, just through a hack for the
> DECL_INITIAL (decl) == decl which I've changed.

LGTM.

[Bug c++/84978] [8 Regression] ICE in cxx_eval_constant_expression at gcc/cp/constexpr.c:4109

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
This ICE apparently depends on whether we perform NRVO or not.  If the size of
S is <=16B we pass it in registers and it compiles fine.  But if the size of S
is >16B, then we pass in memory, and we NRV-optimize.  That means that
s.fn ();
is after finalize_nrv
.fn ();

Then the newly added call to cp_get_callee_fndecl in cp_genericize_r calls
maybe_constant_init, which ends up evaluating , but it's not in the
hash map, so we crash here:
4111   /* We ask for an rvalue for the RESULT_DECL when indirecting
4112  through an invisible reference, or in named return value
4113  optimization.  */
4114   return (*ctx->values->get (t));

[Bug target/84988] Compiler hang in chkp_type_bounds_count for large arrays

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-03-20
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, we should probably bound maximum size of an array that is checked:

  1736for (cur = 0; cur <= TREE_INT_CST_LOW (maxval); cur++)
  1737  chkp_find_bound_slots_1 (etype, have_bound, offs + cur *
esize);

Note the MPX will be removed in next stage1. Thus I would suggest not to come
up with a param.

Let me cook a patch.

[Bug c++/84978] [8 Regression] ICE in cxx_eval_constant_expression at gcc/cp/constexpr.c:4109

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
So we can be more careful there and do:

--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -4111,7 +4111,15 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx,
tree t,
   /* We ask for an rvalue for the RESULT_DECL when indirecting
 through an invisible reference, or in named return value
 optimization.  */
-  return (*ctx->values->get (t));
+  if (tree *p = ctx->values->get (t))
+   return *p;
+  else
+   {
+ if (!ctx->quiet)
+   error ("%qE is not a constant expression", t);
+ *non_constant_p = true;
+   }
+  break;

 case VAR_DECL:
   if (DECL_HAS_VALUE_EXPR_P (t))

[Bug target/84952] [nvptx] bar.sync generated in divergent code

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org
   Target Milestone|--- |8.0

--- Comment #10 from Tom de Vries  ---
(In reply to Tom de Vries from comment #7)
> Created attachment 43708 [details]
> 0002-Verify-bar.sync-position.patch (stage4)

I've put this patch on my stage1 commit branch.

Marking resolved-fixed.

[Bug c++/83258] Rejecting function pointer non-type template parameter without linkage

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||xaxxon at gmail dot com

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