[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.8.3 |---
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.8.1 |4.8.2 --- Comment #45 from Jakub Jelinek jakub at gcc dot gnu.org --- GCC 4.8.1 has been released.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.8.0 |4.8.1 --- Comment #44 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-22 14:41:48 UTC --- GCC 4.8.0 is being released, adjusting target milestone.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #43 from Larry Baker baker at usgs dot gov 2012-10-04 19:14:44 UTC --- Those of you that use the uClinux elf2flt toolchain will find that __stack_start is not correctly defined. This is due to a bug in the elf2flt.ld linker script. Edit either/both elf2flt.ld (from a binary distribution) or elf2flt.ld.in (from the source distribution) to output the .stack section to the flatmem memory image: From .stack : { . = ALIGN(0x4); __stack_start = .; } To .stack : { . = ALIGN(0x4); __stack_start = .; } flatmem See http://mailman.uclinux.org/pipermail/uclinux-dev/2012-October/052176.html.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #41 from Larry Baker baker at usgs dot gov 2012-09-25 18:43:05 UTC --- Created attachment 28276 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28276 Build patched GNU GCC 4.8.0 experimental for ColdFire uClinux Notes to download, patch, and build GNU GCC 4.8.0 experimental for ColdFire uClinux target on Mac OS X and Linux i386 host.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #42 from Larry Baker baker at usgs dot gov 2012-09-25 20:39:10 UTC --- Change log for patches here. The patches here implement GCC stack limit checking for Freescale ColdFire processors (bug no. 28896) and fix the issues identified in the existing GCC source code (bug nos. 53833 and 54584). GCC version 4.6 and later (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896): • gcc/config/m68k/m68k.md – Modify the expansion of movsi pseudo instructions that require PIC relocation to use the destination register for all cases when a pseudo register cannot be created (vs. only when reload_in_progress is set). • gcc/config/m68k/m68k.md – Implement a code generator for the generic conditional trap instruction pattern (*conditional_trap) for all M68000-family processors. Rename the M68020 processor-specific conditional trap instruction pattern (from *conditional_trap to *conditional_trap_68020). • gcc/config/m68k/m68k.md – Remove the M68020 processor-specific filter on the conditional trap pseudo instructions ctrapdi4, ctrapsi4, ctraphi4, and ctrapqi4. • gcc/config/m68k/m68k.c – Compare the stack limit with the stack frame size (fsize_with_regs) after it has been adjusted for the additional stack space used by ColdFire processors (vs. the unadjusted current_frame.size). • gcc/config/m68k/m68k.c – Use a temporary Global Offset Table (GOT) pointer register, a0, for PIC code. • gcc/config/m68k/m68k.c – Change the temporary register used for the stack limit check to address register a0 (vs. data register d0) to enable the code generator to emit a load effective address (lea) instruction. • gcc/config/m68k/m68k.c – Check a stack limit register value before the stack is allocated (vs. after). • gcc/config/m68k/m68k.c – Move the implementation of stack limit checking from the prologue pseudo instruction code generator, m68k_expand_prologue, to a new TARGET_ASM_FUNCTION_PROLOGUE compiler hook function, m68k_function_prologue. (Eliminates the need to save/restore the GOT pointer register, a5, if done in m68k_expand_prologue.) • gcc/opts-global.c and gcc/config/m68k/m68k.c – Reject the use of a floating-point registers (fpn), a volatile registers (d0, d1, a0, a1), or the stack pointer (sp) as the stack limit register. GCC version 4.7 and later (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833) • libgcc/config.host – Disable atomics for ColdFire processors (internal compiler error). GCC version 4.7 and later (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54584) • gcc/config/m68k/uclinux.h – Disable Transactional Memory for uClinux (-msep-data/-fPIC -elf2flt final link failure).
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #36 from Larry Baker baker at usgs dot gov 2012-09-20 17:47:38 UTC --- Created attachment 28231 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28231 Build patched GNU GCC 4.6.4 prerelease for ColdFire uClinux Notes to download, patch, and build GNU GCC 4.6.4 prerelease for ColdFire uClinux target on Mac OS X and Linux i386 host.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #37 from Larry Baker baker at usgs dot gov 2012-09-20 17:51:28 UTC --- Created attachment 28234 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28234 Makefile to build GCC cross compiler and binutils for ColdFire uClinux Makefile used to build Mac OS X and Linux i386 cross compiler and binutils for ColdFire uClinux. (For the notes in the previous attachment.)
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #38 from Larry Baker baker at usgs dot gov 2012-09-20 17:54:41 UTC --- Created attachment 28236 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28236 Patches for GCC 4.7.2 (prerelease) Patches to fix stack limit checking for GCC 4.7.2 (prerelease) (2012-09-15 snapshot from http://fossies.org) for FreeScale Coldfire uClinux.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #39 from Larry Baker baker at usgs dot gov 2012-09-20 17:57:32 UTC --- Created attachment 28237 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28237 Build patched GNU GCC 4.7.2 prerelease for ColdFire uClinux Notes to download, patch, and build GNU GCC 4.7.2 prerelease for ColdFire uClinux target on Mac OS X and Linux i386 host.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #40 from Larry Baker baker at usgs dot gov 2012-09-20 18:58:01 UTC --- Created attachment 28238 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28238 Patches for GCC 4.8.0 (experimental) Patches to fix stack limit checking for GCC 4.8.0 (experimental) (2012-09-16 snapshot from http://fossies.org) for FreeScale Coldfire uClinux.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #34 from Larry Baker baker at usgs dot gov 2012-09-20 00:49:30 UTC --- Created attachment 28223 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28223 Build patched GNU GCC 4.7.1 for ColdFire uClinux Shell script to download, patch, and build GNU GCC 4.7.1 for ColdFire uClinux target on Linux i386 host.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #35 from Larry Baker baker at usgs dot gov 2012-09-20 00:56:02 UTC --- Created attachment 28224 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28224 Patches for GCC 4.6.4 (prerelease) Patches to fix stack limit checking for GCC 4.6.4 (prerelease) (2012-09-14 snapshot from http://fossies.org) for FreeScale Coldfire uClinux.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #33 from Larry Baker baker at usgs dot gov 2012-09-19 01:02:31 UTC --- Created attachment 28220 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28220 Patches for GCC 4.7.1 Patches to fix stack limit checking for GCC 4.7.1 for FreeScale Coldfire uClinux. Also includes patches to disable atomics (internal compiler error) for ColdFire processors (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833) and to disable Transactional Memory (linker failure) for uClinux (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54584). These two features were introduced in GCC 4.7.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #30 from Larry Baker baker at usgs dot gov 2012-09-17 19:28:19 UTC --- Created attachment 28205 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28205 Build patched Sourcery (Mentor Graphics) CodeBench Lite GCC 4.6-2011.09-23 for ColdFire uClinux Shell script to download, patch, and build Sourcery (Mentor Graphics) CodeBench Lite GCC 4.6-2011.09-23 for ColdFire uClinux target on Linux i386 host.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #31 from Larry Baker baker at usgs dot gov 2012-09-17 21:44:34 UTC --- Created attachment 28206 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28206 Patches for GCC 4.6.3 Patches to fix stack limit checking for GCC 4.6.3 for FreeScale Coldfire uClinux. These patches are also good for the GCC 4.6.4 development trunk (fossies.org 20120907 snapshot).
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #32 from Larry Baker baker at usgs dot gov 2012-09-18 02:16:32 UTC --- Created attachment 28208 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28208 Build patched GNU GCC 4.6.3 for ColdFire uClinux Shell script to download, patch, and build GNU GCC 4.6.3 for ColdFire uClinux target on Linux i386 host.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #28 from Larry Baker baker at usgs dot gov 2012-09-14 20:52:14 UTC --- Created attachment 28194 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28194 Patch for trunk version 2012-09-09 of gcc/config/m68k/uclinux.h To fix the same bug reported for GCC 4.7 at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54584.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #29 from Larry Baker baker at usgs dot gov 2012-09-15 05:41:24 UTC --- Created attachment 28196 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28196 Patches for Sourcery (Mentor Graphics) CodeBench Lite GCC 4.6-2011.09-23 Patches to fix stack limit checking for Sourcery (Mentor Graphics) CodeBench Lite GCC 4.6-2011.09-23 for FreeScale Coldfire uClinux.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #27 from Larry Baker baker at usgs dot gov 2012-09-12 20:42:22 UTC --- Created attachment 28178 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28178 Patch for trunk version 2012-09-09 of libgcc/config.host To fix the same bug reported for GCC 4.7 at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 Larry Baker baker at usgs dot gov changed: What|Removed |Added Attachment #28165|0 |1 is obsolete|| --- Comment #26 from Larry Baker baker at usgs dot gov 2012-09-11 21:33:55 UTC --- Created attachment 28174 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28174 Patch for trunk version 2012-08-12 of gcc/config/m68k/m68k.c Missed second LEGITIMATE_CONSTANT_P; should be m68k_legitimate_constant_p.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 Larry Baker baker at usgs dot gov changed: What|Removed |Added Attachment #28054|0 |1 is obsolete|| --- Comment #21 from Larry Baker baker at usgs dot gov 2012-09-10 21:27:25 UTC --- Created attachment 28162 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28162 Patch for trunk version 2012-08-12 of gcc/config/m68k/m68k.md
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 Larry Baker baker at usgs dot gov changed: What|Removed |Added Attachment #28081|0 |1 is obsolete|| --- Comment #22 from Larry Baker baker at usgs dot gov 2012-09-10 21:28:46 UTC --- Created attachment 28164 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28164 Patch for trunk version 2012-08-12 of gcc/config/m68k/m68k.c
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 Larry Baker baker at usgs dot gov changed: What|Removed |Added Attachment #28164|0 |1 is obsolete|| --- Comment #23 from Larry Baker baker at usgs dot gov 2012-09-10 21:31:32 UTC --- Created attachment 28165 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28165 Patch for trunk version 2012-08-12 of gcc/config/m68k/m68k.c Left out Pmode in plus_constant() again. Sorry.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #24 from Larry Baker baker at usgs dot gov 2012-09-10 21:36:24 UTC --- Created attachment 28166 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28166 Patch for trunk version 2012-09-10 of gcc/opts-global.c Reject the pseudo argument pointer register as a -fstack-limit-register.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #25 from Larry Baker baker at usgs dot gov 2012-09-10 21:52:34 UTC --- Created attachment 28167 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28167 Patches for Sourcery GCC-4.6-2011.09-23 for ColdFire uClinux These are the patches I am testing. They are for the Mentor Graphics Sourcery CodeBench Lite Edition C/C++ compilers for ColdFire uClinux. The generated code seems to be fine. Unfortunately, my test system is not. And, my assumption that __stack_start was a good choice for detecting stack overflow does not seem to be working out. For my test uClinux executable, stack-overflow.c: #include stdio.h void overflow( int i ) { /* Allocate automatic array j[256] so stack limit checking works. */ int j[256]; /* Stack limit checking tests only whether the stack is large enough for */ /* the initial stack allocation: saved registers and automatic variables. */ /* Stack limit checking does not test for stack overflow in the body of a */ /* function. That is what happens when j[] is not present. When j[] is */ /* too large, the program will abnormally terminate on its own (illegal */ /* instruction trap?). j[256] works. */ i++; printf( i = %i\n, i ); overflow( i ); } int main() { overflow( 0 ); return 0; } the stack is allocated 4K (0x1000). When I hacked the .s file to print out the stack pointer and __stack start, it shows that there is more than 4K between the value in the stack pointer and __stack_start: %sp = 0x405f3ee4 __stack_start = 0x405f08b4 That is not what I was expecting. Here are the instructions for creating the patched GCC I am using: $ wget --no-check-certificate https://sourcery.mentor.com/GNUToolchain/package9493/public/m68k-uclinux/freescale-coldfire-2011.09-23-m68k-uclinux-i686-pc-linux-gnu.tar.bz2 $ tar -xjf freescale-coldfire-2011.09-23-m68k-uclinux-i686-pc-linux-gnu.tar.bz2 $ wget --no-check-certificate https://sourcery.mentor.com/GNUToolchain/package9493/public/m68k-uclinux/freescale-coldfire-2011.09-23-m68k-uclinux.src.tar.bz2 $ tar -xjf freescale-coldfire-2011.09-23-m68k-uclinux.src.tar.bz2 -O freescale-coldfire-2011.09-23-m68k-uclinux/gcc-2011.09-23.tar.bz2 | tar -xjf - $ cd gcc-4.6-2011.09 $ patch -b -p 1 ../gcc-4.6-2011.09-23.patch $ cd .. $ ( cd cross-gcc-4.6-2011.09 ; \ PATH=${PWD}/../freescale-coldfire-2011.09/bin:${PATH/.:/} \ CC_FOR_BUILD=gcc \ CC=gcc \ CXX=g++ \ AR=ar \ RANLIB=ranlib \ AS_FOR_TARGET=m68k-uclinux-as \ LD_FOR_TARGET=m68k-uclinux-ld \ AR_FOR_TARGET=m68k-uclinux-ar \ RANLIB_FOR_TARGET=m68k-uclinux-ranlib \ NM_FOR_TARGET=m68k-uclinux-nm \ OBJDUMP_FOR_TARGET=m68k-uclinux-objdump \ STRIP_FOR_TARGET=m68k-uclinux-strip \ ${PWD}/../gcc-4.6-2011.09/configure \ --disable-decimal-float \ --disable-fixed-point \ --disable-libffi \ --disable-libgomp \ --disable-libmudflap \ --disable-libquadmath \ --disable-libssp \ --disable-libstdcxx-pch \ --disable-nls \ --disable-shared \ --enable-languages=c,c++ \ --enable-lto \ --enable-poison-system-directories \ --enable-threads \ --prefix=${PWD}/../freescale-coldfire-2011.09 \ --program-prefix=m68k-uclinux- \ --target=m68k-uclinux \ --with-arch=cf \ --with-gnu-as \ --with-gnu-ld \ --with-build-time-tools=${PWD}/../freescale-coldfire-2011.09/m68k-uclinux/bin \ --with-host-libstdcxx='-static-libgcc -static-libstdc++ -lm' \ --with-sysroot=${PWD}/../freescale-coldfire-2011.09/m68k-uclinux/libc ) $ ( cd cross-gcc-4.6-2011.09 ; \ PATH=${PWD}/../freescale-coldfire-2011.09/bin:${PATH/.:/} \ make -j4 ) $ ( cd cross-gcc-4.6-2011.09 ; \ PATH=${PWD}/../freescale-coldfire-2011.09/bin:${PATH/.:/} \ make install ) $ toolchains/freescale-coldfire-2011.09-patched/bin/m68k-uclinux-gcc -mcpu=5208 -fomit-frame-pointer -fno-common -fno-builtin -fno-dwarf2-cfi-asm -msep-data -fstack-limit-symbol=__stack_start -o check-stack-overflow stack-overflow.c Larry Baker
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #19 from Larry Baker baker at usgs dot gov 2012-08-25 00:28:56 UTC --- I plan to start testing my patches on a ColdFire uClinux system on Monday. In the mean time, I am unsure whether my code is correct for the -fPIC -mno-sep-data case. I do not know if a5 is a volatile register, or if, instead, it must be saved/restored. It is possible (as shown by my example) that a5 might otherwise not be needed by the code in a procedure. In that case, my code is not enabling the save/restore of a5, which would be wrong if a5 is not volatile. This is not a problem for -msep-data (implies -fPIC), since a5 already has the correct value, and is not altered by my code. I will investigate whether a5 is volatile. If anyone knows the answer already, please add a comment. If anyone can recommend what has to be called or modified to force a5 to be saved/restored, I would appreciate hearing about that as well. Thank you, Larry Baker
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 Larry Baker baker at usgs dot gov changed: What|Removed |Added Attachment #27998|0 |1 is obsolete|| --- Comment #20 from Larry Baker baker at usgs dot gov 2012-08-25 02:22:30 UTC --- Created attachment 28081 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28081 Patch for trunk version 2012-08-12 of gcc/config/m68k/m68k.c Correct call to plus_constant() (Pmode was missing). Change 4 to INCOMING_FRAME_SP_OFFSET in call to plus_constant(). (I am assuming the hard-coded 4 is the symbolic constant INCOMING_FRAME_SP_OFFSET. Please let me know if that is wrong.)
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 Larry Baker baker at usgs dot gov changed: What|Removed |Added Attachment #28048|0 |1 is obsolete|| --- Comment #18 from Larry Baker baker at usgs dot gov 2012-08-19 21:18:23 UTC --- Created attachment 28054 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28054 Patch for trunk version 2012-08-12 of gcc/config/m68k/m68k.md Change 16-bit word offset (the default) Bcc .+6 instruction to 8-bit short offset Bcc.S .+4 instruction (saves 2 bytes in every procedure prologue).
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 Larry Baker baker at usgs dot gov changed: What|Removed |Added Attachment #28024|0 |1 is obsolete|| --- Comment #17 from Larry Baker baker at usgs dot gov 2012-08-19 03:24:24 UTC --- Created attachment 28048 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28048 Patch for trunk version 2012-08-12 of gcc/config/m68k/m68k.md Change Bcc branch target from .+2 to .+6.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #16 from Larry Baker baker at usgs dot gov 2012-08-17 16:45:22 UTC --- Here are some notes about the patches I made. 1. An alternative to my m68k.md patch: - rtx temp = reload_in_progress ? operands[0] : gen_reg_rtx (Pmode); + rtx temp = can_create_pseudo_p() ? gen_reg_rtx (Pmode) : operands[0]; might be the approach taken by m68k_output_mi_thunk() in m68k.c: /* Pretend to be a post-reload pass while generating rtl. */ reload_completed = 1; : if (!TARGET_SEP_DATA) { /* Use the static chain register as a temporary (call-clobbered) GOT pointer for this function. We can use the static chain register because it isn't live on entry to the thunk. */ SET_REGNO (pic_offset_table_rtx, STATIC_CHAIN_REGNUM); emit_insn (gen_load_got (pic_offset_table_rtx)); } : /* Clean up the vars set above. */ reload_completed = 0; /* Restore the original PIC register. */ if (flag_pic) SET_REGNO (pic_offset_table_rtx, PIC_REG); This fools the compiler by pretending to run post-reload pass (reload_completed = 1). That might have been for the same reason I made the one-line patch above to m68k.md. I am not sure the approach taken in m68k_output_mi_thunk() would be correct in m68k_expand_prologue() in m68k.c: • The alternative code does not undo the effects of an instruction that sets crtl-uses_pic_offset_table while the temporary PIC offset table register is being used. That might cause an unnecessary load of the true PIC offset table register (emit_insn (gen_load_got (pic_offset_table_rtx)) at the end of m68k_expand_prologue()). • I do not know if the prerequisite holds that the static chain register is available in m68k_expand_prologue(). • I do not know if a pseudo register could be created in the stack check code but never be assigned to an actual register since the reload pass has already been run. I decided the patch I made to m68k.md was safe since it followed the intent of the existing conditional that decided whether or not to call gen_reg_rtx() and it did not try to use any registers designated for other purposes or not yet saved. All I did was move the code as-is from before to after the code that set up the PIC offset table register, and, only when that was required (!TARGET_SEP_DATA crtl-uses_pic_offset_table). 2. From what I understand of the GCC Internal Manual, the define_expand TARGET_M68020 condition on ctrapdi4, ctrapsi4, ctraphi4, and ctrapqi4 is ignored by the time those expansions are inserted into the RTL list (by the define_expand prologue pattern). In fact, my implementation of a conditional trap pattern for the other architectures would not have been invoked if it had been otherwise. The correct insn's for conditional_traps will be selected when the define_insn patterns are matched and expanded. I concluded it is correct to remove the TARGET_M68020 condition on ctrapdi4, ctrapsi4, ctraphi4, and ctrapqi4 in m68k.md.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 Larry Baker baker at usgs dot gov changed: What|Removed |Added Attachment #27999|0 |1 is obsolete|| --- Comment #14 from Larry Baker baker at usgs dot gov 2012-08-15 21:38:16 UTC --- Created attachment 28024 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28024 Patch for trunk version 2012-08-12 of gcc/config/m68k/m68k.md Removes TARGET_M68020 condition on ctrapdi4, ctrapsi4, ctraphi4, and ctrapqi4.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #15 from Steven Bosscher steven at gcc dot gnu.org 2012-08-15 21:43:45 UTC --- User reports bug still exits (xf comment #8).
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #11 from Larry Baker baker at usgs dot gov 2012-08-12 21:24:31 UTC --- Andreas, I have patched the Code Sourcery gcc 4.6.1+ ColdFire cross-compiler to fix the bugs I found for -m68020 -fPIC -fstack-limit-symbol and to implement -fstack-limit-symbol for non-68020 processors. The correct code is now generated for -mcpu=68020 -fPIC -fstack-limit-symbol=__stack_start. The PIC offset table register, A5, is now loaded before it is referenced by the stack check code: Larrys-MacBook-Air:gcc baker$ /usr/local/gcc-4.6-2011.09/libexec/gcc/m68k-uclinux/4.6.1/cc1 -mcpu=68020 -fPIC -fstack-limit-symbol=__stack_start -o junk.s junk.c junk Analyzing compilation unit Performing interprocedural optimizations *free_lang_data visibility early_local_cleanups whole-program inlineAssembling functions: junk Execution times (seconds) tree gimplify : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 (25%) wall 0 kB ( 0%) ggc unaccounted todo : 0.00 ( 0%) usr 0.01 (100%) sys 0.01 (25%) wall 0 kB ( 0%) ggc TOTAL : 0.00 0.01 0.04 1090 kB Larrys-MacBook-Air:gcc baker$ cat junk.s #NO_APP .filejunk.c .text .align2 .globljunk .typejunk, @function junk: link.w %fp,#0 lea (%pc, _GLOBAL_OFFSET_TABLE_@GOTPC), %a5 move.l __stack_start@GOT(%a5),%d0 addq.l #4,%d0 cmp.l %sp,%d0 traphi unlk %fp rts .sizejunk, .-junk .identGCC: (GNU) 4.6.1 .section.note.GNU-stack,,@progbits This required patches to m68k.c and m68k.md. I also moved the calculation of current_function_static_stack_size and limit to account for the stack size increase on ColdFire processors (use fsize_with_regs in place of current_frame.size). RTL is now defined to generate code for -fstack-limit-symbol for non-68020 processors: Larrys-MacBook-Air:gcc baker$ /usr/local/gcc-4.6-2011.09/libexec/gcc/m68k-uclinux/4.6.1/cc1 -mcpu=5208 -fPIC -fstack-limit-symbol=__stack_start -o junk.s junk.c junk Analyzing compilation unit Performing interprocedural optimizations *free_lang_data visibility early_local_cleanups whole-program inlineAssembling functions: junk Execution times (seconds) unaccounted todo : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 (100%) wall 0 kB ( 0%) ggc TOTAL : 0.00 0.00 0.01 1089 kB Larrys-MacBook-Air:gcc baker$ cat junk.s#NO_APP .filejunk.c .text .align2 .globljunk .typejunk, @function junk: link.w %fp,#0 move.l #_GLOBAL_OFFSET_TABLE_@GOTPC, %a5 lea (-6, %pc, %a5), %a5 move.l __stack_start@GOT(%a5),%d0 addq.l #4,%d0 cmp.l %sp,%d0 bls .+2 trap #7 unlk %fp rts .sizejunk, .-junk .identGCC: (GNU) 4.6.1 .section.note.GNU-stack,,@progbits This required patches to m68k.md. I implemented the *conditional_trap pattern for non-68020 processors and renamed *conditional_trap to *conditional_trap_68020 for 68020 processors. Compilation, linking, and conversion to uClinux Flat Binary format now works for ColdFire processors (but does not for 32-bit 68020, which is okay): Larrys-MacBook-Air:gcc baker$ /usr/local/gcc-4.6-2011.09/bin/m68k-uclinux-gcc -mcpu=68020 -fPIC -fstack-limit-symbol=__stack_start -o junk main.c junk.c /usr/local/gcc-4.6-2011.09/m68k-uclinux/bin/elf2flt: error: reloc type R_68K_GOT32O is not supported /usr/local/gcc-4.6-2011.09/m68k-uclinux/bin/elf2flt: error: reloc type R_68K_GOT32O is not supported /usr/local/gcc-4.6-2011.09/m68k-uclinux/bin/elf2flt: error: 2 bad relocs collect2: ld returned 1 exit status Larrys-MacBook-Air:gcc baker$ /usr/local/gcc-4.6-2011.09/bin/m68k-uclinux-gcc -mcpu=5206 -fPIC -fstack-limit-symbol=__stack_start -o junk main.c junk.c Please review my patches, m68k.{c,md}.trunk.patch. (I have to figure out how to attach them.) I do not understand, for example, how the TARGET_68020 in define_expand ctrapsi4 works. It seems not to be a problem to get to the patterns for generating the correct conditional trap code for non-68020 processors. (Does that mean they are not necessary?) I have not tested real code yet using the patched Code Sourcery gcc 4.6.1+ ColdFire cross-compiler. I am on vacation at the moment. I will get back to that next week. Larry Baker
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #12 from Larry Baker baker at usgs dot gov 2012-08-12 21:28:39 UTC --- Created attachment 27998 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27998 Patch for trunk version 2012-08-12 of gcc/config/m68k.m68k.c
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #13 from Larry Baker baker at usgs dot gov 2012-08-12 21:29:58 UTC --- Created attachment 27999 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27999 Patch for trunk version 2012-08-12 of gcc/config/m68k/m68k.md
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #9 from Larry Baker baker at usgs dot gov 2012-08-09 02:06:27 UTC --- (In reply to comment #6) Fixed in 4.8. Andreas, My application uses a 4.6.1+ compiler from Code Sourcery for ColdFire uClinux (no longer being sponsored by Freescale). So, I have been working with those sources for the moment. I encounter two gcc ICEs when I request -mcpu=5208 -fstack-limit-symbol=_stack_start: • With-msep-data: internal compiler error: in gen_reg_rtx, at emit-rtl.c • Without -msep-data: internal compiler error: in extract_insn, at recog.c Your fix of bug target 53834/28896 fixes the second ICE, by requiring at least -mcpu=68020. However, it did not cure the first ICE. I traced the second ICE to the -fPIC flag, which is implied by -msep-data. The simplest function, junk.c: void junk() {} will demonstrate the ICE, which occurs in cc1. The simplest cc1 command that will cause the ICE is: $ /usr/local/gcc-4.6-2011.09/libexec/gcc/m68k-uclinux/4.6.1/cc1 -mcpu=68020 -fPIC -fstack-limit-symbol=_stack_start -o junk.s junk.c I put a breakpoint at fancy_abort. Here is the backtrace as far the function prologue code being generated to check the stack pointer in m68k_expand_prologue() at m68k.c:1078: #0 fancy_abort (file=0x10064a588 /Users/baker/Desktop/Software/gcc/gcc-4.6-2011.09/gcc/emit-rtl.c, line=883, function=0x10064a865 gen_reg_rtx) at /Users/baker/Desktop/Software/gcc/gcc-4.6-2011.09/gcc/diagnostic.c:893 #1 0x0001001fdbb8 in gen_reg_rtx (mode=SImode) at /Users/baker/Desktop/Software/gcc/gcc-4.6-2011.09/gcc/emit-rtl.c:883 #2 0x0001000ea32a in gen_movsi (operand0=0x1418dd2c0, operand1=0x1418a9b50) at m68k.md:913 #3 0x00010021ae03 in emit_move_insn_1 (x=0x1418dd2c0, y=0x1418a9b50) at /Users/baker/Desktop/Software/gcc/gcc-4.6-2011.09/gcc/expr.c:3311 #4 0x00010021b2c8 in emit_move_insn (x=0x1418dd2c0, y=0x1418a9b50) at /Users/baker/Desktop/Software/gcc/gcc-4.6-2011.09/gcc/expr.c:3420 #5 0x000100561c98 in m68k_expand_prologue () at /Users/baker/Desktop/Software/gcc/gcc-4.6-2011.09/gcc/config/m68k/m68k.c:1078 : The ICE occurs because of the -fPIC conditional code surrounding m68k.md:913: else if (flag_pic !TARGET_PCREL symbolic_operand (operands[1], SImode)) { /* The source is an address which requires PIC relocation. Call legitimize_pic_address with the source, mode, and a relocation register (a new pseudo, or the final destination if reload_in_progress is set). Then fall through normally */ rtx temp = reload_in_progress ? operands[0] : gen_reg_rtx (Pmode); operands[1] = legitimize_pic_address (operands[1], SImode, temp); } I see the same code in the current gcc source tree. From my reading of the comments, it is preferable to allocate a new pseudo register. If that is not possible, the destination register is used. I believe the bug is caused by the insufficient test for whether a pseudo register can be allocated. I fixed the test to use can_create_pseudo_p(): /*rtx temp = reload_in_progress ? operands[0] : gen_reg_rtx (Pmode); */ rtx temp = can_create_pseudo_p() ? gen_reg_rtx (Pmode) : operands[0]; That cures the ICE caused by -fPIC -fstack-limit-symbol=_stack_start. However, I think the generated code is wrong. The reason is that the stack check code relies on %a5 being valid, but that code is executed before the prologue code which sets up %a5 to point to the GLOBAL_OFFSET_TABLE (see below). Here's my results: $ /usr/local/gcc-4.6-2011.09/libexec/gcc/m68k-uclinux/4.6.1/cc1 -mcpu=68020 -fPIC -fstack-limit-symbol=_stack_start -o junk.s junk.c $ cat junk.s #NO_APP .filejunk.c .text .align2 .globljunk .typejunk, @function junk: move.l _stack_start@GOT(%a5),%d0 addq.l #4,%d0 cmp.l %sp,%d0 traphi link.w %fp,#0 lea (%pc, _GLOBAL_OFFSET_TABLE_@GOTPC), %a5 unlk %fp rts .sizejunk, .-junk .identGCC: (GNU) 4.6.1 .section.note.GNU-stack,,@progbits Without -fPIC, I get: $ /usr/local/gcc-4.6-2011.09/libexec/gcc/m68k-uclinux/4.6.1/cc1 -mcpu=68020 -fstack-limit-symbol=_stack_start -o junk.s junk.c $ cat junk.s #NO_APP .filejunk.c .text .align2 .globljunk .typejunk, @function junk: move.l #_stack_start,%d0 addq.l #4,%d0 cmp.l %sp,%d0 traphi link.w %fp,#0 unlk %fp rts .sizejunk, .-junk .identGCC: (GNU) 4.6.1 .section.note.GNU-stack,,@progbits Next I will look for the prologue code which sets up %a5 for -fPIC code (in m68k_expand_prologue() in m68k.c?). Larry Baker
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #10 from Larry Baker baker at usgs dot gov 2012-08-09 02:16:27 UTC --- (In reply to comment #9) I traced the second ICE to the -fPIC flag, ... should be I traced the first ICE to the -fPIC flag, ... Larry Baker
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added CC||baker at usgs dot gov --- Comment #4 from Andreas Schwab sch...@linux-m68k.org 2012-07-03 07:28:19 UTC --- *** Bug 53834 has been marked as a duplicate of this bug. ***
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #5 from Andreas Schwab schwab at gcc dot gnu.org 2012-07-03 09:46:07 UTC --- Author: schwab Date: Tue Jul 3 09:46:01 2012 New Revision: 189210 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189210 Log: PR target/28896 * config/m68k/m68k.c (m68k_option_override): Reset stack_limit_rtx if !TARGET_68020. testsuite/ * gcc.target/m68k/stack-limit-1.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/m68k/stack-limit-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/m68k/m68k.c trunk/gcc/testsuite/ChangeLog
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #6 from Andreas Schwab sch...@linux-m68k.org 2012-07-03 09:47:41 UTC --- Fixed in 4.8.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #7 from Larry Baker baker at usgs dot gov 2012-07-03 23:43:46 UTC --- (In reply to comment #6) Fixed in 4.8. Refer to bug 53834 (duplicate of this bug) for original report. Changing -mcpu=5208 to -mcpu=68020 resolves only the -fstack-limit-reg= ICE (conditional traps not supported by M5208 processor); the -fstack-limit-symbol= ICE still occurs for a supported processor. # sh -v make_ntpq.sh #!/bin/sh ( cd linux/user/ntp/builddir/ntpq ; \ PATH=/usr/local/src/gcc-xgcc-4.7.1/gcc:$PATH \ ucfront-gcc xgcc -mcpu=68020 -DCONFIG_COLDFIRE -Os -g -fomit-frame-pointer -pipe -fno-common -fno-builtin -Wall -DEMBED -fno-dwarf2-cfi-asm -msep-data -Dlinux -D__linux__ -Dunix -D__uClinux__ -DHAVE_CONFIG_H -I. -I../../ntpq -I.. -I../../include -I../../libopts -DCONFIG_FILE=\/etc/config/ntp.conf\ -MT ntpq.o -MD -MP -MF .deps/ntpq.Tpo -c -o new_ntpq.o ../../ntpq/ntpq.c \ ) ../../ntpq/ntpq.c: In function 'decodeint': ../../ntpq/ntpq.c:1978:7: warning: pointer targets in passing argument 2 of 'hextoint' differ in signedness [-Wpointer-sign] In file included from ../../ntpq/ntpq.c:18:0: ../../include/ntp_stdlib.h:73:12: note: expected 'u_long *' but argument is of type 'long int *' ../../ntpq/ntpq.c:1979:3: warning: pointer targets in passing argument 2 of 'octtoint' differ in signedness [-Wpointer-sign] In file included from ../../ntpq/ntpq.c:18:0: ../../include/ntp_stdlib.h:91:12: note: expected 'u_long *' but argument is of type 'long int *' ( cd linux/user/ntp/builddir/ntpq ; \ PATH=/usr/local/src/gcc-xgcc-4.7.1/gcc:$PATH \ ucfront-gcc xgcc -mcpu=68020 -DCONFIG_COLDFIRE -Os -g -fstack-limit-symbol=_stack_start -fomit-frame-pointer -pipe -fno-common -fno-builtin -Wall -DEMBED -fno-dwarf2-cfi-asm -msep-data -Dlinux -D__linux__ -Dunix -D__uClinux__ -DHAVE_CONFIG_H -I. -I../../ntpq -I.. -I../../include -I../../libopts -DCONFIG_FILE=\/etc/config/ntp.conf\ -MT ntpq.o -MD -MP -MF .deps/ntpq.Tpo -c -o new_ntpq.o ../../ntpq/ntpq.c \ ) ../../ntpq/ntpq.c: In function 'decodeint': ../../ntpq/ntpq.c:1978:7: warning: pointer targets in passing argument 2 of 'hextoint' differ in signedness [-Wpointer-sign] In file included from ../../ntpq/ntpq.c:18:0: ../../include/ntp_stdlib.h:73:12: note: expected 'u_long *' but argument is of type 'long int *' ../../ntpq/ntpq.c:1979:3: warning: pointer targets in passing argument 2 of 'octtoint' differ in signedness [-Wpointer-sign] In file included from ../../ntpq/ntpq.c:18:0: ../../include/ntp_stdlib.h:91:12: note: expected 'u_long *' but argument is of type 'long int *' ../../ntpq/ntpq.c: In function 'assoccmp': ../../ntpq/ntpq.c:3279:1: internal compiler error: in gen_reg_rtx, at emit-rtl.c:859 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. ( cd linux/user/ntp/builddir/ntpq ; \ PATH=/usr/local/src/gcc-xgcc-4.7.1/gcc:$PATH \ ucfront-gcc xgcc -mcpu=68020 -DCONFIG_COLDFIRE -Os -g -fstack-limit-register=a5 -fomit-frame-pointer -pipe -fno-common -fno-builtin -Wall -DEMBED -fno-dwarf2-cfi-asm -msep-data -Dlinux -D__linux__ -Dunix -D__uClinux__ -DHAVE_CONFIG_H -I. -I../../ntpq -I.. -I../../include -I../../libopts -DCONFIG_FILE=\/etc/config/ntp.conf\ -MT ntpq.o -MD -MP -MF .deps/ntpq.Tpo -c -o new_ntpq.o ../../ntpq/ntpq.c \ ) ../../ntpq/ntpq.c: In function 'decodeint': ../../ntpq/ntpq.c:1978:7: warning: pointer targets in passing argument 2 of 'hextoint' differ in signedness [-Wpointer-sign] In file included from ../../ntpq/ntpq.c:18:0: ../../include/ntp_stdlib.h:73:12: note: expected 'u_long *' but argument is of type 'long int *' ../../ntpq/ntpq.c:1979:3: warning: pointer targets in passing argument 2 of 'octtoint' differ in signedness [-Wpointer-sign] In file included from ../../ntpq/ntpq.c:18:0: ../../include/ntp_stdlib.h:91:12: note: expected 'u_long *' but argument is of type 'long int *'
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #8 from Larry Baker baker at usgs dot gov 2012-07-04 01:40:23 UTC --- Andreas, I posted my negative findings that -mcpu=68020 still causes the -fstack-limit-symbol code path to fail. I believe the fundamental problem there is the allocation of two different rtx registers that should actually refer to the same rtx register. Consider the code in gcc/config/m68k/m68k.c: /* If the stack limit is a symbol, we can check it here, before actually allocating the space. */ if (crtl-limit_stack GET_CODE (stack_limit_rtx) == SYMBOL_REF) { limit = plus_constant (stack_limit_rtx, current_frame.size + 4); if (!m68k_legitimate_constant_p (Pmode, limit)) { emit_move_insn (gen_rtx_REG (Pmode, D0_REG), limit); limit = gen_rtx_REG (Pmode, D0_REG); } emit_insn (gen_ctrapsi4 (gen_rtx_LTU (VOIDmode, stack_pointer_rtx, limit), stack_pointer_rtx, limit, const1_rtx)); } fsize_with_regs = current_frame.size; My analysis is (I am NOT a compiler developer, so I could be way off base here) that gen_rtx_REG returns an rtx register reference to an unlimited pool of rtx registers. Somehow, later, the binding of the physical register D0_REG takes place -- I guess in the code generator. The emit_move_insn copies the limit rtx expression into an unnamed rtx register. That rtx register is valid, i.e., has a value. The next line seems to be intended to modify limit to refer to the rtx register containing the original limit value for use in emit_insn( trap ). However, the rtx expression assigned to limit is not the rtx register that has been set up; it is a new rtx register that is not valid, i.e., has no value. This code gets skipped if the limit rtx expression is already a valid constant. Which, I assume means it is a numeric constant, not a symbolic constant. I think the proper code should name the rtx register allocated for the emit_move_insn and then copy the value of that name into the limit rtx expression: { rtx d0reg = gen_rtx_REG (Pmode, D0_REG); emit_move_insn (d0reg, limit); limit =d0reg; } What do you think? Larry Baker US Geological Survey 650-329-5608 ba...@usgs.gov On 3 Jul 2012, at 2:47 AM, sch...@linux-m68k.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #6 from Andreas Schwab sch...@linux-m68k.org 2012-07-03 09:47:41 UTC --- Fixed in 4.8. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-31 03:06 --- Oh: if (current_function_limit_stack GET_CODE (stack_limit_rtx) == SYMBOL_REF) asm_fprintf (stream, \tcmp ASM_DOT l %I%s+%wd,%Rsp\n\ttrapcs\n, XSTR (stack_limit_rtx, 0), current_frame.size + 4); So this is a problem with more than coldfire then and also 68000 and 68010 code gen. Really m68k_output_function_prologue should be rewritten to use rtl patterns instead of text. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-31 03:06:40 date|| Summary|conditional trap goes messed|-fstack-limit-symbol and |up |m68k and non 68020 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896