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
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
