[patch, Fortran] Fix PR 60526, variable name has already been declared as a type
Janne Blomqvist
blomqvist.janne@gmail.com
Thu Feb 11 18:55:00 GMT 2016
On Sat, Feb 6, 2016 at 10:20 PM, Thomas Koenig <tkoenig@netcologne.de> wrote:
> Hi Andre,
>
>> In preventing memory clutter I like to advise the use of:
>>
>> char u_name[GFC_MAX_SYMBOL_LEN + 1];
>>
>> and safe us all the dynamic memory allocation/free.
>
>
> We're really talking micro-optimizations here, but well ... ;-)
/me joins the micro-optimization bikeshed!
> In the attached patch, I have replaced this with alloca. I was going
> to use a VLA originally, but apparently C++ doesn't like that, at least
> not in the version that we use within C++.
IIRC VLA's were proposed for C++14, but were ultimately rejected.
The usual arguments against VLA's (and alloca, which is just another
way to spell the same thing, really) are that
- It reserves an extra register for the frame pointer.
- Functions using VLA's aren't inlined by GCC
- From a correctness perspective, unless you check the size somehow
beforehand, you can easily get a stack overflow crash.
So one solution to these correctness and performance issues is to have
a reasonably small statically sized buffer on the stack, and if the
size is bigger than that, fall back to heap allocation. E.g. something
like
void foo(..., size_t n) {
char tmp[BUFSIZE];
char *buf;
if (n <= BUFSIZE)
buf = tmp;
else
buf = xmalloc(n);
// Use buf
if (n > BUFSIZE)
free(buf);
}
This is roughly what std::string does with the new C++11 compatible
libstdc++ ABI. As we're supposed to be C++ nowadays, why aren't we
using that?
--
Janne Blomqvist
More information about the Gcc-patches
mailing list