This is the mail archive of the 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: [trunk<-vta] Re: [vta, 4.4] make df-scan df_collection_rec arrays overflow-safe

On Jun  1, 2009, Ian Lance Taylor <> wrote:

> Alexandre Oliva <> writes:
>>> So I came up with a trade-off that should benefit nearly everyone.
>>> First, I arranged for the array to start out still on the stack, but
>>> to grow as needed onto the heap.  Using GC memory for growth would
>>> work, but it was easy enough to add explicit deallocation where
>>> needed.
>>> And then, given that the array could now grow unbounded, the initial
>>> sizes didn't have to be so outrageously conservative, so I've reduced
>>> stack usage while at that.  No biggie, but still...

> I like the idea but (sorry) I would rather see this as a more general
> data structure which can be used in other places.  I don't like the ##
> stuff you are using.  Perhaps if you defined a new type of VEC:
> VEC(TYPE, alloca).

Make that a *big* sorry :-(

I've been trying to figure out how to make that fit in the current VEC
API, but I don't see a pleasant way to introduce it.

VEC_alloc uses various function calls before the actual allocation for
alloca to work, and it's structured in such a way that they must be
functions, rather than macros, because we can't define macros while
expanding macros.

I've pondered on some alternate mechanism to initialize caller-supplied
memory, passing a pointer to a deallocation function along with it, and
then deal with it like heap from then on.  Ugly, but it might work.

However, even then, df-scan.c appears to be quite resistant to switching
to a VEC-based data structure.  I've already spent a lot of time trying
to make it work with VEC heap, for the time being, but the current data
structure is quite widespread throughout the file :-(

I really don't feel like spending days revamping df-scan.c's internal
data structures and finding out its corner cases and special NULLs if I
can help it.

May I, please?  IOW, can we take this patch to fix the known problem,
and let the adoption of a more general data structure to someone who
actually understands that code?

Alexandre Oliva, freedom fighter
You must be the change you wish to see in the world. -- Gandhi
Be Free! --   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer

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