clang fails assertion given function with >256 parameters

The clang compiler currently fails an assertion when given a function with more than 256 arguments. This started happening in John McCall's commit r130671, which changed the representation of parameters to reduce memory usage. Specifically, the parameter index (FunctionScopeIndex changed to ParameterIndex in the ParmVarDecl class in Decl.h) was changed from 16 bits to 8 bits.

Changing it back to 16 bits is one obvious solution, but it would increase memory usage. What's the right thing to do here?

John

It shouldn't be too hard to add some error checking here; it's just
that nobody has done it yet. Do you actually have code with a
function that takes more than 256 arguments? :slight_smile:

-Eli

I believe there is an open bug on this, but I forget the PR #.

The solution is for Clang to handle this. We could easily do it (for example) with a side-table for the cases where functions exceed 256 arguments, since that wouldn't be the common case. That solution also avoids the memory bloat.

That seems fine to me.

John.

The clang compiler currently fails an assertion when given a function with more than 256 arguments. This started happening in John McCall's commit r130671, which changed the representation of parameters to reduce memory usage. Specifically, the parameter index (FunctionScopeIndex changed to ParameterIndex in the ParmVarDecl class in Decl.h) was changed from 16 bits to 8 bits.

Changing it back to 16 bits is one obvious solution, but it would increase memory usage. What's the right thing to do here?

It shouldn't be too hard to add some error checking here; it's just
that nobody has done it yet. Do you actually have code with a
function that takes more than 256 arguments? :slight_smile:

I would guess (hope) it's generated code ...

FDIS Annex B recommends 256 as the minimum number of parameters in one function definition.

Would it be possible to use 9 bits for storing the number of parameters (as part of a bitfield)? And check
for overflow, of course.

Jonathan