<html>
<head>
<base href="https://llvm.org/bugs/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - __INT_FAST<n>_TYPE__ predefined macros incorrect"
href="https://llvm.org/bugs/show_bug.cgi?id=27664">27664</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>__INT_FAST<n>_TYPE__ predefined macros incorrect
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>3.8
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Driver
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedclangbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>andyg1001@hotmail.co.uk
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>