[PATCH] libgfortran: Fix up the autoreconf warnings.

[Iain Sandoe]

@tschwinge since he did quite a bit of work on getting autoreconf to
work in the GCC-13 cycle.

This does not address the issues with regenerating lib code, but it
does make things somewhat smoother for cases where the updates are
only in Makefile.am, configure.ac or libtool.m4 for example.

It is based on a patch I've been using on the release branches for
Darwin (written because I wasted a day on a warning missed among the
wall of output).

You should now be able to run "autoreconf -fv" in the libgfortran
directory with only informational output (no warnings).

So far only tested very lightly on trunk - but posting early in case
it helps the way forward.

thanks
Iain

--- 8< ---

This means using sub-dirs and amending some of the recipes accordingly.

libgfortran/ChangeLog:

* Makefile.am: Use sub-dirs, amend recipies accordingly.
* Makefile.in: Regenerate.

Signed-off-by: Iain Sandoe 
---
 libgfortran/Makefile.am | 1431 +++---
 libgfortran/Makefile.in | 9848 ++-
 2 files changed, 4126 insertions(+), 7153 deletions(-)

diff --git a/libgfortran/Makefile.am b/libgfortran/Makefile.am
index 9f8a4f69863..8bef1729219 100644
--- a/libgfortran/Makefile.am
+++ b/libgfortran/Makefile.am
@@ -1,5 +1,6 @@
 ## Process this file with automake to produce Makefile.in
 
+AUTOMAKE_OPTIONS = foreign subdir-objects
 
 ACLOCAL_AMFLAGS = -I .. -I ../config
 
@@ -239,629 +240,629 @@ runtime/stop.c
 endif
 
 i_all_c= \
-$(srcdir)/generated/all_l1.c \
-$(srcdir)/generated/all_l2.c \
-$(srcdir)/generated/all_l4.c \
-$(srcdir)/generated/all_l8.c \
-$(srcdir)/generated/all_l16.c
+generated/all_l1.c \
+generated/all_l2.c \
+generated/all_l4.c \
+generated/all_l8.c \
+generated/all_l16.c
 
 i_any_c= \
-$(srcdir)/generated/any_l1.c \
-$(srcdir)/generated/any_l2.c \
-$(srcdir)/generated/any_l4.c \
-$(srcdir)/generated/any_l8.c \
-$(srcdir)/generated/any_l16.c
+generated/any_l1.c \
+generated/any_l2.c \
+generated/any_l4.c \
+generated/any_l8.c \
+generated/any_l16.c
 
 i_bessel_c= \
-$(srcdir)/generated/bessel_r4.c \
-$(srcdir)/generated/bessel_r8.c \
-$(srcdir)/generated/bessel_r10.c \
-$(srcdir)/generated/bessel_r16.c \
-$(srcdir)/generated/bessel_r17.c
+generated/bessel_r4.c \
+generated/bessel_r8.c \
+generated/bessel_r10.c \
+generated/bessel_r16.c \
+generated/bessel_r17.c
 
 i_count_c= \
-$(srcdir)/generated/count_1_l.c \
-$(srcdir)/generated/count_2_l.c \
-$(srcdir)/generated/count_4_l.c \
-$(srcdir)/generated/count_8_l.c \
-$(srcdir)/generated/count_16_l.c
+generated/count_1_l.c \
+generated/count_2_l.c \
+generated/count_4_l.c \
+generated/count_8_l.c \
+generated/count_16_l.c
 
 i_iall_c= \
-$(srcdir)/generated/iall_i1.c \
-$(srcdir)/generated/iall_i2.c \
-$(srcdir)/generated/iall_i4.c \
-$(srcdir)/generated/iall_i8.c \
-$(srcdir)/generated/iall_i16.c
+generated/iall_i1.c \
+generated/iall_i2.c \
+generated/iall_i4.c \
+generated/iall_i8.c \
+generated/iall_i16.c
 
 i_iany_c= \
-$(srcdir)/generated/iany_i1.c \
-$(srcdir)/generated/iany_i2.c \
-$(srcdir)/generated/iany_i4.c \
-$(srcdir)/generated/iany_i8.c \
-$(srcdir)/generated/iany_i16.c
+generated/iany_i1.c \
+generated/iany_i2.c \
+generated/iany_i4.c \
+generated/iany_i8.c \
+generated/iany_i16.c
 
 i_iparity_c= \
-$(srcdir)/generated/iparity_i1.c \
-$(srcdir)/generated/iparity_i2.c \
-$(srcdir)/generated/iparity_i4.c \
-$(srcdir)/generated/iparity_i8.c \
-$(srcdir)/generated/iparity_i16.c
+generated/iparity_i1.c \
+generated/iparity_i2.c \
+generated/iparity_i4.c \
+generated/iparity_i8.c \
+generated/iparity_i16.c
 
 i_findloc0_c= \
-$(srcdir)/generated/findloc0_i1.c \
-$(srcdir)/generated/findloc0_i2.c \
-$(srcdir)/generated/findloc0_i4.c \
-$(srcdir)/generated/findloc0_i8.c \
-$(srcdir)/generated/findloc0_i16.c \
-$(srcdir)/generated/findloc0_r4.c \
-$(srcdir)/generated/findloc0_r8.c \
-$(srcdir)/generated/findloc0_r10.c \
-$(srcdir)/generated/findloc0_r16.c \
-$(srcdir)/generated/findloc0_r17.c \
-$(srcdir)/generated/findloc0_c4.c \
-$(srcdir)/generated/findloc0_c8.c \
-$(srcdir)/generated/findloc0_c10.c \
-$(srcdir)/generated/findloc0_c16.c \
-$(srcdir)/generated/findloc0_c17.c
+generated/findloc0_i1.c \
+generated/findloc0_i2.c \
+generated/findloc0_i4.c \
+generated/findloc0_i8.c \
+generated/findloc0_i16.c \
+generated/findloc0_r4.c \
+generated/findloc0_r8.c \
+generated/findloc0_r10.c \
+generated/findloc0_r16.c \
+generated/findloc0_r17.c \
+generated/findloc0_c4.c \
+generated/findloc0_c8.c \
+generated/findloc0_c10.c \
+generated/findloc0_c16.c \
+generated/findloc0_c17.c
 
 i_findloc0s_c= \
-$(srcdir)/generated/findloc0_s1.c \
-$(srcdir)/generated/findloc0_s4.c
+generated/findloc0_s1.c \
+generated/findloc0_s4.c
 
 i_findloc1_c= \
-$(srcdir)/generated/findloc1_i1.c \
-$(srcdir)/generated/findloc1_i2.c \
-$(srcdir)/generated/findloc1_i4.c \
-$(srcdir)/generated/findloc1_i8.c \
-$(srcdir)/generated/findloc1_i16.c \
-$(srcdir)/generated/findloc1_r4.c \
-$(srcdir)/generated/findloc1_r8.

Re: [EXT] gfortran: error: unrecognized argument in option '-mcmodel=medium'

[Iain Sandoe]

Hi,

> On 28 Sep 2023, at 14:56, Lingadahally, Vishakha (2023) 
>  wrote:

> Could you please let me know if there happens to be an update regarding how I 
> might be able to resolve it?

when you are on an arm64 machine you need to add "-mcmodel=small” (applies to 
Arm) instead of "-mcmodel=medium” (applies to Intel)

