I think it's hard to say exactly which thing in the file is causing the
problem--type objects often refer to each other. Could you try reducing
the test case, removing as much of types.cc as possible while keeping
the error? Hopefully then it will be clear whether the error is in
Treehydra or Dehydra.
This is a pretty minor error, by the way. It wouldn't affect most
analyses, and if it doesn't affect yours, you might want to just ignore it.
On the subject of tags, I think the latest revision of Dehydra is always
the best, for now.
Dave
Lassi A.Tuura wrote:
Hi,
I've built dehydra on top of gcc 4.3.2. This is on a 64-bit
RHEL4-based system, but building a 32-bit compiler which produces
32-bit binaries (= built with and gcc specs changed to default to
"-m32 -Wa,--32" and 64-bit multilibs turned off).
At the end of my build, I do "make check_both", and I get the output
listed below. Is this a known problem, or is this a feature of my
build? Either way, any ideas where the problem may be and how to fix it?
The two numbers are 2^32-1 and 2^64-1. I assume the bit field it
complains about is in types.cc:
struct Boo {
unsigned int i:31;
} foo;
I am not entirely sure how the max value of that could be either
2^32-1 or 2^64-1.
Regards,
Lassi
PS. I know between little and nothing about mercurial; is it possible
to check out a "tag" or some fixed labelled revision of dehydra stuff
somehow?
python unit_test_harness.py both ".../gcc-4.3.2/obj/gcc/cc1plus -quiet
-O1 -ftest-coverage -fplugin=../gcc_%s.so -o /dev/null -fplugin-arg=%s
%s"
.................x.......................................................
Test Failure:
Test command: .../gcc-4.3.2/obj/gcc/cc1plus -quiet -O1
-ftest-coverage -fplugin=../gcc_treehydra.so -o /dev/null
-fplugin-arg=test_lazytypes.js types.cc
Failure msg: Expected 'OK' output; got 'at path:
root.type.variantOf.members.0.type.members.0.type.bitfieldOf.max.value
dehydra: 4294967295 lazy: 18446744073709551615'
Unit Test Suite Summary:
72 passed
1 failed
0 error(s)
_______________________________________________
dev-static-analysis mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-static-analysis
_______________________________________________
dev-static-analysis mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-static-analysis
