Re: Compiler for Windows

2023-10-16 Thread Arjen Markus
I use the version of gfortran that can be found at equation.com. There are
several other possibilities, such using the packages found in
MinGW-w64/MSYS2 or Cygwin, but this works fine for me and under plain
Windows (i.e. in an ordinary command window).

Regards,

Arjen

Op ma 16 okt 2023 om 18:08 schreef Tucker, Mark :

> Hi Folks,
>
> Please could you let me know where I can find an installer which would
> install Gfortran onto a Windows machine?  Note that we have Windows Server
> 2019.
>
> Thanks in advance,
>
> Dr MarkTucker  PhD
>
> Manager | Actuarial, Insurance and Banking | Deloitte MCS Limited
> 9 Haymarket Square, Edinburgh, EH3 8RY
>
> marktuc...@deloitte.co.uk | +44 7385 933427
>
>
> IMPORTANT NOTICE
>
> This communication is from Deloitte LLP, a limited liability partnership
> registered in England and Wales with registered number OC303675. Its
> registered office is 1 New Street Square, London EC4A 3HQ, United Kingdom.
> Deloitte LLP is the United Kingdom affiliate of Deloitte NSE LLP, a member
> firm of Deloitte Touche Tohmatsu Limited, a UK private company limited by
> guarantee (“DTTL”). DTTL and each of its member firms are legally separate
> and independent entities. DTTL and Deloitte NSE LLP do not provide services
> to clients. Please see www.deloitte.co.uk/about<
> https://www.deloitte.co.uk/about> to learn more about our global network
> of member firms. For details of our professional regulation please see
> Regulators<
> https://www2.deloitte.com/uk/en/footerlinks1/regulators-and-provision-service-regulations.html
> >.
>
> This communication contains information which is confidential and may also
> be privileged. It is for the exclusive use of the intended recipient(s). If
> you are not the intended recipient(s), please notify
> datasecurityrep...@deloitte.co.uk
> and destroy this message immediately. Email communications cannot be
> guaranteed to be secure or free from error or viruses. All emails sent to
> or from a @deloitte.co.uk email account are securely archived and stored
> by an external supplier within the European Union.
>
> You can understand more about how we collect and use (process) your
> personal information in our Privacy Notice<
> https://www2.deloitte.com/uk/en/legal/privacy.html>.
>
> Deloitte LLP does not accept any liability for use of or reliance on the
> contents of this email by any person save by the intended recipient(s) to
> the extent agreed in a Deloitte LLP engagement contract.
>
> Opinions, conclusions and other information in this email which have not
> been delivered by way of the business of Deloitte LLP are neither given nor
> endorsed by it.
>


Re: Can you send me URL to download gfortran

2024-01-10 Thread Arjen Markus
https://gcc.gnu.org/wiki/GFortranBinaries

Op wo 10 jan 2024 om 11:54 schreef abhay dutta :

>
>


Re: Unusual Behavior in Fortran Compiled Program.

2024-02-29 Thread Arjen Markus
The screenshot did not make it (restrictions probably of the email
service), but in any case:

   - Why store an executable that you created in the installation directory
   of gfortran?
   - If you want to do that, why not simply copy it with your favourite
   file manager or via a copy command?
   - Your question has nothing to do with gfortran as such ;)

Regards,

Arjen

Op wo 28 feb 2024 om 22:16 schreef Stanton Easley :

>  For reasons that make no sense, I am using a Text Editor to save a
> recently created Fortran program in the Binary Folder where the gfortran
> Complier is located; when I look in the folder where the saved file located
> with File explorer, the file isn't present, which isn't what the Text
> editor I'm using (ConText) states that it is. Here are screenshots of what
> I mean:
>
>
>
>
>
>
>
> Thanks, Stanton E. Easley Σταντον Cogito Ergo Sum "Regard without ill
> will, despite an offense". FORGIVE implies that one gives up all claim to
> requital and to resentment or vengeful feelings. Sent from iCloud
>
>
>


Re: WinMain???

2025-07-07 Thread Arjen Markus
I get this error if I compile and link a source file without an actual
program, like:

subroutine x
write(8,*) 'Boe'
end subroutine x

> gfortran x.f90

