rs6000/sysv4.h SLOW_UNALIGNED_ACCESS and STRICT_ALIGNMENT

[Franz Sirl]

Am Tue, 04 Jan 2000 schrieb Geoff Keating:
>> From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
>> Date: Tue, 4 Jan 2000 22:53:55 +0100
>> Cc: gcc-patches@gcc.gnu.org, meissner@cygnus.com
>> 
>> Am Tue, 04 Jan 2000 schrieb David Edelsohn:
>> >>>>>> Geoff Keating writes:
>> >
>> >>> This patch undefines the new AIX-dependent macros added to
>> >>> rs6000.h.
>> >
>> >Geoff> If they were AIX-dependent, why weren't they in an AIX-dependent
>> >Geoff> header file?  There's already way too much random junk in rs6000.h now.
>> >
>> >	Because there is no single, central AIX-specific header file.  The
>> >"rs6000" port originally only was AIX.  As the port evolved to support
>> >additional platforms, the AIX-specific definitions were not separated from
>> >the POWER/PowerPC common definitions.  The AIX-specific headers that do
>> >exist are deltas for features specific to various AIX releases.
>> >
>> >	Starting over, one would structure the port differently, but
>> >development instead chose to evolve the port with the least disruptive
>> >change. 
>> 
>> Well, AFAI understand it, this will change in the near future due to the new
>> configure-based include scheme. So this maybe a good time to start with a
>> cleanup now. So it would be nice if the AIX-people would start to split out
>> their stuff into a separate headerfile. After such a change it would probably
>> be easy to change the other OSes.
>> 
>> For Linux/PPC this would mean that tm.h will have the following entries similar
>> to this list:
>> 
>> #include <rs6000/rs6000.h>
>> #include <svr4.h>
>> #include <rs6000/sysv4.h>
>> #include <linux.h>
>> #include <rs6000/linux.h>
>> 
>> Currently this is very hard to do because of all the #define/#include/#undef
>> trickery done in various headers.
>
>OK.  Let's start doing this on the branch now.  I will create an
><aix.h> header, and we can see what should go into it.  Initially, the
><aix[34]*.h> headers will still have to #include these manually, but
>this is no problem to change later.

Great! I will happily work on the Linux part, time to open a new source tree
here :-). BTW, I'm currently working on some genrecog warning fixes and I still
have the -m option switch documentation patch for rs6000.h and sysv4.h in my
queue.

Franz.