Trouble with GAS halfword extraction on PPC

Trouble with GAS halfword extraction on PPC

[Peter Barada]

I'm using binutils-2.8/gas configures as follows:

# ./configure  --host=i586-linux-gnu --target=ppc-rtems-eabi --prefix=/usr/local/wave --exec-prefix=/usr/local/wave/ppc --program-prefix=ppc_ --with-gnu-as --with-gnu-ld --nfp --cache-file=../config.cache

And I'm trying to use a macro that concatenates a large number of
constants and then loads it into a register by using lis/ori pair to
get the halfword constants, or using shifts and mods (since gas does
not like & in macros!), but if I try:


        .text
	.align		4
	.extern  	boot_main
	.globl		_START, _boot


	.macro	LWI	reg, value
	lis	\reg, (\value)>>16
	ori	\reg, \reg, (\value)%0x10000
	.endm

	.macro	LWI2	reg, value
	lis	\reg, \value@h
	ori	\reg, \reg, \value@l
	.endm

	.equ	CONST_VALUE	(RAM1<<20)|(RAM2<<16)
_boot:

	addis	r3, 0, (CONST_VALUE)>>16
	ori	r3, CONST_VALUE%0x10000

	LWI	r4, CONST_VALUE
	LWI2	r5, CONST_VALUE
	b	$
	.end


When I pass this through gas, I get:

/tmp/boot2.s: Assembler messages:
/tmp/boot2.s:22: Error: unsupported relocation type
/tmp/boot2.s:23: Error: unsupported relocation type
/tmp/boot2.s:23: Error: unsupported relocation type
/tmp/boot2.s:25: Error: unsupported relocation type
/tmp/boot2.s:25: Error: unsupported relocation type
/tmp/boot2.s:25: Error: unsupported relocation type
/tmp/boot2.s:26: Error: unsupported relocation type
/tmp/boot2.s:26: Error: unsupported relocation type
/tmp/boot2.s:26: Error: unsupported relocation type

So does anyone have a clue how one does this as constants (Yes I know
I can stick it in memory and then load the value, but i'd rather waste
two insns to save the cache load).

THanx in advance,

- -- 
Peter Barada				pbarada@wavemark.com
Wizard					617-270-7098 x1226
WaveMark Technologies, Inc.		617-270-0193 (fax)

"Real men know that you should never attempt to accomplish with words
what you can do with a flame thrower" --Bruce Ferstein

Re: [Q] Who should I talk to?

[Jeffrey A Law]

  In message <Pine.GSO.3.96.970820021136.23730B-100000@rigel.oac.uci.edu>you wr
ite:
  >   I have a question regarding the code generation of gcc 
  >   for i386+ targets.  Is this mailing list the right place
  >   to ask someone to consider changing a minor aspect of
  >   gcc's code generation?
Yes, absolutely.


  >   also:  What is the "haifa" instruction scheduler?  
It is a new instruction scheduler donated by IBM Haifa.

http://www.cygnus.com/egcs

[ ... ]
  > Note to the uninitiated -- haifa-sched.c is a new instruction scheduler
  > donated by IBM Haifa. It is supposed to be able to improve instruction
  > schedules for superscaler machines. It is included in the egcs snapshot
  > in the hopes that someone will work on some of the issues outlined below.
[ ... ]

Re: f771 dies with trivial fortran code

[Jeffrey A Law]

  In message <199708200523.AAA02390@mercury.xraylith.wisc.edu>you write:
  > f771 dumps core on i386-linux-gnulibc1 when compiling the following simple
  > piece of code. Ditto for a cross-compiled i386-cygwin32-g77.
  > 
  > could someone please check on other platforms just so I know that it's not
  > a local problem?
It's the same basic problem I sent mail about, except it showed up
in su2cor from spec92.

Jeff

Re: Trouble with GAS halfword extraction on PPC

[Jeffrey A Law]

  In message <199708201602.MAA02660@miacomet.wavemark.com>you write:
  > So does anyone have a clue how one does this as constants (Yes I know
  > I can stick it in memory and then load the value, but i'd rather waste
  > two insns to save the cache load).
I believe this is happening because the assembler doesn't know the
value for RAM1 or RAM2.

Jeff

Re: f771 dies with trivial fortran code

[Mumit Khan]

Jim Wilson <wilson@cygnus.com> writes:
> This is due to a backend change made since gcc 2.7.2.
> 
[...]
> 
> I have checked in this patch to fix the problem.
> 