Iain

> 
> Thanks!
> 
> Warm regards,
> Vishakha
> ____
> From: Iain Sandoe 
> Sent: 27 September 2023 08:35
> To: Lingadahally, Vishakha (2023) 
> Cc: GCC Fortran 
> Subject: [EXT] Re: gfortran: error: unrecognized argument in option 
> '-mcmodel=medium'
> 
> 
> 
>> On 27 Sep 2023, at 08:33, Iain Sandoe  wrote:
>> 
>> 
>> 
>>> On 27 Sep 2023, at 08:25, Andrew Pinski via Fortran  
>>> wrote:
>>> 
>>> On Tue, Sep 26, 2023 at 11:39 PM Richard Biener via Fortran
>>>  wrote:
>>>> 
>>>> On Tue, Sep 26, 2023 at 4:44 PM Lingadahally, Vishakha (2023)
>>>>  wrote:
>>>>> 
>>>>> Dear GCC Team,
>>>>> 
>>>>> I'm running Ubuntu 22 on my Mac virtually and my gfortran version is 
>>>>> 11.4.0. When I try to install a certain software package, I encounter the 
>>>>> following error:
>>>>> 
>>>>> gfortran: error: unrecognized argument in option '-mcmodel=medium'
>>>>> gfortran: note: valid arguments to '-mcmodel=' are: large small tiny
>>>>> 
>>>>> Is this due to attempting to run gfortran on arm64 architecture? Could 
>>>>> you please let me know how I could resolve the issue?
>>>> 
>>>> You have to turn to Ubuntu here, -mcmodel=medium is certainly
>>>> supported in GCC 11, maybe Ubuntu patches out
>>>> the support?
>>> 
>>> Well -mcmodel=medium is the x86_64 specific option while they are
>>> trying to run on aarch64 which has a different set options.
>> 
>> 
>> The current Arm64 port (aarch64 on macOS) only supports the “small” mcmodel
>> “tiny” is not supported by macOS and we have not yet implemented “large”.
>> 
>> Despite it’s name “small” should suffice as an approximate equivalent for the
>> x86_64 “medium” (at least on macOS).
>> 
>> So, either you need to change the flag depending on the architecture, or 
>> omit it
>> (on macOS currently GCC only supports the default mcmodel).
>> 
>> We plan to support the “large” model at some stage on Arm64 (but unlikely for
>> GCC 14)
> 
> Ah, and now I see you are not running native so the comments above are not
> relevant.
> Iain
> 
> 
> This email, its contents and any attachments are intended solely for the 
> addressee and may contain confidential information. In certain circumstances, 
> it may also be subject to legal privilege. Any unauthorised use, disclosure, 
> or copying is not permitted. If you have received this email in error, please 
> notify us and immediately and permanently delete it. Any views or opinions 
> expressed in personal emails are solely those of the author and do not 
> necessarily represent those of Royal Holloway, University of London. It is 
> your responsibility to ensure that this email and any attachments are virus 
> free.

Re: gfortran: error: unrecognized argument in option '-mcmodel=medium'

[Iain Sandoe]

> On 27 Sep 2023, at 08:33, Iain Sandoe  wrote:
> 
> 
> 
>> On 27 Sep 2023, at 08:25, Andrew Pinski via Fortran  
>> wrote:
>> 
>> On Tue, Sep 26, 2023 at 11:39 PM Richard Biener via Fortran
>>  wrote:
>>> 
>>> On Tue, Sep 26, 2023 at 4:44 PM Lingadahally, Vishakha (2023)
>>>  wrote:
>>>> 
>>>> Dear GCC Team,
>>>> 
>>>> I'm running Ubuntu 22 on my Mac virtually and my gfortran version is 
>>>> 11.4.0. When I try to install a certain software package, I encounter the 
>>>> following error:
>>>> 
>>>> gfortran: error: unrecognized argument in option '-mcmodel=medium'
>>>> gfortran: note: valid arguments to '-mcmodel=' are: large small tiny
>>>> 
>>>> Is this due to attempting to run gfortran on arm64 architecture? Could you 
>>>> please let me know how I could resolve the issue?
>>> 
>>> You have to turn to Ubuntu here, -mcmodel=medium is certainly
>>> supported in GCC 11, maybe Ubuntu patches out
>>> the support?
>> 
>> Well -mcmodel=medium is the x86_64 specific option while they are
>> trying to run on aarch64 which has a different set options.
> 
> 
> The current Arm64 port (aarch64 on macOS) only supports the “small” mcmodel
> “tiny” is not supported by macOS and we have not yet implemented “large”.
> 
> Despite it’s name “small” should suffice as an approximate equivalent for the
> x86_64 “medium” (at least on macOS).
> 
> So, either you need to change the flag depending on the architecture, or omit 
> it
> (on macOS currently GCC only supports the default mcmodel).
> 
> We plan to support the “large” model at some stage on Arm64 (but unlikely for
> GCC 14)

Ah, and now I see you are not running native so the comments above are not
relevant.
Iain

Re: gfortran: error: unrecognized argument in option '-mcmodel=medium'

[Iain Sandoe]

> On 27 Sep 2023, at 08:25, Andrew Pinski via Fortran  
> wrote:
> 
> On Tue, Sep 26, 2023 at 11:39 PM Richard Biener via Fortran
>  wrote:
>> 
>> On Tue, Sep 26, 2023 at 4:44 PM Lingadahally, Vishakha (2023)
>>  wrote:
>>> 
>>> Dear GCC Team,
>>> 
>>> I'm running Ubuntu 22 on my Mac virtually and my gfortran version is 
>>> 11.4.0. When I try to install a certain software package, I encounter the 
>>> following error:
>>> 
>>> gfortran: error: unrecognized argument in option '-mcmodel=medium'
>>> gfortran: note: valid arguments to '-mcmodel=' are: large small tiny
>>> 
>>> Is this due to attempting to run gfortran on arm64 architecture? Could you 
>>> please let me know how I could resolve the issue?
>> 
>> You have to turn to Ubuntu here, -mcmodel=medium is certainly
>> supported in GCC 11, maybe Ubuntu patches out
>> the support?
> 
> Well -mcmodel=medium is the x86_64 specific option while they are
> trying to run on aarch64 which has a different set options.


The current Arm64 port (aarch64 on macOS) only supports the “small” mcmodel
“tiny” is not supported by macOS and we have not yet implemented “large”.

Despite it’s name “small” should suffice as an approximate equivalent for the
x86_64 “medium” (at least on macOS).

So, either you need to change the flag depending on the architecture, or omit it
(on macOS currently GCC only supports the default mcmodel).

We plan to support the “large” model at some stage on Arm64 (but unlikely for
GCC 14)

HTH,
Iain

Re: What .dylib files does gfortran v 11.2.0 need on a Mac?

[Iain Sandoe]

Hi Leigh,

> On 22 Jul 2023, at 20:05, Leigh House  wrote:
> 

> Thanks for your fast reply!
> 
> My Mac is an intel iMac from 2019. 

That should be fine with “upstream” sources, should you decide to build from 
source (but that should not be necessary, there are several places providing 
gfortran for mac).

