I migrated my clang compiler fork from 3.9 to 4.0.0, seemingly without a
hitch.
Unfortunately I now get sporadically this error, which I have trouble
reproducing:
Did not see access type in access path!
%2 = load %"struct.NSDate::p.timeIntervalSince1970"*,
%"struct.NSDate::p.timeIntervalSince1970"** %_param.addr, align 8, !tbaa !34
!34 = !{!35, !9, i64 0}
fatal error: error in backend: Broken function found, compilation aborted!
What does the above error generally point too. As far as I can deduce
the problem is related to tbaa and it doesn't seem to be happy about the
!34 line ? I don't know anything about tbaa, to be frank. Could I be
emitting incomplete information in my function calls ? I don't even
really know what "access type" and "access path" means?
Ciao
Nat!
P.S. It is kinda sad to see, that running the clang analyzer in Xcode on
clang 4.0.0 itself produces ~80 issues, some of which look like bona
fide bugs to me.
Hi Nat,
I migrated my clang compiler fork from 3.9 to 4.0.0, seemingly without a
hitch.
Unfortunately I now get sporadically this error, which I have trouble
reproducing:
Did not see access type in access path!
%2 = load %"struct.NSDate::p.timeIntervalSince1970"*,
%"struct.NSDate::p.timeIntervalSince1970"** %_param.addr, align 8, !tbaa !34
!34 = !{!35, !9, i64 0}
fatal error: error in backend: Broken function found, compilation aborted!
What does the above error generally point too. As far as I can deduce
the problem is related to tbaa and it doesn't seem to be happy about the
!34 line ? I don't know anything about tbaa, to be frank. Could I be
emitting incomplete information in my function calls ? I don't even
really know what "access type" and "access path" means?
This most likely means the IR you're generated is incorrect. If you
send the whole module to me (privately, or on list), I should be able
to tell you quickly what the problem is exactly.
There is some documentation that I added here -
http://llvm.org/docs/LangRef.html#tbaa-metadata. If something isn't
clear please let me know, and I'll fix it.
There was no change in the metadata specification going from 3.9 ->
4.0; but the verifier was made to be more thorough. So the failure
above most likely indicates that the TBAA metadata was incorrect in
3.9 as well, but LLVM is complaining loudly for the first time in 4.0.
You can also try interfacing via bitcode instead of textual IR -- IIRC
Mehdi Amini implemented something for bitcode where we'd silently
discard bad TBAA metadata instead of failing.
P.S. It is kinda sad to see, that running the clang analyzer in Xcode on
clang 4.0.0 itself produces ~80 issues, some of which look like bona
fide bugs to me.
Please file bugs!
-- Sanjoy