public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* objc SMP patch
@ 1997-08-20  5:23 Oleg Krivosheev
  1997-08-20  5:23 ` threads support on solaris Oleg Krivosheev
  1997-08-20  5:23 ` f771 dies with trivial fortran code Craig Burley
  0 siblings, 2 replies; 8+ messages in thread
From: Oleg Krivosheev @ 1997-08-20  5:23 UTC (permalink / raw)
  To: egcs

 Hi, All

it is still impossible to built ObjC on
any SMP box. I've enclosed below 
a bit hacked Jim Meyering patch
which cures the problem.

Can someone take a look ?

sincerely

OK



	* objc/Make-lang.in (objc/*.o): Depend on $(GCC_PASSES) cc1obj.

=====================================================
--- objc/Make-lang.in.orig	Tue Jul 15 08:53:43 1997
+++ objc/Make-lang.in	Tue Jul 15 08:52:52 1997
@@ -128,58 +128,59 @@
 	objc/thr.o objc/linking.o \
 	objc/$(OBJC_THREAD_FILE).o
 
-objc/hash.o: $(srcdir)/objc/hash.c
+objc/hash.o: $(srcdir)/objc/hash.c $(GCC_PASSES) cc1obj
 	$(GCC_FOR_TARGET) $(GCC_CFLAGS) $(INCLUDES) \
 	-c $(srcdir)/objc/hash.c -o $@
-objc/sarray.o: $(srcdir)/objc/sarray.c
+objc/sarray.o: $(srcdir)/objc/sarray.c $(GCC_PASSES) cc1obj
 	$(GCC_FOR_TARGET) $(GCC_CFLAGS) $(INCLUDES) \
 	-c $(srcdir)/objc/sarray.c -o $@
-objc/class.o: $(srcdir)/objc/class.c
+objc/class.o: $(srcdir)/objc/class.c $(GCC_PASSES) cc1obj
 	$(GCC_FOR_TARGET) $(GCC_CFLAGS) $(INCLUDES) \
 	-c $(srcdir)/objc/class.c -o $@
-objc/sendmsg.o: $(srcdir)/objc/sendmsg.c
+objc/sendmsg.o: $(srcdir)/objc/sendmsg.c $(GCC_PASSES) cc1obj
 	$(GCC_FOR_TARGET) $(GCC_CFLAGS) $(INCLUDES) \
 	-c $(srcdir)/objc/sendmsg.c -o $@
-objc/init.o: $(srcdir)/objc/init.c
+objc/init.o: $(srcdir)/objc/init.c $(GCC_PASSES) cc1obj
 	$(GCC_FOR_TARGET) $(GCC_CFLAGS) $(INCLUDES) \
 	-c $(srcdir)/objc/init.c -o $@
-objc/archive.o: $(srcdir)/objc/archive.c
+objc/archive.o: $(srcdir)/objc/archive.c $(GCC_PASSES) cc1obj
 	$(GCC_FOR_TARGET) $(GCC_CFLAGS) $(INCLUDES) \
 	-c $(srcdir)/objc/archive.c -o $@
-objc/encoding.o: $(srcdir)/objc/encoding.c
+objc/encoding.o: $(srcdir)/objc/encoding.c $(GCC_PASSES) cc1obj
 	$(GCC_FOR_TARGET) $(GCC_CFLAGS) $(INCLUDES) \
 	-c $(srcdir)/objc/encoding.c -o $@
-objc/selector.o: $(srcdir)/objc/selector.c
+objc/selector.o: $(srcdir)/objc/selector.c $(GCC_PASSES) cc1obj
 	$(GCC_FOR_TARGET) $(GCC_CFLAGS) $(INCLUDES) \
 	-c $(srcdir)/objc/selector.c -o $@
-objc/objects.o: $(srcdir)/objc/objects.c
+objc/objects.o: $(srcdir)/objc/objects.c $(GCC_PASSES) cc1obj
 	$(GCC_FOR_TARGET) $(GCC_CFLAGS) $(INCLUDES) \
 	-c $(srcdir)/objc/objects.c -o $@
-objc/misc.o: $(srcdir)/objc/misc.c
+objc/misc.o: $(srcdir)/objc/misc.c $(GCC_PASSES) cc1obj
 	$(GCC_FOR_TARGET) $(GCC_CFLAGS) $(INCLUDES) \
 	-c $(srcdir)/objc/misc.c -o $@
-objc/NXConstStr.o: $(srcdir)/objc/NXConstStr.m
+objc/NXConstStr.o: $(srcdir)/objc/NXConstStr.m $(GCC_PASSES) cc1obj
 	$(GCC_FOR_TARGET) $(GCC_CFLAGS) $(INCLUDES) \
 	-c $(srcdir)/objc/NXConstStr.m -o $@
-objc/Object.o: $(srcdir)/objc/Object.m
+objc/Object.o: $(srcdir)/objc/Object.m $(GCC_PASSES) cc1obj
 	$(GCC_FOR_TARGET) $(GCC_CFLAGS) $(INCLUDES) \
 	-c $(srcdir)/objc/Object.m -o $@
-objc/Protocol.o: $(srcdir)/objc/Protocol.m
+objc/Protocol.o: $(srcdir)/objc/Protocol.m $(GCC_PASSES) cc1obj
 	$(GCC_FOR_TARGET) $(GCC_CFLAGS) $(INCLUDES) \
 	-c $(srcdir)/objc/Protocol.m -o $@
-objc/thr.o: $(srcdir)/objc/thr.h $(srcdir)/objc/thr.c
+objc/thr.o: $(srcdir)/objc/thr.h $(srcdir)/objc/thr.c $(GCC_PASSES) cc1obj
 	$(GCC_FOR_TARGET) $(GCC_CFLAGS) $(INCLUDES) \
 	-c $(srcdir)/objc/thr.c -o $@
-objc/$(OBJC_THREAD_FILE).o: $(srcdir)/objc/$(OBJC_THREAD_FILE).c
+objc/$(OBJC_THREAD_FILE).o: $(srcdir)/objc/$(OBJC_THREAD_FILE).c $(GCC_PASSES) cc1obj
 	$(GCC_FOR_TARGET) $(GCC_CFLAGS) $(INCLUDES) \
 	-c $(srcdir)/objc/$(OBJC_THREAD_FILE).c -o $@
-objc/nil_method.o: $(srcdir)/objc/nil_method.c
+objc/nil_method.o: $(srcdir)/objc/nil_method.c $(GCC_PASSES) cc1obj
 	$(GCC_FOR_TARGET) $(GCC_CFLAGS) $(INCLUDES) \
 	-c $(srcdir)/objc/nil_method.c -o $@
-objc/linking.o: $(srcdir)/objc/linking.m
+objc/linking.o: $(srcdir)/objc/linking.m $(GCC_PASSES) cc1obj
 	$(GCC_FOR_TARGET) $(GCC_CFLAGS) $(INCLUDES) \
 	-c $(srcdir)/objc/linking.m -o $@
-$(srcdir)/objc/libobjc_entry.o: $(srcdir)/objc/libobjc_entry.c
+
+$(srcdir)/objc/libobjc_entry.o: $(srcdir)/objc/libobjc_entry.c $(GCC_PASSES) cc1obj
 	$(GCC_FOR_TARGET) $(GCC_CFLAGS) $(INCLUDES) \
 	-c $(srcdir)/objc/libobjc_entry.c -o $@
 

^ permalink raw reply	[flat|nested] 8+ messages in thread
* f771 dies with trivial fortran code
@ 1997-08-20  5:23 Mumit Khan
  0 siblings, 0 replies; 8+ messages in thread
From: Mumit Khan @ 1997-08-20  5:23 UTC (permalink / raw)
  To: egcs

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

^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: cross compiling to m68k
@ 1997-08-20 15:03 Joel Sherrill
  1997-08-20 15:03 ` f771 dies with trivial fortran code Mumit Khan
  0 siblings, 1 reply; 8+ messages in thread
From: Joel Sherrill @ 1997-08-20 15:03 UTC (permalink / raw)
  To: egcs

On Wed, 20 Aug 1997, Jon McGugan wrote:

> I have tried to cross compile the snapshot to target M68K. 
> This works for the standard gcc package.
> With egcs I get errors from the gnu assembler when the make gets to libgcc2 and 
> module bb
> The errors relates to constructions of form:
> #APP
>         movem.l  d0-d3,sp@-
> #NO APP
> 
> being inserted into the assembler file.
> Does anyone know why:
> 1)  these are put in
> 2) In wrong syntax for GAS - should be movem.l %d0-%d3,%sp@-
> 
> The rest of the assembler code produced is correct
> 
> And, of course, more importantly how to overcome the problem.

This looks like it came from an embedded assembly statement in a C file. 
I do not know which target configuration you are using but it appears to
require the % in front of register names.  You need to identify the C
file.  Then you will find something like "asm ("movem...")" or "asm
volatile( "movem...")".   Once you find this statement, you will need to
change it to include % in front of the register names.  You will probably
have to put %% since % is a special character in the embedded asm format.
Here is an example from RTEMS which shows how we disable interrupts:

#define m68k_disable_interrupts( _level ) \
  asm volatile ( "movew   %%sr,%0\n\t" \
                 "orw     #0x0700,%%sr" \
                    : "=d" (_level))

I think this has enough in it to help you out. I hope this helps you find
the problem.

--joel
Joel Sherrill                    Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (205) 722-9985

^ permalink raw reply	[flat|nested] 8+ messages in thread
* Trouble with GAS halfword extraction on PPC
@ 1997-08-20 16:37 Peter Barada
  1997-08-20 16:37 ` f771 dies with trivial fortran code Jeffrey A Law
  0 siblings, 1 reply; 8+ messages in thread
From: Peter Barada @ 1997-08-20 16:37 UTC (permalink / raw)
  To: egcs

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

^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: f771 dies with trivial fortran code
@ 1997-08-20 19:30 Jim Wilson
  0 siblings, 0 replies; 8+ messages in thread
From: Jim Wilson @ 1997-08-20 19:30 UTC (permalink / raw)
  To: egcs

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

^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: f771 dies with trivial fortran code
@ 1997-08-20 23:11 Mumit Khan
  0 siblings, 0 replies; 8+ messages in thread
From: Mumit Khan @ 1997-08-20 23:11 UTC (permalink / raw)
  To: egcs

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

^ permalink raw reply	[flat|nested] 8+ messages in thread
end of thread, other threads:[~1997-08-20 23:11 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-08-20  5:23 objc SMP patch Oleg Krivosheev
1997-08-20  5:23 ` threads support on solaris Oleg Krivosheev
1997-08-20  5:23 ` f771 dies with trivial fortran code Craig Burley
1997-08-20  5:23 Mumit Khan
1997-08-20 15:03 cross compiling to m68k Joel Sherrill
1997-08-20 15:03 ` f771 dies with trivial fortran code Mumit Khan
1997-08-20 16:37 Trouble with GAS halfword extraction on PPC Peter Barada
1997-08-20 16:37 ` f771 dies with trivial fortran code Jeffrey A Law
1997-08-20 19:30 Jim Wilson
1997-08-20 23:11 Mumit Khan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).