C:/Users/markus/gcc/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:/Users/markus/gcc/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/lib/../lib/libmingw32.a(lib64_libmingw32_a-crt0_c.o):crt0_c.c:(.text.startup+0x2e):
undefined reference to `WinMain'
collect2.exe: error: ld returned 1 exit status

Does this mimick your case?

Regards,

Arjen

Op ma 7 jul 2025 om 21:20 schreef Ken Woolridge :

> To whom it may concern,
>
> I am attempting to use gfortran.  I used the QuickStart installer to
> install it.  I tried the following:
>
> $ gfortran MOD_GID.F90
>
> and received an error about Winmain missing???
>
> What does this mean and how do I fix it?  (I come from Intel's Fortran
> compiler).\\Thanks,
> Ken
>


Re: [Fortran, Coarray] Call-out to everyone having Fortran coarray-codes available

2025-07-21 Thread Arjen Markus
I have a not-so-trivial, but compact test case for you. I will try it out
with the receipe you gave :).

Regards,

Arjen

Op ma 21 jul 2025 om 13:31 schreef Andre Vehreschild :

> Hi all,
>
> we are looking for people having old and/or modern Fortran codes available
> that use Coarrays more or less intensively. Jerry has build a test branch
> on
> gcc's git, so testing is easier than usual:
>
> > For those who need some guidance to the test branch:
> >
> > $ git clone git://gcc.gnu.org/git/gcc.git
> >
> > $ cd gcc
> > $ git checkout remotes/origin/devel/gfortran-test
> > $ git switch -c gfortran-test
> >
> > Configure and build as usual in a separate directory not the source
> directory.
> >
> > cd .. ; mkdir build ; cd build ; ../gcc/configure --prefix=
> > gmake install
> >
> > Replace  with a writeable full path on your system, e.g.
> > ${HOME}/gcc-16
> >
> > To use the new gcc use:
> >
> > export PATH=${HOME}/gcc-16/bin:$PATH
> >
> > and
> >
> > export LD_LIBRARY_PATH=${HOME}/gcc-16/lib64:$LD_LIBRARY_PATH
> >
> > or
> >
> > export LD_LIBRARY_PATH=${HOME}/gcc-16/lib:$LD_LIBRARY_PATH
> >
> > depending on how your OS names the library directory. Just have a look
> into
> > gcc-16 and use lib64 if it is present, else use lib.
>
> We like everyone to test the new caf_shmem library and report back any
> problems, like "does not compile", "does not run" or "hangs during
> execution".
> If you can narrow down the problem, that would be of great help. If you can
> also share (whether in private or in public) any code, that has issues,
> please
> do not hesitate to contact me or the gfortran mailing list.
>
> To compile your Fortran coarray code add -lcaf_shmem instead of -lcaf_mpi,
> if
> you previously used OpenCoarrays. When using the OpenCoarrays compile
> helper
> `caf` replace it with `gfortran -fcoarray=lib` for comiling and `gfortran
> -fcoarray=lib -lcaf_shmem` for linking.
>
> caf_shmem is multi process shared memory library for using coarrays with
> gfortran from version 16 on. It can provide great speed improvements in
> comparison to MPI-based implementations, but is limited to a single node
> where
> all CPUs can share memory.
>
> Any feedback is greatly appreciated.
>
> Thanks and regards,
> Andre
> --
> Andre Vehreschild * Email: vehre ad gmx dot de
>


Re: Interested in participating in Fortran study to compile very large modules

2022-04-24 Thread Arjen Markus via Fortran
MicroSoft's Fortran compiler is a very old compiler that has not been
maintained in a very long time. The gfortran compiler and the Intel Fortran
oneAPI compiler, both freely available, would easily handle such arrays as
you mention. What system are you running on?

Regards,

Arjen

Op vr 22 apr. 2022 om 22:46 schreef William Carter via Fortran <
fortran@gcc.gnu.org>:

> Hello,
>
> I am an engineer for the nuclear power industry.  As part of my master’s
> thesis I developed a model of a fuel pin using Fortran.  At the time I was
> working with a cheap Microsoft compiler.  It was version 5.1 if I remember
> correctly.  My model does 3D finite differencing and is rather demanding on
> the compiler.  My Microsoft compiler was pretty limiting on the size of the
> modules I could compile.  Typically I was working with a 7x7x7 spatial
> array with a 5 properties at each node.  Everything was in double
> precision.  So it was 7x7x7x5.  I could juggle these around, but I had to
> say within this maximum or the compiler would not work.  I would like to
> work with MUCH larger arrays.  I am thinking 100x100x100x5.  Again in
> double precision. So I need a better compiler.  Can you help?
>
> Regards,
>
> Bill Carter
>
>
> Sent from Mail for Windows
>
>


Re: Interested in participating in Fortran study to compile very large modules

2022-04-25 Thread Arjen Markus via Fortran
There are various solutions to install gfortran (or in general the GCC
compiler suite) on Windows: Cygwin and MinGW-w64/MSYS2 are both
environments that mimick to a certain extent Linux and allow you to manage
all manner of packages, among which the GCC compiler suite. I use both but
I also use the installation from equation.com -
http://www.equation.com/servlet/equation.cmd?fa=fortran. You can get Intel
Fortran oneAPI from Intel -
https://www.intel.com/content/www/us/en/developer/tools/oneapi/fortran-compiler.html#gs.xy9u8f.


General questions about Fortran: the comp.lang.fortran newsgroup or, a bit
more modern, Fortran discourse - https://fortran-lang.discourse.group/

Regards,

Arjen

Op ma 25 apr. 2022 om 12:41 schreef William Carter :

> Hello.  I have a windows 10 home 64 bit operating system.   Thanks for
> getting back to me
>
> Sent from Yahoo Mail on Android
> <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>
>
> On Sun, Apr 24, 2022 at 9:39, Arjen Markus
>  wrote:
> MicroSoft's Fortran compiler is a very old compiler that has not been
> maintained in a very long time. The gfortran compiler and the Intel Fortran
> oneAPI compiler, both freely available, would easily handle such arrays as
> you mention. What system are you running on?
>
> Regards,
>
> Arjen
>
> Op vr 22 apr. 2022 om 22:46 schreef William Carter via Fortran <
> fortran@gcc.gnu.org>:
>
> Hello,
>
> I am an engineer for the nuclear power industry.  As part of my master’s
> thesis I developed a model of a fuel pin using Fortran.  At the time I was
> working with a cheap Microsoft compiler.  It was version 5.1 if I remember
> correctly.  My model does 3D finite differencing and is rather demanding on
> the compiler.  My Microsoft compiler was pretty limiting on the size of the
> modules I could compile.  Typically I was working with a 7x7x7 spatial
> array with a 5 properties at each node.  Everything was in double
> precision.  So it was 7x7x7x5.  I could juggle these around, but I had to
> say within this maximum or the compiler would not work.  I would like to
> work with MUCH larger arrays.  I am thinking 100x100x100x5.  Again in
> double precision. So I need a better compiler.  Can you help?
>
> Regards,
>
> Bill Carter
>
>
> Sent from Mail for Windows
>
>


Re: Fortran compiler

2022-04-25 Thread Arjen Markus via Fortran
An alternative is to use a prebuilt distribution. See my answer to William
Carter.

Regards,

Arjen

Op di 26 apr. 2022 om 03:57 schreef Elliot Cramer <
elliottcra...@bellsouth.net>:

> Windows 10; how can we do this?
> Elliot
>
> On 4/23/2022 10:00 PM, Jerry D wrote:
> > Elliot,
> >
> > Let me know what system you want the compiler to run on?
> >
> > Linux, Windows, PowerPC?
> >
> > I can guide you through installing on some of these.
> >
> > Usually we build it from source. However, many linux distributions
> > have packages you can install easily.
> >
> > Cheers,
> >
> > Jerry
> >
> > On 4/23/22 9:31 AM, Elliot Cramer wrote:
> >> A few years ago I started converting a large old Fortran program
> >> which I had running on an IBM 7040 and then on a 360. I have a
> >> copy of Lahey Fortran and ran into a compiler bug and gave up on
> >> it. How can I download your compiler and get documentation. I
> >> don't understand what I've read on the internetThanksElliot
> >>
> >> Sent from AT&T Yahoo Mail on Android
> >
>
> --
>
> Elliot M. Cramer
> PO 428
> Chapel Hill, NC 27514
>
> 919-942-2503
>
> Professor Emeritus
> Department of Psychology
> University of North Carolina at Chapel Hill
>
> ecra...@alum.mit.edu
>
> Websites
> http://www.ourpaws.info/cramer
> http://www.friendsofocas.org
>
>


Re: is there a way to find out gfortran version and/or options from a given binary?

2022-06-01 Thread Arjen Markus via Fortran
Are you perhaps looking for the compiler_version() and compiler_options()
functions? I use them like this, they were defined in Fortran 2008 if I am
not mistaken:


WRITE( lurep, '(a)' ) 'Report of simulation'
WRITE( lurep, '(a)' ) ''
WRITE( lurep, '(a)' ) 'Compiler version: ',
compiler_version()
WRITE( lurep, '(a)' ) 'Compiler options: ',
compiler_options()

Regards,

Arjen

Op wo 1 jun. 2022 om 10:42 schreef Kay Diederichs <
kay.diederi...@uni-konstanz.de>:

> Hi,
>
> is there any gfortran option and/or version information available from/in
> a binary? Maybe accessible with objdump or strings?
>
> For ifort, we use the -sox option ("This option tells the compiler to save
> the compilation options and version number in the executable file. ...").
> This enables e.g.
> strings /path/to/binary | grep Intel
>
> Or is there a gfortran option that makes this accessible in a binary?
>
> Thanks,
> Kay
>
>
>


Re: is there a way to find out gfortran version and/or options from a given binary?

2022-06-01 Thread Arjen Markus via Fortran
I thought you might get this information by using these two functions in a
parameter definition, but that is not allowed, alas.

Regards,

Arjen


Op wo 1 jun. 2022 om 11:50 schreef Andre Vehreschild via Fortran <
fortran@gcc.gnu.org>:

> Hi Kay,
>
> did you try:
>
> $ strings coarray_collectives_18 | grep  GNU
> GCC: (GNU) 11.2.1 20211203 (Red Hat 11.2.1-7)
> GCC: (GNU) 12.0.1 20220214 (experimental)
> GNU Fortran2008 12.0.1 20220214 (experimental) -mtune=generic
> -march=x86-64 -g
> -fcoarray=lib -fintrinsic-modules-path
>
> /home/vehre/Projekte/gcc/gfortran/lib/gcc/x86_64-pc-linux-gnu/12.0.1/finclude
> -fpre-include=/usr/include/finclude/math-vector-fortran.h GNU C11 12.0.1
> 20220214 (experimental) -mshstk -mtune=generic -march=x86-64 -g -O2 -O0
> -std=gnu11 -fcf-protection=full -fcx-fortran-rules -ffunction-sections
> -fdata-sections __GNU_EH_FRAME_HDR
>
> or
>
> strings coarray_collectives_18 | grep GCC
>
> ...
> ?
>
> Both give me some output (albeit more than I desire) for an executable
> compiled
> with gfortran. But presumably, I had activated debug. I don't know, if
> optimized builds will have it, too.
>
> Regards,
> Andre
>
> On Wed, 1 Jun 2022 11:41:41 +0200
> Kay Diederichs  wrote:
>
> > Hi Arjen,
> >
> > thanks for your answer. I do know about these functions, and use them in
> my
> > own programs if appropriate. However, programs distributed to others for
> > production use should not output this because it confuses users (as does
> > "Note: The following floating-point exceptions are signalling:
> > IEEE_INVALID_FLAG" which I need to switch off with -ffpe-summary=none).
> >
> > So I really am looking for strings or other type of info in the binary.
> >
> > Best wishes,
> > Kay
> >
> > On 6/1/22 11:30, Arjen Markus wrote:
> > > Are you perhaps looking for the compiler_version() and
> compiler_options()
> > > functions? I use them like this, they were defined in Fortran 2008 if
> I am
> > > not mistaken:
> > >
> > >
> > >  WRITE( lurep, '(a)' ) 'Report of simulation'
> > >  WRITE( lurep, '(a)' ) ''
> > >  WRITE( lurep, '(a)' ) 'Compiler version: ',
> > > compiler_version() WRITE( lurep, '(a)' ) 'Compiler options: ',
> > > compiler_options()
> > >
> > > Regards,
> > >
> > > Arjen
> > >
> > > Op wo 1 jun. 2022 om 10:42 schreef Kay Diederichs
> > > mailto:kay.diederi...@uni-konstanz.de
> >>:
> > >
> > > Hi,
> > >
> > > is there any gfortran option and/or version information available
> > > from/in a binary? Maybe accessible with objdump or strings?
> > >
> > > For ifort, we use the -sox option ("This option tells the compiler
> to
> > > save the compilation options and version number in the executable file.
> > > ..."). This enables e.g. strings /path/to/binary | grep Intel
> > >
> > > Or is there a gfortran option that makes this accessible in a
> binary?
> > >
> > > Thanks,
> > > Kay
> > >
> > >
> >
>
>
> --
> Andre Vehreschild * Email: vehre ad gmx dot de
>


Re: is there a way to find out gfortran version and/or options from a given binary?

2022-06-01 Thread Arjen Markus via Fortran
Well, if you call these functions in the code, the text is available in the
executable file. I used:

! staticv.f90 --
! Static information about the compiler? Not via parameters
!
program staticv
use iso_fortran_env

implicit none
character(len=200) :: c, d

c = compiler_version()
d = compiler_options()
write(*,*) c(1:1), d(1:)1
end program staticv

to force the text strings to appear. I think a long character string is
required.

Regards,

Arjen

Op wo 1 jun. 2022 om 11:53 schreef Arjen Markus :

> I thought you might get this information by using these two functions in a
> parameter definition, but that is not allowed, alas.
>
> Regards,
>
> Arjen
>
>
> Op wo 1 jun. 2022 om 11:50 schreef Andre Vehreschild via Fortran <
> fortran@gcc.gnu.org>:
>
>> Hi Kay,
>>
>> did you try:
>>
>> $ strings coarray_collectives_18 | grep  GNU
>> GCC: (GNU) 11.2.1 20211203 (Red Hat 11.2.1-7)
>> GCC: (GNU) 12.0.1 20220214 (experimental)
>> GNU Fortran2008 12.0.1 20220214 (experimental) -mtune=generic
>> -march=x86-64 -g
>> -fcoarray=lib -fintrinsic-modules-path
>>
>> /home/vehre/Projekte/gcc/gfortran/lib/gcc/x86_64-pc-linux-gnu/12.0.1/finclude
>> -fpre-include=/usr/include/finclude/math-vector-fortran.h GNU C11 12.0.1
>> 20220214 (experimental) -mshstk -mtune=generic -march=x86-64 -g -O2 -O0
>> -std=gnu11 -fcf-protection=full -fcx-fortran-rules -ffunction-sections
>> -fdata-sections __GNU_EH_FRAME_HDR
>>
>> or
>>
>> strings coarray_collectives_18 | grep GCC
>>
>> ...
>> ?
>>
>> Both give me some output (albeit more than I desire) for an executable
>> compiled
>> with gfortran. But presumably, I had activated debug. I don't know, if
>> optimized builds will have it, too.
>>
>> Regards,
>> Andre
>>
>> On Wed, 1 Jun 2022 11:41:41 +0200
>> Kay Diederichs  wrote:
>>
>> > Hi Arjen,
>> >
>> > thanks for your answer. I do know about these functions, and use them
>> in my
>> > own programs if appropriate. However, programs distributed to others for
>> > production use should not output this because it confuses users (as does
>> > "Note: The following floating-point exceptions are signalling:
>> > IEEE_INVALID_FLAG" which I need to switch off with -ffpe-summary=none).
>> >
>> > So I really am looking for strings or other type of info in the binary.
>> >
>> > Best wishes,
>> > Kay
>> >
>> > On 6/1/22 11:30, Arjen Markus wrote:
>> > > Are you perhaps looking for the compiler_version() and
>> compiler_options()
>> > > functions? I use them like this, they were defined in Fortran 2008 if
>> I am
>> > > not mistaken:
>> > >
>> > >
>> > >  WRITE( lurep, '(a)' ) 'Report of simulation'
>> > >  WRITE( lurep, '(a)' ) ''
>> > >  WRITE( lurep, '(a)' ) 'Compiler version: ',
>> > > compiler_version() WRITE( lurep, '(a)' ) 'Compiler options: ',
>> > > compiler_options()
>> > >
>> > > Regards,
>> > >
>> > > Arjen
>> > >
>> > > Op wo 1 jun. 2022 om 10:42 schreef Kay Diederichs
>> > > > kay.diederi...@uni-konstanz.de>>:
>> > >
>> > > Hi,
>> > >
>> > > is there any gfortran option and/or version information available
>> > > from/in a binary? Maybe accessible with objdump or strings?
>> > >
>> > > For ifort, we use the -sox option ("This option tells the
>> compiler to
>> > > save the compilation options and version number in the executable
>> file.
>> > > ..."). This enables e.g. strings /path/to/binary | grep Intel
>> > >
>> > > Or is there a gfortran option that makes this accessible in a
>> binary?
>> > >
>> > > Thanks,
>> > > Kay
>> > >
>> > >
>> >
>>
>>
>> --
>> Andre Vehreschild * Email: vehre ad gmx dot de
>>
>


Re: is there a way to find out gfortran version and/or options from a given binary?

2022-06-01 Thread Arjen Markus via Fortran
Hm, I ran it without any options - would that be equivalent to -g then? A
rather awkward workaround might be to compile one source file containing
this code with -g, but that is pushing things to the limit.

Regards,

Arjen

Op wo 1 jun. 2022 om 12:16 schreef Kay Diederichs <
kay.diederi...@uni-konstanz.de>:

> I tried your suggestion below, but it does not store the options unless
> the -g option is used.
>
> If -g is used, the executable _always_ has version and option info (no
> extra code invoking compiler_version() and compiler_options() is
> needed). Just use strings  | grep GNU .
> If -g is not used, no option info is in the executable.
>
> Best wishes,
> Kay
>
> On 01.06.22 12:00, Arjen Markus wrote:
> > staticv.f90 --
> > ! Static information about the compiler? Not via parameters
> > !
> > program staticv
> >  use iso_fortran_env
> >
> >  implicit none
> >  character(len=200) :: c, d
> >
> >  c = compiler_version()
> >  d = compiler_options()
> >  write(*,*) c(1:1), d(1:)1
> > end program staticv
> >
>
> --
> Kay Diederichshttp://strucbio.biologie.uni-konstanz.de
> email: kay.diederi...@uni-konstanz.de Tel +49 7531 88 4049
> Fachbereich Biologie, Universität Konstanz, Box M647, D-78457 Konstanz
>
> This e-mail is digitally signed. If your e-mail client does not have the
> necessary capabilities, just ignore the attached signature "smime.p7s".
>


Re: is there a way to find out gfortran version and/or options from a given binary?

2022-06-01 Thread Arjen Markus via Fortran
Are you sure that -g is the trigger? It may very well be that you need to
make sure that the optimiser does not eliminate the variable that holds the
identification. That is why I write the first character of these strings,
to make sure that the variables are retained. That could be achieved in all
manner of ways to fool the optimiser. Note that with -O2 and the program I
posted I still get the strings.

Regards,

Arjen

Op wo 1 jun. 2022 om 13:36 schreef Arjen Markus :

> Hm, I ran it without any options - would that be equivalent to -g then? A
> rather awkward workaround might be to compile one source file containing
> this code with -g, but that is pushing things to the limit.
>
> Regards,
>
> Arjen
>
> Op wo 1 jun. 2022 om 12:16 schreef Kay Diederichs <
> kay.diederi...@uni-konstanz.de>:
>
>> I tried your suggestion below, but it does not store the options unless
>> the -g option is used.
>>
>> If -g is used, the executable _always_ has version and option info (no
>> extra code invoking compiler_version() and compiler_options() is
>> needed). Just use strings  | grep GNU .
>> If -g is not used, no option info is in the executable.
>>
>> Best wishes,
>> Kay
>>
>> On 01.06.22 12:00, Arjen Markus wrote:
>> > staticv.f90 --
>> > ! Static information about the compiler? Not via parameters
>> > !
>> > program staticv
>> >  use iso_fortran_env
>> >
>> >  implicit none
>> >  character(len=200) :: c, d
>> >
>> >  c = compiler_version()
>> >  d = compiler_options()
>> >  write(*,*) c(1:1), d(1:)1
>> > end program staticv
>> >
>>
>> --
>> Kay Diederichshttp://strucbio.biologie.uni-konstanz.de
>> email: kay.diederi...@uni-konstanz.de Tel +49 7531 88 4049
>> Fachbereich Biologie, Universität Konstanz, Box M647, D-78457 Konstanz
>>
>> This e-mail is digitally signed. If your e-mail client does not have the
>> necessary capabilities, just ignore the attached signature "smime.p7s".
>>
>


Re: is there a way to find out gfortran version and/or options from a given binary?

2022-06-01 Thread Arjen Markus via Fortran
Hm, I was using a file viewer, not strings to examine the file and I looked
for the text "GCC". That must be the difference. Indeed, strings does not
show that string nor any string containing "GCC"

Here is a small part of the text in the file (compiled without -O2, as with
it some characters appear mangled):

  GCC version 10.2.0-mtune=generic -march=x86-64staticv.f90   D  ÿ
Trace/breakpoint trap SIGTRAP Terminal quit signal

Regards,

Arjen


Re: is there a way to find out gfortran version and/or options from a given binary?

2022-06-02 Thread Arjen Markus via Fortran
Do you know why the strings command does not show the identification
string,
which clearly present in the executable file, even though it should examine
the
entire file (the --all option does not alter the output)?

Regards,

Arjen

Op vr 3 jun. 2022 om 07:22 schreef Janne Blomqvist <
blomqvist.ja...@gmail.com>:

> 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?

2022-06-03 Thread Arjen Markus via Fortran
Hi Kay,

(you forgot to reply to everybody ;))

I am using a Windows version of gfortran and strings. I use a file viewer
that comes with the Total Commander file manager. So, it may be something
specific to that version of strings.

Regards,

Arjen

Op vr 3 jun. 2022 om 09:25 schreef Kay Diederichs <
kay.diederi...@uni-konstanz.de>:

> On 6/3/22 08:47, Arjen Markus via Fortran wrote:
> > Do you know why the strings command does not show the identification
> > string,
> > which clearly present in the executable file, even though it should
> examine
> > the
> > entire file (the --all option does not alter the output)?
> >
> > Regards,
> >
> > Arjen
> >
> > Op vr 3 jun. 2022 om 07:22 schreef Janne Blomqvist <
> > blomqvist.ja...@gmail.com>:
> >
> >> 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
> >>
> >
>
> Arjen,
>
> "egrep"-ing for 'GNU|GCC' in the "strings" output shows more than
> "grep"-ing for GNU, which is what I tried first.
> But I don't think you see even more with a "fileviewer" (which do you
> refer to?
> I tried the "bless" hex editor and "okteta"; they don't show more than
> "strings").
>
> @Janne thanks for pointing out that -g does not make the code slower.
> Is there an option that prevents the sourcecode to be included when -g is
> used?
>
> thanks,
> Kay
>


Re: Fortran issue

2022-08-27 Thread Arjen Markus via Fortran
The backslash is probably an extension to keep the cursor on the same. You
can achieve that by using advance='no' in the write statement.
Note that some compilers may require a flush statement to actually make the
text visible.

Regards,

Arjen

Op za 27 aug. 2022 15:19 schreef Lars G Golmen :

>
> Hello
> I have an old, small Fortran 4 program doing some statistics on time
> series: Aandstat.
> The .EXE file ran on 32 bits PC with like XP-OS, but not anymore on 64
> bits.
>
> A colleague on mine tried compile the attached code in gfortran.
> The gfortran compilation gave a couple of error messages, gfortran does
> not seem to accept the “\” sign.
> Is there a valid replacement for that sign (command) we can use, to get
> quickly forward?
>
> Sorry for any inconvenience.
>
> Best regards
> Lars Golmen
>
> 
> Lars G. Golmen, oceanographer, senior research scientist, Adj. professor
> NIVA, Norwegian Institute for Water Research - Bergen and Runde branch,
> Tel: (47) 4789 0957, Address: c/o Runde miljøsenter, N-6096 Runde, Norway
> Tokyo University of Marine Science and Technology, 4-5-7 Konan, Minato,
> Tokyo.
> http://www.niva.no
> http://www.rundecentre.no
> https://www.kaiyodai.ac.jp/english/
>  << Fil: AANDSTAT.FOR >>
> _
> Frå: Shamil Iakubov 
> Send: torsdag 25. august 2022 20:35
> Til: Lars G Golmen 
> Emne: RE: Fortran
>
>
> Hi Lars!
>
> Fortran is exciting, in fact it has evolved significantly during the last
> few years and it fits modern standards nowadays, except for the building
> system probably. Also, some of the most in demand machine learning
> libraries still use Fortran code.
>
> Regarding your problem. I have tried to compile it with gfortran, it is a
> free open source compiler. It throws some errors:
>
> ```
> (base) lmsh@l5:~/src/lars_fortran$ gfortran AANDSTAT.FOR -std=legacy -o
> program
> AANDSTAT.FOR:27:22:
>
>27 |  10  WRITE(*,'(//,A\)')' OPPGI FILNAMN FOR INPUT DATA-->'
>   |  1
> Error: Unexpected element ‘\’ in format string at (1)
> AANDSTAT.FOR:30:17:
>
>30 |WRITE(*,'(A\)')' OPPGI FILNAMN FOR RESULTAT (NY FIL)-->'
>   | 1
> Error: Unexpected element ‘\’ in format string at (1)
> (base) lmsh@l5:~/src/lars_fortran$
>
> Some googling proved that the code is compiler specific. It can be
> compiled with the Intel compiler (ifort). Sadly it is not free now. I
> believe NIVA has VisualStudio license with ifort so your files can be
> compiled with visual studio solutions building system, but currently I
> don’t have access to these facilities.
>
> Cheers,
> Shamil
>
> _
> From: Lars G Golmen mailto:lars.gol...@niva.no>>
> Sent: torsdag 25. august 2022 13:29
> To: Shamil Iakubov mailto:shamil.iaku...@niva.no>>
> Subject: Fortran
>
>
> Hei Shamil
> Nice to know you do Fortran.
> I worked with Fortran many years ago, Fortran 4.. on old computers. My
> compliler no longer works.
> Is it possible for you to recompile some source code I have, to work on
> present OS?
> I attach an example, just one program, no subroutines to map here. To make
> some special statistics on a equidistant time series. Input file name to be
> provided, 2 columns w ascii data.
> OK?
> (I have several others..🙂)
>
> Helsing
> Lars G
>  << File: AANDSTAT.FOR >>
>
>


