- User Since
- Dec 28 2012, 2:34 PM (263 w, 5 d)
- Use typeinfo declarations from vcruntime
Is this really a "fix" or does it just hide the ODR issue?
This doesn't seem like it will do the right thing if the global has internal linkage. Do we care about that case? I guess we could handle it by emitting dummy ABSOLUTE relocations from a non-COMDAT section to the section or symbol that we want to preserve.
Wed, Jan 10
Could this also include some of the earlier linking phases in Driver.cpp (I'm thinking input file reading, GC, ICF)?
Tue, Jan 9
Sorry disregard the negative tests comment, i see that you added some to the existing tests.
The code looks good, but please add negative tests as well as tests for the functionality you are adding to ThinLTOBitcodeWriter.
Fri, Jan 5
Thu, Jan 4
Please add some negative tests, e.g. alias of function without jump table entry,
Tue, Dec 19
- Make __hm const
Dec 18 2017
Would it be possible to fix this by stripping the noexcept specifiers from both the function type used in the check and the one that is embedded in the prefix data? The downside is that we won't catch the case where the caller has a noexcept specifier and the callee doesn't, but that seems like an edge case to me, and we can think about fixing it in other ways later.
Dec 15 2017
Please add a test that shows that we create an empty object file with the correct target triple.
Dec 14 2017
I think this patch can be simplified with my suggestions below. Let me know if it works.
The asan pass is more like something like codegenprepare in that we shouldn't really expect it to be run twice. If it does run twice, it most likely indicates a logic error in the pass pipeline, and it would be best to diagnose that with an assertion failure rather than silently ignoring it (which could also hide other unnecessary duplication of passes in the pipeline).
If this doesn't even fix the ThinLTO bug I don't see why we should land it. The other scenarios mentioned on the bug are "no warranty" scenarios because they use flags like -emit-llvm which aren't really user facing.
It looks like bfd and gold use this value for undefined symbols in DSOs that do not have version definitions. But at this point we are only dealing with defined symbols.
Instead of making the behaviour conditional on the flag, could we always emit the long PLT header and then conditionally emit short or long PLTs depending on what the offset is?
Dec 13 2017
I now wonder if we can simply ignore empty symbol name with this
This seems fine to me with the assert.
Dec 12 2017
Dec 11 2017
Dec 8 2017
Dec 7 2017
Dec 6 2017
Now that we basically treat alias summaries in the same way as their aliasees, I wonder whether we can simplify things by removing AliasSummary and summarizing aliases by creating a FunctionSummary or GlobalVariableSummary from the aliasee instead.