dblaikie added a comment. Thanks for filing the bug/reducing a test case - this change should include an automated test case that captures this issue (check for other tests that pass -gembed-source to see how this might be tested, possibly expanding the existing test case case or introducing a new one (test/CodeGen/debug-info-embed-source.c looks like the place to start)
I reduced your test case down a bit further: test.h: int g; test.c: #include "test.h" #define MACRO int x; MACRO Though the #include is needed to reproduce the /crash/, but even without the #include you can still reproduce the underlying bug - a DIFile witohut source and a DIFile with source in the same IR file (one compiled with -gembed-source). Actually - is that a required invariant, that all DIFiles have source if any of them do? That could be a problem for LTO situations that might merge modules (one of which may have embedded source and another that doesn't) Is this fix correct even when the problem occurs in a header file, for instance? Yeah, seems this problem doesn't occur if you move everything into the header - I think it'd be worthwhile to understand/explain why that works out (despite the file ID for the macro would be associated with the source range in both macro-used-in-header and macro-used-in-primary-source-file cases, so why do they need different handling later? Maybe there's a better way to handle this more consistently?) Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D53329/new/ https://reviews.llvm.org/D53329 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
