rnk added a subscriber: probinson. rnk added a comment. In D103495#2806097 <https://reviews.llvm.org/D103495#2806097>, @jyknight wrote:
> Won't this change cause weird effects with LTO, when you're merging multiple > TUs' global_ctors arrays before emitting? Won't this end up reversing the > order of the files, as well as the order of the functions within a single > file? That does not seem likely to be expected, right? True, I think that is an issue, and that probably does affect Sony's actual customers. I hear games tend to use regular LTO, so this will in fact reverse the order of initialization between object files for those users. The only solution I can think of would be to bring the LTO library into the game. It must know whether .ctors of .init_array are in use, since it generates code and it has to pick the section. To ensure that initialization of objects happens in reverse command line order as expected of users of -fno-init-array, the linker would join global_ctors in reverse order. That's not elegant. It encodes this knowledge in two places instead of one. But it does move in the direction of making things more defined, more deterministic, and that seems like a good thing. So, a question for @wolfgangp and @probinson , do we need to make adjustments to the LTO library, or is this OK as is? I think for non-Sony users we can accept the change in initialization order. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D103495/new/ https://reviews.llvm.org/D103495 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
