[Bug target/28896] -fstack-limit-symbol and m68k and non 68020

[Bug target/28896] -fstack-limit-symbol and m68k and non 68020

[schwab@linux-m68k.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |baker at usgs dot gov

--- Comment #4 from Andreas Schwab <schwab@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

[schwab at gcc dot gnu.org]

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=gcc&view=rev&rev=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

[schwab@linux-m68k.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.8.0

--- Comment #6 from Andreas Schwab <schwab@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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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
baker@usgs.gov



On 3 Jul 2012, at 2:47 AM, schwab@linux-m68k.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
> 
> Andreas Schwab <schwab@linux-m68k.org> changed:
> 
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>             Status|NEW                         |RESOLVED
>         Resolution|                            |FIXED
>   Target Milestone|---                         |4.8.0
> 
> --- Comment #6 from Andreas Schwab <schwab@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

[baker at usgs dot gov]

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  0x00000001001fdbb8 in gen_reg_rtx (mode=SImode) at
/Users/baker/Desktop/Software/gcc/gcc-4.6-2011.09/gcc/emit-rtl.c:883
#2  0x00000001000ea32a in gen_movsi (operand0=0x1418dd2c0,
operand1=0x1418a9b50) at m68k.md:913
#3  0x000000010021ae03 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  0x000000010021b2c8 in emit_move_insn (x=0x1418dd2c0, y=0x1418a9b50) at
/Users/baker/Desktop/Software/gcc/gcc-4.6-2011.09/gcc/expr.c:3420
#5  0x0000000100561c98 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
    .file    "junk.c"
    .text
    .align    2
    .globl    junk
    .type    junk, @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
    .size    junk, .-junk
    .ident    "GCC: (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
    .file    "junk.c"
    .text
    .align    2
    .globl    junk
    .type    junk, @function
junk:
    move.l #_stack_start,%d0
    addq.l #4,%d0
    cmp.l %sp,%d0
    traphi
    link.w %fp,#0
    unlk %fp
    rts
    .size    junk, .-junk
    .ident    "GCC: (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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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>
<inline>Assembling 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
    .file    "junk.c"
    .text
    .align    2
    .globl    junk
    .type    junk, @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
    .size    junk, .-junk
    .ident    "GCC: (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>
<inline>Assembling 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
    .file    "junk.c"
    .text
    .align    2
    .globl    junk
    .type    junk, @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
    .size    junk, .-junk
    .ident    "GCC: (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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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

[steven at gcc dot gnu.org]

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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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

[baker at usgs dot gov]

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

[jakub at gcc dot gnu.org]

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

[jakub at gcc dot gnu.org]

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

[jakub at gcc dot gnu.org]

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.2                       |4.8.3

--- Comment #46 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.8.2 has been released.

[Bug target/28896] -fstack-limit-symbol and m68k and non 68020

[rguenth at gcc dot gnu.org]

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] New: m68k port quietly accepts -fstack-limit-symbol on ColdFire

[kazu at gcc dot gnu dot org]

m68k port quietly accepts -fstack-limit-symbol on ColdFire.

-fstack-limit-symbol causes gcc to output "trapcs".
However, ColdFire does not support any conditional trap.


-- 
           Summary: m68k port quietly accepts -fstack-limit-symbol on
                    ColdFire
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: kazu at gcc dot gnu dot org
GCC target triplet: m68k-elf


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896

[Bug target/28896] -fstack-limit-symbol and m68k and non 68020

[pinskia at gcc dot gnu dot org]

------- 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|0000-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