efriedma added a comment. > 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.
Oh, right, it would be sizeof(APValue) * UINT_MAX, which would break in any practical usage. > 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. Definitely not simple, sure. > 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. Making the compiler's behavior depend on the amount of memory installed in the user's computer seems like a non-starter. I think we just have to stick with some combination of: - Try to reduce excessive memory usage in constant folding. - Add strict limits memory usage limits for optional constant folding - Maybe consider disobeying the standard slightly in certain cases: the standard requires that we constant-fold the initializers for all global variables, but that might not really be viable for globals that are expensive to evaluate. 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