Re: Moving to submodule

2022-12-16 Thread Arjen Markus via Fortran
Hi Patrick,

you might have a look at fpt - http://www.simconglobal.com/. Not sure if it
will do what you want exactly, but you never know and the people behind it
are well prepared to help out.

Regards,

Arjen

Op vr 16 dec. 2022 om 15:01 schreef Patrick Begou via Fortran <
fortran@gcc.gnu.org>:

> Hi,
>
> my goal is to move a large fortran90 modular code to fortran 2008 using
> the submodule concept. As I have nearly 400 files to modify I would like
> to know if a tool exist to automatically extract variables from
> fortran90 modules and build interfaces for subroutines and functions ?
>
> Before trying to implement this by myself...
>
> Thanks
>
> Patrick
>
>


Re: F77 indexed file support

2023-03-07 Thread Arjen Markus via Fortran
I have never worked much with VAXes, but I do remember that VAX used a file
system where you made a new version of a file and the older versions were
automatically kept. I guess that is the purpose of the INDEXED
organisation. It is not so much a limitation of gfortran that it does not
support this, but a consequence of the operating system's completely
different view on files and file management.

Regards,

Arjen

Op di 7 mrt 2023 om 23:58 schreef Thomas Koenig via Fortran <
fortran@gcc.gnu.org>:

