Hi,
Last month, there was a talk of a intrinsic bug in MSVC/DDK’s CL, and it
looks like this forum made it get the attention it needed to get a
fix/repro from other people, so I hope nobody minds if I post another one.
The bug is in __addfsbyte, when used with an external. Here’s my test code:
#include <stddef.h>
extern char C;
extern short W;
extern long L;
extern long long LL;
extern unsigned char UC;
extern unsigned short UW;
extern unsigned long UL;
extern unsigned long long ULL;
extern char C1;
extern short W1;
extern long L1;
extern long long LL1;
extern unsigned char UC1;
extern unsigned short UW1;
extern unsigned long UL1;
extern unsigned long long ULL1;
extern char C2;
extern short W2;
extern long L2;
extern long long LL2;
extern unsigned char UC2;
extern unsigned short UW2;
extern unsigned long UL2;
extern unsigned long long ULL2;
extern char C3;
extern short W3;
extern long L3;
extern long long LL3;
extern unsigned char UC3;
extern unsigned short UW3;
extern unsigned long UL3;
extern unsigned long long ULL3;
extern int I;
extern int I1;
extern int I2;
extern int I3;
extern unsigned int UI;
extern unsigned int UI1;
extern unsigned int UI2;
extern unsigned int UI3;
extern int foo();
extern int baz();
extern int bar(int);
extern int bar8(unsigned char);
extern int graz(void *);
extern int grog(unsigned long long);
int id[4];
void faz()
{
__addfsbyte(UL, UC);
}
And here’s the output when compiled:
; Listing generated by Microsoft (R) Optimizing Compiler Version
14.00.50727.177
TITLE C:\PROGRA~2\DDKs\5600\test.c
.686P
.XMM
include listing.inc
.model flat
INCLUDELIB LIBCMT
INCLUDELIB OLDNAMES
_DATA SEGMENT
COMM _id:DWORD:04H
_DATA ENDS
PUBLIC _faz
EXTRN _UL:DWORD
EXTRN _UC:BYTE
; Function compile flags: /Odtp
_TEXT SEGMENT
_faz PROC
; File c:\programming\ddks\5600\test.c
; Line 56
push ebp
mov ebp, esp
; Line 57
mov al, BYTE PTR _UC
mov ecx, DWORD PTR _UL
add BYTE PTR fs:[ecx], ecx
; Line 58
pop ebp
ret 0
_faz ENDP
_TEXT ENDS
END
I also tested with optimizations, and on MSVC’s compiler as well. In
some cases, _UC isn’t even read at all, but in both cases, the final
operation ends up beind add fs:[reg], samereg.
Best regards,
Alex Ionescu</stddef.h>
I fwd’ed the message, I’ll get back to you when there is an update
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alex Ionescu
[397670]
Sent: Thursday, September 14, 2006 5:19 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Another Compiler Intrinsic Bug
Hi,
Last month, there was a talk of a intrinsic bug in MSVC/DDK’s CL, and it
looks like this forum made it get the attention it needed to get a
fix/repro from other people, so I hope nobody minds if I post another
one.
The bug is in __addfsbyte, when used with an external. Here’s my test
code:
#include <stddef.h>
extern char C;
extern short W;
extern long L;
extern long long LL;
extern unsigned char UC;
extern unsigned short UW;
extern unsigned long UL;
extern unsigned long long ULL;
extern char C1;
extern short W1;
extern long L1;
extern long long LL1;
extern unsigned char UC1;
extern unsigned short UW1;
extern unsigned long UL1;
extern unsigned long long ULL1;
extern char C2;
extern short W2;
extern long L2;
extern long long LL2;
extern unsigned char UC2;
extern unsigned short UW2;
extern unsigned long UL2;
extern unsigned long long ULL2;
extern char C3;
extern short W3;
extern long L3;
extern long long LL3;
extern unsigned char UC3;
extern unsigned short UW3;
extern unsigned long UL3;
extern unsigned long long ULL3;
extern int I;
extern int I1;
extern int I2;
extern int I3;
extern unsigned int UI;
extern unsigned int UI1;
extern unsigned int UI2;
extern unsigned int UI3;
extern int foo();
extern int baz();
extern int bar(int);
extern int bar8(unsigned char);
extern int graz(void *);
extern int grog(unsigned long long);
int id[4];
void faz()
{
__addfsbyte(UL, UC);
}
And here’s the output when compiled:
; Listing generated by Microsoft (R) Optimizing Compiler Version
14.00.50727.177
TITLE C:\PROGRA~2\DDKs\5600\test.c
.686P
.XMM
include listing.inc
.model flat
INCLUDELIB LIBCMT
INCLUDELIB OLDNAMES
_DATA SEGMENT
COMM _id:DWORD:04H
_DATA ENDS
PUBLIC _faz
EXTRN _UL:DWORD
EXTRN _UC:BYTE
; Function compile flags: /Odtp
_TEXT SEGMENT
_faz PROC
; File c:\programming\ddks\5600\test.c
; Line 56
push ebp
mov ebp, esp
; Line 57
mov al, BYTE PTR _UC
mov ecx, DWORD PTR _UL
add BYTE PTR fs:[ecx], ecx
; Line 58
pop ebp
ret 0
_faz ENDP
_TEXT ENDS
END
I also tested with optimizations, and on MSVC’s compiler as well. In
some cases, _UC isn’t even read at all, but in both cases, the final
operation ends up beind add fs:[reg], samereg.
Best regards,
Alex Ionescu
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer</stddef.h>