Troubles building gcc-3.2.1 --target=m68k-linux

Troubles building gcc-3.2.1 --target=m68k-linux

[Peter Barada]

Using linux-2.4.19, binutils-2.13, gcc-3.2.1, glibc-2.2.5, and the
following Makefile, I've succeeded in building a gcc-3.2.1
--target=m68k-linux compiler using a x86 host gcc-3.2.1 compiler.

I'm doing this since I'm trying to 'fix' m68k PIC code generation in
gcc-3.2.1 so it can support ColdFire.

But if I modify the m68k target files to change
GO_IF_LEGITIMATE_ADDRESS from a macro to a function call (the same way
that i386.h does it), the build fails to comlete the bootstrap.  I've
gotten to the point that I've convinced myself its a compiler bug in
gcc-3.2.1, so before I file a PR, I figured I would ask people with
better eyes than mine to look at what I've done and tell me where I
went wrong.

Here's the Makefile that built up everything:

begin 644 Makefile
M(PHC($)U:6QD(&%N(&TV.&LM;&EN=7@@8V]M<&EL97(@9G)O;2`J<V-R871C
M:"H*(PH*(R!7:&5R92!A;&P@=&AE('-O=7)C97,@87)E"E-/55)#15]0051(
M("`@(#U^+W=O<FLO8W9S+7=A=F5M87)K+V-R;W-S+6QI;G5X+71O;VQS"@HC
M($)U:6QD:6YG(&]N(&%N(&DV.#8M;&EN=7@@;6%C:&EN90I(3U-4("`@("`@
M("`]:38X-BUL:6YU>`H*(R!487)G970@05)#2"!N965D960@9F]R(&-O;F9I
M9W5R:6YG($QI;G5X(&ME<FYE;`I!4D-("3UM-CAK"@HC(%1A<F=E="!T;R!C
M;VYF:6=U<F4@1TY5('1O;VQS(&9O<@I405)'150@("`@("`@(#TD>T%20TA]
M+6QI;G5X"@HC('=H97)E('1O(&EN<W1A;&P@=&AE('1O;VQS("AH;W-T(&%N
M9"!T87)G970@=&]O;',I"E!2149)6`D)/2]H;VUE+VUY;&]C86PO>&-O;7`*
M24Y35$%,3%]$25(@("`])'M04D5&25A]+W1A<F=E=`I(3U-47TE.4U1!3$Q?
M1$E2"3TD>U!2149)6'TO:&]S=`H*(R!3;W5R8V4@9&ER96-T;W)I97,@*&%L
M;"!S=6)D:7)E8W1O<FEE<R!O9B!33U520T5?4$%42"D*0DE.551)3%-?4T]5
M4D-%7U!!5$@@("`@/21[4T]54D-%7U!!5$A]+V)I;G5T:6QS+3(N,3,*3$E.
M55A?4T]54D-%7U!!5$@)/21[4T]54D-%7U!!5$A]+VQI;G5X+3(N-"XQ.0I'
M0T-?4T]54D-%7U!!5$@@("`@("`@(#TD>U-/55)#15]0051(?2]G8V,M,RXR
M+C$*1TQ)0D-?4T]54D-%7U!!5$@@("`@("`@(#TD>U-/55)#15]0051(?2]G
M;&EB8RTR+C(N-0H*(R!$:7)E8W1O<FEE<R!U<V5D('1O(&)U;&0@96%C:"!C
M;VUP;VYE;G0*0DE.551)3%-?0E5)3$1$25(@("`@/21[5$%21T54?2UB:6YU
M=&EL<PI"3T]44U1205!?0E5)3$1$25(@("`@/21[5$%21T54?2UB;V]T<W1R
M87`*1T-#7T)524Q$1$E2("`@("`@("`])'M405)'151]+6=C8PI'3$E"0U]"
M54E,1$1)4B`@("`@("`@/21[5$%21T54?2UG;&EB8PI(3U-41T-#7T)524Q$
M1$E2"3TD>TA/4U1]+6=C8PH*+E!(3TY9.B!B:6YU=&EL<R!B;V]T<W1R87`@
M8W)O<W-G8V,*"F%L;#H@:&]S="UC;VUP:6QE<B!B:6YU=&EL<R!L:6YU>"UH
M96%D97)S(&)O;W1S=')A<"!G;&EB8PH*8VQE86XZ"@DM<FT@+69R("1[0DE.
M551)3%-?0E5)3$1$25)]("1[0D]/5%-44D%07T)524Q$1$E2?2!<"@DD>T=#
M0U]"54E,1$1)4GT@)'M'3$E"0U]"54E,1$1)4GT*"FAO<W0M8V]M<&EL97(Z
M"6AO<W1G8V,@:6YS=&%L;"UH;W-T9V-C"@IH;W-T9V-C.B`D>TA/4U1'0T-?
M0E5)3$1$25)]("1[2$]35$=#0U]"54E,1$1)4GTO36%K969I;&4@)'M(3U-4
M1T-#7T)524Q$1$E2?2]G8V,O8V,Q(&EN<W1A;&PM:&]S=&=C8PH*)'M(3U-4
M1T-#7T)524Q$1$E2?3H*"6UK9&ER("1[2$]35$=#0U]"54E,1$1)4GT*"B1[
M2$]35$=#0U]"54E,1$1)4GTO36%K969I;&4Z"@EE8VAO('1A<F=E=#H@)'M(
M3U-41T-#7T)524Q$1$E2?2]-86ME9FEL90H)8V0@)'M(3U-41T-#7T)524Q$
M1$E2?3L@7`H))'M'0T-?4T]54D-%7U!!5$A]+V-O;F9I9W5R92`M+7!R969I
M>#TD>TA/4U1?24Y35$%,3%]$25)]("TM96YA8FQE+6QA;F=U86=E<SUC"@HD
M>TA/4U1'0T-?0E5)3$1$25)]+V=C8R]C8S$Z"@EE8VAO('1A<F=E=#H@)'M(
M3U-41T-#7T)53$1$25)]+V=C8R]C8S$*"6UA:V4@+4,@)'M(3U-41T-#7T)5
M24Q$1$E2?0H*:6YS=&%L;"UH;W-T9V-C.@H)96-H;R!T87)G970Z(&EN<W1A
M;&PM:&]S=&=C8PH)8V0@)'M(3U-41T-#7T)524Q$1$E2?2`[(&UA:V4@:6YS
M=&%L;`H*(PHC('1H92!L9"UN97<@=&%R9V5T(&ES;G0@5$A!5"!S96-U<F4@
M86YD('5N:7%U92!E;G1R>2!H97)E+B!$;V5S"B,@86YY;VYE(&AA=F4@86X@
M:61E80HC"F)I;G5T:6QS.B`@("`D>T))3E5424Q37T)524Q$1$E2?2`D>T))
M3E5424Q37T)524Q$1$E2?2]-86ME9FEL92!<"B`@("`@("`@)'M"24Y55$E,
M4U]"54E,1$1)4GTO;&0O;&0M;F5W(&EN<W1A;&PM8FEN=71I;',*"B1[0DE.
M551)3%-?0E5)3$1$25)].@H);6MD:7(@)'M"24Y55$E,4U]"54E,1$1)4GT*
M"B1[0DE.551)3%-?0E5)3$1$25)]+TUA:V5F:6QE.@H)8V0@)'M"24Y55$E,
M4U]"54E,1$1)4GT[(%P*"65X<&]R="!0051(/21[2$]35%])3E-404Q,7T1)
M4GTO8FEN.B0D4$%42#L@7`H)96-H;R`B4$%42#TB)"10051(.R!<"@DD>T))
M3E5424Q37U-/55)#15]0051(?2]C;VYF:6=U<F4@+2UT87)G970])'M405)'
M151](%P*"2TM<')E9FEX/21[24Y35$%,3%]$25)]"@HD>T))3E5424Q37T)5
M24Q$1$E2?2]L9"]L9"UN97<Z"@EE>'!O<G0@4$%42#TD>TA/4U1?24Y35$%,
M3%]$25)]+V)I;CHD)%!!5$@[(%P*"6UA:V4@+4,@)'M"24Y55$E,4U]"54E,
M1$1)4GT*"FEN<W1A;&PM8FEN=71I;',Z"@EE>'!O<G0@4$%42#TD>TA/4U1?
M24Y35$%,3%]$25)]+V)I;CHD)%!!5$@[(%P*"6-D("1[0DE.551)3%-?0E5)
M3$1$25)].R!M86ME(&EN<W1A;&P*(PHC(&-R96%T92!T:&4@;&EN=7@@:&5A
M9&5R<R!A<'!R;W!R:6%T92!F;W(@=&AI<R!A<F-H:71E8W1U<F4*(PIL:6YU
M>"UH96%D97)S.@H)8V0@)'M,24Y56%]33U520T5?4$%42'T[(%P*"6-P(&%R
M8V@O)'M!4D-(?2]D969C;VYF:6<@+F-O;F9I9SL@7`H);6%K92!!4D-(/21[
M05)#2'T@;VQD8V]N9FEG.R!<"@EM86ME($%20T@])'M!4D-(?2!S>6UL:6YK
M<R!I;F-L=61E+VQI;G5X+W9E<G-I;VXN:#L@7`H);6MD:7(@+7`@)'M)3E-4
M04Q,7T1)4GTO)'M405)'151]+VEN8VQU9&4[(%P*"6-P("UR9B!I;F-L=61E
M+VQI;G5X("1[24Y35$%,3%]$25)]+R1[5$%21T54?2]I;F-L=61E+VQI;G5X
M.R!<"@EC<"`M<F8@:6YC;'5D92]A<VTM)'M!4D-(?2`D>TE.4U1!3$Q?1$E2
M?2\D>U1!4D=%5'TO:6YC;'5D92]A<VT*"B,*(R!L:6ME(&%B;W9E+"!T87)G
M970@9V-C+6-R;W-S(&UA>2!B92!W96%K("XN+@HC"F)O;W1S=')A<#H@("`@
M)'M"3T]44U1205!?0E5)3$1$25)]("1[0D]/5%-44D%07T)524Q$1$E2?2]-
M86ME9FEL92!<"@DD>T)/3U135%)!4%]"54E,1$1)4GTO9V-C+V-C,2!I;G-T
M86QL+6)O;W1S=')A<`H*)'M"3T]44U1205!?0E5)3$1$25)].@H);6MD:7(@
M)'M"3T]44U1205!?0E5)3$1$25)]"@HD>T)/3U135%)!4%]"54E,1$1)4GTO
M36%K969I;&4Z"@EE>'!O<G0@4$%42#TD>TE.4U1!3$Q?1$E2?2]B:6XZ)'M(
M3U-47TE.4U1!3$Q?1$E2?2]B:6XZ)"10051(.R!<"@EE8VAO(")0051(/2(D
M)%!!5$@[(%P*"6-D("1[0D]/5%-44D%07T)524Q$1$E2?3L@7`H))'M'0T-?
M4T]54D-%7U!!5$A]+V-O;F9I9W5R92`M+71A<F=E=#TD>U1!4D=%5'T@7`H)
M+2UP<F5F:7@])'M)3E-404Q,7T1)4GT@7`H)+2UW:71H+6QO8V%L+7!R969I
M>#TD>TE.4U1!3$Q?1$E2?2\D>U1!4D=%5'T@7`H@("`@("`@("TM=VET:&]U
M="UH96%D97)S("TM=VET:"UN97=L:6(@7`H)+2UD:7-A8FQE+7-H87)E9"`M
M+65N86)L92UL86YG=6%G97,]8R!<"@DM+61I<V%B;&4M=&AR96%D<PH*)'M"
M3T]44U1205!?0E5)3$1$25)]+V=C8R]C8S$Z"@EE>'!O<G0@4$%42#TD>TE.
M4U1!3$Q?1$E2?2]B:6XZ)'M(3U-47TE.4U1!3$Q?1$E2?2]B:6XZ)"10051(
M.R!<"@EM86ME("U#("1[0D]/5%-44D%07T)524Q$1$E2?2!A;&PM9V-C"@II
M;G-T86QL+6)O;W1S=')A<#H*"65X<&]R="!0051(/21[24Y35$%,3%]$25)]
M+V)I;CHD>TA/4U1?24Y35$%,3%]$25)]+V)I;CHD)%!!5$@[(%P*"6-D("1[
M0D]/5%-44D%07T)524Q$1$E2?3L@;6%K92!I;G-T86QL"@IG;&EB8SH))'M'
M3$E"0U]"54E,1$1)4GT@)'M'3$E"0U]"54E,1$1)4GTO36%K969I;&4@:6YS
M=&%L;"UG;&EB8PH*)'M'3$E"0U]"54E,1$1)4GTZ"@EM:V1I<B`D>T=,24)#
M7T)524Q$1$E2?0H*)'M'3$E"0U]"54E,1$1)4GTO36%K969I;&4Z"@EE>'!O
M<G0@4$%42#TD>TE.4U1!3$Q?1$E2?2]B:6XZ)'M(3U-47TE.4U1!3$Q?1$E2
M?2]B:6XZ)"10051(.R!<"@EE8VAO(")0051(/2(D)%!!5$@[(%P*"6-D("1[
M1TQ)0D-?0E5)3$1$25)].R!<"@E#0STD>U1!4D=%5'TM9V-C($%2/21[5$%2
M1T54?2UA<B!204Y,24(])'M405)'151]+7)A;FQI8B!<"@DD>T=,24)#7U-/
M55)#15]0051(?2]C;VYF:6=U<F4@+2UH;W-T/21[5$%21T54?2!<"@DM+7!R
M969I>#TD>TE.4U1!3$Q?1$E2?2\D>U1!4D=%5'T@7`H)+2UW:71H;W5T+69P
M("TM96YA8FQE+6%D9"UO;G,];&EN=7AT:')E861S(%P*"2TM=VET:"UH96%D
M97)S/21[24Y35$%,3%]$25)]+R1[5$%21T54?2]I;F-L=61E(%P*"2TM96YA
M8FQE+6%D9"UO;G,];&EN=7AT:')E861S"@HD>T=,24)#7T)524Q$1$E2?2]L
M:6)C+F$Z"@EE>'!O<G0@4$%42#TD>TE.4U1!3$Q?1$E2?2]B:6XZ)'M(3U-4
M7TE.4U1!3$Q?1$E2?2]B:6XZ)"10051(.R!<"@EM86ME("U#("1[1TQ)0D-?
M0E5)3$1$25)](&%L;`H*:6YS=&%L;"UG;&EB8SH*"65X<&]R="!0051(/21[
M24Y35$%,3%]$25)]+V)I;CHD>TA/4U1?24Y35$%,3%]$25)]+V)I;CHD)%!!
J5$@[(%P*"6-D("1[1TQ)0D-?0E5)3$1$25)].R!M86ME(&EN<W1A;&P*
`
end


Here's the patch that I used to change GO_IF_LEGITIMATE_ADDRESS from a
macro to a function the m68k target files: 

[pbarada: ~/work/cvs-wavemark/cross-linux-tools/gcc-3.2.1/gcc/config/m68k] > cvs diff -Nu m68k.h m68k-protos.h m68k.c
Index: m68k.h
===================================================================
RCS file: /usr/local/wavemark/cvs/archives/cross-linux-tools/gcc-3.2.1/gcc/config/m68k/m68k.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 m68k.h
--- m68k.h	2002/11/25 23:46:44	1.1.1.1
+++ m68k.h	2002/12/10 16:47:58
@@ -1436,13 +1436,21 @@
 	    || (INTVAL (XEXP (X, 1)) == 8 && !TARGET_5200))))
 
 /* If pic, we accept INDEX+LABEL, which is what do_tablejump makes.  */
