https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81877
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> --- For DO CONCURRENT( I=ABS(LS-LE):MIN(LS+LE,7):2 ) CALL THREEJ(LO,LE,LE,0,0,0,C) CALL THREEJ(LO,LE,LE,0,0,0,C) END DO B=0. DO CONCURRENT( I=ABS(LS-LE):MIN(LS+LE,7):2 ) CALL THREEJ(LO,LE,LE,MO,-2*MO-1,MO+1,C) B = B + C END DO the FE annotates both loops with IVDEP: if (forall_tmp->do_concurrent) cond = build2 (ANNOTATE_EXPR, TREE_TYPE (cond), cond, build_int_cst (integer_type_node, annot_expr_ivdep_kind)); but this seems to have an adverse effect in case the last threej is inlined (which it is only in case the first two are ipa-cp'ed). Ok, so we have <mem_ref 0x7ffff6774c30 type <real_type 0x7ffff68ac348 real(kind=4) SF size <integer_cst 0x7ffff6891e28 constant 32> unit size <integer_cst 0x7ffff6891e40 constant 4> align 32 symtab 0 alias set 1 canonical type 0x7ffff68ac348 precision 32 pointer_to_this <pointer_type 0x7ffff68ac888> reference_to_this <reference_type 0x7ffff6a74a80>> tree_0 tree_1 arg 0 <addr_expr 0x7ffff677c1e0 type <pointer_type 0x7ffff68ac888 type <real_type 0x7ffff68ac348 real(kind=4)> public unsigned DI size <integer_cst 0x7ffff6891be8 constant 64> unit size <integer_cst 0x7ffff6891c00 constant 8> align 64 symtab 0 alias set 8 canonical type 0x7ffff68ac888> arg 0 <var_decl 0x7ffff6694120 c type <real_type 0x7ffff68ac348 real(kind=4)> addressable used SF file /tmp/t.f90 line 82 col 0 size <integer_cst 0x7ffff6891e28 32> unit size <integer_cst 0x7ffff6891e40 4> align 32 context <function_decl 0x7ffff6a72c00 sub1> chain <var_decl 0x7ffff66941b0 i>> /tmp/t.f90:102:0 start: /tmp/t.f90:102:0 finish: /tmp/t.f90:102:0> arg 1 <integer_cst 0x7ffff669c738 type <reference_type 0x7ffff6a74b28> constant 0>> but then there is c.68_18 = c; <var_decl 0x7ffff6694120 c type <real_type 0x7ffff68ac348 real(kind=4) SF size <integer_cst 0x7ffff6891e28 constant 32> unit size <integer_cst 0x7ffff6891e40 constant 4> align 32 symtab 0 alias set 1 canonical type 0x7ffff68ac348 precision 32 pointer_to_this <pointer_type 0x7ffff68ac888> reference_to_this <reference_type 0x7ffff6a74a80>> addressable used SF file /tmp/t.f90 line 82 col 0 size <integer_cst 0x7ffff6891e28 32> unit size <integer_cst 0x7ffff6891e40 4> align 32 context <function_decl 0x7ffff6a72c00 sub1> chain <var_decl 0x7ffff66941b0 i>> which is not detected as equal and things go haywire (alias analysis would detect they alias but we have safelen and thus detecting equal things as equal is now a strict requirement!). This is probably a case that can be easily fixed _but_ LIM is not ready to detect, say, a.b.c and MEM[&a + 8] as equal. This means we somehow need to conservatively(!) compute must-aliases to make the safelen handing in LIM safe. Esp. for accesses with non-constant address this is impossible, like in a loop nest (like this) with the outer loop safelen and the LIM pass after IV optimization which might re-write things in a way that a) isn't fully consistent, b) can have un-CSEd expressions. Bah. Now - the special case above is sth to fix anyways (for !safelen this will result in a missed store motion). Will poke at this a bit.