Using GCC to verify code has no "functional change".

Using GCC to verify code has no "functional change".

[John Steele Scott]

I work on a project which uses a mismash of coding styles. We are planning to
use an auto-formatting tool (uncrustify) to apply a consistent style format
across the codebase.

I'd like to be able to verify that uncrustify has not caused in any functional
change to the compiled code. So far, the best approach I have is to compile to
assembler before & after the style change, and then diff the resulting assembler
files. This is a little unwieldy because line numbers change, and so I need to
strip out a bunch of compiler directives before making the comparison.

It seems like a better way to do this is to compile my before/after source with
-fdump-tree-original-all, and diff the resulting dumps. Then I don't need to
munge the dumps at all. I tried this on a small example and it seems to work
quite well.

Does this sound reasonable? Is there a better way?

Cheers,

John

Re: Using GCC to verify code has no "functional change".

[John Steele Scott]

Resending as plain text, hopefully this makes it to the list . . .
On 31/10/12 16:13, Thomas Martitz wrote:
>
>
> John Steele Scott <toojays@toojays.net> schrieb:
>
> I work on a project which uses a mismash of coding styles. We are planning to
> use an auto-formatting tool (uncrustify) to apply a consistent style format
> across the codebase.
>
> I'd like to be able to verify that uncrustify has not caused in any functional
> change to the compiled code. So far, the best approach I have is to compile to
> assembler before & after the style change, and then diff the resulting assembler
> files. This is a little unwieldy because line numbers change, and so I need to
> strip out a bunch of compiler directives before making the comparison.
>
> It seems like a better way to do this is to compile my before/after source with
> -fdump-tree-original-all, and diff the resulting dumps. Then I don't need to
> munge the dumps at all. I tried this on a small example and it seems to work
> quite well.
>
> Does this sound reasonable? Is there a better way?
>
> Cheers,
>
> John
>
>
> You could also compare the hashes of the binary(ies) I think, md5 or sha1 or whatever.

Thanks Thomas for your reply.

When hashing the binaries, some compiler options need to be used to ensure the
result is th same, otherwise the output is not quite deterministic. At least
-frandom-seed should be use, maybe others. The trouble is then, if the hash does
not match what is expected, how to fin what changed?

This code has quite a few places where __LINE__ is used when building error
messages. The frmat change results in some line numbers changing, and so I still
need to eyeball the diff t ensure that only line numbers are different.

I tried forcing __LINE__ to be a constant on the command line (with
-D__LINE__=0), but thatfails with '<command-line>: error: "__LINE__" redefined'.

Cheers,

John

Re: Using GCC to verify code has no "functional change".

[Ángel González]

On 31/10/12 07:23, John Steele Scott wrote:
> This code has quite a few places where __LINE__ is used when building error
> messages. The frmat change results in some line numbers changing, and so I still
> need to eyeball the diff t ensure that only line numbers are different.
>
> I tried forcing __LINE__ to be a constant on the command line (with
> -D__LINE__=0), but thatfails with '<command-line>: error: "__LINE__" redefined'.

You could replace all uses of __LINE__ with LINE, and then use
-DLINE=__LINE__ in
the normal build, and -DLINE=123 in the comparison one.

Note however that in some cases __LINE__ is used to force
macro-generated identifiers
to be different, so if your code base does that you could end up with
symbols defined
multiple times when setting it to a constant.

Regards