+#if 1
 #define GO_IF_LEGITIMATE_ADDRESS(MODE, X, ADDR)				\
+do {									\
+  if (legitimate_address_p ((MODE), (X)))				\
+    goto ADDR;								\
+} while (0)
+#else
+#define GO_IF_LEGITIMATE_ADDRESS(MODE, X, ADDR)				\
 { GO_IF_NONINDEXED_ADDRESS (X, ADDR);					\
   GO_IF_INDEXED_ADDRESS (X, ADDR);					\
   if (flag_pic && MODE == CASE_VECTOR_MODE && GET_CODE (X) == PLUS	\
       && LEGITIMATE_INDEX_P (XEXP (X, 0))				\
       && GET_CODE (XEXP (X, 1)) == LABEL_REF)				\
     goto ADDR; }
+#endif
 
 /* Don't call memory_address_noforce for the address to fetch
    the switch offset.  This address is ok as it stands (see above),
Index: m68k-protos.h
===================================================================
RCS file: /usr/local/wavemark/cvs/archives/cross-linux-tools/gcc-3.2.1/gcc/config/m68k/m68k-protos.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 m68k-protos.h
--- m68k-protos.h	2002/11/25 23:46:44	1.1.1.1
+++ m68k-protos.h	2002/12/10 16:47:58
@@ -47,6 +47,7 @@
 extern int strict_low_part_peephole_ok PARAMS ((enum machine_mode, rtx, rtx));
 
 /* Functions from m68k.c used in macros.  */
