This is the mail archive of the
mailing list for the GCC project.
Re: [patch] m68k -mcpu32 incorrectly sets __mc68020__
- From: ja2morri at csclub dot uwaterloo dot ca (James A. Morrison)
- To: "Aaron J. Grier" <aaron at frye dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: 19 Nov 2004 22:58:53 -0500
- Subject: Re: [patch] m68k -mcpu32 incorrectly sets __mc68020__
- References: <20041119203248.GJ715@mordor.unix.fryenet>
Where is the patch?
"Aaron J. Grier" <email@example.com> writes:
> now that TARGET_CPU_CPP_BUILTINS is generating #defines for m68k
> variants, it's more important to make sure that those #defines are
> unfortunately the TARGET_* macros are incorrectly evaluated in the cpu32
> case, since the cpu32 ISA isn't strictly speaking a 68020 minus bitfield
> instructions. as the comments in m68k.h state, it's a heuristic, and
> not completely accurate.
> the attached patch modifies the TARGET_68020 and TARGET_CPU32 macros to
> be more specific, so that mc68020 isn't defined when -mcpu32 is passed
> to gcc.
> I ran into problems compiling RTEMS, which uses the mc68020 #define for
> selecting in-line assembly for interrupt service routines. a true 68020
> has a separate interrupt stack pointer which is absent on all cpu32
> variants. previous versions of gcc did not #define mc68020 if -mcpu32
> was passed. this patch addresses that.
> longer-term, some work is still needed to categorize and separate the
> various ISA vs chip defines in the hodge-podge m68k world.
> Aaron J. Grier | Frye Electronics, Tigard, OR | firstname.lastname@example.org
> "Note that many bands' backline amps produce levels exceeding OSHA
> standards for industrial facilities. Yet this is considered normal
> working conditions for musicians. That's showbiz." -- Scott Dorsey