This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch RFC] SH: Use FRAME_GROWS_DOWNWARD


>> Regression testing should cover at least one target without fp, and one with
>> double precision fp, and one big and one little endian target.  E.g. I 
>> commonly use
>> the default (SH1 big endian) and "-m4 -ml" (SH4 little endian) to get 
>> this coverage.
>> If you've already run the gcc/g++/objc regression tests on sh4-linux, we 
>> can count this
>> towards the floating point and little endian testing.
> 
> I'll try it.  Can I assume your patch for PR rtl-optimization/22258
> in http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00053.html?
> Without it, I can't build the mainline for multilibbed sh-elf.

There is one regression for sh-elf/-m4 and sh-elf/-m4/-ml

  gcc.c-torture/execute/stdarg-2.c execution,  -O2

and one regression for sh-elf and sh-elf/-ml:

  gcc.dg/builtin-apply4.c execution test

though it seems that both tests passed on the unpatched compiler
accidentally.  With the patched compiler, stdarg-2.c fails
with sh-elf/-m4 -O2 at the last part of the various tests and
the reduced testcase

--
#include <stdarg.h>

extern void abort (void);

int foo_arg, bar_arg;

void
foo (int v, va_list ap)
{
  foo_arg = va_arg (ap, int);
  foo_arg += va_arg (ap, long double);
}

struct A { int i; va_list g; va_list h[2]; };

void
f12 (int i, ...)
{
  struct A a;
  va_start (a.h[1], i);
  foo (i, a.h[1]);
  va_end (a.h[1]);
}

int
main (void)
{
  f12 (11, 2030, 12.0L);
  if (foo_arg != 2042)
    abort ();
  return 0;
}
--

which is the last test of stdarg-2.c fails with -O2 even
for the unpatched compiler.  I don't look it further yet.

builtin-apply4.c passes with -O2 but fails with -O0 on the
unpatched one.  It calls a function which returns a double
via __builtin_apply and __builtin_return:

double
foo (int arg)
{
  return arg + 1;
}

inline double
bar (int arg)
{
  __builtin_return (__builtin_apply ((void (*) ()) foo,
				     __builtin_apply_args (), 16));
}

Soft-float sh-elf uses r0/r1 pair for the double result and
it looks that the __builtin_return handles only one hardware
resister unless untype_call pattern is defined.  Then if r1
is used for something after calling foo, the result is
clobbered.  It seems to be the case for the unpatched compiler
with -O0:

	jsr	@r0		; <- call foo
	nop
	mov.l	r0,@(28,r14)
	mov	r8,r15
	mov	r14,r1
	add	#28,r1
	mov.l	@r1,r0
	add	#32,r14
	mov	r14,r15
	lds.l	@r15+,pr
	...

and this is optimized to

	jsr	@r8
	mov.l	@(4,r14),r2
	mov.l	r0,@(24,r14)
	mov	r9,r15
	mov.l	@(24,r14),r0
	add	#28,r14
	mov	r14,r15
	lds.l	@r15+,pr
	...

with -O2 and gets rid of the failure by luck.

BTW, it's curious that the patched compiler can't optimize
the corresponding code at -O2.  The output of the patched
one with -O2 is:

	jsr	@r10
	mov.l	@(4,r9),r2
	mov.l	r0,@(36,r8)
	mov	r14,r1
	mov.l	@r14,r0
	mov	r11,r15
	add	#28,r14
	mov	r14,r15
	lds.l	@r15+,pr
	...

Regards,
	kaz


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]