Nat! via llvm-dev
2017-Mar-29 20:14 UTC
[llvm-dev] Problem with tbaa sporadically crashing on me
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.
Sanjoy Das via llvm-dev
2017-Mar-30 18:00 UTC
[llvm-dev] Problem with tbaa sporadically crashing on me
Hi Nat, On March 29, 2017 at 1:15:08 PM, Nat! via llvm-dev (llvm-dev at lists.llvm.org) wrote:> 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