Re: Another Compiler Intrinsic Bug

NTDEV
1

*Bump*

Any news? :slight_smile:

–
Best regards,
Alex Ionescu

Doron Holan wrote:

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>