A question on a conflict of SIN

[bmchenry]

Thought that title might catch your attention...

But in reality i am having the following issue:

I have a program with 3 DLLs which i call from a C++ EXE and everything works fine.

However, when i link the DLLs with a 3rd party C++ EXE (which my C++ was built to mimic) i have ran into the following issue:

The SIN/COS functions are somehow corrupted and produce results >1.0 (and we all know SIN/COS are limited to +/- 1.0!!)

I am in the process of figuring out a fix but wondered if others have had a similar experience and how they tackled the apparent conflict of library name (who'd name anything SIN but SIN??)

This one took forever to track downresults 'changed' and I initially thought was memory issue, etc etc...finally did a number of dumps and found the SIN problem deep within one of the DLLs

so questions are:

1) for future reference, any easy way to determine possible conflicts between IVF and a 3rd party DLL? Like how might I produce a cross reference listing for checking and would it include members from the 3rd party C++ DLL??

2) If you have come across such a situation, how did you resolve (interested in other ideas)

Thank you for you assistance.

Brian

[Steven_L_Intel1]

Brian,

I'm a bit confused here. What exactly did you find? The routine the compiler calls for SIN and COS is not named SIN or COS - the actual name depends on a bunch of things including the datatype. Can you generate a link map (there's an option to do so in the link properties) and attach the map to a reply here? Where is the call to SIN or COS that gives you the wrong answer?

[bmchenry]

Sorry for the confusion.
The Elemental Intrinsic Function SIN produces the incorrect result (result comes out > 1.0)

So my initial thought is that itis the 3rd party C++ routine which uses a conflictinbg SIN function??
other than that it's a memory corruption issue...trying to track it down...

One possible side item: i am using the option /Qimf-arch-consistency:true to avoid issues on an AMD machine and that apparently can produce issues with REAL*8 v REAL*4 but i don't believe that is the issue here.

Thank you for your assistance.

brian

[mecej4]

You dropped dark hints such as "The SIN/COS functions are somehow corrupted and produce results >1.0", but have not shown any example or evidence that this is what happened. And, since Fortran has no reserved names, you have little protection against shooting yourself in the foot.

As Steve already pointed out, simply providing a substitute SIN function will not do the kind of havoc that you described. For example,

[fortran]program sinn
real x,y
x=2.0
write(*,*)x,sin(x)
end program sinn

function sin(x)
sin=x*x
stop 'BAD SIN() CALLED'
return
end function sin
[/fortran]

will not call the substitute function, because the intrinsic function that is actually called has a name such as "___libm_sse2_sinf" rather than "_SIN".

One would have to do something deliberate, e.g., declare SIN as EXTERNAL in the main program, provide a CONTAINed SIN routine within the main program or put in an exported routine called "___libm_sse2_sinf" in one of the DLLs. A programmer who did this would have earned the rewards that would come his way.

We need more information.

[TimP]

As mecej4 said, if some library provided a sin() function, in principle, sin wouldhave to be declared EXTERNAL in the caller, to link against that function.
If sin() were implemented directly by the x87 firmware, the limitation that range reduction is disabled for |argument| > 2**64 (copying the argument directly to the result) could come into play.

[bmchenry]

thanks for the replies
so let me demonstrate the issue
in the code (which is 8000+ lines) in one of the DLLs there is the following statements

SINPS = SIN(PSIT)

COSPS = COS(PSIT)

