cor3ntin added a comment. In D155955#4528571 <https://reviews.llvm.org/D155955#4528571>, @efriedma wrote:
> The UINT_MAX thing seems like a straightforward bug; if we have time to fix > it properly, I'd prefer not to add weird workarounds. Note sure what you mean. Making sure we use `size_t` for all array extents is not something that can be fixed overnight but more importantly, it does not help: Would it not overflow, the allocation would still fail. > The release note says "unless they are part of a constant expression", but I > don't see any code in the implementation that distinguishes folding from > constant expression evaluation. Unless this is just referring to the fact > that bailing out of folding doesn't produce an error? We might want to > consider using a stricter bound for optional folding, though. I need to update the release notes/commit message they are no reflective of the current design which always look at fconstexpr-steps in all modes of evaluation. It's much cleaner that way. > How likely is it that we could add some sort of optimization for new > expressions so we don't represent each element separately in memory? I know > there's no solution in general, but in the cases people actually care about, > all/almost all the elements are identical. I don't think that would make sense in actual code, and having some sort of sparse array is something I considered. And we already delay allocation in some cases, but we do need to create elements to destroy them, read them, etc. So while it may be possible, it seems... complicated. I think a more viable long term fix might be to not crash on allocation failure, and/or to have a way to limit the allocation to some portion of the available memory. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D155955/new/ https://reviews.llvm.org/D155955 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
