Community
cancel
Showing results for 
Search instead for 
Did you mean: 
nemequ
New Contributor I
147 Views

Documentation for previous versions

I'm working on a project ("Hedley") to abstract away some differences between compilers, but I'm having trouble figuring out when certain features were added to ICC.  For example, I have a HEDLEY_DIAGNOSTIC_DISABLE_DEPRECATED macro which maps to `_Pragma("clang diagnostic ignored \"-Wdeprecated\"")` on clang when `__has_warning("-Wdeprecated")` is true, `_Pragma("GCC diagnostic ignored \"-Wdeprecated\"")` for GCC ≥ 4.3, `__pragma(warning(disable:4996))` for MSVC ≥ 15, and `_Pragma("warning(disable:1478)")` for ICC ≥ 16.  Clang, GCC, and MSVC are all pretty straightforward to check, but with ICC I can't seem to find earlier versions of the documentation to see when warning #1478 made its first appearance.

It's not just specific warnings that I'm stuck on (TBH, I can't even find a reference to warning #1478 in the current documentation; any help there would be very welcome as well).  I also have `_Pragma("warning(push)")`/`_Pragma("warning(pop)")` for ICC ≥ 16 only, but I'm pretty confident it is available earlier.  For most other stuff I haven't even looked at ICC yet (largely because of this issue), and instead just rely on the GCC emulation.  I'd really like to support ICC since it has some great options to help with optimizations (optimization reports are fantastic) and I'd love to provide as much detail to the compiler as possible to help make those even better.

0 Kudos
9 Replies
Judith_W_Intel
Employee
147 Views

 

warning #1478 is emitted when an entity that was declared deprecated is referenced, i.e.:

sptxl15-228> cat t.cpp

int variable __attribute((deprecated));

int main() {
   variable++;
   return 0;
}
sptxl15-229> icpc -c t.cpp
t.cpp(5): warning #1478: variable "variable" (declared at line 2) was declared deprecated
     variable++;
     ^

sptxl15-230>

To disable it you can use __pragma(warning(disable:4996)) -- this works with both our Microsoft and Linux compilers or _pragma(warning(disable:1478)). This warning has been around since at least the 14.0 version of our compilers (I don't have anything older than that to try).

This kind of details would not be included with our documentation so having access to it wouldn't help.

The _Pragma warning syntax has been available for at least as far back as 14.0 too.

Judy

nemequ
New Contributor I
147 Views

Okay, I'll lower the requirment for disabling the deprecated warning to 14.0.  However, I still have a lot of other things I'd like to check; for example, what about `_Pragma("warning(push)")`/`_Pragma("warning(pop)")`?  And `__assume_aligned`?  My project has tons of these macros (see the API reference or the code), just asking about each one in this forum doesn't seem fair…

Judith_W_Intel
Employee
147 Views

 

As I said in my previous note the _Pragma syntax you mention goes back at least as far as 14.0. The same is true for __assume_aligned.

I think you can generally assume that features that in older GNU versions are supported in older Intel compilers. It's generally only the ones that we didn't know about at the time (i.e. GNU features that were added in recent releases) that are not supported.

Judy

nemequ
New Contributor I
147 Views

Judith Ward (Intel) wrote:
As I said in my previous note the _Pragma syntax you mention goes back at least as far as 14.0.

Sorry, I thought you were just talking about disabling specific warnings, not the push/pop stuff.

Judith Ward (Intel) wrote:
The same is true for __assume_aligned.

I think you can generally assume that features that in older GNU versions are supported in older Intel compilers. It's generally only the ones that we didn't know about at the time (i.e. GNU features that were added in recent releases) that are not supported.

That's kind of my point.  For versions of ICC which masquerade as GCC versions which have __builtin_assume_aligned (i.e., ≥ 4.7), I can just use that.  However, ICC has supported __assume_aligned for longer, and I would like to support the oldest versions I can.  People tend not to upgrade expensive proprietary compilers as often as free open-source ones…  I know people who still use Visual Studio 2005, I imagine there are people still using old versions of ICC.

I've managed to find a few older versions of the manual:

__assume_aligned appears in the version 9 manual.  Versions as far back as 9 also mention the warning pragma, but I can't find any more details in any version of the manual, and just saying that the "warning" pragma doesn't necessarily mean the push/pop stuff is supported.  Furthermore, I can't seem to find any mention of when the C99-style _Pragma preprocessing operator started being supported.

SergeyKostrov
Valued Contributor II
147 Views

Finally there is another team that tries to work on that problem... >>...I'm working on a project ("Hedley") to abstract away some differences between compilers... I've been working on the ScaLib for BDP project for 7 years and in 2009, when the project was started, an objective was defined in a different way: Since it won't be possible to integrate all C++ compilers let's try to create a Framework to abstract source codes (!) as much as possible and that task is achievable if only Very Common Subsets of Features of every C++ compiler is used in some source codes. In a different way I would say: Nobody ever considered to abstract C++ compiler differences in the way you're doing it, pragmas, for example. Honestly, after 7 years I'm confident that it is some kind of a waste of time because differences in C++ compilers always Existed, they Exist, and they will Exist! It means, that I did Not try to spend any time on abstraction of All these Warning Messages and I allowed them go As Is, concentrated all efforts on creating some Abstraction Layers ( ALs ) and there are six of them at the moment. These ALs take control of everything and considered as a Foundation when implementing some C or C++ functionality in some end-user software product. As of today 6 major brands of C++ compilers integrated ( MinGW, Microsoft, Intel, Borland, Turbo C++, Open Watcom ) and a firm No was finally sad to any attempts to integrate another C++ compiler(s). It doesn't make sense! This is because all modern C++ compilers support Very Common Subsets of Features of Turbo C++ v3.0 C++ compiler ( more than 25-year-old technology ) which is used on the ScaLib for BDP is a Primary Verificator that Nothing Is Broken. It means, if Turbo C++ v3.0 C++ compiler compiles some source codes than a modern C++ compiler must compile it as well. Period. Next, as an example, this is how __builtin_assume_aligned was abstracted in as simple as possible way ( I would say a classic one ): ... #if ( defined ( _WIN32_MSC ) ) ... #define __builtin_assume_aligned( p, a ) p ... #endif #if ( defined ( _WINCE_MSC ) ) ... #define __builtin_assume_aligned( p, a ) p ... #endif #if ( defined ( _WIN32_MGW ) ) ... #if _SCALIB_COMPILER_ID == ( _SCALIB_COMPILER_ID_BASE + 0342 ) #define __builtin_assume_aligned( p, a ) p #else // Supported By Default for all versions after v3.4.2 #endif ... #endif #if ( defined ( _WIN32_BCC ) ) ... #define __builtin_assume_aligned( p, a ) p ... #endif #if ( defined ( _COS16_TCC ) ) ... #define __builtin_assume_aligned( p, a ) p ... #endif #if ( defined ( _WIN32_ICC ) ) ... #define __builtin_assume_aligned( p, a ) p ... #endif #if ( defined ( _WIN32_WCC ) ) ... #define __builtin_assume_aligned( p, a ) p ... #endif ALs of the project are very carefully designed and from time to time some changes are needed. In December 2015, after integration of Open Watcom C++ compiler it was clear that two low level ALs need to be improved ( actually they were redesigned! ) and it created lots of spin-off problems. Try to integrate, if interested and if you really want to challenge yourself, Turbo C++ v3.0 C++ compiler .
SergeyKostrov
Valued Contributor II
147 Views

Finally there is another team that tries to work on that problem... >>...I'm working on a project ("Hedley") to abstract away some differences between compilers... I've been working on the ScaLib for BDP project for 7 years and in 2009, when the project was started, an objective was defined in a different way: Since it won't be possible to integrate all C++ compilers let's try to create a Framework to abstract source codes (!) as much as possible and that task is achievable if only Very Common Subsets of Features of every C++ compiler are used in some source codes. In a different way I would say: Nobody ever considered to abstract C++ compiler differences in the way you're doing it, pragmas, for example. Honestly, after 7 years I'm confident that it is some kind of a waste of time because differences in C++ compilers always Existed, they Exist, and they will Exist! It means, that I did Not try to spend any time on abstraction of All these Warning Messages and I allowed them to go As Is, concentrated all efforts on creating some Abstraction Layers ( ALs ) and there are six of them at the moment. These ALs take control of everything and considered as a Foundation when implementing some C or C++ functionality in some end-user software product. As of today 6 major brands of C++ compilers integrated ( MinGW, Microsoft, Intel, Borland, Turbo C++, Open Watcom ) and a firm No was finally sad to any attempts to integrate another C++ compiler(s). It doesn't make sense! This is because all modern C++ compilers support Very Common Subsets of Features of Turbo C++ v3.0 C++ compiler ( more than 25-year-old technology ) which is used on the ScaLib for BDP as a Primary Verificator that Nothing Is Broken. It means, if Turbo C++ v3.0 C++ compiler compiles some source codes than a modern C++ compiler must compile it as well. Period. Next, as an example, this is how __builtin_assume_aligned was abstracted in as simple as possible way ( I would say a classic one ): ... #if ( defined ( _WIN32_MSC ) ) ... #define __builtin_assume_aligned( p, a ) p ... #endif #if ( defined ( _WINCE_MSC ) ) ... #define __builtin_assume_aligned( p, a ) p ... #endif #if ( defined ( _WIN32_MGW ) ) ... #if _SCALIB_COMPILER_ID == ( _SCALIB_COMPILER_ID_BASE + 0342 ) #define __builtin_assume_aligned( p, a ) p #else // Supported By Default for all versions after v3.4.2 #endif ... #endif #if ( defined ( _WIN32_BCC ) ) ... #define __builtin_assume_aligned( p, a ) p ... #endif #if ( defined ( _COS16_TCC ) ) ... #define __builtin_assume_aligned( p, a ) p ... #endif #if ( defined ( _WIN32_ICC ) ) ... #define __builtin_assume_aligned( p, a ) p ... #endif #if ( defined ( _WIN32_WCC ) ) ... #define __builtin_assume_aligned( p, a ) p ... #endif ALs of the project are very carefully designed and from time to time some changes are needed. In December 2015, after integration of Open Watcom C++ compiler, it was clear that two low level ALs need to be improved ( actually they were redesigned! ) and it created lots of spin-off problems. Try to integrate, if interested and if you really want to challenge yourself, Turbo C++ v3.0 C++ compiler .
SergeyKostrov
Valued Contributor II
147 Views

Some developers are using ICC v4.x and looking for v4.5... >>...I know people who still use Visual Studio 2005, I imagine there are people still using old versions of ICC... Visual Studio 2005 is a Primary IDE on the ScaLib for BDP project and there is absolutely No plans to use any VSs after version 2012. As a follow up here is a list of all supported IDEs and C++ compilers: IDEs: Visual Studio 98 Professional Edition Visual Studio 2005 Professional Edition Visual Studio 2008 Professional Edition Visual Studio 2008 Express Edition Visual Studio 2010 Express Edition Visual Studio 2012 Express Edition C++ compilers: Turbo C++ compiler v3.0.0 16-bit Borland C++ compiler v5.5.1 32-bit MinGW C++ compiler v3.4.2 32-bit MinGW C++ compiler v4.8.1 32-bit MinGW C++ compiler v4.9.2 32-bit MinGW C++ compiler v4.9.2 64-bit MinGW C++ compiler v5.1.0 32-bit MinGW C++ compiler v5.1.0 64-bit MinGW C++ compiler v6.1.0 32-bit MinGW C++ compiler v6.1.0 64-bit Microsoft C++ compiler ( VS98 PE ) 32-bit Microsoft C++ compiler ( VS2005 PE ) 32-bit Microsoft C++ compiler ( VS2008 PE ) 32-bit Microsoft C++ compiler ( VS2008 PE ) 64-bit Microsoft C++ compiler ( VS2008 EE ) 32-bit Microsoft C++ compiler ( VS2010 EE ) 32-bit Microsoft C++ compiler ( VS2012 EE ) 32-bit Microsoft C++ compiler ( VS2012 EE ) 64-bit Intel C++ compiler v7.1.0 ( u029 ) 32-bit Intel C++ compiler v8.1.0 ( u038 ) 32-bit Intel C++ compiler v12.1.7 ( u371 ) 32-bit Intel C++ compiler v13.1.0 ( u149 ) 32-bit Intel C++ compiler v13.1.0 ( u149 ) 64-bit Watcom C++ compiler v1.9.0 32-bit Watcom C++ compiler v2.0.0 32-bit Watcom C++ compiler v2.0.0 64-bit All Non Microsoft / Intel C++ compilers are integrated manually with VSs using make- and bat- files. PS: Some teams have No interest in latest Macrosoft VSs because older versions lighter, faster and satisfy all development needs.
nemequ
New Contributor I
147 Views

Sergey Kostrov wrote:
Finally there is another team that tries to work on that problem...

Sorry to disappoint you, but I think we're working on different (though largely complementary) problems.  While you seem to be focused on creating a abstraction layer on top of a common subset of C++, Hedley is largely about creating a portable way to enable compiler-specific functionality when available.  To be clear, that doesn't mean making such functionality available in all compilers, it means enabling the functionality in compilers that support it and quietly ignoring it in compilers which don't.

Hedley has macros for things like telling the compiler/analyzer that a parameter must never be null and/or is a printf-style format string, that an array parameter has a known length, that a function returns a freshly-allocated block of memory or doesn't return, and that a condition is likely/unlikely to evaluate as true.  The vast majority of the macros are about telling the compiler something about your code so that it can provide better diagnostics when you (or someone using your API) gets something wrong, and/or make better decisions about how to optimize your code.

The abstraction layer part of all of this is that it doesn't force you to write a bunch of ifdefs; the ifdefs are in Hedley, not your code.  That means that something like (and I've simplified the logic a bit from what Hedley really does):

#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L
_Noreturn
#elif defined(__clang) && __has_attribute(noreturn)
__attribute__((__noreturn__))
#elif defined(__GNUC__) && (__GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 2))
__attribute__((__noreturn__))
#elif defined(_MSC_VER) && _MSC_VER >= 1310
__declspec(noreturn)
#endif

#if defined(__clang) && __has_attribute(nonnull)
__attribute__((__nonnull__(1,2)))
#elif defined(__GNUC__) && (__GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 3))
__attribute__((__nonnull__(1,2)))
#endif

#if (defined(__clang) && __has_attribute(format)) || (defined(__GNUC__) && (__GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)))
#if (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 4)) && defined(__MINGW32__)
#if !defined(__USE_MINGW_ANSI_STDIO)
__attribute__((__format__(ms_printf, 2, 3)))
#else
__attribute__((__format__(gnu_printf, 2, 3)))
#endif
#elif defined(__MINGW32__)
/* Nothing */
#else
__attribute__((__format__(printf, 2, 3)))
#endif
#endif
void print_fatal_error(FILE* fp, const char* fmt, ...);

can become

HEDLEY_NO_RETURN
HEDLEY_NON_NULL(1,2)
HEDLEY_PRINTF_FORMAT(2,3)
void print_fatal_error(FILE* fp, const char* fmt, ...);

You still get nice warnings and errors, as well as more optimized code, from compilers which support the relevant features, but for compilers which don't support the relevant features the preprocessor reduces it to

void print_fatal_error(FILE* fp, const char* fmt, ...);

And everything still works.  Sure, you don't get a nice warning if you pass a NULL file pointer or format string, a bad format string, or have code after a call to the function, but if you write correct code it will still work.  On the other hand, since Hedley's macros are actually readable (as opposed to the ifdef soup in the first snippet), even if a compiler doesn't support a feature at least you get what amounts to some human-readable documentation.  In other words, Hedley tries to let you take advantage of some modern compiler features (especially those related to diagnostics, static analysis, and optimization) without getting in the way of compilers which don't support that functionality.

Now, in all honesty you're not likely to see much code like the first snippet in the wild; people are just too lazy to do all that checking.  What's more likely (though still somewhat uncommon) is something like:

#if defined(__GNUC__)
__attribute__(noreturn)
__attribute__((__format__(printf, 2, 3)))
__attribute__((__nonnull__(1,2)))
#elif defined(_MSC_VER)
__declspec(noreturn)
#endif
void print_fatal_error(FILE* fp, const char* fmt, ...)

There are some obvious portability issues here, as well as a less obvious one.  The most obvious one is that GCC < 4.4 will fail since it doesn't support format string checking.  The less obvious one is what happens on current mingw, which is likely to choke on the format string since MS-style format strings are subtly incompatible with standard ones.  The version using Hedley is simpler for the programmer, but also more portable.

Unfortunately, the most common situation is probably just that people don't add any attributes or declspecs at all.  I'm always sad when I see this because the warning that modern compilers generate with those annotations are very good; they are genuinely helpful and catch very real bugs (especially when coupled with static analyzers like Coverity and run-time tools like UBsan).  My hope is that Hedley makes it easy enough to do the right thing that people will actually do it, and the end result will be less buggy software.

Sergey Kostrov wrote:
Nobody ever considered to abstract C++ compiler differences in the way you're doing it, pragmas,

That's not true.  What I'm doing with warning pragmas is pretty much the same thing as glib is doing.  That said, the vast majority of Hedley has nothing to do with pragmas… mostly it's ifdefs and attributes/declspecs.  Pragmas just so happen to be a common way for compilers to support disabling warnings.

Sergey Kostrov wrote:
for example. Honestly, after 7 years I'm confident that it is some kind of a waste of time because differences in
C++ compilers always Existed, they Exist, and they will Exist!

I agree that compiler differences exist and always will, but that doesn't make what I'm doing with Hedley a waste.  It seems like you're thinking about it from the perspective of wanting to make everything work on all compilers.  I have no interest in that… I simply want to be able to take advantage of compiler-specific features when I'm using a compiler which supports it without breaking other compilers.

Sergey Kostrov wrote:
As of today 6 major brands of C++ compilers integrated ( MinGW, Microsoft, Intel, Borland, Turbo C++, Open Watcom ) and
a firm No was finally sad to any attempts to integrate another C++ compiler(s). It doesn't make sense! This is
because all modern C++ compilers support Very Common Subsets of Features of Turbo C++ v3.0
C++ compiler ( more than 25-year-old technology ) which is used on the ScaLib for BDP as
a Primary Verificator that Nothing Is Broken.

It means, if Turbo C++ v3.0 C++ compiler compiles some source codes than a modern C++ compiler
must compile it as well. Period.

That's great, but I don't want to program in a 25 year old subset of what is available today.  I want to be able to declare variables in scopes smaller than a function (e.g., loops).  I want the compiler to warn me if I screw up a format string or forget to add NULL to the end of a list of variadic parameters.  I want to use variable length arrays, restricted pointers, conformant array parameters, fixed-length types, C11 atomics, and generic selections.

That said, Hedley doesn't require any of those things.  The only requirement (beyond C89) should be variadic macros, and that's only for the HEDLEY_NON_NULL macro.  If people want to use ancient compilers Hedley shouldn't stop them.  What it is supposed to do, however, is let them take advantage of more modern features on compilers/platforms which support it without sacrificing compatibility with those which don't.

Sergey Kostrov wrote:
Next, as an example, this is how __builtin_assume_aligned was abstracted in as simple as
possible way ( I would say a classic one ):
...
#if ( defined ( _WIN32_MSC ) )
...
#define __builtin_assume_aligned( p, a ) p
...
#endif
#if ( defined ( _WINCE_MSC ) )
...
#define __builtin_assume_aligned( p, a ) p
...
#endif
#if ( defined ( _WIN32_MGW ) )
...
#if _SCALIB_COMPILER_ID == ( _SCALIB_COMPILER_ID_BASE + 0342 )
#define __builtin_assume_aligned( p, a ) p
#else
// Supported By Default for all versions after v3.4.2
#endif
...
#endif
#if ( defined ( _WIN32_BCC ) )
...
#define __builtin_assume_aligned( p, a ) p
...
#endif
#if ( defined ( _COS16_TCC ) )
...
#define __builtin_assume_aligned( p, a ) p
...
#endif
#if ( defined ( _WIN32_ICC ) )
...
#define __builtin_assume_aligned( p, a ) p
...
#endif
#if ( defined ( _WIN32_WCC ) )
...
#define __builtin_assume_aligned( p, a ) p
...
#endif

Hedley's way would be a bit simpler:

#if defined(HEDLEY_ASSUME_ALIGNED)
#  undef HEDLEY_ASSUME_ALIGNED
#endif
#if HEDLEY_GCC_HAS_BUILTIN(__builtin_assume_aligned, 4, 7, 0)
#  define HEDLEY_ASSUME_ALIGNED(ptr, align) __builtin_assume_aligned(ptr, align)
#elif HEDLEY_INTEL_VERSION_CHECK(9,0,0)
#  define HEDLEY_ASSUME_ALIGNED(ptr, align) (__assume_aligned(ptr, align), ptr)
#elif HEDLEY_MSVC_VERSION_CHECK(13,10,0)
#  define HEDLEY_ASSUME_ALIGNED(ptr, align) (__assume(((ptr) % (align)) == 0), ptr)
#else
#  define HEDLEY_ASSUME_ALIGNED(ptr, align) ptr
#endif

I haven't finalized this yet since I'd like to avoid evaluating ptr twice; I need to figure out if __builtin_assume_aligned works if we ignore the return value…

Sergey Kostrov wrote:
Try to integrate, if interested and if you really want to challenge yourself, Turbo C++ v3.0 C++ compiler .

Does it support variadic macros?  If so, it should already work.  If not, I guess I could add a macro to disable features requiring variadic macros, but it would require ifdefs in user code to make it portable.

Sergey Kostrov wrote:
PS: Some teams have No interest in latest Macrosoft VSs because older versions lighter, faster and satisfy all development needs.

That's interesting.  For most of my projects (the low-level dependencies like Hedley are an exception) I don't care about VS < 2013.  They just don't support enough of C99 to make porting worth the effort.  VS 2013 finally comes close enough to supporting C99 to be useful.  I guess I'm one of those people whose development needs VS 2012 doesn't satisfy.

SergeyKostrov
Valued Contributor II
147 Views

>>...Sorry to disappoint you... No, you did not. >>...but I think we're working on different (though largely complementary) problems.... Yes, that's true after reading your latest post.
Reply