You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@stdcxx.apache.org by fa...@apache.org on 2007/05/25 16:41:42 UTC
svn commit: r541672 - /incubator/stdcxx/trunk/include/rw/_config-msvc.h
Author: faridz
Date: Fri May 25 07:41:40 2007
New Revision: 541672
URL: http://svn.apache.org/viewvc?view=rev&rev=541672
Log:
2007-05-25 Farid Zaripov <Fa...@epam.com>
* _config-msvc.h: MSVC specific #pragma's decorated with #ifndef _INTEL_COMPILER;
added #pragma's to disable ICC warnings.
Modified:
incubator/stdcxx/trunk/include/rw/_config-msvc.h
Modified: incubator/stdcxx/trunk/include/rw/_config-msvc.h
URL: http://svn.apache.org/viewvc/incubator/stdcxx/trunk/include/rw/_config-msvc.h?view=diff&rev=541672&r1=541671&r2=541672
==============================================================================
--- incubator/stdcxx/trunk/include/rw/_config-msvc.h (original)
+++ incubator/stdcxx/trunk/include/rw/_config-msvc.h Fri May 25 07:41:40 2007
@@ -199,17 +199,28 @@
# define _RWSTD_NO_FWD_DECLARATIONS
#endif // _WIN64
+#ifndef __INTEL_COMPILER
// disable "Same type qualifier used more than once"
-#pragma warning (disable: 4114)
+# pragma warning (disable: 4114)
// disable "return type for operator->' is not a UDT"
-#pragma warning (disable: 4284)
+# pragma warning (disable: 4284)
// disable "decorated name length exceeded"
-#pragma warning (disable: 4503)
+# pragma warning (disable: 4503)
// disable "identifier was truncated to 255 characters"
-#pragma warning (disable: 4786)
+# pragma warning (disable: 4786)
+
+#else // __INTEL_COMPILER
+
+ // disable "function was declared "deprecated"
+# pragma warning (disable: 1478)
+
+ // disable "dllexport/dllimport conflict with ... ; dllexport assumed"
+# pragma warning (disable: 1740)
+
+#endif // __INTEL_COMPILER
#if defined (WIN32) && !defined(_WIN32)
# define _WIN32
RE: [PING] Re: svn commit: r541672 - /incubator/stdcxx/trunk/include/rw/_config-msvc.h
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Tuesday, June 05, 2007 7:02 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: [PING] Re: svn commit: r541672 -
> /incubator/stdcxx/trunk/include/rw/_config-msvc.h
>
> > I was not carefully read the comments. Since that section
> is related
> > to the MSVC 6.0 and earlier, I can't check whether that macros
> > detected correctly or not.
>
> Okay, I assume that doesn't change our decision to add the
> new config header (_config-msvcrt.h), correct?
Correct.
Farid.
Re: [PING] Re: svn commit: r541672 - /incubator/stdcxx/trunk/include/rw/_config-msvc.h
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com]
>> Sent: Monday, June 04, 2007 9:36 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: [PING] Re: svn commit: r541672 -
>> /incubator/stdcxx/trunk/include/rw/_config-msvc.h
>>
>>> What I see, is that we could remove all section between
>>> #if _MSC_VER <= 1200 // MSVC <= 6.0
>>> and
>>> #endif // MSVC <= 6.0
>>> because of the all macros are defined in config.h at the
>> configure
>>> step.
>> I think the reason why they are defined in _config_msvc.h is
>> because the autoconfigured ones are (or were at some point)
>> incorrectly detected. That certainly may have changed so we
>> need to check to make sure they are now detected correctly
>> before we take out the overriding definitions.
>
> I was not carefully read the comments. Since that section is related
> to
> the MSVC 6.0 and earlier, I can't check whether that macros detected
> correctly or not.
Okay, I assume that doesn't change our decision to add the new
config header (_config-msvcrt.h), correct? You can just move
all these conditionally #defined macros there for now. At some
point in the future we'll clean up all the MSVC 6.0 cruft since
I don't think we'll ever go back and try to support it.
Martin
RE: [PING] Re: svn commit: r541672 - /incubator/stdcxx/trunk/include/rw/_config-msvc.h
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Monday, June 04, 2007 9:36 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: [PING] Re: svn commit: r541672 -
> /incubator/stdcxx/trunk/include/rw/_config-msvc.h
>
> > What I see, is that we could remove all section between
> > #if _MSC_VER <= 1200 // MSVC <= 6.0
> > and
> > #endif // MSVC <= 6.0
> > because of the all macros are defined in config.h at the
> configure
> > step.
>
> I think the reason why they are defined in _config_msvc.h is
> because the autoconfigured ones are (or were at some point)
> incorrectly detected. That certainly may have changed so we
> need to check to make sure they are now detected correctly
> before we take out the overriding definitions.
I was not carefully read the comments. Since that section is related
to
the MSVC 6.0 and earlier, I can't check whether that macros detected
correctly or not.
Farid.
Re: [PING] Re: svn commit: r541672 - /incubator/stdcxx/trunk/include/rw/_config-msvc.h
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> Farid, do you agree that this is the way to go? If you do, do
>> you plan to move the Intel C++ specific code to the
>> _config-icc.h header? (Just making sure this doesn't slip
>> through the cracks.)
>
> I need to inspect what the macros from _config_msvc.h are Intel C++
> compiler specific (except disabled warnings).
>
> What I see, is that we could remove all section between
> #if _MSC_VER <= 1200 // MSVC <= 6.0
> and
> #endif // MSVC <= 6.0
> because of the all macros are defined in config.h at the configure
> step.
I think the reason why they are defined in _config_msvc.h is
because the autoconfigured ones are (or were at some point)
incorrectly detected. That certainly may have changed so we
need to check to make sure they are now detected correctly
before we take out the overriding definitions.
Martin
RE: [PING] Re: svn commit: r541672 - /incubator/stdcxx/trunk/include/rw/_config-msvc.h
Posted by Farid Zaripov <Fa...@epam.com>.
> Farid, do you agree that this is the way to go? If you do, do
> you plan to move the Intel C++ specific code to the
> _config-icc.h header? (Just making sure this doesn't slip
> through the cracks.)
I need to inspect what the macros from _config_msvc.h are Intel C++
compiler specific (except disabled warnings).
What I see, is that we could remove all section between
#if _MSC_VER <= 1200 // MSVC <= 6.0
and
#endif // MSVC <= 6.0
because of the all macros are defined in config.h at the configure
step.
Farid.
[PING] Re: svn commit: r541672 - /incubator/stdcxx/trunk/include/rw/_config-msvc.h
Posted by Martin Sebor <se...@roguewave.com>.
Farid, do you agree that this is the way to go? If you do,
do you plan to move the Intel C++ specific code to the
_config-icc.h header? (Just making sure this doesn't slip
through the cracks.)
Martin
Martin Sebor wrote:
> faridz@apache.org wrote:
>> Author: faridz
>> Date: Fri May 25 07:41:40 2007
>> New Revision: 541672
>>
>> URL: http://svn.apache.org/viewvc?view=rev&rev=541672
>> Log:
>> 2007-05-25 Farid Zaripov <Fa...@epam.com>
>>
>> * _config-msvc.h: MSVC specific #pragma's decorated with #ifndef
>> _INTEL_COMPILER;
>> added #pragma's to disable ICC warnings.
>
> I wonder if it wouldn't be cleaner to move all the Intel C++
> specific code out of _config-msvc.h and into _config-icc.h
> and make sure we #include the former only for MSVC and the
> latter only for Intel C++. One of the goals of separating
> all the compiler-specific hacks and overrides was to make
> it clear what's where and avoid accidentally breaking one
> compiler while fixing a problem in another. The way we
> handle MSVC and Intel C++ on Windows seems to go against
> the goal (even though the compilers are meant to be fully
> compatible).
>
> Thoughts?
>
> Martin
>
>>
>> Modified:
>> incubator/stdcxx/trunk/include/rw/_config-msvc.h
>>
>> Modified: incubator/stdcxx/trunk/include/rw/_config-msvc.h
>> URL:
>> http://svn.apache.org/viewvc/incubator/stdcxx/trunk/include/rw/_config-msvc.h?view=diff&rev=541672&r1=541671&r2=541672
>>
>> ==============================================================================
>>
>> --- incubator/stdcxx/trunk/include/rw/_config-msvc.h (original)
>> +++ incubator/stdcxx/trunk/include/rw/_config-msvc.h Fri May 25
>> 07:41:40 2007
>> @@ -199,17 +199,28 @@
>> # define _RWSTD_NO_FWD_DECLARATIONS
>> #endif // _WIN64
>>
>> +#ifndef __INTEL_COMPILER
>> // disable "Same type qualifier used more than once"
>> -#pragma warning (disable: 4114)
>> +# pragma warning (disable: 4114)
>>
>> // disable "return type for operator->' is not a UDT"
>> -#pragma warning (disable: 4284)
>> +# pragma warning (disable: 4284)
>>
>> // disable "decorated name length exceeded"
>> -#pragma warning (disable: 4503)
>> +# pragma warning (disable: 4503)
>>
>> // disable "identifier was truncated to 255 characters"
>> -#pragma warning (disable: 4786)
>> +# pragma warning (disable: 4786)
>> +
>> +#else // __INTEL_COMPILER
>> +
>> + // disable "function was declared "deprecated"
>> +# pragma warning (disable: 1478)
>> +
>> + // disable "dllexport/dllimport conflict with ... ; dllexport
>> assumed"
>> +# pragma warning (disable: 1740)
>> +
>> +#endif // __INTEL_COMPILER
>>
>> #if defined (WIN32) && !defined(_WIN32)
>> # define _WIN32
>>
>>
>
>
Re: svn commit: r541672 - /incubator/stdcxx/trunk/include/rw/_config-msvc.h
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com]
>> Sent: Tuesday, May 29, 2007 8:39 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: svn commit: r541672 -
>> /incubator/stdcxx/trunk/include/rw/_config-msvc.h
>>
>> Well, I guess we need to decide if it's a good idea to
>> maintain two sets of the same chunks of code or if it would
>> be better to factor the code into a common file. If the
>> latter, we need to decide on the mechanism we want to use to
>> use the code with each compiler. Here are the possibilities I see:
>>
>> 1. Status quo: For an Intel C++ installation on top of MSVC
>> _config.h #includes both _config-msvc.h and _config-icc.h,
>> and _config-msvc.h must be prepared to deal with it.
>>
>> 2. Duplicate CRT-specific macro hackery from _config-msvc.h
>> in _config-icc.h for Intel C++ on top of MSVC.
>>
>> 3. Move CRT-specific macros hackery from _config-msvc.h to a
>> new config header, say _config-msvcrt.h, and #include this
>> header from both _config-msvc.h and _config-icc.h, making
>> sure _config-msvc.h is #included only for MSVC and not for
>> Intel C++ on top of it.
>>
>> Preferences? Any other possible ways to deal with this?
>
> 3 is optimal way, as for me.
Sounds good to me too. I created a new issue/improvement to
track this change, assigned it you, and scheduled it for 4.2:
https://issues.apache.org/jira/browse/STDCXX-429
Martin
RE: svn commit: r541672 - /incubator/stdcxx/trunk/include/rw/_config-msvc.h
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Tuesday, May 29, 2007 8:39 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: svn commit: r541672 -
> /incubator/stdcxx/trunk/include/rw/_config-msvc.h
>
> Well, I guess we need to decide if it's a good idea to
> maintain two sets of the same chunks of code or if it would
> be better to factor the code into a common file. If the
> latter, we need to decide on the mechanism we want to use to
> use the code with each compiler. Here are the possibilities I see:
>
> 1. Status quo: For an Intel C++ installation on top of MSVC
> _config.h #includes both _config-msvc.h and _config-icc.h,
> and _config-msvc.h must be prepared to deal with it.
>
> 2. Duplicate CRT-specific macro hackery from _config-msvc.h
> in _config-icc.h for Intel C++ on top of MSVC.
>
> 3. Move CRT-specific macros hackery from _config-msvc.h to a
> new config header, say _config-msvcrt.h, and #include this
> header from both _config-msvc.h and _config-icc.h, making
> sure _config-msvc.h is #included only for MSVC and not for
> Intel C++ on top of it.
>
> Preferences? Any other possible ways to deal with this?
3 is optimal way, as for me.
Farid.
Re: svn commit: r541672 - /incubator/stdcxx/trunk/include/rw/_config-msvc.h
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> I wonder if it wouldn't be cleaner to move all the Intel C++
>> specific code out of _config-msvc.h and into _config-icc.h
>> and make sure we #include the former only for MSVC and the
>> latter only for Intel C++. One of the goals of separating all
>> the compiler-specific hacks and overrides was to make it
>> clear what's where and avoid accidentally breaking one
>> compiler while fixing a problem in another. The way we handle
>> MSVC and Intel C++ on Windows seems to go against the goal
>> (even though the compilers are meant to be fully compatible).
>>
>> Thoughts?
>
> The Intel C++ compiler is just set of the binary tools (compiler,
> linker, .... and some
> processor optimized extension libraries (math library, integer and float
> vector class library).
> The package don't include the CRT library and uses the CRT from
> installed MSVC.
> I have the installed three versions of the MSVC: 7.0, 7.1 and 8.0. And I
> can build
> the some project using Intel C++ with any CRT which I have.
>
> I mean that some of the macros from _config-msvc.h is not
> compiler-specific, but CRT specific.
Right, good point. We don't make a distinction between compilers
and their runtime libraries. I don't think Intel C++ on Windows
is the only compiler that uses (parts of) another compiler's
runtime. AFAIK, IBM XLC++ on Linux works the same way (uses
gcc's runtime). I suspect there might be, or will be, others,
such as Sun C++ when Sun implements and deploys its gcc
compatibility mode. See Steve Clamage's comment in this thread:
http://forum.java.sun.com/thread.jspa?threadID=5173584
> If we want to separate the Intel and MSVC config files, we should
> copy-paste that
> macros into the _config_icc.h. Is that corresponds the goals?
Well, I guess we need to decide if it's a good idea to maintain
two sets of the same chunks of code or if it would be better to
factor the code into a common file. If the latter, we need to
decide on the mechanism we want to use to use the code with each
compiler. Here are the possibilities I see:
1. Status quo: For an Intel C++ installation on top of MSVC
_config.h #includes both _config-msvc.h and _config-icc.h,
and _config-msvc.h must be prepared to deal with it.
2. Duplicate CRT-specific macro hackery from _config-msvc.h
in _config-icc.h for Intel C++ on top of MSVC.
3. Move CRT-specific macros hackery from _config-msvc.h to
a new config header, say _config-msvcrt.h, and #include this
header from both _config-msvc.h and _config-icc.h, making
sure _config-msvc.h is #included only for MSVC and not for
Intel C++ on top of it.
Preferences? Any other possible ways to deal with this?
Martin
RE: svn commit: r541672 - /incubator/stdcxx/trunk/include/rw/_config-msvc.h
Posted by Farid Zaripov <Fa...@epam.com>.
> I wonder if it wouldn't be cleaner to move all the Intel C++
> specific code out of _config-msvc.h and into _config-icc.h
> and make sure we #include the former only for MSVC and the
> latter only for Intel C++. One of the goals of separating all
> the compiler-specific hacks and overrides was to make it
> clear what's where and avoid accidentally breaking one
> compiler while fixing a problem in another. The way we handle
> MSVC and Intel C++ on Windows seems to go against the goal
> (even though the compilers are meant to be fully compatible).
>
> Thoughts?
The Intel C++ compiler is just set of the binary tools (compiler,
linker, .... and some
processor optimized extension libraries (math library, integer and float
vector class library).
The package don't include the CRT library and uses the CRT from
installed MSVC.
I have the installed three versions of the MSVC: 7.0, 7.1 and 8.0. And I
can build
the some project using Intel C++ with any CRT which I have.
I mean that some of the macros from _config-msvc.h is not
compiler-specific, but CRT specific.
If we want to separate the Intel and MSVC config files, we should
copy-paste that
macros into the _config_icc.h. Is that corresponds the goals?
Farid.
Re: svn commit: r541672 - /incubator/stdcxx/trunk/include/rw/_config-msvc.h
Posted by Martin Sebor <se...@roguewave.com>.
faridz@apache.org wrote:
> Author: faridz
> Date: Fri May 25 07:41:40 2007
> New Revision: 541672
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=541672
> Log:
> 2007-05-25 Farid Zaripov <Fa...@epam.com>
>
> * _config-msvc.h: MSVC specific #pragma's decorated with #ifndef _INTEL_COMPILER;
> added #pragma's to disable ICC warnings.
I wonder if it wouldn't be cleaner to move all the Intel C++
specific code out of _config-msvc.h and into _config-icc.h
and make sure we #include the former only for MSVC and the
latter only for Intel C++. One of the goals of separating
all the compiler-specific hacks and overrides was to make
it clear what's where and avoid accidentally breaking one
compiler while fixing a problem in another. The way we
handle MSVC and Intel C++ on Windows seems to go against
the goal (even though the compilers are meant to be fully
compatible).
Thoughts?
Martin
>
> Modified:
> incubator/stdcxx/trunk/include/rw/_config-msvc.h
>
> Modified: incubator/stdcxx/trunk/include/rw/_config-msvc.h
> URL: http://svn.apache.org/viewvc/incubator/stdcxx/trunk/include/rw/_config-msvc.h?view=diff&rev=541672&r1=541671&r2=541672
> ==============================================================================
> --- incubator/stdcxx/trunk/include/rw/_config-msvc.h (original)
> +++ incubator/stdcxx/trunk/include/rw/_config-msvc.h Fri May 25 07:41:40 2007
> @@ -199,17 +199,28 @@
> # define _RWSTD_NO_FWD_DECLARATIONS
> #endif // _WIN64
>
> +#ifndef __INTEL_COMPILER
> // disable "Same type qualifier used more than once"
> -#pragma warning (disable: 4114)
> +# pragma warning (disable: 4114)
>
> // disable "return type for operator->' is not a UDT"
> -#pragma warning (disable: 4284)
> +# pragma warning (disable: 4284)
>
> // disable "decorated name length exceeded"
> -#pragma warning (disable: 4503)
> +# pragma warning (disable: 4503)
>
> // disable "identifier was truncated to 255 characters"
> -#pragma warning (disable: 4786)
> +# pragma warning (disable: 4786)
> +
> +#else // __INTEL_COMPILER
> +
> + // disable "function was declared "deprecated"
> +# pragma warning (disable: 1478)
> +
> + // disable "dllexport/dllimport conflict with ... ; dllexport assumed"
> +# pragma warning (disable: 1740)
> +
> +#endif // __INTEL_COMPILER
>
> #if defined (WIN32) && !defined(_WIN32)
> # define _WIN32
>
>