> Hi Roland,
>
> >   210  OPEN (UNIT=K_DRAW_CHAN,
> >   1FILE=DRAWING_DATA,
> >   2STATUS='OLD',
> >   3ORGANIZATION='INDEXED',
>
> I'd never heard of that one up to now.
>
> >   4ACCESS='KEYED',
> >   5RECORDTYPE='FIXED',
> >   6FORM='UNFORMATTED',
> >   7RECL=K_DRAWING_RECORD_SIZE/4,
> >   8CARRIAGECONTROL='FORTRAN',
> >   9KEY=(1:8:CHARACTER),
> >   1DISP='KEEP',
> >   2IOSTAT=L_DRAW_ERR,
> >   3ERR=999)
> >
> > The ORGANIZATION='INDEXED' is key.
> >
> > GnuCOBOL
> >
> > https://gnucobol.sourceforge.io/
> >
> > uses the BerkleyDB (sp?) library so the standard COBOL indexed file
> > support from the big computers can at least be mimicked.
> >
> > I'm searching everywhere and I cannot find Gnu Fortran (any flavor)
> > having an ORGANIZATION clause in the OPEN().
>
> ORGANIZATION is not an extension that gfortran supports.
> ifort, which traces its lineage back to VMS Fortran, supports
> ORGANIZATION, but not 'INDEXED', according to
>
>
> https://www.intel.com/content/www/us/en/develop/documentation/fortran-compiler-oneapi-dev-guide-and-reference/top/language-reference/file-operation-i-o-statements/open-statement-specifiers/open-organization-specifier.html
>
> This is likely a Fortran interface to a VMS speciality; the older
> operating systems had stuff like that.  UNIX did away with all
> the record-orientation (I also remember VSAM and ISAM data sets
> on old IBM mainframes) and UNIX and derivatives, and Windows, now
> just offers the "stream of bytes" model.
>
> So, if you need the functionality, you will have to implement it
> yourself, possibly via a database.
>
> Best regards
>
> Thomas
>


Re: F77 indexed file support

2023-03-08 Thread Arjen Markus via Fortran
Well, that is indeed something completely different.My main frame of
reference (pun not intentional) of that era was our IBM mini, I am not
quite sure of the type number, 3270? It had a very specific record
structure for unformatted files. Normally that was almost completely
hidden, except in the job control, but when we started exchanging data
files with the personal computers that were then coming out, I could write
programs that did the necessary conversions. Jolly good fun. My department
did not use VAXes, other departments did.

So, in your case these files contain data identifiable via some index. Hm,
today you would do that via some library instead of via some builtin
language feature, at least when using Fortran, C, C++, ...

Regards,

Arjen

Op wo 8 mrt 2023 om 14:31 schreef Roland Hughes via Fortran <
fortran@gcc.gnu.org>:

> Thank you!
>
>
> On 3/8/2023 1:57 AM, Bernhard Reutner-Fischer wrote:
> > On 7 March 2023 23:18:58 CET, Roland Hughes via Fortran <
> fortran@gcc.gnu.org> wrote:
> >
> > [ snip namelist IO ]
> >
> >> Btw, is there a "search" utility for the archives or do I have to pull
> down all of the zip files, unzip into directory, and grep to look for stuff
> like this? I'm guessing it has come up before.
> > Indeed we have
> > https://inbox.sourceware.org/fortran/
> >
> > along the traditional pipermail ml interface.
> >
> > thanks,
>
> --
> Roland Hughes, President
> Logikal Solutions
> (630)-205-1593  (cell)
> http://www.theminimumyouneedtoknow.com
> http://www.infiniteexposure.net
> http://www.johnsmith-book.com
>
>


Re: F77 indexed file support

2023-03-09 Thread Arjen Markus via Fortran
Right, 3270 was the terminal. Wonderful beasts :).

Anyway, this reminded me of an experiment I did a couple of years ago with
wrapping the BerkeleyDB library in Fortran. I never had much use for it,
but it works for small enough value of "work".

But this is diverting a lot from the purpose of this mailing list.

Regards,

Arjen

Op wo 8 mrt 2023 om 16:21 schreef Roland Hughes :

