This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch, Fortran] Fix PR 60526, variable name has already been declared as a type


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]