gcc error diagnostics

[Linguofreak]

Does anyone know how to get gcc to output the actual numerical value it's evaluating for a "duplicate case value" error?

I've got a whole bunch of #defines establishing compile time constants that are being bitwise logicked around into other compile time constants, and somehow a bit is being masked that shouldn't be and that's causing two values that are supposed to be separate to collide in a case statement. In trying to debug it, I can get the preprocessor to emit the full final string that the compiler is receiving for each of the relevant cases, but it looks like it should evaluate to separate values, and the preprocessor, of course, isn't doing any math, it's just doing string manipulation, and the compiler is only telling me that the values are duplicates, and the contents of the relevant lines of source, not what it finally evaluated them to. I can't find the right search terms to get Google to cough up any relevant gcc options, and the options section of the gcc manpage is a wall of text.

 

[n72.75]

Does anyone know how to get gcc to output the actual numerical value it's evaluating for a "duplicate case value" error?

I've got a whole bunch of #defines establishing compile time constants that are being bitwise logicked around into other compile time constants, and somehow a bit is being masked that shouldn't be and that's causing two values that are supposed to be separate to collide in a case statement. In trying to debug it, I can get the preprocessor to emit the full final string that the compiler is receiving for each of the relevant cases, but it looks like it should evaluate to separate values, and the preprocessor, of course, isn't doing any math, it's just doing string manipulation, and the compiler is only telling me that the values are duplicates, and the contents of the relevant lines of source, not what it finally evaluated them to. I can't find the right search terms to get Google to cough up any relevant gcc options, and the options section of the gcc manpage is a wall of text.

Do you get anything useful with the -s assembly listing option, by seeing the actual code that's getting generated, or the -E option to see the result of the per-processor.

Is this a modern version of GCC?
What C standard are you using?
What architecture (the unsigned char thing on ARM continues to haunt me occasionally at the end of files...)

 

[Linguofreak]

Do you get anything useful with the -s assembly listing option, by seeing the actual code that's getting generated,

I hadn't tried that option, but don't errors in compilation prevent any code from being generated? But whether or not any code is generated, the compiler has to compute the case values to determine that they duplicate each other, so in principle it should be able to tell you what those are. Whether the humans who wrote the compiler were smart enough to think "this is information that might aid debugging, we should include an option to emit it" is the $64,000 question here.

or the -E option to see the result of the per-processor.

I'd been using #pragma message to extract the end result of preprocessing for the relevant macros, but that of course is a whole long expression in source code form, not the actual numeric value the compiler evaluates it to.

Is this a modern version of GCC?

gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0

What C standard are you using?

Whatever the default is (IIRC C99?).

What architecture (the unsigned char thing on ARM continues to haunt me occasionally at the end of files...)

x86-64

In any case, I managed to figure out the issue (not enough parens to make sure that when a macro used other macros the whole thing was evaluated in the right order), but the broader question about whether gcc has any kind of debug option to emit the values of compile-time constants (such as case values) that trigger errors remains open as a matter of "I'll probably have to debug something like this again someday".

Now I just have to figure out why a flex rule that's supposed to be tokenizing newlines dies on them instead...

 

[Gondos]

did you try with -ftrack-macro-expansion?

 

[Linguofreak]

did you try with -ftrack-macro-expansion?

As I've said, I managed to get the full expansion of the macros in question, and everything looked correct, so I was looking for the actual number that the compiler was evaluating the fully expanded macro to.

It turned out that I was misevaluating the order of operations when I looked at the fully expanded macro. Defensive parentheses around each component macro solved the issue.

 

[jedidia]

Whether the humans who wrote the compiler were smart enough to think "this is information that might aid debugging, we should include an option to emit it" is the $64,000 question here.

I honestly would be surprised if they did. The realization that "clear error messages save our customers money and should therefore be a priority feature" is significantly younger than gcc...