> That would have been a 360/370 IBM Mini. The 3270 was the "smart" terminal.
>
>
> https://imgs.search.brave.com/9CW5yhzliePl3PmZJJad0-GoiArzOyOIKkKfa0cntW8/rs:fit:640:540:1/g:ce/aHR0cHM6Ly9pLnBp/bmltZy5jb20vb3Jp/Z2luYWxzLzRlL2Nk/L2JlLzRlY2RiZTBl/YjQ0YmFlNGUzOTQ4/YjVlNDk2MWY1OWMx/LmpwZw
>
> Yes, I use database libraries all the time with C/C++. Given Gnu COBOL had
> utilized the Berkley DB so they could provide full (or at least nearly
> complete) language syntax I had hoped Gnu Fortran did the same.
>
> C/C++ never provided any indexed file or "record" level support. FORTRAN
> always did, so I had hopes.
>
> Thanks,
>
> Roland
> On 3/8/23 08:30, Arjen Markus wrote:
>
> Well, that is indeed something completely different.My main frame of
> reference (pun not intentional) of that era was our IBM mini, I am not
> quite sure of the type number, 3270? It had a very specific record
> structure for unformatted files. Normally that was almost completely
> hidden, except in the job control, but when we started exchanging data
> files with the personal computers that were then coming out, I could write
> programs that did the necessary conversions. Jolly good fun. My department
> did not use VAXes, other departments did.
>
> So, in your case these files contain data identifiable via some index. Hm,
> today you would do that via some library instead of via some builtin
> language feature, at least when using Fortran, C, C++, ...
>
> Regards,
>
> Arjen
>
> Op wo 8 mrt 2023 om 14:31 schreef Roland Hughes via Fortran <
> fortran@gcc.gnu.org>:
>
>> Thank you!
>>
>>
>> On 3/8/2023 1:57 AM, Bernhard Reutner-Fischer wrote:
>> > On 7 March 2023 23:18:58 CET, Roland Hughes via Fortran <
>> fortran@gcc.gnu.org> wrote:
>> >
>> > [ snip namelist IO ]
>> >
>> >> Btw, is there a "search" utility for the archives or do I have to pull
>> down all of the zip files, unzip into directory, and grep to look for stuff
>> like this? I'm guessing it has come up before.
>> > Indeed we have
>> > https://inbox.sourceware.org/fortran/
>> >
>> > along the traditional pipermail ml interface.
>> >
>> > thanks,
>>
>> --
>> Roland Hughes, President
>> Logikal Solutions
>> (630)-205-1593  (cell)
>> http://www.theminimumyouneedtoknow.com
>> http://www.infiniteexposure.net
>> http://www.johnsmith-book.com
>>
>> --
> Roland Hughes, President
> Logikal Solutions
> (630)-205-1593
> http://www.theminimumyouneedtoknow.comhttp://www.infiniteexposure.nethttp://www.johnsmith-book.comhttp://www.logikalblog.comhttp://www.interestingauthors.com/blog
>
>


Re: Dear Fortran team,

2023-05-25 Thread Arjen Markus via Fortran
As you do not specify what kind of system you have, such advice can only be
very general. But with a decent search engine it should not be too hard to
find a site that allows you to download the software specifically for your
system.

Regards,

Arjen

Op do 25 mei 2023 om 13:47 schreef [Student] Auwal Muhammad via Fortran <
fortran@gcc.gnu.org>:

> pls may you kindly furnish me with the detail installation and
> configuration process of fortran in my system.
>
> Auwal Muhammad
>


Re: Can't get the horse out of the gate

2023-07-10 Thread Arjen Markus via Fortran
You might be better asking a question on comp.lang.fortran newsgroup or the
Fortran discourse site (https://fortran-lang.discourse.group/). This
mailing list is specifically for the gfortran compiler, not user questions.

Also, I might add, the title and the contents of your message may be
understandable for someone well-versed in your cultural context, but to me
as a mainland European it looked in first instance like spam.

I suggest you formulate more elaborately what you are trying to do and what
you expect to happen. I am not being cynical here, justtrying to help you
to get people interested in helping you out.

Regards,

Arjen

Op di 11 jul 2023 om 07:28 schreef Guy Daniels III via Fortran <
fortran@gcc.gnu.org>:

> Hi and thx in adv. Started this tut
> , have TDM-GCC 10.3.0-2 and
> Notepad++, am trying diff extensions (.f90, .f03, etc) but nothing giving.
> What am I missing?
>
> --
>
>
> *"Make the best of your time while you're here"*
>


Re: spurious out-of-bounds warning message

2023-07-13 Thread Arjen Markus via Fortran
I would say it is indeed very hard to capture all false positves.

Regards,

Arjen

Op wo 12 jul 2023 om 17:05 schreef Vivek Rao via Fortran <
fortran@gcc.gnu.org>:

> For the code
>
> program main
> implicit none
> integer, parameter :: n = 10
> real :: x(n), dx(n)
> integer :: i
> call random_number(x)
> do i=1,n
>if (i > 1) then
>   dx(i) = x(i) - x(i-1)
>else
>   dx(i) = 0.0
>end if
> end do
> print*,dx
> end program main
>
> gfortran -Wextra says for GNU Fortran (GCC) 13.0.0 20221218
>
> xspur.f90:9:23:
>
>
> 7 | do i=1,n
>   |2
> 8 |if (i > 1) then
> 9 |   dx(i) = x(i) - x(i-1)
>   |   1
> Warning: Array reference at (1) out of bounds (0 < 1) in loop beginning at
> (2) [-Wdo-subscript]
>
> but the code is fine because of the if guard. Ideally such spurious
> messages would be suppressed, but I don't know if this is too hard.
>
> Vivek Rao
>


Re:

2023-08-23 Thread Arjen Markus via Fortran
Hello,

gfortran is certainly an option, I use an installation from equation.com,
but there are other possibilities as well. The best solution does depend a
bit on your actual requirements.

Regards,

Arjen

Op di 22 aug 2023 om 15:06 schreef Mamadou Diop via Fortran <
fortran@gcc.gnu.org>:

> I am a retired scientist and have some fortan programs and looking for an
> open source fortran compiler.
> Regards ?
>
> Mamadou Diop
>
> Envoyé à partir de Courrier
> pour Windows
>
>


Re: Requesting Inputs : Anonymous Survey for Developer Tools

2021-06-02 Thread Arjen Markus via Fortran
I am not sure that your diagnosis is correct: the survey was announcement
by Stack Overflow. See https:// stackoverflow.blog/ 2021/ 05/
25/the-2021-developer-survey-is-now-open/
?utm_source=Iterable&utm_medium=email&utm_campaign=the_overflow_newsletter
(to avoid an embedded link just in case, I have added spaces after the
slashes)

Op wo 2 jun. 2021 om 15:08 schreef Paul Koning via Fortran <
fortran@gcc.gnu.org>:

> That sure looks like a phishing attack.  The .gle link is a major red
> flag.  I'm not going there and I would recommend everyone else avoid it too.
>
> paul
>
> > On Jun 1, 2021, at 11:02 PM, Dev Survey via Fortran 
> wrote:
> >
> > Dear All,
> > I have attached a survey form so that I can better understand what kind
> of tools developers like to have to facilitate their workflows on a day to
> day basis.
> > No login required or identifiable information collection and is a
> completely anonymous survey, and takes no more than 5-10 minutes.
> > Developer Tools Survey
> >
> > To confirm this is not spam, please check via :
> https://www.phishtank.com/
> > Shortened URL : https://forms.gle/vTrFNUhfFcqznSRr9
> > Full URL :
> https://docs.google.com/forms/d/e/1FAIpQLSePzAwRUsem1wunWWtXr_FoX2viruIfoyb744zGufX5jBxH8A/viewform?usp=sf_link
> > Thanks,Fellow Developer
>
>


Re: Error in installing home brew

2021-07-05 Thread Arjen Markus via Fortran
An alternative is to post your questions on either comp.lang.fortran or
Fortran Discourse (https://fortran-lang.discourse.group/).

Regards,

Arjen

Op ma 5 jul. 2021 om 09:15 schreef Iain Sandoe via Fortran <
fortran@gcc.gnu.org>:

> Hi Soumyadip,
>
> this mailing list is primarily for discussion of gfortran development -
>
> > On 5 Jul 2021, at 08:05, Soumyadip Sahoo via Fortran <
> fortran@gcc.gnu.org> 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: F2018 C937

2021-08-18 Thread Arjen Markus via Fortran
Hi Steve,

I am willing to take up this challenge ;), as well as the patch for C949.
It would be my next attempt to get acquainted with the source code (a first
step hopefully to actively contribute).

Regards,

Arjen

Op di 17 aug. 2021 om 21:02 schreef Steve Kargl via Fortran <
fortran@gcc.gnu.org>:

> For those that might care, I draw your attention to
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101951
>
> Good opportunity for a lurker to step forward and
> become a gfortran committer.  Otherwise, this patch
> will fester in bugzilla the dozen or so other patches
> I've attached to PRs.
>
> --
> Steve
>


Re: F2018 C937

2021-08-19 Thread Arjen Markus via Fortran
I have applied the patches locally (take care to restore the tabs ;)).
Should I now commit these changes or is there a more formal procedure
involved?

Regards,

Arjen

Op do 19 aug. 2021 om 08:59 schreef Arjen Markus :

> Hi Steve,
>
> I am willing to take up this challenge ;), as well as the patch for C949.
> It would be my next attempt to get acquainted with the source code (a first
> step hopefully to actively contribute).
>
> Regards,
>
> Arjen
>
> Op di 17 aug. 2021 om 21:02 schreef Steve Kargl via Fortran <
> fortran@gcc.gnu.org>:
>
>> For those that might care, I draw your attention to
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101951
>>
>> Good opportunity for a lurker to step forward and
>> become a gfortran committer.  Otherwise, this patch
>> will fester in bugzilla the dozen or so other patches
>> I've attached to PRs.
>>
>> --
>> Steve
>>
>


Re: F2018 C937

