Remove stray #undef FFS and #undef FLOAT

[Gabriel Dos Reis]

On Wed, May 19, 2010 at 3:27 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> I am working on implementing the multilib selection changes I proposed
> in <http://gcc.gnu.org/ml/gcc/2010-01/msg00063.html> for 4.6.
>
> This involves sharing command-line option processing between the
> driver and the compilers proper (cc1 etc.), and option processing code
> naturally depends on diagnostics code for reporting issues with
> options, so this means that the diagnostics code should be shared
> first.  This in turn requires disentangling the dependencies of
> diagnostics code on trees and other pieces of the core compiler, to be
> handled through callbacks that won't be defined or will be defined
> differently in the driver.
>
> This patch does the very first piece of preparation for such
> disentanglement.  Several source files in GCC, diagnostic.c and
> pretty-print.c among them, have the following code:
>
> #undef FLOAT /* This is for hpux. They should change hpux.  */
> #undef FFS  /* Some systems define this in param.h.  */
>
> This is because of the use of FLOAT and FFS in RTL.  diagnostic.c and
> pretty-print.c should not involve RTL at all; unlike trees (and
> langhooks, and plugins) where there is a real dependency to
> disentangle, I don't think there is any actual RTL dependency.  In
> fact, I believe these #undef directives are useless everywhere they
> appear except in rtl.h, which is where GCC's versions of FLOAT and FFS
> end up getting defined in an enum.  Evidence for this is that they
> appear immediately after config.h is included, and before system.h,
> which is what would include the system headers potentially defining
> them as macros.  Before r18726, "Major cutover to using system.h",
> they did at least more plausibly appear in the middle of system header
> includes.
>
> You can argue about whether rtl.h or system.h is the right place to
> #undef these macros (and ABS and PC which are also the subject of
> #undef in rtl.h) - but individual .c files clearly aren't, and as
> discussed above I do not believe the #undefs in individual source
> files have any effect.  This patch removes them along with two
> comments in random .c files about header inclusion ordering for FFS.
>
> Bootstrapped with no regressions on x86_64-unknown-linux-gnu.  OK to
> commit?

yes,

-- Gaby