+extern int legitimate_address_p PARAMS ((enum machine_mode, rtx));
 extern int symbolic_operand PARAMS ((rtx, enum machine_mode));
 extern int const_int_cost PARAMS ((rtx));
 extern int standard_68881_constant_p PARAMS ((rtx));
Index: m68k.c
===================================================================
RCS file: /usr/local/wavemark/cvs/archives/cross-linux-tools/gcc-3.2.1/gcc/config/m68k/m68k.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 m68k.c
--- m68k.c	2002/11/25 23:46:44	1.1.1.1
+++ m68k.c	2002/12/10 16:47:58
@@ -4261,3 +4261,18 @@
   output_asm_insn (output_move_simode (xop), xop);
 }
 #endif
+
+int legitimate_address_p(MODE, X)
+     enum machine_mode MODE;
+     rtx X;
+{
+  GO_IF_NONINDEXED_ADDRESS (X, good);
+  GO_IF_INDEXED_ADDRESS (X, good);
+  if (flag_pic && MODE == CASE_VECTOR_MODE && GET_CODE (X) == PLUS
+      && LEGITIMATE_INDEX_P (XEXP (X, 0))
+      && GET_CODE (XEXP (X, 1)) == LABEL_REF)
+    goto good;
+  return 0;
+ good:
+  return 1;
+}

