https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77488
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
__FILE__ expands to whatever you pass on the command line as the base file (and
for headers whatever the directory is where they are found + the header
filename. So, if you compile with gcc -c something.c -I subdir/ , then
__FILE__ will be "something.c" or e.g. "subdir/something.h". If you use
absolute filenames, that is what you get. So, if you care about the lengths of
these, just tweak your Makefiles so that you do the right thing (compile in the
directory with the sources, with -o to the directory of object files if
different), rather than compiling in the object directory, with absolute
filenames as sources. Adding yet another __FILE__-like builtin preprocessor
constant is IMHO undesirable, especially in the spelling you're proposing.
As for strrchr folding, I see it folded properly, e.g. __builtin_strrchr
(__FILE__, '/') is optimized into "foo/bar/baz.c" + 7. Optimizing it into
"baz.c" would be incorrect, you can do later on with the returned pointer e.g.
ptr -= 4; etc., which would be undefined behavior if everything before the last
/ is removed from the string literal.