> I didn’t keep detailed notes about where I got the compiler package, though 
> I’ve often gone to hpc.sourceforge.net in the past, under “Computation 
> Tools”. I suspect that is where I got my current compiler from. 
> 
> And I didn’t keep notes about which .dylib file I had to find and copy into 
> /usr/local/lib, though from a colleague’s experience it may have been 
> libgfortran.5.dylib.

I checked the version(s) for which the initialization bug is fixed:

GCC-10.4
GCC-11.3 <<- so you are almost certainly seeing it with 11.2.
GCC-12.1
GCC-13.1
(and current development ’trunk’).

This was a very unusual case - we try to be backward compatible as much as 
possible, but the change was out of our hands.

So, I’d recommend that you see if your “usual source” has an update - or, 
alternately, go to one of the ‘OSS distributions’ like Homebrew.

HTH,
Iain

Re: What .dylib files does gfortran v 11.2.0 need on a Mac?

[Iain Sandoe]

Hi Leigh

> On 22 Jul 2023, at 19:20, Leigh House via Fortran  wrote:
> 
> I’ve not been able to get any output written to a file by a program I 
> compiled with gfortran v11.2.0 on my Mac. The Mac has MacOS Monterey 
> (v12.6.7). This seems like a simple problem, yet I’ve not been able to find a 
> solution. And it is an increasing obstacle for me. The problem includes 
> fortran programs that were compiled years ago. Suddenly, they can no longer 
> write output to a file. For example, writing to standard out (lun 6) works 
> fine to the screen, but when redirected to a file, that file is empty.

Is your mac Intel or Arm64**?

You do not say where you got the compiler from (or if you built from source), 
it might be relevant to a resolution.

> A colleague got a clue that the problem may be in an out-of-date, faulty or 
> corrupted .dylib file. Perhaps /usr/local/lib/libgfortran.5.dylib? The file 
> /usr/local/lib/libgfortran.dylib is a symbolic link to 
> /usr/local/lib/libgfortran.5.dylib. That file has a date of Nov 9, 2021 on my 
> Mac. Should I have a newer file? If so, how do I get it? I would have thought 
> it would be included in the gfortran install, but maybe not?

Actually, there was an operating system change in the way that initialization 
was handled that is backwards-incompatible. We raised a ‘feedback’ with Apple, 
but the response was that this was intentional - it is possible that you are 
running into this - I’d need to check the exact versions at which we fixed it.

> More generally, can I get a list of the .dylib files that gfortran (11.2.0) 
> and gcc (also 11.2.0) need for programs they compile to function properly? 
> And the dates for them? Do these files need to be owned by user “root” or 
> have other special permissions (on my Mac, I own them as a regular user).

No, nothing in GCC requires elevated permissions.

(of course, if you elect to build it from source and install to some place that 
requires admin privs., but that’s only for installation).
 
> This seems like a very obscure, yet debilitating problem that I have 
> encountered. If I cannot write or modify my fortran codes and have them work 
> properly, I am SOL. 

gfortran works fine on Monterey - so I am sure that we will be able to fix this.

Iain

** Arm64 does require building an out-of-tree branch, but that is being used 
widely, so also very well-tested.

Re: [PATCH][stage1] Remove conditionals around free()

[Iain Sandoe]

> On 3 Mar 2023, at 23:11, Bernhard Reutner-Fischer via Fortran 
>  wrote:
> 
> On 2 March 2023 02:23:10 CET, Jerry D  wrote:
>> On 3/1/23 4:07 PM, Steve Kargl via Fortran wrote:
>>> On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via 
>>> Fortran wrote:
  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 +--
>>> 
>>> The Fortran ones are OK.
>>> 
>> 
>> The only question I have: Is free posix compliant on all platforms?
>> 
>> For example ming64 or mac?

OSX / macOS are [certified] Posix compliant - but to unix03 (and might be 
missing features declared as optional at that revision, or features from later 
Posix versions).

In the case of free() man says:
"The free() function deallocates the memory allocation pointed to by ptr. If 
ptr is a NULL pointer, no operation is performed.”

Iain


>>  It seems sometimes we run into things like this once in a while.
> 
> I think we have the -liberty to cater even for non compliant systems either 
> way, if you please excuse the pun. That's not an excuse on POSIX systems, 
> imho.
> 
>> 
>> Otherwise I have no issue at all.  It is a lot cleaner.
>> 
>> Jerry

Re: gfortran run on 64bit Mac ?

[Iain Sandoe via Fortran]

Hello David,

> On 29 Jan 2022, at 11:14, dmainprice via Fortran  wrote:

> gfortran  run on 64bit Mac ?

Yes, gfortran has been running on (x86_64) 64bit Mac since macOS 10.6.

> Any suggestions will F77 code run ?

if it will compile with gfortran, then you could expect it to run,

cheers
Iain

> 
> all the best and happy year
> 
> David Mainprice 
> 
> 

[pushed] libgfortran: Fix bootstrap on targets without static_assert macro.

[Iain Sandoe via Fortran]

Although we build the library with GCC which is known to support
_Static_assert this might be done on a system without the macro
mapping static_assert to the compiler keyword.

The use of static_assert introduced with r12-6126-g3430132f3e82
causes bootstrap to fail on such targets, fixed by using the keyword
directly.

tested on i686-darwin9 and x86_64-darwin18, without regressions,
pushed to master as an obvious bootstrap fix (and as approved by FX).
thanks
Iain

Signed-off-by: Iain Sandoe 

libgfortran/ChangeLog:

* runtime/string.c (gfc_itoa): Use _Static_assert directly
instead of via the static_assert macro.
---
 libgfortran/runtime/string.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libgfortran/runtime/string.c b/libgfortran/runtime/string.c
index 21585f48dc9..5bc202320c0 100644
--- a/libgfortran/runtime/string.c
+++ b/libgfortran/runtime/string.c
@@ -242,8 +242,8 @@ gfc_itoa (GFC_UINTEGER_LARGEST n, char *buffer, size_t len)
 integers (we would need three calls), but they do suffice for all
 values up to 2^127, which is the largest that Fortran can produce
 (-HUGE(0_16)-1) with its signed integer types.  */
-  static_assert(sizeof(GFC_UINTEGER_LARGEST) <= 2 * sizeof(uint64_t),
-   "integer too large");
+  _Static_assert (sizeof(GFC_UINTEGER_LARGEST) <= 2 * sizeof(uint64_t),
+ "integer too large");
 
   GFC_UINTEGER_LARGEST r;
   r = n % TEN19;
-- 
2.24.3 (Apple Git-128)

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Iain Sandoe]

> On 9 Oct 2021, at 10:11, Thomas Koenig  wrote:
> 
> 
> On 09.10.21 01:18, Iain Sandoe wrote:
>>> I meant the case where the user writes, with an old, KIND=16 is double
>>> double compiler,
>>> 
>>>  subroutine foo(a)
>>>real(kind=16) :: a
>>>a = a + 1._16
>>>  end subroutine foo
>>> 
>>> and puts it in a library or an old object file, and in new code with an
>>> IEEE QP compiler calls that with
>>> 
>>>  real(kind=16) :: a
>>>  a = 2._16
>>>  call foo(a)
>>>  print *,a
>>> 
>>> this will result in silent generation of garbage values, since Fortran
>>> does not mangle the function name based on it types. For both cases, the
>>> subroutine will be called foo_  (or MOD..._foo).
>> hmm, well I thought about that case, but  … isn’t this “pilot error”?
>> if one compiles different parts of a project with incompatible command line 
>> options…
>> … or, say, compile with -mavx512 and then try to run code on hardware without
>> such a vector unit?
>> Getting wrong answers silently can likely be done with other command line
>> option mismatches.
> 
> Again, it depends.
> 
> What I was thinking about what a scenario where we do not change the
> SONAME on POWER and rely on name mangling to get to the correct version
> of a libgfortran library function. That could work, but it would not
> work for user procedures.