If this patch is not applied, the Makefile completes, and I have an
m68k-linux compiler that looks like it works(I built up a hello word
app, but I have no m68k hardware to test it on).  When the patch is
applied, the build process fails in the bootstrap with: 

/home/pbarada/work/cvs-wavemark/cross-linux-tools/foo/m68k-linux-bootstrap/gcc/xgcc -B/home/pbarada/work/cvs-wavemark/cross-linux-tools/foo/m68k-linux-bootstrap/gcc/ -B/home/mylocal/xcomp/target/m68k-linux/bin/ -B/home/mylocal/xcomp/target/m68k-linux/lib/ -isystem /home/mylocal/xcomp/target/m68k-linux/include -O2  -DIN_GCC -DCROSS_COMPILE   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include  -fPIC -g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2.1/gcc -I/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2.1/gcc/. -I/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2.1/gcc/config -I/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2.1/gcc/../include -fexceptions -c /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2.1/gcc/unwind-dw2-fde-glibc.c -o libgcc/./unwind-dw2-fde-glibc.o
In file included from /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2.1/gcc/unwind-dw2-fde-glibc.c:47:
/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2.1/gcc/unwind-pe.h: In function `size_of_encoded_value':
/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2.1/gcc/unwind-pe.h:76: warning: implicit declaration of function `abort'
In file included from /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2.1/gcc/unwind-dw2-fde-glibc.c:298:
/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2.1/gcc/unwind-dw2-fde.c: In function `get_cie_encoding':
/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2.1/gcc/unwind-dw2-fde.c:271: warning: implicit declaration of function `strlen'
In file included from /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2.1/gcc/unwind-dw2-fde-glibc.c:298:
/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2.1/gcc/unwind-dw2-fde.c: In function `search_object':
/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2.1/gcc/unwind-dw2-fde.c:968: Internal compiler error in print_operand_address, at config/m68k/m68k.c:3702
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
make[2]: *** [libgcc/./unwind-dw2-fde-glibc.o] Error 1
make[2]: Leaving directory `/home/pbarada/work/cvs-wavemark/cross-linux-tools/foo/m68k-linux-bootstrap/gcc'


