Re: [atlas-devel] anybody know of need for C89 compliance?

[Jeff H. <jef...@gm...>]

On Sat, Jan 14, 2017 at 1:11 PM, Andrew Reilly <ar...@bi...>
wrote:
>
> Hi Clint,
>
> The two compilers with least support for c99 features that I'm aware of
are MSVC and TI CodeComposer.  Both have most of the support for C99
library features, but both (being primarily C++ compilers) don't have good
support for the C99 language features that aren't in C++.
>
> So: you'll find // comments everywhere.
> You'll need a macro to define inline _inline on some systems.

+1 to ATLAS_INLINE macro.

>
> You'll need a macro to define ATLAS_RESTRICT _restrict on at least MSVC.
Alas you can't actually use or redefine the keyword "restrict", because
that is already a magic keyword used in the Windows header files, and some
other Windows magic compilation directives.

+1 to ATLAS_RESTRICT macro.

> I'm fairly sure that modern versions of MSVC support long long int and
%llu, although you might have to spell the former as __int64 on some
versions.

Fixed-width integer types are part of C++11 (
http://en.cppreference.com/w/cpp/types/integer) so I would expect that MSVC
supports them, but I have made no attempts to verify this.

>
> You will need a macro to define snprintf to _snprintf on MSVC, and you'll
need to define _CRT_SECURE_NO_WARNINGS before including any of the standard
headers to turn off the deprecation warnings.
>
> I haven't tried to use _Complex or _Thread_local myself.  I have a memory
of _Atomic being supported in many places though.  I expect that the others
are too.
>

*_Complex* - This is a C99 feature and I don't know of a compiler that
doesn't support it.  However, just to be safe, you should typedef
atlas_complex_{float,double} and follow e.g.
https://stackoverflow.com/questions/1063406/c99-complex-support-with-visual-studio
if C99 support isn't available.

I can't remember what ISO C and Fortran say about the interoperability of
their respective complex types but I doubt it is an issue in practice.
Clint probably knows what works (and doesn't) already anyways.

*_Atomic* - This is a C11 feature and it is a bad one.  It is also
completely optional (see __STDC_NO_ATOMICS__).  You should use the explicit
types like atomic_int rather than "_Atomic int" and the explicit API (e.g.
atomic_load) rather than relying on operator overloading (ding ding ding -
this is why _Atomic is evil and totally un-C-like).

The Intel compiler supports the explicit C11 atomics API but not _Atomic
and it correctly reports the lack of complete support for C11 atomics via
__STDC_NO_ATOMICS__, so you have to explicitly test for the explicit API or
query the compiler version macro.
https://github.com/jeffhammond/HPCInfo/blob/master/atomics/ping-pong/c11-ping-pong.c
demonstrates the latter (it also notes a show-stopper GCC bug if you use
mix with OpenMP).

GCC and Clang support both C11 atomics APIs.  I have not tested Cray C11
support exhaustively, but they have at least the explicit API.

*_Thread_local* - This is a C11 feature and it is also strictly option (see
__STDC_NO_THREADS__).

I recommend you have a macro ATLAS_THREAD_LOCAL for the C11 _Thread_local,
GCC __thread, MSVC __declspec(thread), and any other implementation-defined
equivalents.

One must be careful when mixing TLS (thread-local storage) specifiers with
different threading models.  I don't think one can guarentee that the TLS
attribute associated with C11, GCC and OpenMP are *guaranteed* to work
across C11, POSIX and OpenMP threads.

Best,

Jeff

>
> Cheers,
>
> Andrew Reilly
> M: 0409-824-272
> ar...@bi...
>
>
>
> > On 15 Jan 2017, at 04:35 , R. Clint Whaley <rcw...@ls...> wrote:
> >
> > Guys,
> >
> > In the developer release, I am considering relaxing ATLAS's present
> > strict adherence to ANSI/ISO 9899-1990 standard, so that I can assume
> > stuff from C99.  Frankly, the lack // is slowly killing me.
> >
> > Right now, any C99 features are enabled only by macros that can be shut
> > off.
> >
> > There is little benefit aside from  aesthetics to this (though safe
> > string ops would be *so* nice), so I don't want to do it if anybody
> > reports using a compiler that doesn't support these features, but I'm
> > thinking that while their might still be some compilers w/o full C99
> > support, they'll all have the features I most want to add.
> >
> > Here's the list of things I'd definitely like to assume support for that
> > I think all compilers support (even likely obscure ones on embedded
> > systems):
> >    // style comments
> >    inline
> >    restrict
> >    long long int, %llu
> >    Safe string operations, like snprintf (this lack is painful)
> >
> > In addition there are more advanced features that might be useful, but
> > I'm not sure if I can count on them being universally available:
> >    _Complex support
> >    _Atomic
> >    _Thread_local
> >
> > Does anyone have comments on this idea?
> >
> > Thanks,
> > Clint
> >
> > --
> > **********************************************************************
> > ** R. Clint Whaley, PhD * Assoc Prof, LSU * www.csc.lsu.edu/~whaley **
> > **********************************************************************
> >
> >
------------------------------------------------------------------------------
> > Developer Access Program for Intel Xeon Phi Processors
> > Access to Intel Xeon Phi processor-based developer platforms.
> > With one year of Intel Parallel Studio XE.
> > Training and support from Colfax.
> > Order your platform today. http://sdm.link/xeonphi
> > _______________________________________________
> > Math-atlas-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/math-atlas-devel
>
>
>
------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Math-atlas-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/math-atlas-devel




--
Jeff Hammond
jef...@gm...
http://jeffhammond.github.io/