What I’m missing is why it has to.

IF  the user wants to use old (or not-owned) code compiled for double-double, 
then
she must select a command-line option to use that on Power(New).

Else

The user recompiles all the code in her project to use the new shiny QP.

I doubt there’s a way for this to proceed in a way that a user of Power (New) 
can
avoid having to think it through - a new library SO name won’t help them with 
the
interop with thier own (or not owned) code.

> I have thought of mangling the name of all user Fortran procedures
> which contain a reference to an IEEE QP in their argument list, like
> _foo%QP, but that would fall down for C interop.  So, no luck there.

agreed, I did the same thought exercise. 


> So, a new SONAME at least on POWER is mandatory, I think.
> 
> The question is still if we can avoid a new SONAME for >99% of our users
> for no gain at all for them.  Is there a possibility of aliasing the
> SONAME somehow (grasping at straws here)?
> 
> Best regards
> 
>   Thomas

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Iain Sandoe]

> On 8 Oct 2021, at 23:55, Thomas Koenig via Gcc  wrote:
> 
> 
> Hi Iain,
> 
>>> Things get interesting for user code, calling a routine compiled
>>> for double double with newer IEEE QP will result in breakage.
>> That would not happen with the proposal above, since the library would
>> have different entry points for the two formats.
> 
> I meant the case where the user writes, with an old, KIND=16 is double
> double compiler,
> 
>  subroutine foo(a)
>real(kind=16) :: a
>a = a + 1._16
>  end subroutine foo
> 
> and puts it in a library or an old object file, and in new code with an
> IEEE QP compiler calls that with
> 
>  real(kind=16) :: a
>  a = 2._16
>  call foo(a)
>  print *,a
> 
> this will result in silent generation of garbage values, since Fortran
> does not mangle the function name based on it types. For both cases, the
> subroutine will be called foo_  (or MOD..._foo).

hmm, well I thought about that case, but  … isn’t this “pilot error”?

if one compiles different parts of a project with incompatible command line 
options…

… or, say, compile with -mavx512 and then try to run code on hardware without
such a vector unit?

Getting wrong answers silently can likely be done with other command line
option mismatches.

Iain

> 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.
> 
> This is starting to look like a can of worms from Pandora's box,
> if you pardon my mixed metaphors.

> 
> Best regards
> 
>   Thomas

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Iain Sandoe]

Hi Thomas,

recognising that this is complex - the intent here is to see if there are ways
to partition the problem (where the pain falls does depend on the choices
made).

perhaps:

 *A  library (interface, name)
 *B  compiler internals
 *C  user-facing changes

> On 8 Oct 2021, at 17:26, Thomas Koenig  wrote:
> 

>> If one wanted to prioritize library SO name stability - then, perhaps, the
>> approach Jonathan mentioned has been used for libstdc++ (add new
>> symbols for ieee128 with a different mangling to the existing r/c_16 ..)
>> would be preferable (the FE then has to choose the relevant symbol/
>> mangling depending on target).

(A) the points here ^^ are:

1/ the SO name could be left as it is
2/ a target that defaulted to QP routines would still (perhaps under
   some command line flag be able to use the older implementation).

I think both of those could be very helpful to end-users…

> That's not all that would have to be changed.


>  Consider
> 
>  write (*,*) 1.0_16
> end program
> 
> which is translated (using -fdump-tree-original) to
> 
> 
>_gfortran_st_write (_parm.0);
>{
>  static real(kind=16) C.3873 = 1.0e+0;
> 
>  _gfortran_transfer_real128_write (_parm.0, , 16);
>}
>_gfortran_st_write_done (_parm.0);
> 
> so we actually pass a separate kind number as well (why, I'm not sure).
> We would have to go through libgfortran with a fine comb to find all
> the occurrences.  Probably some m4 hackery in iparm.m4 and ifunction.m4.
> So, doable from the library side, if some work.

(B) This is the second area of interest, the fact that changes in the compiler 
internals
would be needed - and those take the time of the volunteers to implement 
(believe
me, I am painfully aware of how that pressure falls).

> Things get interesting for user code, calling a routine compiled
> for double double with newer IEEE QP will result in breakage.

That would not happen with the proposal above, since the library would
have different entry points for the two formats.

> We cannot use the KIND number to differentiate, because we must
> assume that people have used KIND=16 and selected_real_kind(30)
> interchangably, and we certainly do not want to nail people to
> the old double double precision on hardware for which IEEE QP
> is available.  

you don’t *have* to use the KIND number to differentiate to the library or the 
compiler
(although some alternate, more flexible, token would have to be invented).

(C) It’s the mapping between that internal token and the user’s view of the 
world that
needs to be defined in terms of what the combination of platform and command 
line
flags implies to the treatment of KIND=NN and selected_real_kind().

> So, KIND=15 for IEEE QP is out.

(C) I must confess this kind of change is where things seem very tricky to me.

changing how the language represents things seems to be something
that would benefit from agreement between compiler vendors

> It's not an easy problem, unfortunately.

no. it is not.
Iain

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Iain Sandoe]

> On 8 Oct 2021, at 07:35, Thomas Koenig via Fortran  
> wrote:
> 
> 
> On 07.10.21 17:33, Jakub Jelinek wrote:
>>> It will also be a compatibility issue if users have code compiled on a LE
>>> system with GCC 11 and earlier with KIND=16, it will not link with GCC 12.
>> libgfortran ABI changed multiple times in the past already, e.g. the
>> so.1 -> so.2 transition in 4.2
>> so.2 -> so.3 transition in 4.3
>> so.3 -> so.4 transition in 7
>> so.4 -> so.5 transition in 8
>> and users have coped.
> 
> Yes, and it has always been a hassle for users, and we've been
> criticized for it.
> 
> This is currently a change which brings users on non-POWER-systems
> (the vast majority) all pain and no gain.  If this cannot be
> avoided, I would at least try to fit in as much of other improvements
> as there are possible.

If one wanted to prioritize library SO name stability - then, perhaps, the
approach Jonathan mentioned has been used for libstdc++ (add new
symbols for ieee128 with a different mangling to the existing r/c_16 ..)
would be preferable (the FE then has to choose the relevant symbol/
mangling depending on target).

.. perhaps I missed where that idea was already ruled out (in which case
sorry for the noise).
Iain
> 
> There's a PR for it somewhere, but I can think of three areas, none
> of the small, and all require an ABI change:
> 
> a) Get PDTs right (Paul?)
> b) Make file descriptors conform to the C interop version
> c) Remove the run-time parsing of I/O arguments and
>   replace them with a bit field.
> 
> What I mean by the last one is that
> 
>  WRITE (unit,'(A)',ADVANCE="NO")
> 
> we currently parse the "NO" at runtime, for every statement
> execution.  What we could be doing instead is to have
> 
> dt_parm.0.advance = __gfortran_evaluate_yesno ("NO")
> 
> where the latter function can be simplified at compile-time.
> 
> We should strive to break the ABI as few times as possible.
> 
> Best regards
> 
>   Thomas

