i386 code label alignment patch (version 2)

[Ian Lance Taylor]

   Date: Tue, 19 May 1998 13:46:45 -0400
   From: john@feith.com (John Wehle)

     1) Ian suggested only picking up the version number from
	../gas/configure.in when doing a Canadian Cross.  I'm not
	sure how to support a single tree native or cross build
	without checking for VERSION in ../gas since the assembler
	which will be used with gcc may not yet exist.
	My current logic is:

	  a) If there is an executable assembler in the current
	     directory, then check it.

	  b) Check for VERSION in ../gas.

	  c) If host == target then check the assembler in $path.

	Should I just drop "b" and not worry about single tree build /
	how would you like a single tree build to be handled?

Note that there is no longer any VERSION file in the gas directory.
You do need to check configure.in and Makefile.in.

I see what you mean about the checking the assembler in a single tree
build.  Perhaps in that specific case you should check configure.in
and Makefile.in, and otherwise do a feature test.

I can't help but wonder if there is some other approach entirely.
Using .p2align is only interesting for a target for which gcc does not
define ASM_OUTPUT_ALIGN correctly.  I don't mean to make you retread
old ground, but I wonder what targets those are?  Is it feasible to
get gcc to define ASM_OUTPUT_ALIGN correctly?  Or is the problem that
the definition of .align changed in gas?

     2) How should the results of the feature test(s) be expressed.
	I can think of two choices:

	  a) Use the feature test to determine the minimum GAS version.
	     If .p2align,,7 assembles then set GAS version to 2.8.

	  b) Use a separate define for each feature.  If .p2align,,7
	     assembles then define HAVE_GAS_MAX_SKIP_P2ALIGN.  If .p2align
	     assembles then define HAVE_GAS_P2ALIGN.

	My only concern with "b" is that I can imagine an explosion of
	HAVE_GAS_xxx macros as new features of gas are used.  In general
	newer versions of gas will probably support the older features
	so it may be undesirable to have a lot of different defines where
	one version define will suffice.  The advantage of "b" is that it's
	finer grain and will handle the gas of a newer gas dropping an old
	feature.

I think choice b is clearly correct.  Doing a feature test implies
using a feature specific define.

I would not worry about a proliferation of HAVE_GAS macros.  That's a
problem we can deal with if it arises, a case which I would consider
to be extremely unlikely.  We've gotten along so far without any
version dependent gas tests, so I doubt we are going to be adding many
more in the near future.

Ian