Adopt C11 as base language

[GoogleCodeExporter]

The C 2011 standard [ISO/IEC 9899:2011] was ratified in May 2011, and is 
available for purchase here:
http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=578
53

A near-identical draft is available freely here:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

The C99 standard has been officially deprecated by ISO, as stated in the 
forward:

"This third edition cancels and replaces the second edition, ISO/IEC 9899:1999"

Further, it is no longer even possible to purchase legitimate copies of the C99 
spec from ISO, they have been removed from their online store. This places UPC 
in the awkward position of specifying against a base language document that 
technically no longer exists.

I believe we need to move towards adopting C11 as the base language for UPC, 
ideally in 1.4. This thread is intended to start discussion about what's 
involved in making this happen for the spec and implementations.

As a starting point, here is the summary provided by ISO about major changes 
introduced in C11:

— conditional (optional) features (including some that were previously 
mandatory)
— support for multiple threads of execution including an improved memory 
sequencing model, atomic objects, and thread-local storage (<stdatomic.h> and 
<threads.h>)
— additional floating-point characteristic macros (<float.h>)
— querying and specifying alignment of objects (<stdalign.h>, <stdlib.h>)
— Unicode characters and strings (<uchar.h>) (originally specified in
ISO/IEC TR 19769:2004)
— type-generic expressions
— static assertions
— anonymous structures and unions
— no-return functions
— macros to create complex numbers (<complex.h>)
— support for opening files for exclusive access
— removed the gets function (<stdio.h>)
— added the aligned_alloc, at_quick_exit, and quick_exit functions
(<stdlib.h>)
— (conditional) support for bounds-checking interfaces (originally specified 
in ISO/IEC TR 24731−1:2007)
— (conditional) support for analyzability

Many of these new features are conditional (ie optional), therefore C11/UPC 
implementations can simply omit them and still remain compliant. Some we can 
simply recommend should omitted from all UPC implementations, specifically the 
new optional threading support, which doesn't play nicely with the PGAS model. 
It would be nice from a learning-curve standpoint if our new atomics library 
(issue 7) followed the general form of the C11 atomics, but those are also 
optional and thus can be safely ignored.

My review of the remaining C11 features introduced by that spec didn't uncover 
anything that seems fundamentally in conflict with anything specified by UPC. 
On the contrary, most of the features are purely convenience features added to 
the serial language and should be completely orthogonal to the UPC extensions. 
Many of them just provide standardized names for vendor-specific C99 compiler 
features that are already widely implemented (and by extension already 
available in many UPC implementations). In some cases C11 actually *weakens* 
the set of required features relative to C99, including some features that have 
limited support in current UPC implementations (notably <complex.h> and 
variable-length arrays). As a result it's possible some UPC implementations are 
actually closer to strict compliance with C11 than with C99.

Questions that I think need to be answered:
1. UPC vendors: are your compiler teams already working on developing C11 
compliant C compilers?
2. If so, would those C11 extensions automatically or easily be reflected in 
your UPC compiler offering, or is a parallel effort required to provide the C11 
features in your UPC compiler?
3. Which of the C11 required features (if any) would cause difficulty for UPC 
implementations?
3. What is the "right" upgrade path for upgrading UPC's base language document? 
Do we need to issue an "intermediate" spec that allows implementations to 
support either C99 or C11, or can we go straight to requiring C11 compliance in 
UPC 1.4?

Original issue reported on code.google.com by danbonachea on 14 Sep 2012 at 6:33

[GoogleCodeExporter]

Support for C11 atomics in compilers is quite new.  Do any vendor compilers 
support it yet?

Original comment by [email protected] on 14 Dec 2014 at 4:35

[GoogleCodeExporter]

Really not following why you would want to avoid addressing C11 threading by 
recommending that UPC implementations omit it.  People already use OpenMP, 
pthreads, etc within UPC threads for implementations where UPC threads are 
processes, but they are forced to do so without any guidance whatsoever from 
any spec as to how they interact.  It would be nice to solve that problem and 
not ignore it just because it is perhaps more inconvenient for thread-oriented 
implementations of UPC.  And yeah I know the spec doesn't say how UPC threads 
are implemented, but UPC thread vs C11 thread interaction will eventually be a 
practical issue for users because it already is for OpenMP.

Original comment by [email protected] on 14 Dec 2014 at 4:46

[GoogleCodeExporter]

I'm a huge fan of thread interoperability discussions because it's a huge 
problem, but I am curious for whom C11 threads are essential, given that they 
don't appear to do anything that Pthreads can't today.

Original comment by [email protected] on 14 Dec 2014 at 4:52

[GoogleCodeExporter]

Jeff -- no idea who uses C11 threads.  I was referring to use of OpenMP in UPC 
codes being an issue for users.

Original comment by [email protected] on 14 Dec 2014 at 2:34

[GoogleCodeExporter]

Re: "Support for C11 atomics in compilers is quite new.  Do any vendor 
compilers support it yet?"

This page summarizes GCC support for C11 in GCC 4.8 (Released May 31, 2013).  
It looks like C11 atomics are fully implemented.  GCC 4.8 is currently 
available on most Linux distributions.
https://gcc.gnu.org/gcc-4.8/cxx0x_status.html

Original comment by gary.funck on 14 Dec 2014 at 8:20

[GoogleCodeExporter]

Gary:

As far as I can tell, GCC 4.9 is the _only_ compiler that supports C11 atomics 
and only it and very recent clang even attempt to support the full set of 
required features (which does not include atomics or threads).

GCC had the first implementation and works as of 4.9 (on the other hand, 
threads.h is missing), per https://gcc.gnu.org/wiki/C11Status.  Your citation 
is for C++11, for which atomics support happened earlier.

Clang/LLVM claims to support it online but it does not work as of version 3.5 
(stdatomic.h is missing) on my laptop.

IBM claims to support C11 now 
(http://www.ibm.com/developerworks/rational/library/support-iso-c11/) but if 
it's anything like their "support" of other novel language features in C/C++, 
then it's not going to be functional (in the sense of correct code generation 
and non-erroneous termination of the compiler execution) for a while :-)

According to 
https://software.intel.com/en-us/articles/c11-support-in-intel-c-compiler, 
Intel supports almost none of C11 in the latest release.

As of version 8.3.4, Cray Compiler Environment says it doesn't support C11 via 
__STDC_VERSION__ and I am inclined to believe it.

The only reference to PGI support for C11 is in a press release 
(http://www.pgroup.com/about/news.htm) and it is indicated to be something for 
the future as part of OpenPOWER support.

At the rate things are going, I wouldn't be surprised if it's 2016 before C11 
is fully supported by multiple HPC vendors.

Original comment by [email protected] on 14 Dec 2014 at 10:16

[GoogleCodeExporter]

Jeff, nice summary.  I tend to agree with your timeframe.  There seems to be  
higher demand / interest in C++11 than C11 and therefore feel that widespread 
C11 support will lag behind. 

Original comment by [email protected] on 14 Dec 2014 at 10:25

[GoogleCodeExporter]

Maybe we should make C++11 the base language for UPC? :-)

(I am well-aware of UPC++ and Coarray C++, so no one should bother with a 
serious reply to this question.)

Original comment by [email protected] on 14 Dec 2014 at 10:37

[GoogleCodeExporter]

Jeff, thanks for the correction/clarification re: C11 atomic support in GCC.

Original comment by gary.funck on 14 Dec 2014 at 10:50