simple enough. works like a charm when called from MY c++ routine (one of 3 dlls, and this is but a small portion that i tracked the error to)
under normal situations, for PSIT = 4.1840, SINPS=-.86 & COSPS = -.50
however, when called from the 3rd party C++ DLL the results are SINPS = 2.662, COSPS=5.046???
both routines call
--- D:\users\nbtester\x86win_nightly\branch-12_0\20110310_010000\libdev\libm\real\sinf_bwr.c
which i expect is the library routine for SIN??
(this is the path provided when i step at the SINPS= line
any ideas on what might be causing this error?
again, works fine when called from my C++ routine, generally works fine when 2 DLLs are called, however when the 3rd DLL is called it somehow corrupts the SIN/COS routines??

thanks agins for your assistance
b

[mecej4]

Sorry, I don't see that you have demonstrated that "... when the 3rd DLL is called it somehow corrupts the SIN/COS routines". Although that remains a possible explanation, there are others.

Looking at variables in a source-level debugger may not give a true picture of the machine state with code that may have been compiled with some optimizations turned on -- such as the code in the "3rd DLL".

We need to see short code, along with stipulated compiler and OS versions, that allows replication of the problem. Without that, we can speculate at length, but we will make little progress towards resolving the problem

[bmchenry]

Thanks again for responses.
The problem presents itself in DEBUG mode both while tracking and when i write results out to a dump file.
interesting at one location the error was fixedif i used

SINPS = sngl(DSIN(dble(PSIT)))
COSPS =sngL(DCOS(dble(PSIT)))
in place of the simple SIN(PSIT) and COS(PSIT)
(obviously not a solution but it didproduce the correct results!)
And also theSIN function is used all over the program so i ned to get possible reasons for the issue to solve it, not work around it.
I can'tprovide sample code because it works fine when called from my C++ routine (in MVS 2008, IVF 12.0.3470.2008 compiled in win32 on a win64 machine) and only fubars when linked with the 3rd party C++ routine (which is MVS 2008 C++ compiled in win32).
To run i enter the 3rd party C++ routine exe name as the command argumentsin startup project of my solution (which contains the 3 DLLs). Debug then allows me to walk through my code as it is called from the 3rd party EXE.
I know this is a sketchy error report as it's ONLY when linked to the 3rd party EXE.
Note that there are 3 DLLs, and the third party C++ EXEworks correctly when used with 2 of the 3 DLLs. When an option is chosen which calls the 3rd DLLthe SIN problems when angle > pi radians problem occurs.

[Steven_L_Intel1]

Please attach the link map.

[Steven_L_Intel1]

Brian,

Thanks for attaching the maps (in a private reply). It isn't clear to me from your replies earlier where the SIN and COS calls are that are getting wrong answers. Furthermore, I see no evidence that any of these libraries you build declare a routine named SIN or COS. The only references to SIN and COS library routines I can find are all resolved in the same Intel math library DLL.

I think you need to debug this a bit more - step into the SIN call that goes awry - where does it lead? What is the actual routine name being called there? (You can do a disassembly view to see.)

[bmchenry]

Steve,

still walking through things trying to determine where things go haywire.
One interesting anomaly i found was the following:
if a solution contains two projects with similar routines, the MVS/iVF debug may walk through the wrong routine?
here's how it presented itself:
To test/check for memory swap issues, i copied one of the projects to a different directory, created a new project with a different name. Lets call it name2.
So name1 and name2 are projects are in a solution.
now name1 and name2 have all the same subroutine but create separate dlls.
A control routine, callname1and2, seperatly calls name1 and name2.
and all appears to be working fine.
until i walk through it in debug.
apparently the MVS/IVF debugger gets confused?
As I walk through to the 'main' routine of name1 and/or name2 to verify that it is calling them and then walk to the first subroutine call, it jumps to the other (original) project subroutine for source display (for testing purposes, i called name2 first) and then when i call Name1 it (correctly) walks through name1 routines.
make since?
Now this reminded me that unique names make things run better.
Is there an easier way to call two separate routines with all the same ssubroutine names and walks through each one in debug?

thanks again for your asisstance.

B

[Steven_L_Intel1]

I've never seen that behavior. As each routine is compiled, information about the source file and lines is added to the "program database" that the debugger uses when you step through code. Each project has its own PDB file.

I could imagine a problem if the .vfproj files for multiple projects were in the same directory. There's a bug in the compiler where it always writes the PDB file to the project directory rather than the "intermediate" directory for each project. You might try deleting the PDB file (VCxx.PDB), rebuilding the one project, and see if that helps. But I'm more interested in knowing what the assembly code shows is the routine being called to compute the SIN or COS.

[bmchenry]

ahhhhh....

All the files for all the separate projects all residein separate directories
however, I use output directory for all projects as $(SolutionDir)$(ConfigurationName)

(so alldlls are in one location) and no need to copy.

soooo...

the PDB file is also copied to $(SolutionDir)$(ConfigurationName) so therein lies the confusion factor.
i will send some excerpts from the disassembly in a separate thread

[bmchenry]

To update...Program once again working...correctly!! (see it was working, just giving funky results!)

I will try to create a test solutions to mimic the behavior after the dust settles and i make up for spinning my wheels for a couple of weeks (if i strip 90% of the code will it still misbehave?)

And it is working fast (amazing blazing speed in execution! The speed of the code created with this INTEL compiler is amazing!)

These problems did not surface until i used the option: /Qimf-arch-consistency:true
(I also have non-/Qimf-arch-consistency:true versions of the program which don't require any of these strange work-arounds and fnution properly...so this thread is for folks who have code which have issues on 'non-Intel' chipsets and use the -/Qimf-arch-consistency:true option)

(That option isrequired due to some issues on a couple ofAMD machines on the other side of the world)

(The /Qimf... option makes use of math library routine _bwr_sinf where the "bwr" means it's the version that returns the same results on all architectures)

(This all came from another issue i had: http://software.intel.com/en-us/forums/showpost.php?p=144183)

So for this project i used...

SINPS = sngl(DSIN(dble(PSIT)))
COSPS = SngL(DCOS(dble(PSIT)))
in place of

SINPS = SIN(PSIT)

COSPS = COS(PSIT)

(COSPS and SINPS are real, PSIT is real(4))

(yes it was a strange solution but it provides the correct results)

This new issue is related to that older issue http://software.intel.com/en-us/forums/showpost.php?p=144183
It is pasrt of the same 'solution (sln)' but a different project (this new problem from a new project added to the solution) and ONLY with the SIN/COS functions and only with /Qimf-arch-consistency:true

In that older solution I had to use

SPSI1 = SIN(dble(PSI1))

CPSI1 = COS(dble(PSI1))

(SPSI1 and SPSI2 are real(8), PSI1 is real(4))

Now obviously i note that the solution should have been

SPSI1 = DSIN(dble(PSI1))

CPSI1 = DCOS(dble(PSI1))

In reviewing tat issue, i thought the incorrect use of SIN in place of DSINmight be it!
But changing that didn't correct this new issue.
It also isn't a totalcorruption of the _bwr_sinf. SIN/COS work as expected in other areas of the program???

One other change i made in the final panic to find a solution was to remove
'Check Routine Interfaces'
which i recall from other postings sometimes can cause issue. I plan to test again (once i make additional progress on this project) rebuilding w/Check Routine Interfaces back on.

Note i've tried various combinations of the two items above and these are the only ones which work.

I will look for other avenues to determine where and why the SIN/COS functions produce strange results in only certain routines??

thanks for all your assitance.

brian

[Steven_L_Intel1]

It would be extremely helpful if you could come up with a test case that shows the problem with the bwr_sinf routine. It sounds as if there may be a bug there and we'd like to fix it if there is.

[bmchenry]

i will try to get to itnext week as I am also interested in resolving so identical code runs with any/all options (as it should!).

Just banging up on a project deadline and wanted to postup a solution for any others who might encounter something similar.

since this only occurs when called by the 3rd party application.
Myfirst item is to get their compiler build options/version/etc.
Thenhave them send a simple test exeto see if it will produce the same strageness.
I am sending out an email to them right now.

brian