Hello folks, I am not subscribed to this mailing list, so please address responses directly to me.
I have a program that generates this error: <file>.c: In function ‘f0’: <file>.c:117:4: error: this ‘else’ clause does not guard... [-Werror=misleading-indentation] 117 | //#endif // | ^~~~ <file>.c:120:2: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘else’ 120 | } | ^ cc1: all warnings being treated as errors for this small snippet of code: void * f0(void *ip6hdr) { if (ip6hdr) { //#ifdef KQD // } else if (0) { //#endif // } else if (ip6hdr) { } else { } return 0; } The failure was induced by a commit to a header file that is not even directly included by this source file. To produce the error the file must include a large swath of header files (some part of FreeBSD, some proprietary). Additionally, the failure is very, very sensitive to the contents of the source & included header files. Normally, to investigate a potential gcc defect, one would preprocess the file and pare down the output. But, preprocessing the input and compiling the preprocessed output causes the failure to evaporate. This is probably because the standalone preprocessor does not produce a verbatim rendering of the input sources. Nevertheless, the preprocessed output, containing proprietary code, is on the order of 80K lines, which is too large (IMHO) to submit in a defect report. Consequently, I need to narrow this down further. But, making progress beyond the current state is challenging because the failure is very sensitive to the contents of the input source, and header files are including other headers to a depth of 13. I am here to solicit ideas on how to further narrow this this down. Is there any undocumented option that I can use to cause the standalone preprocessor to produce output identical to input? Note that '-traditional-cpp' does not work because some of the code is not recognized (variadic macros, for example). thutt --