[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