2021-08-19 Thread Arjen Markus via Fortran
Hi Steve,

thanks for this detailed workflow. I am familiar enough with git to know
that there are myriads of procedures possible ;). Like you said, the first
three steps have been done. I will get working on step 4 and work my way
down the list.

Regards,

Arjen

Op do 19 aug. 2021 om 18:23 schreef Steve Kargl <
s...@troutmask.apl.washington.edu>:

> Arjen,
>
> If this is your first go around with patching gfortran,
> I'll suggest running the testsuite (if you haven't, see
> step 5. below; if you have see step 6.).  I suspect you
> already know much of what I enumerate below, but it may
> help others.
>
> With a bug report, the workflow for me is/was
>
> 1. Check versions of the standard to determine if it is
>a bug, and what is the expected result.
>
> 2. Identify where the problem can be addressed in source.
>
>For you (or anyone else interested in gfortran development),
>I suspect there a lot of question about how to do this
>step and the structure of the gfortran source code.  I can
>answer some of those questions in follow-up emails.  Send
>them to fortran@ and CC me.
>
> 3. Develop patch.
>
>I've done the first 3 steps.  You are now at testing the patch.
>
> 4. Build gfortran with the patch.  Assuming a Unix-like system,
>I have gcc/gccx with the source and gcc/objx is the build
>directory.  So, for a first time build on an N cpu system do
>
>% cd gcc/objx
>% ../gcc/gccx/configure --prefix=$HOME/work/x \
>  --enable-languages=c,c++,fortran,lto \
>  --enable-bootstrap --disable-nls --enable-checking
>% make -j N-1 bootstrap && make install
>
>Otherwise,
>
>% cd gcc/objx
>% make -j N-1 && make install
>
>This installs everything in $HOME/work/x.
>
> 5. Run the testsuite to check for regressions.  If any occur,
>fix regressions or fix the patch.
>
>% make -j N-1 check-fortran
>% tail gcc/testsuite/gfortran/gfortran.sum
>
> === gfortran Summary ===
>
># of expected passes58647
># of expected failures  253
># of unsupported tests  92
>objx/gcc/gfortran  version 12.0.0 20210816 (experimental) (GCC)
>
>With the C937 and C949 patches, I changed "typespec" to
>"type-spec" in nearby unrelated error messages.  Both are
>being used and type-spec matches the standard.  This may
>cause a regression, so one or more testcases may need a change.
>The C937 patch did not cause a regression.  The C949 one
>did.  You'll see a line like
>
># of unexpected failures  7
>
>The file gcc/testsuite/gfortran/gfortran.log contains the
>buildlog, which is huge.  You can find the failures with
>a search for lines containing ^FAIL.
>
> 6. Prepare ChangeLog.
>
>This has changed with git so you'll need to ask Tobias,
>Thomas, Harald, or on the gcc@ list for guidance.
>
> 7. Submit patch to fortran@gcc and gcc-patches@gcc asking
>for review.
>
> 8. Wait a few days.  Ping fortran@gcc and gcc-patches@gcc.
>
> 9. Wait a few days.  Ping fortran@gcc and gcc-patches@gcc.
>
>As I developed, the original patch and presumably you reviewed
>it for correctness, you can probably skip step 9.
>
> 10. Wait a few days.  Commit patch with or without a review.
>
> I do not know if you need any explicit access/permission to
> commit a patch.  I iknow very little about git and how it
> works.
>
> At this point, you can either backport the patch to release
> branches or close the PR.  For me, I always did a backport
> if it was a trivial task.  At some point, HEAD will diverge
> sufficiently from a branch, I would then stop backporting.
>
> --
> steve
>
> On Thu, Aug 19, 2021 at 05:10:47PM +0200, Arjen Markus wrote:
> > I have applied the patches locally (take care to restore the tabs ;)).
> > Should I now commit these changes or is there a more formal procedure
> > involved?
> >
> > Regards,
> >
> > Arjen
> >
> > Op do 19 aug. 2021 om 08:59 schreef Arjen Markus <
> arjen.markus...@gmail.com
> > >:
> >
> > > Hi Steve,
> > >
> > > I am willing to take up this challenge ;), as well as the patch for
> C949.
> > > It would be my next attempt to get acquainted with the source code (a
> first
> > > step hopefully to actively contribute).
> > >
> > > Regards,
> > >
> > > Arjen
> > >
> > > Op di 17 aug. 2021 om 21:02 schreef Steve Kargl via Fortran <
> > > fortran@gcc.gnu.org>:
> > >
> > >> For those that might care, I draw your attention to
> > >>
> > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101951
> > >>
> > >> Good opportunity for a lurker to step forward and
> > >> become a gfortran committer.  Otherwise, this patch
> > >> will fester in bugzilla the dozen or so other patches
> > >> I've attached to PRs.
> > >>
> > >> --
> > >> Steve
> > >>
> > >
>
> --
> Steve
>


Re: F2018 C937

2021-08-19 Thread Arjen Markus via Fortran
Yes, I already had arranged for that copyright one and a half years ago,
but my first attempts failed (learning curve, real life getting in the way
etc.)

Op vr 20 aug. 2021 om 08:47 schreef Steve Kargl <
s...@troutmask.apl.washington.edu>:

> Feel free to ask questions.  I forgot to point to
> the contributing page
>
> https://gcc.gnu.org/contribute.html
>
> At one time, you need to assign copyright to the FSF.
> That is no longer required.  Scan the above page for
> details.
>
> --
> steve
>
> On Fri, Aug 20, 2021 at 08:36:42AM +0200, Arjen Markus wrote:
> > Hi Steve,
> >
> > thanks for this detailed workflow. I am familiar enough with git to know
> > that there are myriads of procedures possible ;). Like you said, the
> first
> > three steps have been done. I will get working on step 4 and work my way
> > down the list.
> >
> > Regards,
> >
> > Arjen
> >
> > Op do 19 aug. 2021 om 18:23 schreef Steve Kargl <
> > s...@troutmask.apl.washington.edu>:
> >
> > > Arjen,
> > >
> > > If this is your first go around with patching gfortran,
> > > I'll suggest running the testsuite (if you haven't, see
> > > step 5. below; if you have see step 6.).  I suspect you
> > > already know much of what I enumerate below, but it may
> > > help others.
> > >
> > > With a bug report, the workflow for me is/was
> > >
> > > 1. Check versions of the standard to determine if it is
> > >a bug, and what is the expected result.
> > >
> > > 2. Identify where the problem can be addressed in source.
> > >
> > >For you (or anyone else interested in gfortran development),
> > >I suspect there a lot of question about how to do this
> > >step and the structure of the gfortran source code.  I can
> > >answer some of those questions in follow-up emails.  Send
> > >them to fortran@ and CC me.
> > >
> > > 3. Develop patch.
> > >
> > >I've done the first 3 steps.  You are now at testing the patch.
> > >
> > > 4. Build gfortran with the patch.  Assuming a Unix-like system,
> > >I have gcc/gccx with the source and gcc/objx is the build
> > >directory.  So, for a first time build on an N cpu system do
> > >
> > >% cd gcc/objx
> > >% ../gcc/gccx/configure --prefix=$HOME/work/x \
> > >  --enable-languages=c,c++,fortran,lto \
> > >  --enable-bootstrap --disable-nls --enable-checking
> > >% make -j N-1 bootstrap && make install
> > >
> > >Otherwise,
> > >
> > >% cd gcc/objx
> > >% make -j N-1 && make install
> > >
> > >This installs everything in $HOME/work/x.
> > >
> > > 5. Run the testsuite to check for regressions.  If any occur,
> > >fix regressions or fix the patch.
> > >
> > >% make -j N-1 check-fortran
> > >% tail gcc/testsuite/gfortran/gfortran.sum
> > >
> > > === gfortran Summary ===
> > >
> > ># of expected passes58647
> > ># of expected failures  253
> > ># of unsupported tests  92
> > >objx/gcc/gfortran  version 12.0.0 20210816 (experimental) (GCC)
> > >
> > >With the C937 and C949 patches, I changed "typespec" to
> > >"type-spec" in nearby unrelated error messages.  Both are
> > >being used and type-spec matches the standard.  This may
> > >cause a regression, so one or more testcases may need a change.
> > >The C937 patch did not cause a regression.  The C949 one
> > >did.  You'll see a line like
> > >
> > ># of unexpected failures  7
> > >
> > >The file gcc/testsuite/gfortran/gfortran.log contains the
> > >buildlog, which is huge.  You can find the failures with
> > >a search for lines containing ^FAIL.
> > >
> > > 6. Prepare ChangeLog.
> > >
> > >This has changed with git so you'll need to ask Tobias,
> > >Thomas, Harald, or on the gcc@ list for guidance.
> > >
> > > 7. Submit patch to fortran@gcc and gcc-patches@gcc asking
> > >for review.
> > >
> > > 8. Wait a few days.  Ping fortran@gcc and gcc-patches@gcc.
> > >
> > > 9. Wait a few days.  Ping fortran@gcc and gcc-patches@gcc.
> > >
> > >As I developed, the original p

Build problems: mpfr, mpc

2021-08-20 Thread Arjen Markus via Fortran
I am trying to build the compiler suite to test the two patches Steve Kargl
posted. But I run into a problem with the mpfr and mpc libraries: the
linker claims it cannot find them.

