bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Don’t use AC_EGREP_CPP if affected by CFLAGS


From: Bruno Haible
Subject: Re: [PATCH] Don’t use AC_EGREP_CPP if affected by CFLAGS
Date: Tue, 07 Nov 2017 02:24:57 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-97-generic; KDE/5.18.0; x86_64; ; )

> > The problem is not limited to flags like -m32 and -m64. Flags like 
> > -fsanitize=address can also affect preprocessor behavior. A complete 
> > list of such flags would be daunting to maintain.
> 
> I didn't know about the -fsanitize=address effect, but it is easy to 
> determine:
> 
> $ diff <(:|gcc -E -dM -|LC_ALL=C sort) <(:|gcc -fsanitize=address -E -dM 
> -|LC_ALL=C sort)
> 155a156
> > #define __SANITIZE_ADDRESS__ 1

It is not limited to -fsanitize=address. -O does it as well:

$ diff <(:|gcc -E -dM -|LC_ALL=C sort) <(:|gcc -O -E -dM -|LC_ALL=C sort)
0a1
> #define _FORTIFY_SOURCE 2
148c149
< #define __NO_INLINE__ 1
---
> #define __OPTIMIZE__ 1

But people do put options like -O and -fsanitize=address into $CFLAGS and not
into $CPPFLAGS. So, if our check considers __OPTIMIZE__ and __SANITIZE_ADDRESS__
as relevant macros, it will fail in even the most basic setting, namely
  CC=gcc CFLAGS="-O2 -g"

Probably we need to draw a line between
  - macros that often change the result of $CPP output
    (e.g. -D and -I options, but also -m32/-m64)
  - macros that rarely change the result of $CPP output because they are just
    witness macros of optimization options (e.g. __OPTIMIZE__).

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]