I pulled open the debugger and found that the compiler is trying to
emit the following instruction:

(gdb) frame 6
#6  0x080c7c2d in final_scan_insn (insn=0x401cb5e0, file=0x826cb60, 
    optimize=2, prescan=0, nopeepholes=0)
    at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2.1/gcc/final.c:2643
(gdb) call debug_rtx(insn)

(insn 362 360 656 (set (reg/v:SI 3 %d3 [92])
        (mem/s:SI (plus:SI (mem:SI (plus:SI (reg/f:SI 14 %a6)
                        (const_int -20 [0xffffffec])) [27 vec S4 A8])
                (const_int 4 [0x4])) [4 <variable>.count+0 S4 A16])) 29 {*m68k.md:976} (nil)
    (nil))

Note the use of two 'mem' operations in the second operand.  The
compiler can't handle this.  I looked through the debug dumps and
found that this is generated by reload (by finding this insn in
unwind-dw2-fde-glibc.c.21.greg). 

1) Does my change look correct?  If not, where'd I go wrong???
2) If its correct, is this a bug in gcc-3.2.1 for i386 and should I
   file a PR on it?
3) How should I proceed?

Thanx for any help!

-- 
Peter Barada                                   Peter.Barada@motorola.com
Wizard                                         781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola)   781-270-0193 (fax)

