[LLVMdev] updated code size comparison
edwintorok at gmail.com
Wed Jan 20 12:58:15 PST 2010
On 01/20/2010 10:49 PM, John Regehr wrote:
>> Indeed, but can't an analysis find at least one value for each variable
>> where the behavior is not undefined?
>> Such a value must exist, or the entire function is useless if it always
>> has undefined behavior.
> Good point :).
>> Sure, testing on 1 such value (or a random) value won't prove that the
>> result is correct, but may help finding trivial
>> miscompilations like the neon_helper case.
> Are you absolutely sure it's a miscompilation? I have already shot
> myself in the foot a couple times on the GCC mailing list or bugzilla
> by pointing out a bug that turned out to be code with subtle undefined
Well if it is not then it is a qemu bug, so it is a bug in either case,
you just have to report it to another bugzilla ;)
The code does conversions by assigning to one union member and reading
AFAIK that was a GCC language extension, maybe they don't support it in
the latest release, or accidentaly broke it. I don't know.
Someone should reduce a testcase for gcc-head to see exactly what it is
about. My gcc (4.4) doesn't miscompile it.
Either way I'd rather see a warning from gcc when it decides to optimize
the entire function away.
>> Alternatively a testcase could be manually constructed for the top 10
>> functions in the size comparison charts,
>> and see whether they are miscompiled. Repeat until top 10 has no
> Tell you what: if I get enough test cases like this, I'll write the
> test harness supporting it. I don't have time to do this kind of code
> inspection myself.
> There has been talk (I don't remember where) about a Clang option for
> detecting undefined behavior. Is there any progress on this? This
> could be used to enable automated random testing.
More information about the llvm-dev