On Wed, Aug 31, 2016 at 1:49 AM, Paul Hargrove wrote:
> Responses inline, below.
>
>
> On Mon, Aug 29, 2016 at 8:42 PM, C Bergström
> wrote:
>>
>> On Tue, Aug 30, 2016 at 5:49 AM, Paul Hargrove wrote:
>> >
>> > On Mon, Aug 29, 2016 at 8:32 AM, C Bergström
>> > wrote:
>> > [...snip...]
>> >>
>>
On Wed, Aug 31, 2016 at 2:25 AM, Paul Hargrove wrote:
>
> On Tue, Aug 30, 2016 at 7:06 AM, C Bergström
> wrote:
>>
>>
>> >
>> > 3. More complete patches for fixing the issues. Specifically, the 3
>> > provided patches fix certain issues in some parts of the code base, but the
>> > same issues oc
Nathan,
Unless I have misunderstood both Chris and the Clang bug report, the
problematic functions are in glibc.
So, addition of the gnu_inline attribute would probably require either
modifying system headers or interposing ahead of them.
-Paul
On Tue, Aug 30, 2016 at 8:30 AM, Nathan Hjelm wrot
On Tue, Aug 30, 2016 at 7:06 AM, C Bergström
wrote:
>
> >
> > 3. More complete patches for fixing the issues. Specifically, the 3
> provided patches fix certain issues in some parts of the code base, but the
> same issues occur in other places in the code base. As such, the provided
> patches a
On Tue, Aug 30, 2016 at 7:06 AM, C Bergström
wrote:
> On Tue, Aug 30, 2016 at 9:20 PM, Jeff Squyres (jsquyres)
> wrote:
> > On Aug 29, 2016, at 11:42 PM, C Bergström
> wrote:
> >>
> >> Paul - Is this your typical post? I can't tell if you're trying to be
> >> rude or it's accidental.
> >
> > I
Responses inline, below.
On Mon, Aug 29, 2016 at 8:42 PM, C Bergström
wrote:
> On Tue, Aug 30, 2016 at 5:49 AM, Paul Hargrove wrote:
> >
> > On Mon, Aug 29, 2016 at 8:32 AM, C Bergström
> > wrote:
> > [...snip...]
> >>
> >> Based on the latest response - it seems that we'll just fork OMPI and
On Tue, Aug 30, 2016 at 11:30 PM, Nathan Hjelm wrote:
> The best way to put this is his compiler defaults to --std=gnu89. That gives
> him about 90% of what we require from C99 but has weirdness like __restrict.
> The real solution is the list of functions that are called out on link and
> spot fi
The best way to put this is his compiler defaults to --std=gnu89. That gives
him about 90% of what we require from C99 but has weirdness like __restrict.
The real solution is the list of functions that are called out on link and spot
fixing with the gnu_inline attribute if -fgnu89-inline does n
Chris
At the risk of being annoying, it would really help me if you could answer my
question: is Gilles correct in his feeling that we are looking at a scenario
where you can support 90% of C99 (e.g., C99-style comments, named structure
fields), and only the things modified in this PR are requi
On Tue, Aug 30, 2016 at 9:20 PM, Jeff Squyres (jsquyres)
wrote:
> On Aug 29, 2016, at 11:42 PM, C Bergström wrote:
>>
>> Paul - Is this your typical post? I can't tell if you're trying to be
>> rude or it's accidental.
>
> I believe that multiple people on this thread are reacting to the
> passi
On Aug 29, 2016, at 11:42 PM, C Bergström wrote:
>
> Paul - Is this your typical post? I can't tell if you're trying to be
> rude or it's accidental.
I believe that multiple people on this thread are reacting to the
passive-aggressive tones and negative connotations in charged replies. So
may
Chris
For me, this is the critical point:
> On Aug 29, 2016, at 9:50 PM, Gilles Gouaillardet wrote:
>
> iirc, we use C99 struct initialisers, so stricly speaking, i do not think
> Open MPI can be built with a pure C89 compiler when configure'd
>
> with the --disable-c99 option. i'd rather im
Christopher,
Building with gnu is a non-starter for us. If we ever encounter an
issue, we can't just point our users to something else as a proposed
fix. There's also technical reasons why this may not work beyond pure
C code. (Fortran and C++ both being special)
Fortran compilers from differ
On Tue, Aug 30, 2016 at 12:50 PM, Gilles Gouaillardet wrote:
> Folks,
>
>
> i am under the impression we are being mislead by the title of this thread.
>
> the patches that were initially submitted were enhanced and are available at
> https://github.com/open-mpi/ompi-release/pull/1345
>
>
> it bas
Folks,
i am under the impression we are being mislead by the title of this thread.
the patches that were initially submitted were enhanced and are
available at https://github.com/open-mpi/ompi-release/pull/1345
it basically does 3 things when the --disable-c99 option (yet an other
misleadi
There's a bunch of documentation on this and others could have googled
to find it. I didn't have the link handy since I was replying from a
mobile device. (I did offer to find the links in a previous email)
On Tue, Aug 30, 2016 at 11:52 AM, Nathan Hjelm wrote:
> Looking at the bug in google cache
Looking at the bug in google cache
(https://webcache.googleusercontent.com/search?q=cache:p2WZm7Vlt2gJ:https://llvm.org/bugs/show_bug.cgi%3Fid%3D5960+&cd=1&hl=en&ct=clnk&gl=us)
then isn’t the answer to just use -fgnu89-inline on this platform? Does that
not solve the linking issue? From what I c
On Tue, Aug 30, 2016 at 5:49 AM, Paul Hargrove wrote:
>
> On Mon, Aug 29, 2016 at 8:32 AM, C Bergström
> wrote:
> [...snip...]
>>
>> Based on the latest response - it seems that we'll just fork OMPI and
>> maintain those patches on top. I'll advise our customers not to use
>> OMPI and document wh
On Mon, Aug 29, 2016 at 8:32 AM, C Bergström
wrote:
[...snip...]
> Based on the latest response - it seems that we'll just fork OMPI and
> maintain those patches on top. I'll advise our customers not to use
> OMPI and document why.
>
> Thanks again
> __
Just to clarify: we primarily use c99 features in our plugins as a means of
directly specifying which functions are being implemented, and which are not.
In c89, this can only be done by maintaining positional alignment - c99 allows
us to do this using the function names. Thus, the c99 method is
On Aug 29, 2016, at 11:32 AM, C Bergström wrote:
>
> Based on the latest response - it seems that we'll just fork OMPI and
> maintain those patches on top. I'll advise our customers not to use
> OMPI and document why.
Chris: you didn't answer several of the specific, directed questions on this
btw, I never felt quite comfortable with the option named "--disable-c99"
would "--disable-c99-check" be a better fit ?
feel free to suggest ab ever better option name
Cheers,
Gilles
On Monday, August 29, 2016, Gilles Gouaillardet <
gilles.gouaillar...@gmail.com> wrote:
> Ralph,
>
> I added tha
On Mon, Aug 29, 2016 at 11:22 PM, Jeff Squyres (jsquyres)
wrote:
> On Aug 29, 2016, at 11:06 AM, C Bergström wrote:
>>
>> If the patches are performance impacting I would never burden
>> upstream, but I do hope that regardless you'll consider them. Based on
>> the patch for 1.x it seems cosmetic.
Just so people don’t spend a lot of time on this: as the release manager for
the 1.10 series, you are going to have to provide me with a great deal of
motivation to accept this proposed change. We ended C89 support way back in the
1.7 series, so reviving it here would really seem odd.
I haven’t
On Aug 29, 2016, at 11:06 AM, C Bergström wrote:
>
> If the patches are performance impacting I would never burden
> upstream, but I do hope that regardless you'll consider them. Based on
> the patch for 1.x it seems cosmetic. I'll take the most honest and
> unbiased look at the patches against 2
Keep in mind that just because you have the flag to enable or disable
a specific language standard, it doesn't mean the compiler (I assume
gcc) actually complies with that standard. Clang and now PathScale by
inheritance is more strict on this matter.
I don't know if SLES10 or any of the partner f
Ralph,
I added that option into this PR, since I thought it was safer (e.g. the
user has to explicitly use this option, and he hopefully knows what he is
doing) than simply not aborting if the compiler is not C99 capable.
Cheers,
Gilles
On Monday, August 29, 2016, r...@open-mpi.org wrote:
> I
I hadn’t realized we still have a --disable-c99 configure option - that sounds
bad as we can’t possibly build that way. We need to internally perform the
configure check, but we shouldn’t be exposing a configure option as that just
confuses people into thinking it really is an option.
> On Aug
FYI, C99 has been required since late 2012. Going through the commits there is
no way Open MPI could possibly compile with —std=c89 or —std=gnu99. Older
compilers require we add —std=c99 so we can not remove the configure check.
commit aebd1ea43237741bd29878604b742b14cc87d68b
Author: Nathan Hje
Thanks Brice !
On Monday, August 29, 2016, Brice Goglin wrote:
> s/June 2016/June 2006/ :)
>
> Anyway, it ended on July 31st based on https://www.suse.com/lifecycle/
>
> Brice
>
>
>
> Le 29/08/2016 16:03, Gilles Gouaillardet a écrit :
>
> According to wikipedia, SLES 10 was released on June 2016
s/June 2016/June 2006/ :)
Anyway, it ended on July 31st based on https://www.suse.com/lifecycle/
Brice
Le 29/08/2016 16:03, Gilles Gouaillardet a écrit :
> According to wikipedia, SLES 10 was released on June 2016, and is
> supported for 10 years.
> (SLES 12 is supported for 13 years, and I ho
According to wikipedia, SLES 10 was released on June 2016, and is supported
for 10 years.
(SLES 12 is supported for 13 years, and I honestly do not know whether SLES
10 support has been extended)
so SLES 10 might already been EOL
Cheers,
Gilles
On Monday, August 29, 2016, Jeff Squyres (jsquyres)
The patches for master/v2.x will be considerably larger (we have embraced at
least a few of the C99 constructs quite a bit).
When is the EOL for SLES 10?
Can you provide the doc links and an example of the link error that these
patches are fixing?
> On Aug 29, 2016, at 1:04 AM, C Bergström
On Mon, Aug 29, 2016 at 12:59 PM, Gilles Gouaillardet wrote:
> Christopher,
>
>
> i made PR #1345 https://github.com/open-mpi/ompi-release/pull/1345
>
> (there is no copyright in these files, let me know how i should credit
> pathscale (if you want that of course)
I'm not sure that there is anyth
r us up to svn trunk.
The patch is simple and non-performance impacting.
Original Message
From: Nathan Hjelm
Sent: Saturday, August 27, 2016 20:23
To: Open MPI Developers
Reply To: Open MPI Developers
Subject: Re: [OMPI devel] C89 support
Considering gcc more or less had full C99 support in 3
nd any real c99 compiler fails at link time.
>>
>> This effects all versions of clang or us up to svn trunk.
>>
>> The patch is simple and non-performance impacting.
>>
>> Original Message
>> From: Nathan Hjelm
>> Sent: Saturday, August 27, 2016 20:23
patch is simple and non-performance impacting.
>
> Original Message
> From: Nathan Hjelm
> Sent: Saturday, August 27, 2016 20:23
> To: Open MPI Developers
> Reply To: Open MPI Developers
> Subject: Re: [OMPI devel] C89 support
>
> Considering gcc more or less had full C99 supp
t; From: Nathan Hjelm
> Sent: Saturday, August 27, 2016 20:23
> To: Open MPI Developers
> Reply To: Open MPI Developers
> Subject: Re: [OMPI devel] C89 support
>
> Considering gcc more or less had full C99 support in 3.1 (2002) and SLES10
> dates back to 2004 I find this surpr
link time.
This effects all versions of clang or us up to svn trunk.
The patch is simple and non-performance impacting.
Original Message
From: Nathan Hjelm
Sent: Saturday, August 27, 2016 20:23
To: Open MPI Developers
Reply To: Open MPI Developers
Subject: Re: [OMPI devel] C89 support
Consi
out of curiosity, does Open MPI fails in configure (because it does not
detect a valid C99 compiler) ?
or does it fail in make (because some C99 syntax is not supported, and that
was not detected at configure time) ?
Cheers,
Gilles
On Saturday, August 27, 2016, C Bergström wrote:
> I realize a
Considering gcc more or less had full C99 support in 3.1 (2002) and SLES10
dates back to 2004 I find this surprising. Clangs goal from the beginning was
full C99 support. Checking back it looks like llvm 1.0 (2003) had C99 support.
What version of clang/llvm are you using?
-Nathan
> On Aug 27,
On Aug 27, 2016, at 8:38 AM, C Bergström wrote:
>
> I realize a number of changes have been made to make the codebase C99.
> As I'm setting up more testing platforms, I found that this caused
> Clang (and us) to be broken on SLES10. While I realize that platform
> is quite *old*, it is still used
42 matches
Mail list logo
