Hi Paul, > Le 20 janv. 2021 à 02:50, Paul Eggert <egg...@cs.ucla.edu> a écrit : > > On 1/19/21 10:22 AM, Akim Demaille wrote: > >> Clang 3.3 and 3.4 cannot compile the new scratch-buffer module. On Bison's >> CI (Clang 3.4: https://api.travis-ci.org/v3/job/755133481/log.txt), there is: >>> ... >>> CC lib/lib_libbison_a-canonicalize.o >>> In file included from ../lib/canonicalize.c:31: >>> In file included from ../lib/scratch_buffer.h:28: >>> ../lib/malloc/scratch_buffer.h:69:11: error: unknown type name 'max_align_t' > > Evidently the stddef module is not arranging for the replacement stddef.h to > define max_align_t properly. Could you investigate why that might be? What > does lib/stddef.h look like? What is the output of 'clang -E > lib/lib_libbison_a-canonicalize.c' (with the proper compile-time options)?
See below for the output: - clang 3.4: https://api.travis-ci.org/v3/job/755390946/log.txt - clang 3.3: https://api.travis-ci.org/v3/job/755390947/log.txt Look for "make spy" in there. Both come from this job: - https://travis-ci.org/github/akimd/bison/builds/755390943 >>> ../lib/canonicalize.c:237:15: warning: declaration does not declare >>> anything [-Wmissing-declarations] >>> FALLTHROUGH; >>> ^~~~~~~~~~~ >>> ../lib/attribute.h:142:21: note: expanded from macro 'FALLTHROUGH' >>> #define FALLTHROUGH _GL_ATTRIBUTE_FALLTHROUGH >>> ^~~~~~~~~~~~~~~~~~~~~~~~~ >>> ./lib/config.h:2016:36: note: expanded from macro >>> '_GL_ATTRIBUTE_FALLTHROUGH' >>> # define _GL_ATTRIBUTE_FALLTHROUGH __attribute__ ((__fallthrough__)) > > My guess is that the preprocessor expands __has_attribute (__fallthrough__) > to 1 but the attribute does not actually work. Is that the case? has_attribute is indeed 1. > Looking at the Clang 3.4 source code, I don't see how that could be, as > clang-3.4/include/clang/Basic/Attr.td lists the clang::fallthrough attribute > for CXX11 but not for C. Possibly I'm misunderstanding that file, but just to > check, does your preprocessor version match your compiler version? or are you > compiling with clang++? No, this is the genuine C compiler of that version. As provided by Ubuntu. > It might not worth worrying about this warning glitch for such an old > compiler, as you can just ignore the bogus warnings. I sure can do that, but that would require to check at configure time what compiler I'm using to enable the warning or not. Or to make it not covered by -Werror, indeed. Except that I want it to be really an error with modern compilers, so that the CI would catch these issues in Bison's own files. So I guess we are back to the discussion about applying a host project compiler flags to a guest gnulib. In the current case, it would perfectly work for me. So I should look into it, and use different warning flags for host and guest files, indeed. Cheers!
