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 not work.
-Nathan
On Aug 30, 2016, at 09:23 AM, "r...@open-mpi.org" <r...@open-mpi.org> wrote:
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 required?
I’m asking because these changes are minor and okay, but going back thru the
code to revise all the comments and other C99isms would be a rather large task.
On Aug 30, 2016, at 7:06 AM, C Bergström <cbergst...@pathscale.com> wrote:
On Tue, Aug 30, 2016 at 9:20 PM, Jeff Squyres (jsquyres)
<jsquy...@cisco.com> wrote:
On Aug 29, 2016, at 11:42 PM, C Bergström <cbergst...@pathscale.com> 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.
Total bullshit - If any of my replies were "charged", passive
aggressive or otherwise that was not my intention. Anyone who I
thought has replied rudely, I have called out directly and I don't
mince words.
I'm not interested to spend 50 replies on 3 small patches. If you guys
don't care about platform X, Foo compiler or older standards I respect
that. My 1st email started with what I consider a humble tone. My
patches are public and I've given all the details I have time for.
Last try
I'd like to see:
1. The specific link error that we're talking about.
As posted before - the error is *exactly* the same as in the public
clang bug report.
(Thanks to Nathan)
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
2. All the information listed on https://www.open-mpi.org/community/help/ for
compile/build problems.
I'm not going to shift threw this wall of text to try to figure out
what you feel is missing. (Now my tone is "curt" if I have to be
clear)
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 are not
complete.
The patches against 1.x are complete. If you want to test and fix 2.x
branch or git master feel free to pull my patches when I push them to
our github.
You can verify the patches with clang and SLES10. In the near future
it's likely I'll even post prebuilt binaries of clang which could be
used for easier validation. There's also of course the nightly EKOPath
builds that are available.. etc etc
------------
In parting - I will test LDFLAGS|CFLAGS=“-fgnu89-inline” and if it
does indeed fix the issue without side effects I'll let you guys know.
_______________________________________________
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
