[llvm-bugs] [Bug 27664] New: __INT_FAST<n>_TYPE__ predefined macros incorrect

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=27664

            Bug ID: 27664
           Summary: __INT_FAST<n>_TYPE__ predefined macros incorrect
           Product: clang
           Version: 3.8
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
          Assignee: unassignedclangbugs at nondot.org
          Reporter: andyg1001 at hotmail.co.uk
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Ok, I'll qualify the statement that "__INT_FAST<n>_TYPE__ predefined macros are
incorrect" as "incorrect compared to gcc", which I realise is itself not
necessarily a bug!

However, please compare the two outputs from gcc and clang:

gcc -E -dM -xc - < /dev/null | grep -i '\(fast\|least\).*type' | sort
#define __INT_FAST16_TYPE__ long int
#define __INT_FAST32_TYPE__ long int
#define __INT_FAST64_TYPE__ long int
#define __INT_FAST8_TYPE__ signed char
#define __INT_LEAST16_TYPE__ short int
#define __INT_LEAST32_TYPE__ int
#define __INT_LEAST64_TYPE__ long int
#define __INT_LEAST8_TYPE__ signed char
#define __UINT_FAST16_TYPE__ long unsigned int
#define __UINT_FAST32_TYPE__ long unsigned int
#define __UINT_FAST64_TYPE__ long unsigned int
#define __UINT_FAST8_TYPE__ unsigned char
#define __UINT_LEAST16_TYPE__ short unsigned int
#define __UINT_LEAST32_TYPE__ unsigned int
#define __UINT_LEAST64_TYPE__ long unsigned int
#define __UINT_LEAST8_TYPE__ unsigned char

clang -E -dM -xc /dev/null | grep -i '\(fast\|least\).*type' | sort
#define __INT_FAST16_TYPE__ short
#define __INT_FAST32_TYPE__ int
#define __INT_FAST64_TYPE__ long int
#define __INT_FAST8_TYPE__ signed char
#define __INT_LEAST16_TYPE__ short
#define __INT_LEAST32_TYPE__ int
#define __INT_LEAST64_TYPE__ long int
#define __INT_LEAST8_TYPE__ signed char
#define __UINT_FAST16_TYPE__ unsigned short
#define __UINT_FAST32_TYPE__ unsigned int
#define __UINT_FAST64_TYPE__ long unsigned int
#define __UINT_FAST8_TYPE__ unsigned char
#define __UINT_LEAST16_TYPE__ unsigned short
#define __UINT_LEAST32_TYPE__ unsigned int
#define __UINT_LEAST64_TYPE__ long unsigned int
#define __UINT_LEAST8_TYPE__ unsigned char

Note that in clang all the "fast" types match types of the exact width, unlike
gcc that often chooses larger, and one would assume, more optimal types.

Now, I observe that most implementations of stdint.h totally ignore these
compiler defines, but this raises the question, why have these defines at all
if they cannot be trusted to be correct?  Or, is clang doing optimisations
behind the scenes that means that the code generated by using "short" will
always be as fast as using "int_fast16_t", for example?

Unfortunately, I am currently porting embedded code using a minimal libc
(worse, from a proprietary source!) which itself makes use of these defines and
I'm getting quite a number of performance regressions which appear to be
related to this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160506/fc4eee2c/attachment.html>