Re: [Python-Dev] C99

2016-10-06 Thread Nathaniel Smith 
On Thu, Oct 6, 2016 at 10:10 PM, Nathaniel Smith  wrote:
[...]
> And in practice this almost certainly doesn't matter -- the only
> reason people jump through hoops to get gcc 4.8 is for its improved
> C++ support. I just tried my c99 test file on CentOS 5's default gcc
> 4.1 and it was fine. And since RHEL 5 is going EOL in March 2017, for
> 3.6 purposes we only care about RHEL 6+, which ships with gcc 4.4,
> which is even less of a worry.
>
> tl;dr: for purposes of 3.6 on linux, "CPython has to build on gcc 4.4"
> should be a fine rule that works for everyone. But I guess we probably
> also want a CentOS 5+gcc 4.1 buildbot for testing 3.5 point releases.

Doh, I have an off-by-one error, and wrote 3.5/3.6 where I meant 3.6/3.7.

If the change is on the table for 3.6, then I guess I'd suggest
continuing to support gcc 4.1 through the 3.6 support lifecycle, since
I believe CentOS/RHEL 5 are considered supported platforms for 3.6,
and the burden of doing this is probably very small. In particular, it
doesn't seem to block any C99 features that we care about.

(Is the list of supported platforms for Linux documented anywhere? PEP
11 documents the rule for Windows, and I'm assuming that the same rule
applies to RHEL.)

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] C99

2016-10-06 Thread Nathaniel Smith 
On Fri, Aug 5, 2016 at 8:02 PM, Nick Coghlan  wrote:
> On 6 August 2016 at 12:15, Steve Dower  wrote:
>> FYI, it's MSVC 14.0 (which is included in VS 2015).
>>
>> Personally I'd like to see it restricted to the common subset of C99 and
>> some version of C++ (which is obviously mostly C and includes no C++),
>> because I know there are a few things in C99 only that are very obscure
>> because they aren't also in C++.
>
> As a pragmatic requirement, what if we went with:
>
> - must compile with the Python 3.5 Windows compiler (so MSVC 14.0)
> - must compile with the Python 3.5 Mac OS X compiler (some version of clang?)
> - must compile with the manylinux1 gcc compiler (gcc 4.8.2, as per PEP 513)
>
> The reason I like the pragmatic definition is that it's one we can
> readily automate by ensuring these 3 configurations are always present
> in the stable buildbot fleet, while the formal standards based version
> is technically more precise, but not in a way we can easily test.

This approach makes a lot of sense to me. In particular it seems like
it can avoid getting bogged down in a lot of questions about the
theoretical idea of C99, which is often somewhat unclear.

I wrote a little test file for all the C99 features that were
mentioned in this thread (I think):
  https://gist.github.com/njsmith/f71de31f35644bb91a815c9cad75

Ned reports that our OS X compiler is currently GCC 4.2, and that this
doesn't officially support "C99" -- but I just checked and it happily
builds that file :-). (Judging from [1], it looks like the major
feature missing in 4.2 was support for C99's more obscure inlining
semantics; but I think we only really care about 'static inline'
specifically, and that appears to be unchanged [2].)

> Phrasing the policy that way would mean moving future iterations of
> the manylinux spec out of distutils-sig only territory into one which
> needs to be reviewed by both distutils-sig and python-dev (since it
> would now also modify CPython's compiler compatibility requirements in
> PEP 7), but I think that's a reasonable position to adopt, and
> unlikely to cause any major problems (manylinux is a *trailing* edge
> definition that is only likely to get updated as the oldest enterprise
> Linux definitions drop out of commercial support)

With my manylinux maintainer hat on, I don't think there'd be any
problem with bringing python-dev into those discussions.

But note that technically, the manylinux1 spec doesn't say what
compiler you can use; it says that whatever compiler you use has to
generate binaries that work on CentOS 5. (Why CentOS 5? Because it's
the oldest non-EOL linux distribution in common use; manylinux2 will
presumably bump the requirement to CentOS 6 once CentOS 5 goes EOL).

The reason this matters is that the official vendor compiler on RHEL 5
is gcc 4.1, but there's also a separately-distributed version of gcc
4.8.2 that can target it. If a packager trying to build manylinux
wheels wants a more modern gcc, then it's reasonable to ask them to
get this patched gcc. But for an end-user who's just trying to build
CPython on their machine, you might or might not consider this an
acceptable request -- maybe CPython wants to work on default vendor
compiler to imposing that on users.

And in practice this almost certainly doesn't matter -- the only
reason people jump through hoops to get gcc 4.8 is for its improved
C++ support. I just tried my c99 test file on CentOS 5's default gcc
4.1 and it was fine. And since RHEL 5 is going EOL in March 2017, for
3.6 purposes we only care about RHEL 6+, which ships with gcc 4.4,
which is even less of a worry.

tl;dr: for purposes of 3.6 on linux, "CPython has to build on gcc 4.4"
should be a fine rule that works for everyone. But I guess we probably
also want a CentOS 5+gcc 4.1 buildbot for testing 3.5 point releases.

-n

[1] https://gcc.gnu.org/c99status.html
[2] "The [different versions] of inlining behave similarly ... when
the inline keyword is used on a static function" --
https://gcc.gnu.org/onlinedocs/gcc/Inline.html

-- 
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] C99

2016-10-06 Thread Michael Felt 



On 04-Jun-16 10:12, Sebastian Krause wrote:

Sounds good for features that are well-supported by compilers that
>people use. (Are there other compilers used than just GCC and MSVC?)
Just thought I'd mention that "little ole me" is using IBM vac on AIX 
rather than gcc.
This has more to do with maintaining the gcc rte requirements of 
anything built by gcc rather compiler features.


There is one gcc compiler feature that has proved a show-stopper - 
constructor - in glibc (Gnome). There they also make an exception for 
Windows, but not for "other" compilers.


FYI: calling the IBM C compiler as c99 magically makes it c99 compliant, 
as xlc makes it c99 plus several extensions - and take note - as cc it 
is "pre-c89". In other words, calling IBM compiler as "cc" is not a wise 
thing to do - I recommend to anyone listing to use either "xlc" or "xlc_r".


Michael
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com