Re: Executable on Apple M1 and Apple Intel

[Iain Sandoe]

Hello Heiner.

> On 29 Sep 2021, at 08:04, Heiner Veelken via Fortran  
> wrote:

> This is my first post; kindly inform me, if I did anything wrong :-)
> I am using gfortran (M1) from hpc.sourceforge.net 
>  on my Apple Macbook Pro M1. I just create my 
> executable via:
> 
> gfortran Pmain.f psub.F -o prog_m1
> 
> This only works on my machine. On Apple Intel Macbook Pros the response in 
> the terminal is a.o. "bad cpu type".
> Is there a possibility to create something like a "universal binary" in 
> gfortran, which works as well for M1- and Intel-CPUs? In case of, what would 
> be the option to call the compiler, how would it look like?

Yes it is possible, but I don’t know if any distribution is supplying the 
relevant compiler for gfortran.

Essentially, one needs a [cross]compiler generating Intel (x86_64) code which 
runs on the M1.

then you build your program with the native compiler => m1/my_prog
then you build your program with the cross-compiler => intel/my_prog

then you make a “FAT” version, thus:

lipo m1/my_prog intel/my_prog  -create -output fat/my_prog 

(or however you prefer to layout your work, of course)

so you’d need to see if hpc.sourceforge.net is providing a cross compiler 
targetting intel .. 
if not, then ask back here and perhaps we can suggest an alternative.

Iain.

> Remark: Is there a Fortran-guru here living in Aachen, Germany, too?

Re: [PATCH] libgfortran : Use the libtool macro to determine libm availability.

[Iain Sandoe]

> On 22 Aug 2021, at 09:44, Iain Sandoe  wrote:
> 
> 
> 
>> On 21 Aug 2021, at 23:18, Eric Gallager  wrote:
>> 
>> On Fri, Aug 20, 2021 at 3:53 AM Tobias Burnus  
>> wrote:
>>> 
>>> On 20.08.21 09:34, Richard Biener via Fortran wrote:
>>> 
>>>> On Thu, Aug 19, 2021 at 10:10 PM Iain Sandoe  wrote:
>>>>> libm is not needed on Darwin, and should not be added unconditionally
>>>>> even if that is (mostly) harmless since it is a symlink to libc.
>>>>> 
>>>>> tested on x86_64, i686-darwin, x86_64-linux,
>>>>> OK for master?
>>>> OK.
>>>> Richard.
>>> 
>>> Looks also good to me – but for completeness and as background, I also
>>> want to remark the following.
>>> 
>>> (At least as I understand it, I did not dig deeper.)
>>> 
>>>> --- a/libgfortran/configure.ac
>>>> +++ b/libgfortran/configure.ac
>>>> ...
>>>> +AC_CHECK_LIBM
>>> 
>>> This CHECK_LIBM has a hard-coded list of targets and for some (like
>>> Darwin) it simply does not set $LIBM.
>> 
>> I thought the proper macro to use was LT_LIB_M ?
> 
> you could well be right, libtool.m4 contains:
> 
> # Old name:
> AU_ALIAS([AC_CHECK_LIBM], [LT_LIB_M])
> 
> I guess the patch can be changed and then do another round of testing …
> … will add this to the TODO, and withdraw the current patch.

this is what I pushed after retesting (with the extras space removed too):

==
libgfortran: Use the libtool macro to determine libm
 availability.

We recently had a report of build failure against a Darwin branch on
the latest OS release.  This was because (temporarily) the symlink
from libm.dylib => libSystem.dylib had been removed/omitted.

libm is not needed on Darwin, and should not be added unconditionally
even if that is (mostly) harmless since it is a symlink to libc.

There could be cases where the addition was not completely harmless
because the presentation of the symlink would cause the symbols exposed
in libSystem to be considered ahead of ones presented in convenience
libraries.

libgfortran/ChangeLog:

* Makefile.am: Use configured libm availability.
* Makefile.in: Regenerate.
* configure: Regenerate.
* configure.ac: Use libtool macro to find libm availability.
* libgfortran.spec.in: Use configured libm availability.
---
 libgfortran/Makefile.am |   2 +-
 libgfortran/Makefile.in |   3 +-
 libgfortran/configure   | 146 +++-
 libgfortran/configure.ac|   1 +
 libgfortran/libgfortran.spec.in |   2 +-
 5 files changed, 149 insertions(+), 5 deletions(-)

diff --git a/libgfortran/Makefile.am b/libgfortran/Makefile.am
index 8d104321567..6fc4b465c6e 100644
--- a/libgfortran/Makefile.am
+++ b/libgfortran/Makefile.am
@@ -42,7 +42,7 @@ libgfortran_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS)
 libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' 