Thanks! I just built a relatively messy body of FORTRAN code that seem to
be producing the correct results (not using any optimization yet since any
level of optimization is causing libstdc++ tests to fail).

Mumit

Re: f771 dies with trivial fortran code

[Jim Wilson]

This is due to a backend change made since gcc 2.7.2.

Some code was added to handle C++ destructors inside conditional expressions
differently than they used to be handled.  This apparently was necessary
for correct behaviour, though I don't know exactly what bug was being fixed.
(Perhaps destructors were always run, even if the variable was only constructed
on one side of the conditional expression?)

Anyways, this causes problems if a conditional expression appears inside
the type expression of a parameter.  The code expects us to always have
a binding contour, but we do not have one when parsing the parameters.
Since no destructors are possible in this case, it is safe for us to
do nothing.

A C testcase:

sub (int a, int b, int c[a > b ? a : b])
{
}

A Fortran testcase:

	subroutine foo ()
	character*(*) str
c
	return
c
	entry bar (str)
	str = 'a'
c	^^^^^^^^ culprit
	return
	end
c

I have checked in this patch to fix the problem.

Wed Aug 20 11:58:33 1997  Jim Wilson  <wilson@cygnus.com>

	* stmt.c (start_cleanup_deferal, end_cleanup_deferal): Test
	block_stack before dereferencing it.

