Re: [PATCH] Fortran: fix treatment of character, value, optional dummy arguments [PR107444]
On Nov 10 2022, Harald Anlauf via Gcc-patches wrote: > Dear Fortranners, > > the attached patch is a follow-up to the fix for PR107441, > as it finally fixes the treatment of character dummy arguments > that have the value,optional attribute, and allows for checking > of the presence of such arguments. > > This entails a small ABI clarification, as the previous text > was not really clear on the argument passing conventions, > and the previously generated code was inconsistent at best, > or rather wrong, for this kind of procedure arguments. > (E.g. the number of passed arguments was varying...) > > Testcase cross-checked with NAG 7.1. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? This breaks aarch64: $ /opt/gcc/gcc-20221113/Build/./gcc/xgcc -B/opt/gcc/gcc-20221113/Build/./gcc/ -B/usr/aarch64-suse-linux/bin/ -B/usr/aarch64-suse-linux/lib/ -isystem /usr/aarch64-suse-linux/include -isystem /usr/aarch64-suse-linux/sys-include -fchecking=1 ../../../../libgomp/testsuite/libgomp.fortran/is_device_ptr-2.f90 -mabi=lp64 -B/opt/gcc/gcc-20221113/Build/aarch64-suse-linux/./libgomp/ -B/opt/gcc/gcc-20221113/Build/aarch64-suse-linux/./libgomp/.libs -I/opt/gcc/gcc-20221113/Build/aarch64-suse-linux/./libgomp -I../../../../libgomp/testsuite/../../include -I../../../../libgomp/testsuite/.. -fmessage-length=0 -fno-diagnostics-show-caret -fdiagnostics-color=never -fopenmp -O -fdump-tree-original -B/opt/gcc/gcc-20221113/Build/aarch64-suse-linux/./libgomp/../libgfortran/.libs -fintrinsic-modules-path=/opt/gcc/gcc-20221113/Build/aarch64-suse-linux/./libgomp -L/opt/gcc/gcc-20221113/Build/aarch64-suse-linux/./libgomp/.libs -L/opt/gcc/gcc-20221113/Build/aarch64-suse-linux/./libgomp/../libgfortran/.libs -lgfortran -foffload=-lgfortran -lm -o ./is_device_ptr-2.exe during GIMPLE pass: omplower ../../../../libgomp/testsuite/libgomp.fortran/is_device_ptr-2.f90:66:77: internal compiler error: in gfc_omp_check_optional_argument, at fortran/trans-openmp.cc:137 0x8acb63 gfc_omp_check_optional_argument(tree_node*, bool) ../../gcc/fortran/trans-openmp.cc:137 0xd29fc3 lower_omp_target ../../gcc/omp-low.cc:13632 0xd314b3 lower_omp_1 ../../gcc/omp-low.cc:14523 0xd314b3 lower_omp ../../gcc/omp-low.cc:14662 0xd31283 lower_omp_1 ../../gcc/omp-low.cc:14436 0xd31283 lower_omp ../../gcc/omp-low.cc:14662 0xd318a3 lower_omp_1 ../../gcc/omp-low.cc:14452 0xd318a3 lower_omp ../../gcc/omp-low.cc:14662 0xd377fb execute_lower_omp ../../gcc/omp-low.cc:14701 0xd377fb execute ../../gcc/omp-low.cc:14755 Please submit a full bug report, with preprocessed source (by using -freport-bug). -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH] Fortran: fix treatment of character, value, optional dummy arguments [PR107444]
On Nov 13 2022, Harald Anlauf wrote: > Can you please confirm that it fixes your issues? Looks good. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [patch, fortran, doc] Explicitly mention undefined overflow
On Mär 19 2023, Thomas Koenig via Gcc-patches wrote: > diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi > index c483e13686d..93c66b18938 100644 > --- a/gcc/fortran/gfortran.texi > +++ b/gcc/fortran/gfortran.texi > @@ -820,6 +820,7 @@ might in some way or another become visible to the > programmer. > * File operations on symbolic links:: > * File format of unformatted sequential files:: > * Asynchronous I/O:: > +* Behavior on integer overflow::o s/o$// -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH] Fortran: fix passing of optional dummy as actual to optional argument [PR55978]
On Jun 24 2024, Mikael Morin wrote: > tree-pretty-print.cc's op_symbol_code handles them as: > > case TRUTH_AND_EXPR: > case TRUTH_ANDIF_EXPR: > return "&&"; > > so no, I don't think they are differentiated. Only because C does not have a TRUTH_AND_EXPR operator. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
[PATCH] testsuite: Relax line number match in gfortran.dg/pr95690.f90
The actual line number is target dependent, and immaterial for the test.
* gfortran.dg/pr95690.f90: Allow matching error message anywhere.
---
gcc/testsuite/gfortran.dg/pr95690.f90 | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gfortran.dg/pr95690.f90
b/gcc/testsuite/gfortran.dg/pr95690.f90
index 1432937438a..4bd19b3dcdd 100644
--- a/gcc/testsuite/gfortran.dg/pr95690.f90
+++ b/gcc/testsuite/gfortran.dg/pr95690.f90
@@ -2,8 +2,10 @@
module m
contains
subroutine s
- print *, (erfc) ! { dg-error "not a floating constant" "" { target
i?86-*-* x86_64-*-* sparc*-*-* cris-*-* hppa*-*-* } }
- end ! { dg-error "not a floating constant" "" { target { ! "i?86-*-*
x86_64-*-* sparc*-*-* cris-*-* hppa*-*-*" } } }
+ print *, (erfc)
+ end
function erfc()
end
end
+! The actual line number is target dependent, allow any
+! { dg-error "not a floating constant" "" { target *-*-* } 0 }
--
2.46.0
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Re: [PATCH 3/3] [PR libfortran/101305] Fix ISO_Fortran_binding.h paths in gfortran testsuite
On Jul 13 2021, Sandra Loosemore wrote: > diff --git a/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_1.c > b/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_1.c > index a571459..9da5d85 100644 > --- a/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_1.c > +++ b/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_1.c > @@ -1,6 +1,6 @@ > /* Test F2008 18.5: ISO_Fortran_binding.h functions. */ > > -#include "../../../libgfortran/ISO_Fortran_binding.h" > +#include "ISO_Fortran_binding.h" Shouldn't that use since that is an installed header, not one that is supposed to be picked up from the current directory? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
This misses the m68k extended real format.
Andreas.
* ISO_Fortran_binding.h (CFI_type_long_double)
(CFI_type_long_double_Complex) [LDBL_MANT_DIG == 64 &&
LDBL_MIN_EXP == -16382 && LDBL_MAX_EXP == 16384]: Define.
---
libgfortran/ISO_Fortran_binding.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libgfortran/ISO_Fortran_binding.h
b/libgfortran/ISO_Fortran_binding.h
index 5335ea471c7..9c42464affa 100644
--- a/libgfortran/ISO_Fortran_binding.h
+++ b/libgfortran/ISO_Fortran_binding.h
@@ -233,6 +233,13 @@ extern int CFI_setpointer (CFI_cdesc_t *, CFI_cdesc_t *,
const CFI_index_t []);
#define CFI_type_long_double (CFI_type_Real + (10 << CFI_type_kind_shift))
#define CFI_type_long_double_Complex (CFI_type_Complex + (10 <<
CFI_type_kind_shift))
+/* This is the 96-bit encoding on m68k; Fortran assigns it kind 10. */
+#elif (LDBL_MANT_DIG == 64 \
+ && LDBL_MIN_EXP == -16382 \
+ && LDBL_MAX_EXP == 16384)
+#define CFI_type_long_double (CFI_type_Real + (10 << CFI_type_kind_shift))
+#define CFI_type_long_double_Complex (CFI_type_Complex + (10 <<
CFI_type_kind_shift))
+
/* This is the IEEE 128-bit encoding, same as float128. */
#elif (LDBL_MANT_DIG == 113 \
&& LDBL_MIN_EXP == -16381 \
--
2.33.0
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
On Sep 13 2021, Gerald Pfeifer wrote: > % egrep -r '#define.*LDBL_(MANT_DIG|MIN_EXP|MAX_EXP)' /usr/include/ > /usr/include/x86/float.h:#define LDBL_MANT_DIG 64 > /usr/include/x86/float.h:#define LDBL_MIN_EXP (-16381) > /usr/include/x86/float.h:#define LDBL_MAX_EXP 16384 > > This looks like it matches existing Linux case already in place? gcc has its own , see gcc/include/float.h in the build directory. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
On Sep 14 2021, Gerald Pfeifer wrote: > #define __LDBL_MANT_DIG__ 53 > #define __LDBL_DIG__ 15 > #define __LDBL_MIN_EXP__ (-16381) > #define __LDBL_MIN_10_EXP__ (-4931) > #define __LDBL_MAX_EXP__ 16384 > #define __LDBL_MAX_10_EXP__ 4932 > #define __LDBL_DECIMAL_DIG__ 17 > #define __LDBL_MAX__ 1.18973149535723163299902939989638351e+4932L > #define __LDBL_NORM_MAX__ 1.18973149535723163299902939989638351e+4932L > #define __LDBL_MIN__ 3.36210314311209350626267781732175260e-4932L > #define __LDBL_EPSILON__ 2.22044604925031308084726333618164062e-16L > #define __LDBL_DENORM_MIN__ 7.46536864129530798597817535205257178e-4948L > #define __LDBL_HAS_DENORM__ 1 > #define __LDBL_HAS_INFINITY__ 1 > #define __LDBL_HAS_QUIET_NAN__ 1 > #define __LDBL_IS_IEC_60559__ 2 That looks like range of extended float, but rounded to double float precision. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h
On Sep 14 2021, Jakub Jelinek wrote: > But, wonder why it didn't work with the float.h include then, because > https://github.com/lattera/freebsd/blob/master/sys/x86/include/float.h > seems to define LDBL_MANT_DIG to 64, LDBL_MIN_EXP to (-16381) and > LDBL_MAX_EXP to 16384 and that case was handled in ISO_Fortran_binding.h. Doesn't gcc always use its own float.h? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Okt 07 2021, Alastair McKinstry wrote: > I strongly advise against this -- identical SONAMEs for the libraries on > all architectures is a key assumption on all Debian-based distributions > and designs Even glibc has differing sonames on some architectures. And libgcc_s, too. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Okt 09 2021, Thomas Koenig via Fortran wrote: > There is no choice - we need to make object code compiled by the user > incompatible between the old and the new format on the systems where > we make the switch. If you link, but not recompile, object files compiled against different versions of glibc, you are in for surprises, too. This isn't something new. There is no guarantee of API stability. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH] doc: Remove @code wrapping of fortran option names [PR116801]
On Sep 23 2024, Mikael Morin wrote:
> For options where the variable is not a separate argument, I think it's
> preferable to keep the variable.
>
> For example, -ffree-line-length-@var{n} looks better on the index page as
> "-ffree-line-length-n" (with the n having a different formatting), than as
> "-free-line-length-". It makes it clear that there is a suffix to the
> option.
Whatever you feel like is the right solution, please make it constent
throughout the manual.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: [PATCH] doc: Remove @code wrapping of fortran option names [PR116801]
On Sep 22 2024, Jakub Jelinek wrote:
> On Sun, Sep 22, 2024 at 10:52:37PM +0200, Andreas Schwab wrote:
>> On Sep 22 2024, Mikael Morin wrote:
>>
>> > @@ -370,7 +370,7 @@ Set the default accessibility of module entities to
>> > @code{PRIVATE}.
>> > Use-associated entities will not be accessible unless they are explicitly
>> > declared as @code{PUBLIC}.
>> >
>> > -@opindex @code{ffixed-line-length-}@var{n}
>> > +@opindex ffixed-line-length-@var{n}
>>
>> Shouldn't all the @var{...} parts be dropped as well, throughout?
>
> We have it all over the other manuals:
But it causes them to not show up in the urls files.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: [PATCH] doc: Remove @code wrapping of fortran option names [PR116801]
On Sep 22 2024, Arsen Arsenović wrote:
> Andreas Schwab writes:
>
>> On Sep 22 2024, Jakub Jelinek wrote:
>>
>>> On Sun, Sep 22, 2024 at 10:52:37PM +0200, Andreas Schwab wrote:
>>>> On Sep 22 2024, Mikael Morin wrote:
>>>>
>>>> > @@ -370,7 +370,7 @@ Set the default accessibility of module entities to
>>>> > @code{PRIVATE}.
>>>> > Use-associated entities will not be accessible unless they are
>>>> > explicitly
>>>> > declared as @code{PUBLIC}.
>>>> >
>>>> > -@opindex @code{ffixed-line-length-}@var{n}
>>>> > +@opindex ffixed-line-length-@var{n}
>>>>
>>>> Shouldn't all the @var{...} parts be dropped as well, throughout?
>>>
>>> We have it all over the other manuals:
>>
>> But it causes them to not show up in the urls files.
>
> That seems like a defect of the regen script rather than of the manuals.
> They're there for a reason (signifying that something is not a fixed
> string).
It's only about the @opindex. The vast majority have those variable
parts removed from the index entry.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: [PATCH] doc: Remove @code wrapping of fortran option names [PR116801]
On Sep 22 2024, Mikael Morin wrote:
> @@ -370,7 +370,7 @@ Set the default accessibility of module entities to
> @code{PRIVATE}.
> Use-associated entities will not be accessible unless they are explicitly
> declared as @code{PUBLIC}.
>
> -@opindex @code{ffixed-line-length-}@var{n}
> +@opindex ffixed-line-length-@var{n}
Shouldn't all the @var{...} parts be dropped as well, throughout?
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: [PATCH] Fortran: fix crash with bounds check writing array section [PR117791]
../../gcc/fortran/trans-io.cc: In function 'tree_node* gfc_trans_transfer(gfc_code*)': ../../gcc/fortran/trans-io.cc:2662:24: error: enumeration value 'EXPR_UNKNOWN' not handled in switch [-Werror=switch] 2662 | switch (ref->u.ar.start[n]->expr_type) |^ ../../gcc/fortran/trans-io.cc:2662:24: error: enumeration value 'EXPR_CONSTANT' not handled in switch [-Werror=switch] ../../gcc/fortran/trans-io.cc:2662:24: error: enumeration value 'EXPR_VARIABLE' not handled in switch [-Werror=switch] ../../gcc/fortran/trans-io.cc:2662:24: error: enumeration value 'EXPR_SUBSTRING' not handled in switch [-Werror=switch] ../../gcc/fortran/trans-io.cc:2662:24: error: enumeration value 'EXPR_STRUCTURE' not handled in switch [-Werror=switch] ../../gcc/fortran/trans-io.cc:2662:24: error: enumeration value 'EXPR_ARRAY' not handled in switch [-Werror=switch] ../../gcc/fortran/trans-io.cc:2662:24: error: enumeration value 'EXPR_NULL' not handled in switch [-Werror=switch] ../../gcc/fortran/trans-io.cc:2662:24: error: enumeration value 'EXPR_COMPCALL' not handled in switch [-Werror=switch] ../../gcc/fortran/trans-io.cc:2662:24: error: enumeration value 'EXPR_PPC' not handled in switch [-Werror=switch] cc1plus: all warnings being treated as errors make[3]: *** [Makefile:1203: fortran/trans-io.o] Error 1 -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
