[RFC][PATCH 0/1] Fortran compiler detection

[Kempke, Nils-Christian]

> -----Original Message-----
> From: Andrew Burgess <aburgess@redhat.com>
> Sent: Thursday, January 13, 2022 4:30 PM
> To: Kempke, Nils-Christian <nils-christian.kempke@intel.com>
> Cc: gdb-patches@sourceware.org
> Subject: Re: [RFC][PATCH 0/1] Fortran compiler detection
> 
> * Kempke, Nils-Christian <nils-christian.kempke@intel.com> [2022-01-13
> 14:07:52 +0000]:
> 
> > Hi Andrew,
> >
> > > -----Original Message-----
> > > From: Andrew Burgess <aburgess@redhat.com>
> > > Sent: Wednesday, January 12, 2022 4:09 PM
> > > To: Kempke, Nils-Christian <nils-christian.kempke@intel.com>
> > > Cc: gdb-patches@sourceware.org
> > > Subject: Re: [RFC][PATCH 0/1] Fortran compiler detection
> > >
> > > * Nils-Christian Kempke via Gdb-patches <gdb-
> patches@sourceware.org>
> > > [2022-01-11 18:12:39 +0100]:
> > >
> > > > Hi,
> > > >
> > > > in a recent mail with the subject
> > > >
> > > > [RFC][PATCH 0/1] gdb, testsuite, fortran, ada: gfortran symbols get
> > > demangled as ada
> > > >
> > > > I sent a Fortran compiler specific patch that tries to distinguish
> > > > between gfortran and ifort.  This is done by querying the procedure
> > > > test_compiler_info for icc-* to detect ifort.  Similarly, we'd like to
> > > > add the newer Intel compilers ifx/icpx/icx to the testsuite and detect
> > > > those as well.  The patch for adding the "next gen" Intel compilers
> > > > is in the attached mail and is our initial idea.
> > > >
> > > > The question that rose when we discussed the upstreaming of both,
> > > > above patch and Intel compiler support, is: Is the way gdb-testsuite
> > > > currently detects Fortran compilers the way to go?
> > >
> > > No, the current approach is not good!
> > >
> > > >
> > > > In fortran.exp the same detection mechanism is used heavily to
> > > > detect e.g. the name of a Fortran main function (MAIN_ or MAIN__ for
> > > > flang).  We think it is a bit hacky to use c/cpp preprocessing to
> > > > determine the Fortran compiler used. It for example prevents one from
> > > > running the testsuite using CC_FOR_TARGET='gcc' in combination with
> > > > F90_FOR_TARGET='ifort' since in this case the wrong Fortran compiler
> > > > will get detected (whether one wants to run this is another
> > > > question).
> > >
> > > I have wanted to do things like this in the past, though I don't
> > > recall what I was doing at the time, and it is annoying that this
> > > doesn't work.
> > >
> > > >
> > > > The only other real other 'idea' we came up with was using a similar
> > > > detection mechanism for Fortran as is currently in use for c/cpp.  While
> > > > preprocessing is not standard Frotran, gfortran/ifort/ifx/flang all
> > > > implement it. For those compilers one can use the preprorcessor
> defines
> > > > to identify the Fortran compiler separately from the c/cpp compiler.
> > > > I think this is also what Cmake does to identify Fortran compilers.
> > >
> > > I think that if all the major players currently support this, then
> > > lets just go with that for now (unless someone proposes a super neat
> > > solution).  We can figure out an alternative when there's a Fortran
> > > compiler that doesn't support preprocessors.
> > >
> > > > We wanted to get some feedback on how to proceed here before
> > > > implementing anything that requires more effort.
> > >
> > > You'll notice that get_compiler_info already supports an arg, which is
> > > the language to check for.  Currently this only support C or C++, but
> > > this could be extended to cover other languages.
> > >
> > > Then test_compiler_info, which currently takes just a pattern to
> > > compare against, could take both a pattern and a language (with the
> > > language defaulting to C).
> >
> > Probably, to keep the old behavior the same, one would also default to
> > the C compiler detection in the case where the Fortran compiler could
> > not be detected.
> >
> > > After that, you just need to update the test_compiler_info calls in
> > > the Fortran tests, and you're done I think.
> > >
> > > Thanks,
> > > Andrew
> >
> > Ok, thanks for the input! I'll go ahead then and extend the
> > test_compiler_info for now.
> >
> > Should we still push the RFC patch? It would enable running the fortran
> > testsuite with ifx until a new compiler detection is implemented.
> 
> Yes, I agree that pushing that patch will be good in the short term.
> 
> > If we want to push it - should I resend it to the list? Since I initially sent a
> RFC ..
> > Also, I cannot push it myself since this would be my first time and I do not
> > have an account or write after approval rights.
> 
> Can I assume Intel have a company wide copyright assignment in place?
> If you (or someone else) can confirm that, then I'm happy to push the
> patch.
> 
> Thanks,
> Andrew

Yes, Intel has a companywide assignment.

Thanks,
Nils

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928