<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:v =
"urn:schemas-microsoft-com:vml" xmlns:o =
"urn:schemas-microsoft-com:office:office" xmlns:w =
"urn:schemas-microsoft-com:office:word" xmlns:st1 =
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6000.16414" name=GENERATOR><!--[if !mso]>
<STYLE>v\:* {
BEHAVIOR: url(#default#VML)
}
o\:* {
BEHAVIOR: url(#default#VML)
}
w\:* {
BEHAVIOR: url(#default#VML)
}
.shape {
BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]--><o:SmartTagType name="place"
namespaceuri="urn:schemas-microsoft-com:office:smarttags"></o:SmartTagType><!--[if !mso]>
<STYLE>st1\:* {
BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
font-family: Tahoma;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
COLOR: blue; TEXT-DECORATION: underline
}
P {
FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: "Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto
}
SPAN.EmailStyle18 {
COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
page: Section1
}
</STYLE>
</HEAD>
<BODY lang=EN-US vLink=blue link=blue>
<DIV><SPAN class=931590000-30052007><FONT face=Arial color=#0000ff size=2>I
guess we can do the workaround as you suggest (that is either use padding or a
union which would only be a change to the struct
themselves).</FONT></SPAN></DIV>
<DIV><SPAN class=931590000-30052007><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=931590000-30052007><FONT face=Arial color=#0000ff size=2>We
would probably have to wait for the OFED release before we switch our compiler
though.</FONT></SPAN></DIV>
<DIV><SPAN class=931590000-30052007><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=931590000-30052007><FONT face=Arial color=#0000ff
size=2>Another issue that I saw with the new compiler is that if I open many
applications compiling takes much longer. I wander if anyone has seen this or
has some idea of how to solve this issue.</FONT></SPAN></DIV>
<DIV><SPAN class=931590000-30052007><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=931590000-30052007><FONT face=Arial color=#0000ff
size=2>Thanks</FONT></SPAN></DIV>
<DIV><SPAN class=931590000-30052007><FONT face=Arial color=#0000ff
size=2>Tzachi</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Jan Bottorff
[mailto:jbottorff@xsigo.com] <BR><B>Sent:</B> Wednesday, May 30, 2007 1:56
AM<BR><B>To:</B> Tzachi Dar; Mirko Benz;
ofw@lists.openfabrics.org<BR><B>Subject:</B> RE: [ofw] Vista
supported?<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV class=Section1>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi,<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Yes, I know about the
suggestion on NTDEV, I was the person who started the
thread.<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">The workaround is
fine for my trivial test example, but unfortunately, it would take changing
the IB stack sources in many places to use this workaround. If we could find a
workaround that only needed to change the structure declaration (like
explicitly adding a pad field on 32-bit builds) it would be much easier.
Changing EVERY call point is a lot of changes. <o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">-
Jan<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<DIV>
<DIV class=MsoNormal style="TEXT-ALIGN: center" align=center><FONT
face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt">
<HR tabIndex=-1 align=center width="100%" SIZE=2>
</SPAN></FONT></DIV>
<P class=MsoNormal><B><FONT face=Tahoma size=2><SPAN
style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:</SPAN></FONT></B><FONT
face=Tahoma size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> Tzachi
Dar [mailto:tzachid@mellanox.co.il] <BR><B><SPAN
style="FONT-WEIGHT: bold">Sent:</SPAN></B> Saturday, May 26, 2007 1:32
PM<BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> Jan Bottorff; Mirko
Benz; ofw@lists.openfabrics.org<BR><B><SPAN
style="FONT-WEIGHT: bold">Subject:</SPAN></B> RE: [ofw] <st1:place
w:st="on">Vista</st1:place> supported?</SPAN></FONT><o:p></o:p></P></DIV>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN
style="FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P>
<P><FONT face="Times New Roman" size=3><SPAN
style="FONT-SIZE: 12pt">Hi,<BR><BR>As far as for the compiler bugs it seems
that it has a simple workaround, see bellow for ideas that I have.<BR><BR>The
main issue that I currently see is that we are getting close to a new release,
and replacing the compiler so close to a release is not that good idea. As you
said, for now we can continue based on the binary computability of
vista.<BR><BR>Thanks<BR>Tzachi<BR><BR>2 ways in order to work around the
compiler bugs:<BR>As remembered the problem is because we have to make sure
that we reserve 64 bit for a pointer even on 32 bit systems. The obvious way
to do this is to use __ptr64 that doesn't work on new builds.<BR>1) As was
suggested in the OSR forum, one can simply change the struct to use a union of
the pointer and some 64 bits value.<BR>2) one can use the same struct as
before but do some other thing:<BR>void test(long
val)<BR>{<BR> if (val ==
0)<BR>
return;<BR><BR> // the following
line crashes the 6000/6001 WDK 32-bit compiler
with<BR> // error C1001: An internal
error has occurred in the
compiler.<BR>
//var1->funcPtr(0);<BR><FONT color=red><SPAN
style="COLOR: red"> var2 =
var1->funcPtr;<BR> var2(0); //
Very ugly but Compiles well<BR></SPAN></FONT>}<BR></SPAN></FONT><FONT
size=2><SPAN style="FONT-SIZE: 10pt"><BR><BR>> -----Original
Message-----<BR>> From: ofw-bounces@lists.openfabrics.org<BR>> [<A
href="mailto:ofw-bounces@lists.openfabrics.org">mailto:ofw-bounces@lists.openfabrics.org</A>]
On Behalf Of Jan Bottorff<BR>> Sent: Friday, May 25, 2007 10:21 PM<BR>>
To: Mirko Benz; ofw@lists.openfabrics.org<BR>> Subject: RE: [ofw]
<st1:place w:st="on">Vista</st1:place> supported?<BR>><BR>> I know the
WinIB source tree will not compile with the <st1:place
w:st="on">Vista</st1:place><BR>> (or later) WDK (at least will not compile
for checked 32-bit<BR>> platforms). The problem is the compiler aborts
when<BR>> processing __ptr64 pointers inside a structure. The WinIB<BR>>
stack uses this in LOTS of places.<BR>><BR>> I'm not super optimistic
about Microsoft fixing the compiler<BR>> anytime soon, because I also see
compiler bugs in the code<BR>> generation for InterlockedAnd (and other
Interlocked<BR>> functions) that have been know for more than a year, are
not<BR>> fixed. The most recent WDK betas seems to have a fix for<BR>>
InterlockedAnd in the debug build, but the free build still<BR>> gets it
wrong.<BR>><BR>> The following will reproduce the __ptr64
bug:<BR>><BR>>
---------------------------------------------------------------<BR>>
#include <ntddk.h><BR>><BR>> struct
{<BR>> void (* __ptr64 funcPtr)(long
val); } *var1;<BR>><BR>><BR>><BR>><BR>> void test(long
val)<BR>> {<BR>> if (val == 0)<BR>>
return;<BR>><BR>> // the following line
crashes the 6000/6001 WDK 32-bit<BR>> compiler with<BR>>
// error C1001: An internal error has occurred
in the compiler.<BR>>
var1->funcPtr(0);<BR>> }<BR>><BR>> NTSTATUS
DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING<BR>>
RegistryPath)<BR>> {<BR>>
var1->funcPtr = &test;<BR>>
test(1);<BR>> return STATUS_SUCCESS;<BR>>
}<BR>>
--------------------------------------------------------------<BR>><BR>>
The InterlockedAnd bug shows up in code like:<BR>><BR>> // atomic test
and clear<BR>> If (InterlockedAnd(&flag, 0)) {<BR>>
// this code never executes<BR>>
// InterlockedAnd is documented to return the
old value<BR>> // but actually returns the
modified value }<BR>><BR>> Binaries compiled using the W2k3 SP1 DDK can
run on <st1:place w:st="on">Vista</st1:place>,<BR>> but doing development
on the latest tools is a serious<BR>> problem. I view it a Microsoft
problem, since it was<BR>> something in the <st1:place
w:st="on">Vista</st1:place> (and later) WDK compiler that
broke.<BR>><BR>> - Jan<BR>><BR>><BR>> -----Original
Message-----<BR>> From: ofw-bounces@lists.openfabrics.org<BR>> [<A
href="mailto:ofw-bounces@lists.openfabrics.org">mailto:ofw-bounces@lists.openfabrics.org</A>]
On Behalf Of Mirko Benz<BR>> Sent: Friday, May 25, 2007 1:38 AM<BR>> To:
ofw@lists.openfabrics.org<BR>> Subject: [ofw] <st1:place
w:st="on">Vista</st1:place> supported?<BR>><BR>> Hi,<BR>><BR>>
What is the status of support for <st1:place w:st="on">Vista</st1:place>?
Should SRP work?<BR>><BR>> Regards,<BR>> Mirko<BR>>
_______________________________________________<BR>> ofw mailing
list<BR>> ofw@lists.openfabrics.org<BR>> <A
href="http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw">http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw</A><BR>>
_______________________________________________<BR>> ofw mailing
list<BR>> ofw@lists.openfabrics.org<BR>> <A
href="http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw">http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw</A><BR>>
</SPAN></FONT><o:p></o:p></P></DIV></BLOCKQUOTE></BODY></HTML>