* Narrowing down preprocessor-related potential defect
@ 2022-06-21 19:30 thutt
2022-06-21 19:35 ` Jonathan Wakely
0 siblings, 1 reply; 4+ messages in thread
From: thutt @ 2022-06-21 19:30 UTC (permalink / raw)
To: gcc
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
--
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Narrowing down preprocessor-related potential defect
2022-06-21 19:30 Narrowing down preprocessor-related potential defect thutt
@ 2022-06-21 19:35 ` Jonathan Wakely
2022-06-21 19:47 ` Jonathan Wakely
2022-06-21 20:25 ` thutt
0 siblings, 2 replies; 4+ messages in thread
From: Jonathan Wakely @ 2022-06-21 19:35 UTC (permalink / raw)
To: thutt; +Cc: gcc
On Tue, 21 Jun 2022 at 20:31, thutt--- via Gcc <gcc@gcc.gnu.org> wrote:
> 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).
This seems off-topic for the gcc mailing list. It belongs on the gcc-help list.
Have you tried not using a standalone preprocessor?
The usual approach is to add -save-temps to the gcc invocation, so it
leaves the preprocessed output in a separate .i file.
N.B. it's a warning, not an error. You told GCC to turn that warning
into an error.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Narrowing down preprocessor-related potential defect
2022-06-21 19:35 ` Jonathan Wakely
@ 2022-06-21 19:47 ` Jonathan Wakely
2022-06-21 20:25 ` thutt
1 sibling, 0 replies; 4+ messages in thread
From: Jonathan Wakely @ 2022-06-21 19:47 UTC (permalink / raw)
To: thutt; +Cc: gcc
On Tue, 21 Jun 2022, 20:35 Jonathan Wakely, <jwakely.gcc@gmail.com> wrote:
> On Tue, 21 Jun 2022 at 20:31, thutt--- via Gcc <gcc@gcc.gnu.org> wrote:
> > 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).
>
> This seems off-topic for the gcc mailing list. It belongs on the gcc-help
> list.
>
> Have you tried not using a standalone preprocessor?
>
> The usual approach is to add -save-temps to the gcc invocation, so it
> leaves the preprocessed output in a separate .i file.
>
> N.B. it's a warning, not an error. You told GCC to turn that warning
> into an error.
>
GCC has a whole guide to test case reduction here:
https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction
I don't know how much will be applicable it usable in this instance.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Narrowing down preprocessor-related potential defect
2022-06-21 19:35 ` Jonathan Wakely
2022-06-21 19:47 ` Jonathan Wakely
@ 2022-06-21 20:25 ` thutt
1 sibling, 0 replies; 4+ messages in thread
From: thutt @ 2022-06-21 20:25 UTC (permalink / raw)
To: Jonathan Wakely; +Cc: thutt, gcc
Jonathan Wakely writes:
> âs External Email
>
> On Tue, 21 Jun 2022 at 20:31, thutt--- via Gcc <gcc@gcc.gnu.org> wrote:
> > 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).
>
> This seems off-topic for the gcc mailing list. It belongs on the gcc-help list.
>
> Have you tried not using a standalone preprocessor?
I am not using a standalone preprocessor. Only using gcc directly to
preprocess and compile the file results in the failure.
> The usual approach is to add -save-temps to the gcc invocation, so it
> leaves the preprocessed output in a separate .i file.
This doesn't have a satisfactory outcome. The file is preprocessed
and multiple spaces appear to be replaced with a single space. The
resultant output has no tabs that are not in quoted strings. It is
currently believed the failure is produced when a mix of tabs and
spaces are present.
>
> N.B. it's a warning, not an error. You told GCC to turn that warning
> into an error.
I'm aware of that. We treat all warnings as errors.
--
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-06-21 20:26 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-21 19:30 Narrowing down preprocessor-related potential defect thutt
2022-06-21 19:35 ` Jonathan Wakely
2022-06-21 19:47 ` Jonathan Wakely
2022-06-21 20:25 ` thutt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).