On Wed, Jun 15, 2016 at 11:00:22AM +0930, Alan Modra wrote: > On Tue, Jun 14, 2016 at 09:26:19AM -0700, H.J. Lu wrote: > > On Thu, May 26, 2016 at 4:02 AM, Alan Modra <amo...@gmail.com> wrote: > > > This fixes lack of bb_loop_depth info in some of the early parts of > > > ira, which has been the case for quite some time. All active branches > > > return 0 from bb_loop_depth() in update_equiv_regs, but whether that > > > actually causes mis-optimization anywhere but trunk is yet to be > > > determined. > > > > > > I played a little with trying to consolidate this loop_optimizer_init > > > call with one that occurs a little later, but ran into ICEs. (We now > > > have four calls to loop_optimizer_init in ira.c.) > > > > > > Bootstrapped and regression tested powerpc64le-linux and x86_64-linux. > > > OK to apply? > > > > > > PR rtl-optimization/71275 > > > * ira.c (ira): Call loop_optimizer_init to set up bb_loop_depth > > > for update_equiv_regs and combine_and_move_insns. > > > > > > > This caused: > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71531
So, not guilty. Or at least only guilty of exposing another bug. You have a problem with parameter passing. cat > pass.c <<EOF extern int __attribute__ ((pure)) f1 (int, int); int main (void) { if (f1 (1, 0) != 2) __builtin_abort (); if (f1 (1, 1) != 0) __builtin_abort (); return 0; } EOF cat > pass2.c <<EOF int __attribute__ ((pure)) f2 (int); int __attribute__ ((pure)) f1 (int a, int b) { int x = a; if (b) x = -a; return f2 (x + 1); } EOF cat > pass3.c <<EOF int __attribute__ ((pure)) f2 (int a) { return a; } EOF gcc -m32 -march=corei7 -mtune=slm -O2 pass.c pass2.c pass3.c ./a.out Aborted gcc -O2 pass.c pass2.c pass3.c ./a.out > I have an x86 ABI question. Is it correct according to the ABI that > parameter passing stack slots always have the same value on function > exit as they had on entry? > > Between these two calls to _gfortran_string_verify, > if (verify(c4, "A", back = .true.) .ne. 3) call abort > if (verify(c4, "AB") .ne. 0) call abort > it seems that gfortran is assuming that parameters passed on the stack > are unchanged. > > _gfortran_string_verify is a C function, declared as follows in > libgfortran/intrinsics/string_intrinsics_inc.c: > gfc_charlen_type > string_verify (gfc_charlen_type slen, const CHARTYPE *str, > gfc_charlen_type setlen, const CHARTYPE *set, > GFC_LOGICAL_4 back) > > This function happens to modify the stack slot for "slen" to -1 when > "back" is true. > > -- > Alan Modra > Australia Development Lab, IBM -- Alan Modra Australia Development Lab, IBM