Re: [PATCH][stage1] Remove conditionals around free()
On Wed, Mar 1, 2023 at 11:31 PM Bernhard Reutner-Fischer via Fortran wrote: > > Hi! > > Mere cosmetics. > > - if (foo != NULL) > free (foo); > > With the caveat that coccinelle ruins replacement whitespace or i'm > uneducated enough to be unable to _not_ run the diff through > sed -e 's/^+\([[:space:]]*\)free(/+\1free (/' > at least. If anybody knows how to improve replacement whitespace, > i'd be interrested but didn't look nor ask. ISTM that leading > whitespace is somewhat ruined, too, so beware (8 spaces versus tab as > far as i have spot-checked). > > Would touch > gcc/ada/rtinit.c |3 +-- > intl/bindtextdom.c |3 +-- > intl/loadmsgcat.c|6 ++ > intl/localcharset.c |3 +-- > libbacktrace/xztest.c|9 +++-- > libbacktrace/zstdtest.c |9 +++-- > libbacktrace/ztest.c |9 +++-- > libgfortran/caf/single.c |6 ++ > libgfortran/io/async.c |6 ++ > libgfortran/io/format.c |3 +-- > libgfortran/io/transfer.c|6 ++ > libgfortran/io/unix.c|3 +-- > libgo/runtime/go-setenv.c|6 ++ > libgo/runtime/go-unsetenv.c |3 +-- > libgomp/target.c |3 +-- > libiberty/concat.c |3 +-- > zlib/contrib/minizip/unzip.c |2 +- > zlib/contrib/minizip/zip.c |2 +- > zlib/examples/enough.c |6 ++ > zlib/examples/gun.c |2 +- > zlib/examples/gzjoin.c |3 +-- > zlib/examples/gzlog.c|6 ++ > > coccinelle script and invocation inline. > Would need to be split for the respective maintainers and run through > mklog with subject changelog and should of course be compiled and > tested before that. > > Remarks: > 1) We should do this in if-conversion (?) on our own. >I suppose. Independently of -fdelete-null-pointer-checks > 2) Maybe not silently, but raise language awareness nowadays. >By now it's been a long time since this was first mandated. > 3) fallout from looking at something completely different > 4) i most likely will not remember to split it apart and send proper >patches, tested patches, in stage 1 to maintainers proper, so if >anyone feels like pursuing this, be my guest. I thought i'd just >mention it. > > cheers, Back in 2011 Jim Meyering applied a patch doing this, see https://gcc.gnu.org/legacy-ml/gcc-patches/2011-03/msg00403.html , and the gcc/README.Portability snippet added then which is still there. Per analysis done then, it seems SunOS 4 was the last system where free() of a NULL pointer didn't behave per the spec. Also in Jim's patch intl/ and zlib/ directories were not touched as those are imported from other upstreams. -- Janne Blomqvist
Re: Team Collaboration Considerations
On Sun, Dec 4, 2022 at 5:53 AM Jerry D via Fortran wrote: > 1. Slack has adopted some limitations on being able to go back and look > at older posts. Functionally it is quite good and integrates well > with github. > 2. I looked at Element and Fractal which use the Matrix protocols. > Very open source, not so mature yet. > 3. Mattermost looks pretty good and was easy to set up. The free > version is a bit better than Slacks. GCC C++ uses it. > > If we can get a concensus I would happy to get something set up . I am > leaning to Mattermost. The mobile phone app is easy and the web browser > works fine. > > I do think in the long run, doing this will help everyone greatly. > > Any thoughts from all? Hi, I haven't commented earlier as I haven't been active in GFortran development for a couple of years (new job, kids, etc. etc.). So don't take my opinions too seriously. But in general, yes, I do think IRC is showing its age in an increasingly multi-device and mobile world. From a Free Software perspective, adopting a closed platform like Slack is perhaps not ideal, if alternatives exist. And I believe the free (as in beer) version of Slack has some significant limitations compared to the licensed one. Matrix is perhaps the one with the most future potential, but maybe it's not really there yet. While I haven't used Mattermost myself, I've heard good things about it. And as long as it's not used as some sort of permanent record of things instead of the mailing list, I guess it's relatively easy to switch to another platform in the future. Just to be sure, this is some hosted version, and not something which Jerry must maintain himself on some server in a dusty corner? As for the perennial question of how to attract new contributors, yeah, it's hard. I'm happy to see that Harald has gotten off to a flying start, amazing! I also do note with some satisfaction that there's some good efforts to make modern Fortran attractive for developers, and not just something you use because the codebase you work on was started 4 decades ago. Gtk-Fortran was an early example of this which showed that modern Fortran could be useful outside the core numerics domain. I'm also thinking of the https://fortran-lang.org site and associated efforts like the 'stdlib', a more fleshed out 'standard' library (https://stdlib.fortran-lang.org/ ), and the package manager FPM (https://fpm.fortran-lang.org ). Keeping in touch with these people, and suggesting that people help that effort if they aren't comfortable with hacking on the compiler outright, could be a way of growing the open source Fortran programmer base, which could eventually grow into contributors to the compiler itself? In particular if they want to use some newfangled Fortran feature that doesn't work in GFortran; scratching your own itch is always a good motivator! -- Janne Blomqvist
Re: [PATCH 3/5] Fortran: Narrow return types [PR78798]
On Sun, Nov 13, 2022 at 1:47 AM Bernhard Reutner-Fischer via Fortran
wrote:
> --- a/gcc/fortran/arith.cc
> +++ b/gcc/fortran/arith.cc
> @@ -1135,7 +1135,7 @@ compare_complex (gfc_expr *op1, gfc_expr *op2)
> strings. We return -1 for a < b, 0 for a == b and 1 for a > b.
> We use the processor's default collating sequence. */
>
> -int
> +signed char
> gfc_compare_string (gfc_expr *a, gfc_expr *b)
> {
>size_t len, alen, blen, i;
> @@ -1162,7 +1162,7 @@ gfc_compare_string (gfc_expr *a, gfc_expr *b)
> }
Hmm, really? PR 78798 mentions changing int to bool, where
appropriate, which I think is uncontroversial, but this?
--
Janne Blomqvist
Re: Handling of large stack objects in GPU code generation -- maybe transform into heap allocation?
On Fri, Nov 11, 2022 at 4:13 PM Thomas Schwinge wrote: > For example, for Fortran code like: > > write (*,*) "Hello world" > > ..., 'gfortran' creates: > The issue: the stack object 'dt_parm.0' is a half-KiB in size (yes, > really! -- there's a lot of state in Fortran I/O apparently). > Any other clever ideas? There's a lot of potential options to set during Fortran I/O, but in the vast majority of cases only a few are used. So a better library interface would be to transfer only those options that are used, and then let the full set of options live in heap memory managed by libgfortran. Say some kind of simple byte-code format, with an 'opcode' saying which option it is, followed by the value. See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48419 for some rough ideas in this direction, although I'm not personally working on GFortran at this time so somebody else would have to pick it up. -- Janne Blomqvist
Re: is there a way to find out gfortran version and/or options from a given binary?
On Thu, Jun 2, 2022 at 10:33 PM Kay Diederichs wrote: > Am 02.06.22 um 21:06 schrieb Janne Blomqvist: > > As an alternative approach, make a command-line option (say, "-v") > > that prints the version number of the program, name of the author and > > other pertinent information, as well as the output of > > compiler_version() and compiler_options(), and then exits. That would > > ensure that those calls won't be optimized away. > > > > I was thinking of such a -v option as well, and it is a solution for > some situations, but not e.g. for a dynamically loadable library (see > https://cims.nyu.edu/~donev/Fortran/DLL/DLL.Forum.txt ) which is my > situation ( > https://strucbio.biologie.uni-konstanz.de/xdswiki/index.php/LIB ). I'd > like to be able to see later which compiler version and options were > used when compiling that library, because over the years of distributing > this code, compilers and options have been changing. For the library case, can't you make a function libraryname_print_version_info() or whatever you want to call it that does the same? Of course, if the user never calls that function, uses a static library, and everything is compiled with -ffunction-sections and linked with --gc-sections that will not work, but otherwise the string should still be there in the binary so you should be able to find it with the strings tool? > -g includes the source code, which is not always desired, and is not > possible here due to license issues - there was no concept of "open > source" as we have it today in the 80ies when this code was started. Hmm, maybe that's the case, I don't have a legal opinion to offer on this, sorry. > Also I think it makes the code slower. No, at least with GCC -g doesn't affect the code generation. It makes the binary bigger so it takes longer to copy around, and depending on how the debug info is spread out in the binary some of that might be unnecessarily mapped into memory when running, but I think you'd be very hard pressed to measure any difference in performance. -- Janne Blomqvist
Re: is there a way to find out gfortran version and/or options from a given binary?
On Wed, Jun 1, 2022 at 1:16 PM Kay Diederichs wrote: > If -g is used, the executable _always_ has version and option info Well, isn't that the answer to your question then? As an alternative approach, make a command-line option (say, "-v") that prints the version number of the program, name of the author and other pertinent information, as well as the output of compiler_version() and compiler_options(), and then exits. That would ensure that those calls won't be optimized away. -- Janne Blomqvist