I checked this, in fist instance they were not present in the location they
were assumed to be, but I had copies from an earlier build, so I copied
them into the location indicated by the -L option. That does not help
though: same error messages.

How do I solve this?

Regards,

Arjen


Re: Build problems: mpfr, mpc

2021-08-20 Thread Arjen Markus via Fortran
Op vr 20 aug. 2021 om 11:54 schreef Richard Biener:

>
>
> The easiest is probably to build them in-tree by means of
> executing ./contrib/download_prerequesites which will download
> and unpack them into your source tree.
>
>
Well, I do have the libraries (source and all) and I copied the built
libraries (that is the content of mpfr/,libs and mpc/.libs to the locations
that are referred to in the link statement, so I assumed that would enable
the linker to find them.

Other than that you are likely either missing some of the requirements
> or lack the appropriate --with-{gmp,mpc,mpfr}[-lib] configury.
>
>
The odd thing is that the link statement as presented in the command window
knows where to find the libraries. Here is the (hopefully) relevant part:

g++ -std=c++11 -no-pie   -g -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall
  (...)  ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a
 -L/cygdrive/d/gfortran/gcc/build-gcc/./gmp/.libs
-L/cygdrive/d/gfortran/gcc/build-gcc/./mpfr/src/.libs
-L/cygdrive/d/gfortran/gcc/build-gcc/./mpc/src/.libs -lmpc -lmpfr -lgmp
-L./../zlib -lz  libcommon.a ../libcpp/libcpp.a  -liconv
../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lmpc
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lmpc
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lmpfr
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lmpfr
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lmpc
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lmpfr


What host operating system are you using?
>
> Cygwin on Windows 10

Oops, now that I copied the relevant bit of the link command, I see what I
did wrong: the libraries are under mpfr/./libs, not mpfr/src/.libs (and
ditto for mpc).

Okay, trying again!

Thanks for the reply. This ought to do it.

Regards,

Arjen


Re: Build problems: mpfr, mpc

2021-08-20 Thread Arjen Markus via Fortran
Okay, that solved that error, now I get:

 -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=fs_ops.lo -fimplicit-templates -g -O2 -c
../../../../../../libstdc++-v3/src/c++17/fs_ops.cc -o fs_ops.o
In file included from ../../../../../../libstdc++-v3/src/c++17/fs_ops.cc:58:
../../../../../../libstdc++-v3/src/c++17/../filesystem/ops-common.h: In
function 'const char*
std::filesystem::get_temp_directory_from_env(std::error_code&)':
../../../../../../libstdc++-v3/src/c++17/../filesystem/ops-common.h:601:25:
error: '::secure_getenv' has not been declared
  601 | auto tmpdir = ::secure_getenv(env);
  | ^

and there is a weird subdirectory under the build directory:  gccd: - the
colon cannot be part of a directory name under Windows. I guess this is my
mistake, as I set the install directory to "d:/gfortran/work" - that should
become "/cygdrive/d/gfortran/work". Easily fixed, but I do not know what to
do about the first error.

Regards,

Arjen

Op vr 20 aug. 2021 om 12:10 schreef Arjen Markus :

>
>
> Op vr 20 aug. 2021 om 11:54 schreef Richard Biener:
>
>>
>>
>> The easiest is probably to build them in-tree by means of
>> executing ./contrib/download_prerequesites which will download
>> and unpack them into your source tree.
>>
>>
> Well, I do have the libraries (source and all) and I copied the built
> libraries (that is the content of mpfr/,libs and mpc/.libs to the locations
> that are referred to in the link statement, so I assumed that would enable
> the linker to find them.
>
> Other than that you are likely either missing some of the requirements
>> or lack the appropriate --with-{gmp,mpc,mpfr}[-lib] configury.
>>
>>
> The odd thing is that the link statement as presented in the command
> window knows where to find the libraries. Here is the (hopefully) relevant
> part:
>
> g++ -std=c++11 -no-pie   -g -DIN_GCC -fno-exceptions -fno-rtti
> -fasynchronous-unwind-tables -W -Wall
>   (...)  ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a
>  -L/cygdrive/d/gfortran/gcc/build-gcc/./gmp/.libs
> -L/cygdrive/d/gfortran/gcc/build-gcc/./mpfr/src/.libs
> -L/cygdrive/d/gfortran/gcc/build-gcc/./mpc/src/.libs -lmpc -lmpfr -lgmp
> -L./../zlib -lz  libcommon.a ../libcpp/libcpp.a  -liconv
> ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
> ../libdecnumber/libdecnumber.a
> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lmpc
> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lmpc
> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lmpfr
> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lmpfr
> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lmpc
> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lmpfr
>
>
> What host operating system are you using?
>>
>> Cygwin on Windows 10
>
> Oops, now that I copied the relevant bit of the link command, I see what I
> did wrong: the libraries are under mpfr/./libs, not mpfr/src/.libs (and
> ditto for mpc).
>
> Okay, trying again!
>
> Thanks for the reply. This ought to do it.
>
> Regards,
>
> Arjen
>


Re: Build problems: mpfr, mpc

2021-08-20 Thread Arjen Markus via Fortran
Going the WSL2 route (I am not all that familiar with WSL) or a Linux
emulation may be the way to go, indeed, but your remark triggered me to do
a bit of searching: there is some discussion about the secure_getenv()
function wrt Cygwin but there actually is a prototype for it in Cygwin's
stdlib.h. It is protected by a symbol __GNU_VISIBLE. I will try to define
that and see what happens.

Regards,

Arjen

Op vr 20 aug. 2021 om 14:31 schreef Richard Biener <
richard.guent...@gmail.com>:

> On Fri, Aug 20, 2021 at 12:55 PM Arjen Markus 
> wrote:
> >
> > Okay, that solved that error, now I get:
> >
> >  -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
> -fdiagnostics-show-location=once -ffunction-sections -fdata-sections
> -frandom-seed=fs_ops.lo -fimplicit-templates -g -O2 -c
> ../../../../../../libstdc++-v3/src/c++17/fs_ops.cc -o fs_ops.o
> > In file included from
> ../../../../../../libstdc++-v3/src/c++17/fs_ops.cc:58:
> > ../../../../../../libstdc++-v3/src/c++17/../filesystem/ops-common.h: In
> function 'const char*
> std::filesystem::get_temp_directory_from_env(std::error_code&)':
> >
> ../../../../../../libstdc++-v3/src/c++17/../filesystem/ops-common.h:601:25:
> error: '::secure_getenv' has not been declared
> >   601 | auto tmpdir = ::secure_getenv(env);
> >   | ^
> >
> > and there is a weird subdirectory under the build directory:  gccd: -
> the colon cannot be part of a directory name under Windows. I guess this is
> my mistake, as I set the install directory to "d:/gfortran/work" - that
> should become "/cygdrive/d/gfortran/work". Easily fixed, but I do not know
> what to do about the first error.
>
> Possibly secure_getenv is not available in cygwin and for some reason
> AC_CHECK_FUNCS (secure_getenv) as done by
> libstdc++ configury misdetects it and/or the use site has a different
> set of includes.  Jonathan might know.
>
> Note using cygwin (or mingw for that) might make GCC development more
> painful than necessary. It might be
> that using a WSL2 based setup is easier if you're stuck to a Windows
> host.  Using Linux in a virtual machine
> might be another option of course.
>
> Richard.
>
> > Regards,
> >
> > Arjen
> >
> > Op vr 20 aug. 2021 om 12:10 schreef Arjen Markus <
> arjen.markus...@gmail.com>:
> >>
> >>
> >>
> >> Op vr 20 aug. 2021 om 11:54 schreef Richard Biener:
> >>>
> >>>
> >>>
> >>> The easiest is probably to build them in-tree by means of
> >>> executing ./contrib/download_prerequesites which will download
> >>> and unpack them into your source tree.
> >>>
> >>
> >> Well, I do have the libraries (source and all) and I copied the built
> libraries (that is the content of mpfr/,libs and mpc/.libs to the locations
> that are referred to in the link statement, so I assumed that would enable
> the linker to find them.
> >>
> >>> Other than that you are likely either missing some of the requirements
> >>> or lack the appropriate --with-{gmp,mpc,mpfr}[-lib] configury.
> >>>
> >>
> >> The odd thing is that the link statement as presented in the command
> window knows where to find the libraries. Here is the (hopefully) relevant
> part:
> >>
> >> g++ -std=c++11 -no-pie   -g -DIN_GCC -fno-exceptions -fno-rtti
> -fasynchronous-unwind-tables -W -Wall
> >>   (...)  ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a
> -L/cygdrive/d/gfortran/gcc/build-gcc/./gmp/.libs
> -L/cygdrive/d/gfortran/gcc/build-gcc/./mpfr/src/.libs
> -L/cygdrive/d/gfortran/gcc/build-gcc/./mpc/src/.libs -lmpc -lmpfr -lgmp
>  -L./../zlib -lz  libcommon.a ../libcpp/libcpp.a  -liconv
> ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
> ../libdecnumber/libdecnumber.a
> >> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lmpc
> >> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lmpc
> >> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lmpfr
> >> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lmpfr
> >> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lmpc
> >> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lmpfr
> >>
> >>
> >>> What host operating system are you using?
> >>>
> >> Cygwin on Windows 10
> >>
> >> Oops, now that I copied the relevant bit of the link command, I see
> what I did wrong: the libraries are under mpfr/./libs, not mpfr/src/.libs
> (and ditto for mpc).
> >>
> >> Okay, trying again!
> >>
> >> Thanks for the reply. This ought to do it.
> >>
> >> Regards,
> >>
> >> Arjen
>


Re: Build problems: mpfr, mpc

2021-08-20 Thread Arjen Markus via Fortran
Ah, thanks, I restarted the build with _GNU_SOURCE instead.

Regards,

Arjen

Op vr 20 aug. 2021 om 15:11 schreef Jonathan Wakely :

> On Fri, 20 Aug 2021 at 14:09, Jonathan Wakely wrote:
> >
> > On Fri, 20 Aug 2021 at 13:59, Arjen Markus wrote:
> > >
> > > Going the WSL2 route (I am not all that familiar with WSL) or a Linux
> emulation may be the way to go, indeed, but your remark triggered me to do
> a bit of searching: there is some discussion about the secure_getenv()
> function wrt Cygwin but there actually is a prototype for it in Cygwin's
> stdlib.h. It is protected by a symbol __GNU_VISIBLE. I will try to define
> that and see what happens.
> >
> > Don't do that. Define _GNU_SOURCE to tell Cygwin you want the GNU
> > extensions like secure_getenv, and then  will define
> > __GNU_VISIBLE.
>
> As it says in  ...
>
> * The following private macros are used throughout the headers to control
> * which symbols should be exposed.  They are for internal use only, as
> * indicated by the leading double underscore, and must never be used
> outside
> * of these headers.
> ...
> * __GNU_VISIBLE
> *  GNU extensions; enabled with _GNU_SOURCE.
>
>
> >
> > I am curious why _GNU_SOURCE would be defined during configure but not
> > when compiling.
>


Re: Build problems: mpfr, mpc

2021-08-23 Thread Arjen Markus via Fortran
I defined both CFLAGS and CXXFLAGS as -D_GNU_SOURCE and it did the trick. I
see a number of unexpected failures in the log, so I will look into those.
But the good news is that the procedure does work.

Regards,

Arjen

Op vr 20 aug. 2021 om 15:17 schreef Arjen Markus :

> Ah, thanks, I restarted the build with _GNU_SOURCE instead.
>
> Regards,
>
> Arjen
>
> Op vr 20 aug. 2021 om 15:11 schreef Jonathan Wakely  >:
>
>> On Fri, 20 Aug 2021 at 14:09, Jonathan Wakely wrote:
>> >
>> > On Fri, 20 Aug 2021 at 13:59, Arjen Markus wrote:
>> > >
>> > > Going the WSL2 route (I am not all that familiar with WSL) or a Linux
>> emulation may be the way to go, indeed, but your remark triggered me to do
>> a bit of searching: there is some discussion about the secure_getenv()
>> function wrt Cygwin but there actually is a prototype for it in Cygwin's
>> stdlib.h. It is protected by a symbol __GNU_VISIBLE. I will try to define
>> that and see what happens.
>> >
>> > Don't do that. Define _GNU_SOURCE to tell Cygwin you want the GNU
>> > extensions like secure_getenv, and then  will define
>> > __GNU_VISIBLE.
>>
>> As it says in  ...
>>
>> * The following private macros are used throughout the headers to control
>> * which symbols should be exposed.  They are for internal use only, as
>> * indicated by the leading double underscore, and must never be used
>> outside
>> * of these headers.
>> ...
>> * __GNU_VISIBLE
>> *  GNU extensions; enabled with _GNU_SOURCE.
>>
>>
>> >
>> > I am curious why _GNU_SOURCE would be defined during configure but not
>> > when compiling.
>>
>


Re: F2018 C937

2021-08-23 Thread Arjen Markus via Fortran
Hi Steve,

yes, the extra macro did the job, so the testuite has run. So, this means
the patch has to be adapted.

I will report the unexpectedly failing tests in a separate mail.

Regards,

Arjen

Op ma 23 aug. 2021 om 19:18 schreef Steve Kargl <
s...@troutmask.apl.washington.edu>:

> Hi Arjen,
>
> Don't know if you've made any progress with cygwin (yes,
> I saw the other thread).  I lurk on the J3 Fortran mailing
> list, and have come to learn that C937 has been deleted in
> the draft for Fortran 202x.  What this means is that the
> "gcc_error ()" statement will need to be changed to use
> the "gfc_notify_std()" method reporting errors.
>
> --
> steve
>
> On Thu, Aug 19, 2021 at 08:59:05AM +0200, Arjen Markus wrote:
> > Hi Steve,
> >
> > I am willing to take up this challenge ;), as well as the patch for C949.
> > It would be my next attempt to get acquainted with the source code (a
> first
> > step hopefully to actively contribute).
> >
> > Regards,
> >
> > Arjen
> >
> > Op di 17 aug. 2021 om 21:02 schreef Steve Kargl via Fortran <
> > fortran@gcc.gnu.org>:
> >
> > > For those that might care, I draw your attention to
> > >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101951
> > >
> > > Good opportunity for a lurker to step forward and
> > > become a gfortran committer.  Otherwise, this patch
> > > will fester in bugzilla the dozen or so other patches
> > > I've attached to PRs.
> > >
> > > --
> > > Steve
> > >
>
> --
> Steve
>


Failing tests after applying patches?

2021-08-23 Thread Arjen Markus via Fortran
Hello,

as promised, here is an overview of the unexpectedly failing tests. I got
these after applying the patches by Steve Kargl for bug ID 101951 and
101967. The platform I used to build it is Cygwin on WIndows 10.

FAIL: gfortran.dg/analyzer/pr96949.f90   -O  (internal compiler error)
FAIL: gfortran.dg/analyzer/pr96949.f90   -O  (test for excess errors)

I tried to reproduce this problem with version 10.2.0 but the program is
compiled and runs without problems. The analyzer options (in the dg
instructions) were not accepted, neither with the freshly built gfortran
executable. Probably too naïve to try itlike that ;).

Anyway, my question: is this a problem due to the patches or not?

FAIL: gfortran.dg/round_4.f90   -O0  execution test
and ditto with -O1, -O2, etc.

When built with version 10.2.0, the program fails with error code 2.I guess
this means this program is failing independently of these patches. Judging
from the comments, I conclude that it is a tough one, as it depends on the
implementation of strtod().

Regards,

Arjen


Re: Failing tests after applying patches?

2021-08-23 Thread Arjen Markus via Fortran
Hi Tobias,

thanks for these tips - this should come in handy indeed.

One thing though: when I tried to run my freshly built gfortran compiler on
one of the test programs, I got the message that it could not find the file
libgfortran.spec. Is there some environment variable that muist be set?

Regards,

Arjen

Op ma 23 aug. 2021 om 21:36 schreef Tobias Burnus :

> Hi Arjen,
>
> On 23.08.21 20:59, Arjen Markus via Fortran wrote:
> > as promised, here is an overview of the unexpectedly failing tests. I got
> > these after applying the patches by Steve Kargl for bug ID 101951 and
> > 101967. The platform I used to build it is Cygwin on WIndows 10.
> >
> > FAIL: gfortran.dg/analyzer/pr96949.f90   -O  (internal compiler error)
> > FAIL: gfortran.dg/analyzer/pr96949.f90   -O  (test for excess errors)
>
> I recommend: https://gcc.gnu.org/pipermail/gcc-testresults/current – it
> shows what others are getting.
>
> In particular, it helps: to ensure to look at the right branch (12.0
> mainline), to look at  x86-64 Linux (as others tend to have some
> additional issues) — and to make sure that that build actual does test
> Fortran.
>
> But the simplest test is to undo your patches - recompile GCC and then
> run (in the build directory):
>
> cd gcc; make check-fortran RUNTESTFLAGS="analyzer.exp=pr96949.f90"
>
> If the error still occurs, it is probably unrelated to the patch; if it
> is gone, the patch probably caused it.
>
> I also do note that many analyzer commits have been committed today,
> hence, it is a moving target. (It does work for me – with the current
> checkout. But this does not tell anything about when you did your tests,
> given that several commits were done this evening.)
>
> Tobias
>
>


Re: Replacing keyword in RISC-V Fortran

2021-10-25 Thread Arjen Markus via Fortran
I am not sure I understand your question correctly, but Fortran uses the
KIND mechanism to declare the precise characteristics of floating-point
variables and constants. Typically, these are identifying integer numbers
for single precision, double precision and quadruple precision. A custom
floating-point type would mean an additional KIND number with the relevant
runtime support and support from the various intrinsic functions and
modules In the directory gcc/fortran I find several source files that use
the typedef gfc_real_info and the array of kinds gfc_rel_kinds to deal with
floating-point data of various kinds. Would that help? (Caveat: I am a mere
beginner, and perhaps not even that, when it comes to the internals of the
GCC compiler suite)

Regards,

Arjen

Op za 23 okt. 2021 om 03:28 schreef Amit Hmath via Fortran <
fortran@gcc.gnu.org>:

> Hello All,
>
> I am working on a custom float in RISC-V 32, one can replace keyword
> "float" with  custom keyword like "fp_custom" at line # 482
> riscv-gcc/gcc/c-family/c-common.c. But in the case of Fortran,  can you
> please tell which files to modify to replace the "float" keyword?
>
> And also, in case of c/c++ one can do custom encoding and decoding of
> custom floats in gcc/real.c how about in fortran for custom real data type,
> which file(s) one has to modify?
>
> Many Thanks,
> -Amit
>