Elford, Chris L wrote:
Of course the inline is a hint rather than a directive (see
http://www.codeproject.com/cpp/Macros_vs_Inlines.asp), you need to expect
variability.
I think one should expect compiler to compiler differences when one uses the
c++ features like the inline directive. I don't think that there is any
guarantee that you will get an external symbol for an inlined implementation
[After all, you may decide to have 10 different inline implementations in 10
different files and cause all sorts of confusion]... One tends to do this with
putting inlined accessor methods within the header files. If the methods get
too big, you start to see compiler to compiler and platform to platform
variation at [dynamic] link time.
This behavior suggests that the Intel compiler is more aggressive at optimization than the MS compiler. This isn't too surprising and certainly doesn't imply that either is "incorrect". As more compilers on more platforms are used to compile DRLVM and the native class library components, I fully expect more latent bugs like this in the source code to show up.
I absolutely don't understand how you can claim a "hint" like "inline"
can be considered a bug in the source when the sourcebase is being
compiled by the same compiler. can you explain?
geir
Thanks,
Chris
-----Original Message-----
From: Mikhail Fursov [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 30, 2006 7:01 AM
To: [email protected]
Subject: Re: [build] HWA doesn't work
IMO I think this is a "feature" of Intel compiler - here it's incompatible
with MS.
If method is marked as inline only in cpp file ICC inlines it and could not
produce body for the method in object file. Since method is public object
loader (MS one) looks for this method and fails.
PS. making this method not inlined does not affect performance at all.
On 11/30/06, Dmitry Irlyanov <[EMAIL PROTECTED]> wrote:
Geir, Evgueni
May be you are right, I've just explained my own opinion :)
Of course, missing stability due to inlining is a bug
But I don't know the compiler optimisation features and refer to a
compiler
as a universal product that can be used ererywhere - so we should apply it
with all it's features-bugs.
2006/11/30, Evgueni Brevnov <[EMAIL PROTECTED]>:
Sorry - I don't understand either. Could you explain please?
Evgueni
On 11/30/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Sorry - how can it be a classloader bug if every other compiler we've
built with doesn't have a problem?
geir
Dmitry Irlyanov wrote:
Geir,
I think it is rather a classloader bug.
JIRA №2375 has been created (
http://issues.apache.org/jira/browse/HARMONY-2375)
________________
With Best Regards,
Irlyanov Dmitry
Intel Corporation
Middleware Products Division
2006/11/29, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
Just can't wait to see the JIRA... what is the solution? is this
an
Intel compiler bug?
geir
Dmitry Irlyanov wrote:
Tested on Revision: 480581
before any changes:
./java Hello
Failed to open JVM DLL:
/harmony/trunk/working_vm/build/lnx_ia32_icc_release/deploy/jre/bin/default/harmonyvm
(harmony/trunk/working_vm/build/lnx_ia32_icc_release/deploy/jre/bin/default/libharmonyvm.so:
undefined symbol:
_ZN20BootstrapClassLoader13SetBCPElementEPKcP10apr_pool_t)
after removing inline option of SetBCPElement in
\harmony\trunk\working_vm\vm\vmcore\src\class_support\classloader.cpp
./java Hello
Hello
Thank you, Mikhail!
Now I'm preparing the patch and creating a JIRA issue.
2006/11/29, Dmitry Irlyanov <[EMAIL PROTECTED]>:
I think, it is the most likely reason :)
Now I'll test this issue and after the testing inform the
result.
2006/11/29, Mikhail Fursov <[EMAIL PROTECTED]>:
Actually I do not understand why this method is marked as
"inline" in
cpp.
Could it be the reason?
On 11/29/06, Dmitry Irlyanov <[EMAIL PROTECTED]> wrote:
Compiler: icc (ICC) 9.0 20051020
OS:SuSE Linux 9.2 (i586)
2006/11/29, Geir Magnusson Jr. < [EMAIL PROTECTED]>:
What toolset?
Dmitry Irlyanov wrote:
Mikhail,
The system was built from the very beginning (svn co))
This error received after the following command:
./java -classpath . Hello
May be this exotic output is happen by reason of exotic
compiler?
2006/11/29, Mikhail Fursov < [EMAIL PROTECTED]>:
Dmitry,
SetBCPElement has become public inside of vmcore module
after
H2008
is
applied. This is the only change I remember for this
method.
Also it's very strange that you can link DRLVM and get
this
error
on
runtime
: this method is vmcore library local.
Did you try clean build?
On 11/29/06, Dmitry Irlyanov < [EMAIL PROTECTED]>
wrote:
Good day!
I've successfully build class libraries and DRLVM on
Linux,
but
the
build
doesn't work.
After starting Hello World Application the followinng
exceptionis
thrown:
Failed to open JVM
DLL:/drlvm/trunk/build/lnx_ia32_icc_release/deploy/jre/bin/default/harmonyvm(/drlvm/trunk/build/lnx_ia32_icc_release/deploy/jre/bin/default/libharmonyvm.so:
undefined symbol:
_ZN20BootstrapClassLoader13SetBCPElementEPKcP10apr_pool_t)
Do you know the cause of this error?
Should I add this to JIRA or it is my fault?
_______________
With Best Regards,
Irlyanov Dmitry
Intel Corporation
Middleware Products Division
--
Mikhail Fursov
_______________
With Best Regards,
Irlyanov Dmitry
Intel Corporation
Middleware Products Division
--
_______________
With Best Regards,
Irlyanov Dmitry
Intel Corporation
Middleware Products Division
--
Mikhail Fursov
--
_______________
With Best Regards,
Irlyanov Dmitry
Intel Corporation
Middleware Products Division
--
_______________
With Best Regards,
Irlyanov Dmitry
Intel Corporation
Middleware Products Division