Index: stmt.c
===================================================================
RCS file: /cvs/cvsfiles/egcs/stmt.c,v
retrieving revision 1.1.1.1
diff -p -r1.1.1.1 stmt.c
*** stmt.c	1997/08/11 15:57:13	1.1.1.1
--- stmt.c	1997/08/20 18:43:30
*************** expand_cleanups (list, dont_do, in_fixup
*** 4212,4218 ****
  void
  start_cleanup_deferal ()
  {
!   ++block_stack->data.block.conditional_code;
  }
  
  /* Mark the end of a conditional region of code.  Because cleanup
--- 4212,4221 ----
  void
  start_cleanup_deferal ()
  {
!   /* block_stack can be NULL if we are inside the parameter list.  It is
!      OK to do nothing, because cleanups aren't possible here.  */
!   if (block_stack)
!     ++block_stack->data.block.conditional_code;
  }
  
  /* Mark the end of a conditional region of code.  Because cleanup
*************** start_cleanup_deferal ()
*** 4223,4229 ****
  void
  end_cleanup_deferal ()
  {
!   --block_stack->data.block.conditional_code;
  }
  
  /* Move all cleanups from the current block_stack
--- 4226,4235 ----
  void
  end_cleanup_deferal ()
  {
!   /* block_stack can be NULL if we are inside the parameter list.  It is
!      OK to do nothing, because cleanups aren't possible here.  */
!   if (block_stack)
!     --block_stack->data.block.conditional_code;
  }
  
  /* Move all cleanups from the current block_stack

Re: f771 dies with trivial fortran code

[Mumit Khan]

Craig Burley <burley@gnu.ai.mit.edu> writes:
> >f771 dumps core on i386-linux-gnulibc1 when compiling the following simple
> >piece of code. Ditto for a cross-compiled i386-cygwin32-g77.
> >
> >could someone please check on other platforms just so I know that it's not
> >a local problem?
> 
> It doesn't crash on g77-0.5.21-19970818, which is based on a fairly
> heavily modified gcc-2.7.2.2, running on my i486-unknown-linuxaout
> system, FWIW.
> 

Then it might have something to do with the backend. Also crashes on
hppa1.1-hp-hpux10.20, exactly the same place, same problem.

Mumit

Re: f771 dies with trivial fortran code

[Craig Burley]

>f771 dumps core on i386-linux-gnulibc1 when compiling the following simple
>piece of code. Ditto for a cross-compiled i386-cygwin32-g77.
>
>could someone please check on other platforms just so I know that it's not
>a local problem?

It doesn't crash on g77-0.5.21-19970818, which is based on a fairly
heavily modified gcc-2.7.2.2, running on my i486-unknown-linuxaout
system, FWIW.

        tq vm, (burley)

f771 dies with trivial fortran code

[Mumit Khan]

f771 dumps core on i386-linux-gnulibc1 when compiling the following simple
piece of code. Ditto for a cross-compiled i386-cygwin32-g77.

could someone please check on other platforms just so I know that it's not
a local problem?

c ==== f77-bug1.f
	subroutine foo ()
	character*(*) str
c
	return
c
	entry bar (str)
	str = 'a'
c	^^^^^^^^ culprit
	return
	end
c
c ==== END f77-bug1.f

% /scratch/src/gnu/bin/g77 -v -c f77-bug1.f
g77 version 0.5.21-19970811
 /scratch/src/gnu/bin/gcc -v -c f77-bug1.f
Reading specs from /scratch/src/gnu/lib/gcc-lib/i386-linux-gnulibc1/egcs-2.90.00/specs
gcc version egcs-2.90.00 970814 (gcc2-970802 experimental)
 /scratch/src/gnu/lib/gcc-lib/i386-linux-gnulibc1/egcs-2.90.00/f771 f77-bug1.f -fset-g77-defaults -quiet -dumpbase f77-bug1.f -version -fversion -o /tmp/cca32362.s
GNU F77 version egcs-2.90.00 970814 (gcc2-970802 experimental) (i386-linux-gnulibc1) compiled by GNU C version egcs-2.90.00 970814 (gcc2-970802 experimental).
GNU Fortran Front End version 0.5.21-19970811 compiled: Aug 17 1997 12:38:30
gcc: Internal compiler error: program f771 got fatal signal 11
% gdb /scratch/src/gnu/lib/gcc-lib/i386-linux-gnulibc1/egcs-2.90.00/f771 core
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i586-unknown-linux), Copyright 1996 Free Software Foundation, Inc...
Core was generated by `/scratch/src/gnu/lib/gcc-lib/i386-linux-gnulibc1/egcs-2.90.00/f771 f77-bug1.f -fset-`,\x10\b\x03'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libc.so.5.3.12...done.
Reading symbols from /lib/ld-linux.so.1...done.
#0  0x80dadb4 in start_cleanup_deferal () at stmt.c:4215
4215      ++block_stack->data.block.conditional_code;
(gdb) print block_stack
$1 = (struct nesting *) 0x0
(gdb) bt
#0  0x80dadb4 in start_cleanup_deferal () at stmt.c:4215
#1  0x80e717a in expand_expr (exp=0x8206f58, target=0x8207368, tmode=SImode, 
    modifier=EXPAND_NORMAL) at expr.c:6848
#2  0x80e1d36 in store_expr (exp=0x8206f58, target=0x8207368, want_value=0)
    at expr.c:3228
#3  0x80e47df in expand_expr (exp=0x8206f74, target=0x0, tmode=VOIDmode, 
    modifier=EXPAND_MEMORY_USE_BAD) at expr.c:5180
#4  0x80d64aa in expand_function_start (subr=0x82189d4, parms_have_cleanups=0)
    at function.c:5445
#5  0x805bc30 in store_parm_decls (is_main_program=0) at f/com.c:14394
#6  0x8054a06 in ffecom_start_progunit_ () at f/com.c:7867
#7  0x80587c5 in ffecom_end_transition () at f/com.c:11319
#8  0x80a5e31 in ffestd_exec_end () at f/std.c:1402
#9  0x809d948 in ffestc_shriek_subroutine_ (ok=true) at f/stc.c:4935
#10 0x80a45fd in ffestc_R1225 (name=0x0) at f/stc.c:12423
#11 0x809e17e in ffestc_end () at f/stc.c:5658
#12 0x80874d0 in ffestb_end3_ (t=0x821c850) at f/stb.c:3207
#13 0x808719a in ffestb_end (t=0x821c850) at f/stb.c:2986
#14 0x808433d in ffesta_second_ (t=0x821c850) at f/sta.c:1358
#15 0x807f20d in ffelex_send_token_ () at f/lex.c:1652
#16 0x807e196 in ffelex_finish_statement_ () at f/lex.c:973
#17 0x808079b in ffelex_file_fixed (wf=0x821b9d8, f=0x8202bb8) at f/lex.c:2994
#18 0x80bc767 in ffe_file (wf=0x821b9d8, f=0x8202bb8) at f/top.c:555
#19 0x8082b3d in yyparse () at f/parse.c:77
#20 0x80be9bc in compile_file (name=0xbffffad4 "f77-bug1.f") at toplev.c:2470
#21 0x80c123b in main (argc=10, argv=0xbffff968, envp=0xbffff994)
    at toplev.c:4309
#22 0x80491db in _start ()
(gdb) quit