Re: [PATCH] PR 78534 Change character length from int to size_t
On 12/29/17 5:31 AM, Janne Blomqvist wrote: In order to handle large character lengths on (L)LP64 targets, switch the GFortran character length from an int to a size_t. This is an ABI change, as procedures with character arguments take hidden arguments with the character length. Did this change not make it into gcc 7 then? I am one of those who still use these hidden arguments for Fortran <-> C interfaces. Based on discussions a year ago, I added this to my code: #if defined(__GNUC__) && (__GNUC__ > 6) #include #define FORSTR_STDARG_TYPE size_t #else #define FORSTR_STDARG_TYPE int #endif I infer from this thread that I should change this to __GNUC__ > 7 now. Is this still the correct/best way to determine the hidden argument size? (note that we're still using 4.x... ugh, don't ask... so the >6 check hasn't actually been used yet, I just want to future-proof things as much as possible without having to rewrite the entire Fortran <-> C interface.) Thanks... -Bob Bob Deen @ NASA-JPL Multmission Image Processing Lab bob.d...@jpl.nasa.gov
Re: [PATCH] PR 78534 Change character length from int to size_t
On 1/3/18 11:43 AM, Janne Blomqvist wrote: On Wed, Jan 3, 2018 at 8:34 PM, Bob Deen wrote: On 12/29/17 5:31 AM, Janne Blomqvist wrote: In order to handle large character lengths on (L)LP64 targets, switch the GFortran character length from an int to a size_t. This is an ABI change, as procedures with character arguments take hidden arguments with the character length. Did this change not make it into gcc 7 then? No, it caused regressions on big endian targets, and it was so late in the gcc 7 cycle that there was no time to fix them (at the time I didn't have access to a big endian target to test on, and getting said access took time), so I had to revert it. Those regressions have now been fixed, and the ABI has been broken anyway due to other changes, so I'm trying again for gcc 8. Okay. If for some reason it doesn't make 8, it would be nice to know. I lurk here and try to pay attention but obviously I missed that it was pulled from 7. (which is why I'd prefer something specific to test rather than a version number, but it is what it is). Thanks... -Bob I am one of those who still use these hidden arguments for Fortran <-> C interfaces. Based on discussions a year ago, I added this to my code: #if defined(__GNUC__) && (__GNUC__ > 6) #include #define FORSTR_STDARG_TYPE size_t #else #define FORSTR_STDARG_TYPE int #endif I infer from this thread that I should change this to __GNUC__ > 7 now. Is this still the correct/best way to determine the hidden argument size? Yes, I would say so. (note that we're still using 4.x... ugh, don't ask... so the >6 check hasn't actually been used yet, I just want to future-proof things as much as possible without having to rewrite the entire Fortran <-> C interface.) Thanks... -Bob Bob Deen @ NASA-JPL Multmission Image Processing Lab bob.d...@jpl.nasa.gov
Re: [PATCH] PR 78534 Change character length from int to size_t
> However, this will also affect people doing C->Fortran calls the > old-fashioned way without ISO_C_BINDING, as they will have to change > the string length argument from int to size_t in their prototypes. > Then again, Intel Fortran did this some years ago so I guess at least > people who care about portability to several compilers are aware. We do a ton of this (old fashioned c-fortran binding) and changing the string length argument size will have a big impact on us. We don't use the Intel compiler so we never noticed a change there. Is there really a use case for strings > 2 GB that justifies the breakage? I certainly understand wanting to do it "right" but I'm probably not the only one with practical considerations that argue against it if there are no compelling use cases. Thanks... -Bob Bob Deen @ NASA-JPL Multimission Image Processing Lab bob.d...@jpl.nasa.gov
Re: [PATCH] PR 78534 Change character length from int to size_t
Hi all... I never saw any followup on this...? It's one thing to break the ABI between the compiler and the gfortran library; those can generally be expected to be in sync. It's another to break the ABI between two *languages*, when there might be no such expectation (especially if gcc does NOT break their ABI at the same version number transition). Yes, the pre-ISO_C_BINDING method may be old-fashioned, but it is a de-facto standard, and breaking it should not be done lightly. If you do proceed with changing the size, I would request that there at least be a facility to reliably tell at compile time (on the C side) which definition is being used, so I can adjust our macros accordingly. Our code does depend on the size, and it has to cross-platform (and now, if this change is made, cross-version), so with this change I would have to support both int and size_t. A C-side preprocessor symbol definition would do the trick. Of course that assumes the versions of gcc/g++ and gfortran are in sync, which is never guaranteed. But that assumption is better than nothing. Unless someone has a better idea...? Perhaps it might be best to wait until a time when gcc is also breaking their ABI, so that there's no question of code (on either side) working across the transition...? Thanks... -Bob P.S. I'm just a lurker here, but I lurk specifically to look for things that will break our code base, like this ;-) Bob.Deen @ NASA-JPL Multimission Image Processing Lab bob.d...@jpl.nasa.gov On 12/12/16 10:26 AM, Bob Deen wrote: However, this will also affect people doing C->Fortran calls the old-fashioned way without ISO_C_BINDING, as they will have to change the string length argument from int to size_t in their prototypes. Then again, Intel Fortran did this some years ago so I guess at least people who care about portability to several compilers are aware. We do a ton of this (old fashioned c-fortran binding) and changing the string length argument size will have a big impact on us. We don't use the Intel compiler so we never noticed a change there. Is there really a use case for strings > 2 GB that justifies the breakage? I certainly understand wanting to do it "right" but I'm probably not the only one with practical considerations that argue against it if there are no compelling use cases. Thanks... -Bob Bob Deen @ NASA-JPL Multimission Image Processing Lab bob.d...@jpl.nasa.gov
Re: [PATCH] PR 78534 Change character length from int to size_t
On 12/19/16 11:33 AM, Janne Blomqvist wrote: On Mon, Dec 19, 2016 at 6:43 PM, Bob Deen wrote: Hi all... I never saw any followup on this...? It's one thing to break the ABI between the compiler and the gfortran library; those can generally be expected to be in sync. It's another to break the ABI between two *languages*, when there might be no such expectation (especially if gcc does NOT break their ABI at the same version number transition). Yes, the pre-ISO_C_BINDING method may be old-fashioned, but it is a de-facto standard, and breaking it should not be done lightly. First: No, it's not done "lightly". And secondly, cross-language interfacing is always tricky, which is why most languages, including Fortran with ISO_C_BINDING, have devised standardized ways for communication with C so users don't need to rely on various cross-call mechanisms that are not guaranteed to work. Apologies if I offended (and to Steve too). I see all the deliberation you're doing for breaking the language->library ABI, and appreciate that. It's well-justified. My point, however, is that with this change you are breaking an entirely *different* ABI - that between Fortran and C - and the sum total of discussion was one message from Janne pointing out that it was breaking (thanks for that heads-up, I had missed it!), with no followup. Janne, you yourself in that message questioned the need for large strings, and had no use cases in response to FX's inquiry. Now that I think about it, it's not even an ABI change, it's an API change... requiring a code change, not just a recompile. So in this case, this change represents (AFAIK) the only breakage in the old-style Fortran<->C ABI/API, with no known use cases... and thus my question about whether it's justified. It's a fair question. I'm not arguing the language->library ABI at all. C changed to use size_t for string lengths instead of int with ANSI C in, what, 1989. With 2-socket servers, typically used e.g. in HPC clusters, today easily having hundreds of gigs of RAM, limiting GFortran char lengths to 2 GB for all eternity in the name of compatibility seems quaint at best. Maybe in your organization Fortran is legacy code that YE SHALL NOT TOUCH, but GFortran also has to cater to users who have chosen to write new code in Fortran. I understand that. It just seems that opening up an entirely *new* ABI/API for breakage deserved a little more discussion. Y'all are the ones doing the (mostly volunteer) work on gfortran, and I appreciate it. You're also much more invested in the future of the language than I (yeah, it's mostly legacy code for us). If you end up deciding that it needs to be done, then I'll deal with it. I just wanted to chime in that there are users who will be affected. If I'm the only one, I wouldn't want to stand in the way of progress - but also don't want to get steamrolled if it's not an important change, or if there are other affected users. So... ARE there any other affected users out there?? Oh, you have macros rather than hard-coded int all over the place? Shouldn't it be a relatively trivial affair then to define that macro appropriately depending on which compiler and which version you're using? I wouldn't call it trivial by any means... it's tricky code I haven't had to look at in 10 years. But in the end, probably doable. Steve showed how you can do it for Fortran. From the C side, just check the version from the __GNUC__ macro. I dislike having to check for version numbers (feels kludgy) but that's a personal preference. That will probably work, with a bit of futzing. Thanks for your attention... -Bob Bob Deen @ NASA-JPL Multimission Image Processing Lab bob.d...@jpl.nasa.gov
Re: [Patch, Fortran] PR 48174+45304: No varags if interface is known
Hi Tobias...
I've been a lurker here since I posted a problem with varargs (stdarg,
really) interfaces back on May 31, 2010 ("Variable argument call does
not work on 64-bit gfortran"). You were able to determine that my
problem existed on gfortran 4.1 but was fixed in all of 4.2 through 4.6,
although you weren't sure how it got fixed. We switched to 4.4 and
everything worked fine. I appreciate the help!!
This proposed patch is probably okay but makes me nervous. However, the
"related" issue scares me. Referring to my original email, we have a
large legacy f77 system with 15,000 calls to C stdarg functions.
Because the stdarg and non-stdarg ABI appears to be different for x86_64
platforms, these need to be called using the stdarg ABI.
So I hope you can understand why I might be nervous when something is
tweaked in this area!
Our code does not declare these routines to Fortran, therefore the
procedure interface is unknown and this patch "should" not bother
anything. But for the related issue... deducing the interface from
usage is likely to break things badly in my case (and doesn't sound very
robust in any case). Unless I'm misunderstanding the application of the
issue?
Would it be possible for you to try my test case again after this patch,
just to make sure? I can post it again if you like.
Thanks...
-Bob
Bob Deen @ NASA-JPL Multimission Image Processing Lab
bob.d...@jpl.nasa.gov
On 3/22/11 1:21 AM, Tobias Burnus wrote:
This patch makes sure that there is no vararg if the procedure interface
is known. Before, for functions and subroutines without arguments, no
void_list_node.
(Related, separate and unfixed issue: For procedures without explicit
interface, the interface should be deduced from the usage.)
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
Re: [patch, fortran] Fix PR 87689, wrong decls / ABI violation on POWER
On 2/18/19 12:48 AM, Janne Blomqvist wrote: On Sun, Feb 17, 2019 at 8:19 PM Thomas Koenig wrote: Hello world, the attached patch fixes a rather bad ABI violation on POWER systems. ... I agree, although we're close to the GCC-9 release, it's better to get this in now. So Ok. I wonder if we shouldn't exorcise all the varargs stuff, it seems to cause more problems than benefits? But not in stage4 if we can avoid it.. Please don't. Some of us still use varargs interfaces (in my case, Fortran calling C stdarg subroutines). Thanks... -Bob Deen @ NASA-JPL Multimission Image Processing Lab bob.d...@jpl.nasa.gov
Re: [patch, fortran] Fix PR 87689, wrong decls / ABI violation on POWER
On 2/19/19 2:44 PM, Thomas Koenig wrote: Bob, Some of us still use varargs interfaces (in my case, Fortran calling C stdarg subroutines). The problem for us is that that sometimes using varargs made standard- conforming Fortran code like, in file a.f subroutine foo(a) print *,a end and in file main.f programme main call foo(1.0) end depend ABI details: The call to foo used to be called using the varargs convention, and the subroutine foo was compiled as a non-varargs function. This "worked" until PR 87689 showed that this breaks standard-conforming Fortran code on a primary gcc platform. I don't know if that makes a difference for the platform you work on. For the System V AMD64 ABI, I suspect it actually might not matter (at least from glancing at the corresponding Wikipedia article), but I am _not_ an expert in this field, so please take this with a chunk of rock salt of appropriate size. So, we cannot really keep this as a feature (note that varargs are also not C interoperable). Okay. But I hope you don't let the perfect be the enemy of the good. That particular platform is not a concern for us, so if you break it there I'm not happy, but it's not the end of the world either. But please don't break it other places just because it doesn't work on that one platform. I know it's not good design practice to have that kind of platform-dependent behavior, but sometimes practicalities force less than ideal choices. Thanks... -Bob
