On August 5, 2016 4:42:48 PM GMT+02:00, Aldy Hernandez <al...@redhat.com> wrote: > >> I was surprised by the always_inline trick. I suppose it makes >> sense but I wouldn't have expected to be able to rely on it. Out >> of curiosity I tested it with other compilers. It turns out that >> it only works with some like GCC and IBM XLC++, but not others >> like Clang or Sun CC. In recursive calls, they don't seem to >> hold on to the memory allocated via alloca by the class ctor in >> the caller. > >Well, it was surprising to me as well, hence the comment. I expected >it >to just work, and when it didn't I had to hunt in the inliner code to >find out why it was selectively inlining: > > case GIMPLE_CALL: > /* Refuse to inline alloca call unless user explicitly forced so as > this may change program's memory overhead drastically when the > function using alloca is called in loop. In GCC present in > SPEC2000 inlining into schedule_block cause it to require 2GB of > RAM instead of 256MB. Don't do so for alloca calls emitted for > VLA objects as those can't cause unbounded growth (they're always > wrapped inside stack_save/stack_restore regions. */ > >As Richi pointed out, if the constructor doesn't get inlined (as you're > >seeing in Clang and Sun CC), we could potentially clobber freed memory. > > So much for that idea... > >> >> FWIW, rather than creating a new class around alloca and putting >> effort into changing code to use it I think that investing time >> into replacing the function's uses with an existing C++ container >> class (either GCC's own or one from the STL) might be a better >> way to go. > >Yes, I suggested a combination of auto_vec<> (gcc's) and std::string >down thread.
Please don't use std::string. For string building you can use obstacks. Richard. >Thanks for checking out the result from other compilers. Much >appreciated. > >Aldy