[cfe-dev] Patch for arbitrary fixed-width integer types

[Eli Friedman]

On Sat, Feb 7, 2009 at 6:47 PM, Chris Lattner <clattner at apple.com> wrote:
>> The attached patch adds one user for the new fixed-width types: the
>> implementation of the mode attribute.  That said, this is probably
>> overkill for that particular use, and it might confuse code that uses
>> function overloading.
>
> This sounds like a good use for it.  I'm not too concerned with C++
> overloading for attribute(mode).  I have never seen attribute mode used with
> C++ code.

Ah, I remembered the reason why using the fixed-width types for this
is bad while trying some compiling: the glibc sys/types.h redefines
int8_t and friends using the mode attribute, and that has to be
consistent with the way stdint.h defines it; therefore, we have to
follow the same logic as InitializePredefinedMacros.

>> Another possible use is that there was a request on the list a while
>> ago for a way to declare integer types of arbitrary width; this patch
>> would make implementing that relatively easy.
>
> Yes, it would.  attribute(bitwidth(42)) would be nice to support.  This
> would also give you something to pretty print to with:

Is bitwidth a good name?  Is there any precedent here?

>> Also, we could use this for gcc compatibility for testcases like the
>> following, although I'm not sure it's worthwhile:
>> struct {unsigned long long x : 33;} x;
>> unsigned long long a(void) {return x.x+1;}
>
> This would also be very nice.  We really should support this case at the
> very least, because this is a silent miscompilation otherwise.  How does "x"
> act w.r.t to overloading in this case with gcc?

gcc compiles this differently in C and C++ modes.  In C++ mode, x.x is
a 64-bit "unsigned long long"; in C mode, it's a 33-bit unsigned
integer.  The behavior difference is rather evil :(.

> +++ lib/AST/ASTContext.cpp      (working copy)
> @@ -373,6 +373,13 @@
>       break;
>     }
>     break;
> +  case Type::FixedWidthInt:
> +    // FIXME: This isn't precisely correct; the width/alignment should
> depend
> +    // on the available types for the target
> +    Width = cast<FixedWidthIntType>(T)->getWidth();
> +    Width = std::max(llvm::NextPowerOf2(Width - 1), 8ULL);
> +    Align = Width;
> +    break;
>
> This should probably follow the same logic that TargetData has on the LLVM
> IR  side of things.

I don't think the relevant information is exposed by the targets
outside of getTargetDescription(), and I don't think we want the AST
to depend on that.  I'll file a PR when I commit this.

> Instead of doing two/three lookups (one for count one for return and one for
> the insert), please just do one:

Okay.

-Eli