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

[John Steele Scott <toojays at toojays dot net>]

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