Hi Harald,
The patch looks OK to me. Probably wait a bit for another opinion, since I’m
not that active and I may have missed something.
Thanks,
FX
Hi,
> this patch extends the previous version by adding further code testing
> the presence of an optional deferred-length character argument also
> in the function initialization code. This allows to re-enable a
> commented-out test in v2.
Nice, that sounds logical.
> Regtested on x86_64-pc-li
Hi Paul,
Thanks for doing that, it is tedious but very useful work for users and
developers.
How does the Reid list compare to Chivers & Sleightholme?
Also, because Chivers & Sleightholme have several versions of their list, am I
correct in understanding your reference is
https://dl.acm.org/do
Hi Harald,
> here's another fix for the CONTIGUOUS attribute: NULL() should
> derive its characteristics from its MOLD argument; otherwise it is
> "determined by the entity with which the reference is associated".
> (F2018:16.9.144).
Looking good to me, but leave 48 hours for someone else to obje
When gfortran invokes the linker, it reads the linking spec from libgfortran.
This ends up doing things like:
-lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
where you can see that libgcc (both -lgcc and -lgcc_s) is linked in twice. This
wasn’t a problem, until the new macOS linker, which gives a warning f
Hi Harald,
> If we do not want to break the existing ABI, so that we can
> link gfortran-13 and gfortran-14+(?) compiled code, we need
> to keep _gfortran_get_command_i4 & friends, and introduce
> new library functions that are able to handle the new
> requirements.
I have been thinking about the
Hi,
> I am getting side notes about people having these issues with gfortran 13. Is
> this something that should be backported.
I have already backported it in the latest Homebrew package (because we have
many users complaining about it). I intend to backport but will wait for a
conservative a
> Likely GFC_INTEGER_8 or int64_t or compatible. We have 32/64bit and
> -fdefault-integer-8 to deal with…
That’s why I am suggesting either “int” or “size_t”, i.e., a well-defined C
type. Means we don’t have to deal with -fdefault-integer.
FX
Hi Harald,
OK to push, thanks for picking it up!
FX
Hi Steve,
Thanks for the patch. I’ll take time to do a proper review, but after a first
read I had the following questions:
- "an OS's libm may/will contain cospi(), etc.”: do those functions conform to
any standard? Are there plans to implement them outside FreeBSD at this point?
- On systems
Hi,
> Hopefully, FX sees this as my emails to gmail bounce.
I am seeing this email.
> Now, if
> the OS adds cospi() to libm and it's in libm's symbol map, then the
> cospi() used by gfortran depends on the search order of the loaded
> libraries.
We only include the fallback math functions in l
>> print *, -128_int8
>
> This is a unary minus operator with an operand of 128.
> gfortran does not have negative integers.
To be clear, it’s not gfortran, it’s the standard(s). It’s not exactly true
either, because there is a "signed-int-literal-constant” which is allowed in
some contexts:
> Interesting example.
>
> % gfcx -o z a.f90 && ./z
> -128
> % gfcx -o z -pedantic a.f90 && ./z
> a.f90:5:20:
>
>5 | data j /-128_int8/
> |1
> Error: Integer too big for its kind at (1). This check can be disabled with
> the option ‘-fno-range-check’
That qualifi
> Tested on i686, x86_64, aarch64 Darwin, x86_64, aarch64 Linux,
> OK for trunk?
Looks good to me. Please leave 48h before pushing for other Fortran maintainers
to comment if they see something I missed (in particular the coarrays part).
FX
> Regression tested on x86_64 and new test case.
> OK for trunk?
OK, and thanks!
FX
> OK for trunk?
> I think simple enough to backport to 13 as well.
OK, but probably best to wait a few weeks before backporting.
FX
> OK for trunk and later backport to 13?
OK. Thanks for the patch!
FX
Skipping is the right thing to do at this point.
OK to push from the Fortran part.
FX
Hi,
These two (independent) patches add two tiny Fortran 2023 features: new
ISO_FORTRAN_ENV named constants and SELECTED_LOGICAL_KIND intrinsic.
Bootstrapped and regtested on x86_64-pc-linux-gnu.
Please review, and let me know if it’s okay to push once we’re back in stage 1.
(I know it’s not par
Hi Harald,
Thanks for the patch.
> + if (attr.function)
> +{
> + gfc_error ("FPTR at %L to C_F_POINTER is a function returning a
> pointer",
> + &fptr->where);
> + return false;
> +}
> +
>if (fptr->rank > 0 && !is_c_interoperable (fptr, &msg, false, true))
> return g
> Gentle ping. If this looks good, can someone commit to main (I don't have
> commit privileges). This is also something that could be considered for
> stable, since it's been around for many years.
Thanks for the patch. Pushed as
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3bd3ca05b519b99b5e
Hi Harald,
> Regtested on x86_64-pc-linux-gnu. OK for mainline?
Looks good to me.
FX
> I regenerate auto* files from time to time for libgfortran. Regenerating
> them has always been very fragile (using --enable-maintainer-mode),
> and difficult to get right.
I have never found them difficult to regenerate, but if you have only a non
maintainer build, it is a pain to have to make
> libgfortran/ChangeLog:
> * Makefile.am: Use sub-dirs, amend recipies accordingly.
> * Makefile.in: Regenerate.
Thanks Iain, I’ve tested it both with and without maintainer mode, and
regenerated files with no issue. I can also confirm that the many autoreconf
warnings that plagued libgfortran a
Hi Rainer,
> This patch fixes this by allowing for the new structure.
> Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11.
>
> Ok for trunk?
OK to push, given it’s localised inside LIBGFOR_USE_SYMVER_SUN.
I find it weird though that .libs is harcoded there. If we look at all the
lib*/Mak
> libgfortran/ChangeLog:
> * config/t-aix (all-local, libcaf_single): Explicitly reference
> caf/.libs/single.o
OK, and sorry for the breakage.
FX
Hi Tobias,
> That is for https://gcc.gnu.org/PR115150 – a GCC 12/13/14/15 regression,
> caused when switching from a libgomp call to inline code and missing the
> corner case of zero-size arrays …
OK to push, thanks.
FX
Hi Tobias,
> OK for mainline?
Seems reasonable, OK to push in 48 hours unless someone has suggestions related
to wording.
FX
Seems good, thanks Tobias!
FX
> I am interested in your company's Fortran Compiler.
> Is it free? If not, how much for a permanent license?
gfortran is free, part of GCC which is open source software. It is provided on
your system:
- for Windows see there: https://gcc.gnu.org/wiki/GFortranBinaries
- for macOS, as part of
Hi,
> Furthermore, the test is supposed to use IEEE arithmetic module
No, the test does not use the IEEE arithmetic module.
FX
Hi,
The core of the powerpc-FPU manipulation is okay for me. Some comments below.
> --- a/gcc/testsuite/gfortran.dg/ieee/signaling_2_c.c
> +++ b/gcc/testsuite/gfortran.dg/ieee/signaling_2_c.c
> @@ -1,3 +1,11 @@
> +#ifdef __POWERPC__ // No support for issignaling in math.h on Darwin PPC
Two thin
Pushed after testing on x86_64-unknown-linux-gnu.
The macro may not be present in all libc's, but the built-in is always
available.
See https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656409.html for context.
gcc/testsuite/ChangeLog:
* gfortran.dg/ieee/signaling_2.f90: Adjust test.
> This part of the patch is quite old, but from the remaining log it looks I
> got an error here:
> Now on a second thought, this did not require a fix perhaps. We can drop it.
I have addressed this:
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656484.html
The test should now be run on al
Can you post an updated version of the patch, following the first round of
review?
FX
Hi,
> I dropped a change to the test file, since you have fixed it appropriately,
> and switched to Apple libm convention for flags, as you have suggested.
> Please let me know if I should do anything further to improve it and make it
> acceptable for a merge.
The patch itself is OK. Please add
> Thank you for responding.
> I have added a changelog (is this a correct way?).
Content seems ok, lines are maybe too long. Check with
contrib/gcc-changelog/git_check_commit.py before pushing.
Once that is fine, OK to push.
FX
Thanks Sergey,
I have pushed the patch at
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1cfe4a4d0d4447b364815d5e5c889deb2e533669
FX
Hi,
>> As UNSIGNED has been booted off the F202Y list, I think calling it
>> an extension at this time is fair.
>
> Looks good to me. And yes, calling it an extension is fair.
I apologise, I had missed this piece of information. If UNSIGNED is not on
track to becoming a feature in the next sta
Hi,
> My Fortran project is based on -std=f2008. The GNU Fortran (For GCC version
> 15.0.0) manual’s 8.260 STAT example does not link if -std=f2008 is on the
> command line: gfortran -std=f2008 test_stat.f90; ./a.out
> The ld error is “undefined reference to `stat_’”
Our doc (https://gcc.gnu.o
Hi Thomas,
Thanks for the clarification. I really hope that it makes it into the standard,
I do not disagree that it is useful, I just really wish we don’t have to
maintain long-term a lot of nonstandard (or worse, standard-incompatible)
extensions. -std=legacy took a lot of ugly work over the
> So, I think we could ignore signed zeros (from the Fortran standard
> perspective)
>
> - for complex arithmetic, always
> - for real arithmetic, if none of the IEEE modules is USEd
That seems like a very backward-incompatible change to introduce :(
I might break a lot of existing codes.
FX
Hi Steve,
I think it’d be simpler not to create a front-end expression for the
c_null_char. Unless I’m mistaken, you only need it as an argument to pass to
build_call_expr_loc (input_location, gfor_fndecl_concat_string, …). You can
pass a pointer to the constant character, and the length is one
Hi Steve,
> I've an almost complete implementation of F_C_STRING,
> but need a bit of insight on the inlining that I'm
> trying to implement.
Maybe I can help. Can you send in your current patch?
FX
Hi Jerry,
This looks okay to me, but maybe leave 48 hours for others to comment?
Best,
FX
Hi,
The error message was fixed by Harald in:
commit fb132276d173907d575ea61fda3b846a9bc6e456
Author: Harald Anlauf
Date: 2025-03-28 20:31:08 +0100
Fortran: fix spelling of flag -fallow-invalid-boz
gcc/fortran/ChangeLog:
* check.cc (gfc_invalid_boz): Correct spel
Hi,
> I cannot see if there is proper support for kind=17 in your patch;
> at least the libgfortran/ieee/ieee_arithmetic.F90 part does not
> seem to have any related code.
Can real(kind=17) ever be an IEEE mode? If so, something seriously wrong
happened, because the IEEE modules have no kind=17
Hi,
This is a repost of the patch at
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600887.html
which never really got green light, but I stopped pushing because stage 1 was
closing and I was out of time.
It depends on a middle-end patch adding a type-generic __builtin_iseqsig(),
whi
Hi Steve,
I am not subscribed to the list (too little time, sadly), please keep me in CC
of your responses.
> 1. You added fmin, fmax, and friends. Are these used
>internally by gfortran in support of the IEEE_*
>functions or are these exposed to the user?
The math builtins are added
> Having a POWER system isn't enough, it also needs the IBM "advance
> toolchain", and (at least with current distros, which default to
> ibm long double), you need to dance counterclockwise three
> times... I mean you need to invoke configure with some special magic
Thanks for the frank descripti
Hi Harald,
> I just looked at that thread. I guess if you answer Mikael's
> questions at
> https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601744.html
> the patch will be fine.
Amended patch, adding the required testing of signalling vs. quiet behaviour.
I still need to get an OK on th
Hi Thomas,
> The KIND=17 is a bit of a kludge. It is not visible for
> user programs, they use KIND=16, but this is then translated
> to library calls as if it was KIND=17 if the IEEE 128-bit floats
> are selected
Can you check what the IEEE test results are when -mabi=ieeelongdouble is
enabled
Given the agreement that the patch is not making things for powerpc worse, and
the review by Steve, I have committed as
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=17bccd1d2c0fa1f08e0483c8ed841994a95febb0
Best,
FX
Hi,
I was looking at our table for Fortran 2008 conformance
(https://gcc.gnu.org/wiki/Fortran2008Status) and we really have only a few
items missing. One in particular is: "Data statement restrictions lifted”.
Quoting the document:
> Subscripts and nested implied-do limits in a data statement
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109373
I don’t believe it is widely used, and it was removed from everywhere else in
gcc.
Bootstrapped and regtested on x86_64-pc-linux-gnu.
OK to commit?
FX
0001-libgfortran-remove-support-for-enable-intermodule.patch
Description: Binary data
> OK, thanks.
Committed at
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ecc96eb5d2a0e5dd93365ef76a58d7f754273934
Hi,
> Running
> nohup make -j7 check-fortran
> RUNTESTFLAGS="--target_board=unix/-mabi=ieeelongdouble/-mcpu=power9"&
> from the gcc subdirectory yielded only a single failure:
I dug more into the code and I understand why all tests are running: since
db630423a97ec6690a8eb0e5c3cb186c91e3740d and
Hi,
Thanks Harald. I see there are bugs open, but actually not that many, compared
to other areas of the compiler :)
I think the code I sent was not really covered in the testsuite, so I have
committed it (after testing on x86_64-linux).
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a54c71ccc248
58 matches
Mail list logo