Re: Troubles building gcc-3.2.1 --target=m68k-linux

[Jim Wilson]

You need to have REG_OK_STRICT and !REG_OK_STRICT versions of the macro
GO_IF_LEGITIMATE_ADDRESS.  See for instance the definition in the mips port.

When strict is false, you can accept pseudo-regs where a reg is OK.
When strict is true, you can't accept pseudo-regs where a reg is OK, because
a pseudo-reg is actually a MEM refering to a stack-slot.

Jim

Re: Troubles building gcc-3.2.1 --target=m68k-linux

[Peter Barada]

>You need to have REG_OK_STRICT and !REG_OK_STRICT versions of the macro
>GO_IF_LEGITIMATE_ADDRESS.  See for instance the definition in the mips port.
>
>When strict is false, you can accept pseudo-regs where a reg is OK.
>When strict is true, you can't accept pseudo-regs where a reg is OK, because
>a pseudo-reg is actually a MEM refering to a stack-slot.

I was wondering about that, since I see that in the i386 version.
Eventually I'll include that in the new GO_IF_LEGITIMATE_ADDRESS for m68k.

What I'm *more* concerned (at the moment) is why as a macro
GO_IF_LEGITIMATE_ADDRESS works, but as a function it fails....

-- 
Peter Barada                                   Peter.Barada@motorola.com
Wizard                                         781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola)   781-270-0193 (fax)

Re: Troubles building gcc-3.2.1 --target=m68k-linux

[Peter Barada]

>You need to have REG_OK_STRICT and !REG_OK_STRICT versions of the macro
>GO_IF_LEGITIMATE_ADDRESS.  See for instance the definition in the mips port.
>
>When strict is false, you can accept pseudo-regs where a reg is OK.
>When strict is true, you can't accept pseudo-regs where a reg is OK, because
>a pseudo-reg is actually a MEM refering to a stack-slot.

Can you give me an example of an address that is legal when !strict,
but illegal when strict(and the other way around(if it exists))?

Thanx.

-- 
Peter Barada                                   Peter.Barada@motorola.com
Wizard                                         781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola)   781-270-0193 (fax)

Re: Troubles building gcc-3.2.1 --target=m68k-linux

[Andreas Schwab]

Peter Barada <pbarada@mail.wm.sps.mot.com> writes:

|> >You need to have REG_OK_STRICT and !REG_OK_STRICT versions of the macro
|> >GO_IF_LEGITIMATE_ADDRESS.  See for instance the definition in the mips port.
|> >
|> >When strict is false, you can accept pseudo-regs where a reg is OK.
|> >When strict is true, you can't accept pseudo-regs where a reg is OK, because
|> >a pseudo-reg is actually a MEM refering to a stack-slot.
|> 
|> I was wondering about that, since I see that in the i386 version.
|> Eventually I'll include that in the new GO_IF_LEGITIMATE_ADDRESS for m68k.
|> 
|> What I'm *more* concerned (at the moment) is why as a macro
|> GO_IF_LEGITIMATE_ADDRESS works, but as a function it fails....

Because you only have one version, but all those macros ultimatively
depend on REG_OK_FOR_INDEX_P and REG_OK_FOR_BASE_P, and those differ
between REG_OK_STRICT and !REG_OK_STRICT.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Troubles building gcc-3.2.1 --target=m68k-linux

[Peter Barada]

>|> What I'm *more* concerned (at the moment) is why as a macro
>|> GO_IF_LEGITIMATE_ADDRESS works, but as a function it fails....
>
>Because you only have one version, but all those macros ultimatively
>depend on REG_OK_FOR_INDEX_P and REG_OK_FOR_BASE_P, and those differ
>between REG_OK_STRICT and !REG_OK_STRICT.

Duh.

Since I only saw one definition of GO_IF_LEGITIMATE_ADDRESS, I thought
it was invariant.  Obviously that's wrong.

-- 
Peter Barada                                   Peter.Barada@motorola.com
Wizard                                         781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola)   781-270-0193 (fax)