$(srcdir)/libtool-version` \
$(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \
$(HWCAP_LDFLAGS) \
-   -lm $(extra_ldflags_libgfortran) \
+   $(LIBM) $(extra_ldflags_libgfortran) \
$(version_arg) -Wc,-shared-libgcc
 libgfortran_la_DEPENDENCIES = $(version_dep) libgfortran.spec $(LIBQUADLIB_DEP)
  
 
diff --git a/libgfortran/configure.ac b/libgfortran/configure.ac
index 523eb24bca1..a77509801e6 100644
--- a/libgfortran/configure.ac
+++ b/libgfortran/configure.ac
@@ -260,6 +260,7 @@ AC_PROG_INSTALL
 #AC_MSG_NOTICE([== Starting libtool configuration])
 AC_LIBTOOL_DLOPEN
 AM_PROG_LIBTOOL
+LT_LIB_M
 ACX_LT_HOST_FLAGS
 AC_SUBST(enable_shared)
 AC_SUBST(enable_static)
diff --git a/libgfortran/libgfortran.spec.in b/libgfortran/libgfortran.spec.in
index 95aa3f842a3..367d485c230 100644
--- a/libgfortran/libgfortran.spec.in
+++ b/libgfortran/libgfortran.spec.in
@@ -5,4 +5,4 @@
 #
 
 %rename lib liborig
-*lib: @LIBQUADSPEC@ -lm %(libgcc) %(liborig)
+*lib: @LIBQUADSPEC@ @LIBM@ %(libgcc) %(liborig)
-- 
2.24.3 (Apple Git-128)

Re: [PATCH] libgfortran : Use the libtool macro to determine libm availability.

[Iain Sandoe]

> On 21 Aug 2021, at 23:18, Eric Gallager  wrote:
> 
> On Fri, Aug 20, 2021 at 3:53 AM Tobias Burnus  wrote:
>> 
>> On 20.08.21 09:34, Richard Biener via Fortran wrote:
>> 
>>> On Thu, Aug 19, 2021 at 10:10 PM Iain Sandoe  wrote:
>>>> libm is not needed on Darwin, and should not be added unconditionally
>>>> even if that is (mostly) harmless since it is a symlink to libc.
>>>> 
>>>> tested on x86_64, i686-darwin, x86_64-linux,
>>>> OK for master?
>>> OK.
>>> Richard.
>> 
>> Looks also good to me – but for completeness and as background, I also
>> want to remark the following.
>> 
>> (At least as I understand it, I did not dig deeper.)
>> 
>>> --- a/libgfortran/configure.ac
>>> +++ b/libgfortran/configure.ac
>>> ...
>>> +AC_CHECK_LIBM
>> 
>> This CHECK_LIBM has a hard-coded list of targets and for some (like
>> Darwin) it simply does not set $LIBM.
> 
> I thought the proper macro to use was LT_LIB_M ?

you could well be right, libtool.m4 contains:

# Old name:
AU_ALIAS([AC_CHECK_LIBM], [LT_LIB_M])

I guess the patch can be changed and then do another round of testing …
… will add this to the TODO, and withdraw the current patch.

Iain

Re: [PATCH] libgfortran : Use the libtool macro to determine libm availability.

[Iain Sandoe]

> On 20 Aug 2021, at 08:52, Tobias Burnus  wrote:
> 
> On 20.08.21 09:34, Richard Biener via Fortran wrote:
> 
>> On Thu, Aug 19, 2021 at 10:10 PM Iain Sandoe  wrote:
>>> libm is not needed on Darwin, and should not be added unconditionally
>>> even if that is (mostly) harmless since it is a symlink to libc.
>>> 
>>> tested on x86_64, i686-darwin, x86_64-linux,
>>> OK for master?
>> OK.
>> Richard.
> 
> Looks also good to me – but for completeness and as background, I also
> want to remark the following.
> 
> (At least as I understand it, I did not dig deeper.)
> 
>> --- a/libgfortran/configure.ac
>> +++ b/libgfortran/configure.ac
>> ...
>> +AC_CHECK_LIBM
> 
> This CHECK_LIBM has a hard-coded list of targets and for some (like
> Darwin) it simply does not set $LIBM.

however, it’s one place to make changes (and, probably, I suppose a table is 
about the
only way to do it, reliably)?

>>> +++ b/libgfortran/Makefile.am
>>> @@ -42,7 +42,7 @@ libgfortran_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS)
>>>  libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' 
>>> $(srcdir)/libtool-version` \
>>> $(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \
>>> $(HWCAP_LDFLAGS) \
>>> -   -lm $(extra_ldflags_libgfortran) \
>>> +   $(LIBM) $(extra_ldflags_libgfortran) \
> 
> I think usage like this one do not actually link '-lm' as
> gcc/config/darwin.h contains:
> 
> #define LINK_SPEC  \
>   ...
>   %:remove-outfile(-lm) \

right, I have tried to be defensive w.r.t unneeded libs in the Darwin specs, 
but as
you note it doesn’t work for libraries added as infiles…

It’s also consistent to use the configure-discovered value, right?

> However, this spec change comes too early for:
>> --- a/libgfortran/libgfortran.spec.in
>> +++ b/libgfortran/libgfortran.spec.in
>> @@ -5,4 +5,4 @@
>>  #
>> 
>>  %rename lib liborig
>> -*lib: @LIBQUADSPEC@ -lm %(libgcc) %(liborig)
>> +*lib: @LIBQUADSPEC@  @LIBM@ %(libgcc) %(liborig)
> NIT: There are two spaces instead of one before @LIBM@.

… thanks.
> 
> Thus, it makes sense to the unconditional '-lm' from the .spec file.

I’ll hold off committing until this evening in case there are other comments.

thanks
Iain

> 
> Tobias
> 
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
> München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
> Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
> München, HRB 106955

[PATCH] libgfortran : Use the libtool macro to determine libm availability.

[Iain Sandoe]

Hi,

A while ago had a report of build failure against a Darwin branch on
the latest OS release.  This was because (temporarily) the symlink
from libm.dylib => libSystem.dylib had been removed/omitted.

libm is not needed on Darwin, and should not be added unconditionally
even if that is (mostly) harmless since it is a symlink to libc.

There could be cases where the addition was not completely harmless
because the presentation of the symlink would cause the symbols exposed
in libSystem to be considered ahead of ones presented in convenience
libraries.

tested on x86_64, i686-darwin, x86_64-linux,
OK for master?
thanks
Iain

libgfortran/ChangeLog:

* Makefile.am: Use configured libm availability.
* Makefile.in: Regenerate.
* configure: Regenerate.
* configure.ac: Use libtool macro to find libm availability.
* libgfortran.spec.in: Use configured libm availability.
---
 libgfortran/Makefile.am |   2 +-
 libgfortran/Makefile.in |   3 +-
 libgfortran/configure   | 142 
 libgfortran/configure.ac|   1 +
 libgfortran/libgfortran.spec.in |   2 +-
 5 files changed, 147 insertions(+), 3 deletions(-)

diff --git a/libgfortran/Makefile.am b/libgfortran/Makefile.am
index 8d104321567..6fc4b465c6e 100644
--- a/libgfortran/Makefile.am
+++ b/libgfortran/Makefile.am
@@ -42,7 +42,7 @@ libgfortran_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS)
 libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' 
