Re: [PATCH] add FreeBSD/IA-64 to gcc 3.0.3

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

Hi David,

In article <20011027134016.A12518@dragon.nuxi.com>:

> I would like to commit this to the gcc-3_0-branch.  We need this for
> FreeBSD's porting effort to the IA-64.

> I configured both stock and with my changes each of "ia64-unknown-linux",
> "ia64-unknown-elf", and "ia64-unknown-hpux" and varied no change in the
> output of 'gcc -E' ran on the created tm.h.
>
> Permission to commit?

General comments: it would be best if you generated a patch for the
gcc mainline and get that approved before generating one for the 3.0.X
branch.  It would also be helpful if you reported exactly which
configurations you have bootstrapped while posting this type of
configuration change.  I see that you ensured you didn't break
non-FreeBSD ports but it is unclear that this patch doesn't change the
configuration on FreeBSD/ia32.

I can only comment on these parts of your patch:

>+	* config.gcc: Add FreeBSD/IA-64 target.  Move inclusion of IA-64
>+	target headers to tm_file.

The new entry for ia64*-*-freebsd looks inline with all others for freebsd.

>+	* config/frebsd.h: Clean up and change default debugging type to DWARF2.
		    ^ missing an e here?

Something is funky with the config/frebsd.h patch.  For example, on
both mainline and 3.0.3 in the FSF tree, the default debugging type
for freebsd is already DWARF2.  A lot of the minor clean up
(e.g. spacing and adding extra comments) is not appropriate for the
3.0.X branch.  However, you are doing more than clean up.  Some of the
changes would appear to change the ABI.  The Changelog should report
each new/deleted/changed macro.  I know this is a bit different than
you do in the freebsd.org CVS tree.

> Index: config/ia63/elf.h

Where is ia63 coming from?

>Index: config/freebsd.h

[Only retaining the thunks of the patch upon which I want to comment.]

>@@ -81,8 +83,8 @@
> /* Provide a CPP_SPEC appropriate for FreeBSD.  We just deal with the GCC 
>    option `-posix', and PIC issues.  */
> 
>-#undef CPP_SPEC
>-#define CPP_SPEC "%(cpp_cpu)						\
>+#define FBSD_CPP_SPEC "							\
>+  %(cpp_cpu)								\
>   %{fPIC:-D__PIC__ -D__pic__} %{fpic:-D__PIC__ -D__pic__}		\
>   %{posix:-D_POSIX_SOURCE}"

This change looks like it might break the FSF gcc tree for FreeBSD
since no where else is FBSD_CPP_SPEC referred as far as I can see.
I think we had this issue almost creep into the FSF tree once before.

>-#undef WCHAR_TYPE
>-#define WCHAR_TYPE "int"

>-#undef WCHAR_UNSIGNED
>-#define WCHAR_UNSIGNED 0

Why are we disabling/changing wchar support? (or are these now the
default)?  Perhaps it should not be there, but that should not be
changed on the 3.0.X branch since it will hit future minor releases.

>+#undef  PCC_BITFIELD_TYPE_MATTERS
>+#define PCC_BITFIELD_TYPE_MATTERS 1

Likewise, this change might be OK on mainline, but will this change
the default compiler between minor releases?

>+/* The prefix to add to user-visible assembler symbols.
>+   For System V Release 4 & ELF the convention is *not* to prepend a leading
>+   underscore onto user-level symbol names.  */
>+
>+#undef  USER_LABEL_PREFIX
>+#define USER_LABEL_PREFIX ""

I take it that the configuration is buggy without adding this?  It
seems wrong to change this between only minor releases unless we know
it does not break the ABI.  Do you know the impact of these changes on
the ABI?

Regards,
Loren
-- 
Loren J. Rittle
Senior Staff Software Engineer, Distributed Object Technology Lab
Networks and Infrastructure Research Lab (IL02/2240), Motorola Labs
rittle@rsch.comm.mot.com, KeyID: 2048/ADCE34A5, FDC0292446937F2A240BC07D42763672