$(srcdir)/libtool-version` \
$(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \
$(HWCAP_LDFLAGS) \
-   -lm $(extra_ldflags_libgfortran) \
+   $(LIBM) $(extra_ldflags_libgfortran) \
$(version_arg) -Wc,-shared-libgcc
 libgfortran_la_DEPENDENCIES = $(version_dep) libgfortran.spec $(LIBQUADLIB_DEP)
 
diff --git a/libgfortran/configure.ac b/libgfortran/configure.ac
index 523eb24bca1..513fd80b936 100644
--- a/libgfortran/configure.ac
+++ b/libgfortran/configure.ac
@@ -260,6 +260,7 @@ AC_PROG_INSTALL
 #AC_MSG_NOTICE([== Starting libtool configuration])
 AC_LIBTOOL_DLOPEN
 AM_PROG_LIBTOOL
+AC_CHECK_LIBM
 ACX_LT_HOST_FLAGS
 AC_SUBST(enable_shared)
 AC_SUBST(enable_static)
diff --git a/libgfortran/libgfortran.spec.in b/libgfortran/libgfortran.spec.in
index 95aa3f842a3..b870e78c151 100644
--- a/libgfortran/libgfortran.spec.in
+++ b/libgfortran/libgfortran.spec.in
@@ -5,4 +5,4 @@
 #
 
 %rename lib liborig
-*lib: @LIBQUADSPEC@ -lm %(libgcc) %(liborig)
+*lib: @LIBQUADSPEC@  @LIBM@ %(libgcc) %(liborig)
-- 
2.24.3 (Apple Git-128)

Re: [Patch v3 Fortran] Fix c_float128 and c_float128_complex on targets with 128-bit long double.

[Iain Sandoe via Fortran]

Hi Folks

> On 11 Aug 2021, at 11:55, Segher Boessenkool  
> wrote:

> On Tue, Aug 10, 2021 at 04:46:11PM -0600, Sandra Loosemore wrote:
>> OK.  I used your wording verbatim for the first one.  For the second 
>> one, I'm still pretty confused as I think it is at least theoretically 
>> possible on PowerPC to have a target with 64-bit long double (AIX?) that 
> 
> Some embedded and embedded-like subtargets use 64-bit long double by
> default.  You can also configure this on any Power target (not that it
> will necessarily work ;-) )
> 
> I don't know if any subtarget with default 64-bit long double supports
> Fortran.

I realize that this is not directly relevant to unscrambling the PPC 128bit 
stuff,
but aarch64-apple-darwin2x has only 64b long double and supports gfortran.
(on both the new M1 desktop macOS and embedded iOS)

 - it is not clear to me yet if there will at some point be a transition to a 
128b
   long double for at least the desktop version.

So the permutation definitely exists for at least one non-legacy, non-embedded
platform (and gfortran is very much in demand from the new M1 users).

Iain

>> also supports the __ibm128 format, and it would be wrong to assume that 
>> *any* 128-bit mode that's not long double is IEEE.
> 
> Absolutely.  Modes are not types, and types are not modes.  There are
> 128-bit floating point modes that are not IEEE, there are that are, and
> either can be used for long double, or neither.
> 
> 
> Segher

Fwd: Curious Behavior with Fortran gfortran-10.2-catalina.dmg on macOS Big Sur Version 11.4

[Iain Sandoe]

At a first look, this does not seem to involve anything Darwin-specific 
(particularly, since this is x86_64, so nothing using experimental support).

… perhaps someone here can see what the issue might be?
Iain

> Begin forwarded message:
> 
> From: Lawrence Doctors 
> Subject: Curious Behavior with Fortran gfortran-10.2-catalina.dmg on macOS 
> Big Sur Version 11.4
> Date: 29 July 2021 at 11:58:40 BST
> To: "g...@gcc.gnu.org" 
> Cc: Lawrence Doctors 
> 
> Dear Sir/Madam:
> 
> I would firstly like to thank the folks at GCC for their fine work on 
> developing the Fortran compilers, which I have been using for about 12 years 
> now, on a series of four MacBook Pro computers. In total, I have had over 50 
> years experience using Fortran, this being on a variety of different 
> platforms. I therefore do consider myself as being a very experienced 
> programmer.
> 
> I have recently installed your gfortran-10.2-catalina.dmg on macOS Big Sur 
> Version 11.4 with a 2.4 GHz 8-core Intel Core i9 processor. The computer has 
> 64 GB 2667 MHz DDR4 of memory, with a disk capacity of 8 TB. During my 
> previous experience, when I switched to a new computer on about six or seven 
> occasions, most of my programs (now 553 in number) compiled successfully the 
> first time, but some of the programs required minor modifications. On this 
> occasion, I encountered the following new challenges:
> 
> (1) I see that you now check consistency of the argument types and rank, in 
> CALL statements. Thus, if an argument would normally be an array, but is 
> unused in some CALL statements, my practice was to use a dummy argument with 
> a short name, such as "d". This has worked for over 50 years without trouble. 
> However, you now check for consistency. Obviously this was easy to fix, as I 
> simple declared a dummy array in a DIMENSION statement with the name "d (1)", 
> which solved the problem. On reflection, I would say that this is an 
> improvement, because it forces the programmer to think carefully when writing 
> the CALL statement.
> 
> (2) I encountered a curious failure on compilation with the following 
> statement using integer arithmetic:
>  n= (m + 4)/5
> with the message
> Error: Integer division truncated to constant ‘2’ at (1) 
> [-Werror=integer-division]
> f951: all warnings being treated as errors
> 
> This error only occurs if both (a) the value of  "m" would lead to a 
> truncation (say 7 but not 6), and ALSO if (b) the value of "m" was set in a 
> PARAMETER statement. I can work my way around this difficulty by rewriting 
> the statement as:
>  n= int ((1.0*m + 4)/5)
> but it does seem clumsy.
> 
> (3) The new compiler seems to dislike large fixed DIMENSION statements, such 
> as the following at the beginning of the program unit:
>  parameter (n= 105)
>  dimension a (n)
> 
> The compiler then issues the following message:
>3 |   dimension a (n)
>  | 1
> Error: Array ‘a’ at (1) is larger than limit set by ‘-fmax-stack-var-size=’, 
> moved from stack to static storage. This makes the procedure unsafe when 
> called recursively, or concurrently from multiple threads. Consider using 
> ‘-frecursive’, or increase the ‘-fmax-stack-var-size=’ limit, or change the 
> code to use an ALLOCATABLE array. [-Werror=surprising]
> f951: all warnings being treated as errors
> 
> I agree that the message is clear and I was able to follow the suggestion to 
> use an ALLOCATABLE statement, but I still wonder why you consider the program 
> unsatisfactory in the first place. I can understand (to some degree) why such 
> a large array is frowned upon, because one should economize on the size of 
> arrays. On the other hand, if the use of a large array makes the task of the 
> programmer easier, it should be allowed. Furthermore, an array size of 
> 100 elements or so is very small, considering the size of the RAM and the 
> disk available nowadays.
> 
> I would be pleased if you have the time to respond and I would like to 
> express my appreciation again for the considerable effort that your group has 
> invested in the Fortran compilers over the years.
> 
> Sincerely,
> 
> Larry
> 
> Lawrence J. Doctors
> Emeritus Professor
> Naval Architecture Program
> School of Mechanical and Manufacturing Engineering
> The University of New South Wales
> Sydney, NSW 2052, Australia
> Email: l.doct...@unsw.edu.au
> Telephone: +61-2-9371 4158
> 

Re: Error in installing home brew

[Iain Sandoe via Fortran]

Hi Soumyadip,

this mailing list is primarily for discussion of gfortran development - 

> On 5 Jul 2021, at 08:05, Soumyadip Sahoo via Fortran  
> wrote:
> 
> Here is the error :-
> soumyadipsahoo@soumyadips-MacBook-Pro ~ % sudo apt install—gfortran

— You will need to file problems/errors directly with homebrew,

thanks
Iain

Re: Installation in MAC M1

[Iain Sandoe via Fortran]

Hello Soumyadip,

> On 5 Jul 2021, at 07:18, Soumyadip Sahoo via Fortran  
> wrote:
> 
> HII, I am soumyadip ,from India , I want to install fortran compiler in my 
> Mac Pro M1 processor . Please give me proper way to installation , it will be 
> very helpful. 

GCC (and therefore gfortran) support is experimental on M1, while you could 
build from source, probably the easiest way is to use homebrew (see the 
homebrew website for information).

thanks
Iain

[pushed] libgfortran, configure : Adjust configure to autoconf-2.69

[Iain Sandoe]

Hi

As discussed on irc with Tobias…

(I’ve included the changes to configure in this case since
 they are the only changes in the patch)

bootstrapped on x86-64-linux-gnu
pushed to releases/gcc-9.
thanks
Iain

==


It appears that at some point the configure file has been
regenerated with autoconf-2.69b.  This regenerates it with
autoconf-2.69.

libgfortran/ChangeLog:

* configure: Regenerate.
---
 libgfortran/configure | 28 
 1 file changed, 8 insertions(+), 20 deletions(-)

diff --git a/libgfortran/configure b/libgfortran/configure
index 60867b93d0e..71f48166ec6 100755
--- a/libgfortran/configure
+++ b/libgfortran/configure
@@ -780,7 +780,6 @@ infodir
 docdir
 oldincludedir
 includedir
-runstatedir
 localstatedir
 sharedstatedir
 sysconfdir
@@ -871,7 +870,6 @@ datadir='${datarootdir}'
 sysconfdir='${prefix}/etc'
 sharedstatedir='${prefix}/com'
 localstatedir='${prefix}/var'
-runstatedir='${localstatedir}/run'
 includedir='${prefix}/include'
 oldincludedir='/usr/include'
 docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
@@ -1124,15 +1122,6 @@ do
   | -silent | --silent | --silen | --sile | --sil)
 silent=yes ;;
 
-  -runstatedir | --runstatedir | --runstatedi | --runstated \
-  | --runstate | --runstat | --runsta | --runst | --runs \
-  | --run | --ru | --r)
-ac_prev=runstatedir ;;
-  -runstatedir=* | --runstatedir=* | --runstatedi=* | --runstated=* \
-  | --runstate=* | --runstat=* | --runsta=* | --runst=* | --runs=* \
-  | --run=* | --ru=* | --r=*)
-runstatedir=$ac_optarg ;;
-
   -sbindir | --sbindir | --sbindi | --sbind | --sbin | --sbi | --sb)
 ac_prev=sbindir ;;
   -sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \
@@ -1270,7 +1259,7 @@ fi
 for ac_var in  exec_prefix prefix bindir sbindir libexecdir datarootdir \
datadir sysconfdir sharedstatedir localstatedir includedir \
oldincludedir docdir infodir htmldir dvidir pdfdir psdir \
-   libdir localedir mandir runstatedir
+   libdir localedir mandir
 do
   eval ac_val=\$$ac_var
   # Remove trailing slashes.
@@ -1423,7 +1412,6 @@ Fine tuning of the installation directories:
   --sysconfdir=DIRread-only single-machine data [PREFIX/etc]
   --sharedstatedir=DIRmodifiable architecture-independent data [PREFIX/com]
   --localstatedir=DIR modifiable single-machine data [PREFIX/var]
-  --runstatedir=DIR   modifiable per-process data [LOCALSTATEDIR/run]
   --libdir=DIRobject code libraries [EPREFIX/lib]
   --includedir=DIRC header files [PREFIX/include]
   --oldincludedir=DIR C header files for non-gcc [/usr/include]
@@ -12700,7 +12688,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 12703 "configure"
+#line 12691 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -12806,7 +12794,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 12809 "configure"
+#line 12797 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -16055,7 +16043,7 @@ else
 We can't simply define LARGE_OFF_T to be 9223372036854775807,
 since some C++ compilers masquerading as C compilers
 incorrectly reject 9223372036854775807.  */
-#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))
+#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
   int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
   && LARGE_OFF_T % 2147483647 == 1)
  ? 1 : -1];
@@ -16101,7 +16089,7 @@ else
 We can't simply define LARGE_OFF_T to be 9223372036854775807,
 since some C++ compilers masquerading as C compilers
 incorrectly reject 9223372036854775807.  */
-#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))
+#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
   int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
   && LARGE_OFF_T % 2147483647 == 1)
  ? 1 : -1];
@@ -16125,7 +16113,7 @@ rm -f core conftest.err conftest.$ac_objext 
conftest.$ac_ext
 We can't simply define LARGE_OFF_T to be 9223372036854775807,
 since some C++ compilers masquerading as C compilers
 incorrectly reject 9223372036854775807.  */
-#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))
+#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
   int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
   && LARGE_OFF_T % 2147483647 == 1)
  ? 1 : -1];
@@ -16170,7 +16158,7 @@ else
 We can't simply define LARGE_OFF_T to be 9223372036854775807,
 since some C++ compilers masquerading as C compilers
 incorrectly reject 9223372036854775807.  */
-#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))
+#define 

Re: gfortran static linking under OS X (was: Re: )

[Iain Sandoe via Fortran]

Daniel Feenberg  wrote:




On Fri, 19 Mar 2021, Tobias Burnus wrote:



This seems to be a OS X issue ? and I have no idea about OS X, but I  
found the following:


https://github.com/fxcoudert/gfortran-for-macOS/issues/12


It is certainly an OS X issue.


Actually, it’s a gfortran issue.


There is no problem in Linux, FreeBSD or Windows with the same compiler.
As I understand it, OS X doesn't allow true dynamic linking, but it does  
allow a compiler/linker to produce an executable binary which only  
requires OS supplied libraries at execution time, and which includes all  
the compiler specific libraries.


OSX doesn’t allow a completely  statically-linked user space application.

but it does allow libgfortran and libquadmath to be statically linked - the  
issue is that there’s no spec to deal with it.


Apparently the problem arises because the authors of libquadm don't want  
users to use it in statically linked binaries,


no such issue, there is a static libquadmath.a installed ...



you should be able to work around this without changing the compiler or  
rebuilding it,


find

/path/to/compiler/install/lib/libgfortran.spec

make a copy of that (for backup only)

the file contains something like:

#
# This spec file is read by gfortran when linking.
# It is used to specify the libraries we need to link in, in the right
# order.
#

%rename lib liborig
*lib:  -lquadmath -lm %(libgcc) %(liborig)

change the last line line to :

*lib: %{!static-libgfortran: -lquadmath } %{static-libgfortran:  
libquadmath.a%s} %(libgcc) %(liborig)


===

and try your link again

look at the linked object with “otool -Lv executable” and you should see  
that it only refers to libSystem.dylib.



HTH
Iain

Re: gfortran static linking under OS X (was: Re: )

[Iain Sandoe via Fortran]

Hi Daniel,

Tobias Burnus  wrote:

I am not sure whether it helps, but I want to point out that libm is the  
math library which is on Linux usually GLIBC and I assume on OS X it is  
provided by the OS vendor.


actually part of libSystem  (but, yes, provided by the vendor)


On 19.03.21 21:22, Daniel Feenberg via Fortran wrote:


Is there a way to make a statically linked binary with fortran in OS
X? For much of the past year I have been using:

 gfortran taxsim.for -static-libgfortran -static-libgcc


OK - that should work - modulo the quadmath issue (if present) -
.. but that is probably solvable (with some changes to the link spec).


but since January I only get the error message;

 ld: library not found for -lm.
 collect2: error: ld returned 1 exit status?


lm has not been needed on macOS for a [very] long time (for many releases  
it was simply a convenience symlink to libSystem.dylib, for the sake of OSS  
code that appends ‘-lm’).


There doesn’t seem to be an issue with gcc-11 (master, development) or  
10.2.1 (upcoming 10.3) on macOS 11 - will see if I can fire up a copy of  
gcc6.5 there ...


Will have a think about how to fake the libm too .. not so easy these days.


This is OS X 11,2,3 Big Sur and fortran version 6.3.0.


This is an old version of Fortran on a very new version of macOS, at  
present the first supported GCC version for macOS 11 is the upcoming 10.3  
release (although homebrew no doubt has a preview courtesy of FX).


Is there any way you would be able to update to a newer (and eventually  
supported) Fortran version ?



I need static
linking because my users are not developers and do not have Xcode or
gcc installed.


understood.


This is free software.  I have seen postings from 2015
suggesting that I rename libquadmath.0.dylib, which I did try but
which did not help.

Of course I have no need for lquad precision variables, which I
understand is the source of the problem.


not from what you posted - it’s the absence of “libm.dylib” that results in  
the message.


I realise that this mail contains no solutions - but will try to reproduce  
the issue over the weekend.


cheers
Iain