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

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

[Nils-Christian Kempke]

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?

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).

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.
	
We wanted to get some feedback on how to proceed here before
implementing anything that requires more effort.

Also, if someone has a better idea that we could realize we'd be happy
to do so!

Cheers,

Nils

abijaz (1):
  gdb/testsuite: enable __INTEL_LLVM_COMPILER preprocessor in
    get_compiler_info

 gdb/testsuite/lib/compiler.c  | 9 +++++++++
 gdb/testsuite/lib/compiler.cc | 9 +++++++++
 gdb/testsuite/lib/fortran.exp | 3 ++-
 3 files changed, 20 insertions(+), 1 deletion(-)

-- 
2.25.1

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

[RFC][PATCH 1/1] gdb/testsuite: enable __INTEL_LLVM_COMPILER preprocessor in get_compiler_info

[Nils-Christian Kempke]

Intel Next Gen compiler defines preprocessor __INTEL_LLVM_COMPILER and provides
version info in __clang_version__ e.g. value: 12.0.0 (icx 2020.10.0.1113).

gdb/testsuite/ChangeLog:
2020-12-07  Abdul Basit Ijaz  <abdul.b.ijaz@intel.com>

	* lib/compiler.c: Add Intel next gen compiler pre-processor check.
	* lib/compiler.cc: Ditto.
	* lib/fortran.exp (fortran_main): Check Intel next gen compiler in
	test_compiler_info.
---
 gdb/testsuite/lib/compiler.c  | 9 +++++++++
 gdb/testsuite/lib/compiler.cc | 9 +++++++++
 gdb/testsuite/lib/fortran.exp | 3 ++-
 3 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/lib/compiler.c b/gdb/testsuite/lib/compiler.c
index 191bced041..4cab1c5052 100644
--- a/gdb/testsuite/lib/compiler.c
+++ b/gdb/testsuite/lib/compiler.c
@@ -67,4 +67,13 @@ set icc_major [string range __ICL 0 1]
 set icc_minor [format "%d" [string range __ICL 2 [expr {[string length __ICL] -1}]]]
 set icc_update __INTEL_COMPILER_UPDATE
 set compiler_info [join "icc $icc_major $icc_minor $icc_update" -]
+#elif defined(__INTEL_LLVM_COMPILER) && defined(__clang_version__)
+/* Intel Next Gen compiler defines preprocessor __INTEL_LLVM_COMPILER and
+   provides version info in __clang_version__ e.g. value:
+   "12.0.0 (icx 2020.10.0.1113)". */
+set total_length [string length __clang_version__]
+set version_start_index [string last "(" __clang_version__]
+set version_string [string range __clang_version__ $version_start_index+5 $total_length-2]
+set version_updated_string [string map {. -} $version_string]
+set compiler_info "intel-$version_updated_string"
 #endif
diff --git a/gdb/testsuite/lib/compiler.cc b/gdb/testsuite/lib/compiler.cc
index ab36bea43a..fa9059c68d 100755
--- a/gdb/testsuite/lib/compiler.cc
+++ b/gdb/testsuite/lib/compiler.cc
@@ -55,4 +55,13 @@ set icc_major [string range __ICL 0 1]
 set icc_minor [format "%d" [string range __ICL 2 [expr {[string length __ICL] -1}]]]
 set icc_update __INTEL_COMPILER_UPDATE
 set compiler_info [join "icc $icc_major $icc_minor $icc_update" -]
+#elif defined(__INTEL_LLVM_COMPILER) && defined(__clang_version__)
+/* Intel Next Gen compiler defines preprocessor __INTEL_LLVM_COMPILER and
+   provides version info in __clang_version__ e.g. value:
+   "12.0.0 (icx 2020.10.0.1113)". */
+set total_length [string length __clang_version__]
+set version_start_index [string last "(" __clang_version__]
+set version_string [string range __clang_version__ $version_start_index+5 $total_length-2]
+set version_updated_string [string map {. -} $version_string]
+set compiler_info "intel-$version_updated_string"
 #endif
diff --git a/gdb/testsuite/lib/fortran.exp b/gdb/testsuite/lib/fortran.exp
index ee7fe12ad9..a97c6eeb4e 100644
--- a/gdb/testsuite/lib/fortran.exp
+++ b/gdb/testsuite/lib/fortran.exp
@@ -160,7 +160,8 @@ proc fortran_character1 {} {
 proc fortran_main {} {
     if {[test_compiler_info {gcc-4-[012]-*}]
          || [test_compiler_info {gcc-*}]
-         || [test_compiler_info {icc-*}]} {
+         || [test_compiler_info {icc-*}]
+         || [test_compiler_info {intel-*}]} {
 	return "MAIN__"
     } elseif {[test_compiler_info {clang-*}]} {
 	return "MAIN_"
-- 
2.25.1

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

Re: [RFC][PATCH 1/1] gdb/testsuite: enable __INTEL_LLVM_COMPILER preprocessor in get_compiler_info

[Andrew Burgess]

* Nils-Christian Kempke via Gdb-patches <gdb-patches@sourceware.org> [2022-01-11 18:12:40 +0100]:

> Intel Next Gen compiler defines preprocessor __INTEL_LLVM_COMPILER and provides
> version info in __clang_version__ e.g. value: 12.0.0 (icx 2020.10.0.1113).

This looks good to me...

> 
> gdb/testsuite/ChangeLog:
> 2020-12-07  Abdul Basit Ijaz  <abdul.b.ijaz@intel.com>
> 
> 	* lib/compiler.c: Add Intel next gen compiler pre-processor check.
> 	* lib/compiler.cc: Ditto.
> 	* lib/fortran.exp (fortran_main): Check Intel next gen compiler in
> 	test_compiler_info.

FYI, ChangeLog entries should not be committed in tree.  It's fine to
have these entries in the commit message though.

Thanks,
Andrew

> ---
>  gdb/testsuite/lib/compiler.c  | 9 +++++++++
>  gdb/testsuite/lib/compiler.cc | 9 +++++++++
>  gdb/testsuite/lib/fortran.exp | 3 ++-
>  3 files changed, 20 insertions(+), 1 deletion(-)
> 
> diff --git a/gdb/testsuite/lib/compiler.c b/gdb/testsuite/lib/compiler.c
> index 191bced041..4cab1c5052 100644
> --- a/gdb/testsuite/lib/compiler.c
> +++ b/gdb/testsuite/lib/compiler.c
> @@ -67,4 +67,13 @@ set icc_major [string range __ICL 0 1]
>  set icc_minor [format "%d" [string range __ICL 2 [expr {[string length __ICL] -1}]]]
>  set icc_update __INTEL_COMPILER_UPDATE
>  set compiler_info [join "icc $icc_major $icc_minor $icc_update" -]
> +#elif defined(__INTEL_LLVM_COMPILER) && defined(__clang_version__)
> +/* Intel Next Gen compiler defines preprocessor __INTEL_LLVM_COMPILER and
> +   provides version info in __clang_version__ e.g. value:
> +   "12.0.0 (icx 2020.10.0.1113)". */
> +set total_length [string length __clang_version__]
> +set version_start_index [string last "(" __clang_version__]
> +set version_string [string range __clang_version__ $version_start_index+5 $total_length-2]
> +set version_updated_string [string map {. -} $version_string]
> +set compiler_info "intel-$version_updated_string"
>  #endif
> diff --git a/gdb/testsuite/lib/compiler.cc b/gdb/testsuite/lib/compiler.cc
> index ab36bea43a..fa9059c68d 100755
> --- a/gdb/testsuite/lib/compiler.cc
> +++ b/gdb/testsuite/lib/compiler.cc
> @@ -55,4 +55,13 @@ set icc_major [string range __ICL 0 1]
>  set icc_minor [format "%d" [string range __ICL 2 [expr {[string length __ICL] -1}]]]
>  set icc_update __INTEL_COMPILER_UPDATE
>  set compiler_info [join "icc $icc_major $icc_minor $icc_update" -]
> +#elif defined(__INTEL_LLVM_COMPILER) && defined(__clang_version__)
> +/* Intel Next Gen compiler defines preprocessor __INTEL_LLVM_COMPILER and
> +   provides version info in __clang_version__ e.g. value:
> +   "12.0.0 (icx 2020.10.0.1113)". */
> +set total_length [string length __clang_version__]
> +set version_start_index [string last "(" __clang_version__]
> +set version_string [string range __clang_version__ $version_start_index+5 $total_length-2]
> +set version_updated_string [string map {. -} $version_string]
> +set compiler_info "intel-$version_updated_string"
>  #endif
> diff --git a/gdb/testsuite/lib/fortran.exp b/gdb/testsuite/lib/fortran.exp
> index ee7fe12ad9..a97c6eeb4e 100644
> --- a/gdb/testsuite/lib/fortran.exp
> +++ b/gdb/testsuite/lib/fortran.exp
> @@ -160,7 +160,8 @@ proc fortran_character1 {} {
>  proc fortran_main {} {
>      if {[test_compiler_info {gcc-4-[012]-*}]
>           || [test_compiler_info {gcc-*}]
> -         || [test_compiler_info {icc-*}]} {
> +         || [test_compiler_info {icc-*}]
> +         || [test_compiler_info {intel-*}]} {
>  	return "MAIN__"
>      } elseif {[test_compiler_info {clang-*}]} {
>  	return "MAIN_"
> -- 
> 2.25.1
> 
> 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
> 

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

[Andrew Burgess]

* 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).

After that, you just need to update the test_compiler_info calls in
the Fortran tests, and you're done I think.

Thanks,
Andrew

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

[Kempke, Nils-Christian]

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.

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.

Thanks,
Nils

RE: [RFC][PATCH 1/1] gdb/testsuite: enable __INTEL_LLVM_COMPILER preprocessor in get_compiler_info

[Kempke, Nils-Christian]

> -----Original Message-----
> From: Andrew Burgess <aburgess@redhat.com>
> Sent: Wednesday, January 12, 2022 4:02 PM
> To: Kempke, Nils-Christian <nils-christian.kempke@intel.com>
> Cc: gdb-patches@sourceware.org
> Subject: Re: [RFC][PATCH 1/1] gdb/testsuite: enable
> __INTEL_LLVM_COMPILER preprocessor in get_compiler_info
> 
> * Nils-Christian Kempke via Gdb-patches <gdb-patches@sourceware.org>
> [2022-01-11 18:12:40 +0100]:
> 
> > Intel Next Gen compiler defines preprocessor __INTEL_LLVM_COMPILER
> and provides
> > version info in __clang_version__ e.g. value: 12.0.0 (icx 2020.10.0.1113).
> 
> This looks good to me...
> 
> >
> > gdb/testsuite/ChangeLog:
> > 2020-12-07  Abdul Basit Ijaz  <abdul.b.ijaz@intel.com>
> >
> > 	* lib/compiler.c: Add Intel next gen compiler pre-processor check.
> > 	* lib/compiler.cc: Ditto.
> > 	* lib/fortran.exp (fortran_main): Check Intel next gen compiler in
> > 	test_compiler_info.
> 
> FYI, ChangeLog entries should not be committed in tree.  It's fine to
> have these entries in the commit message though.

Ok, thanks, got it! Our (Intel) currently published master is based on some older
gdb and thus all commits from there still have a ChangeLog in them.

Cheers,

Nils

> 
> Thanks,
> Andrew
> 
> > ---
> >  gdb/testsuite/lib/compiler.c  | 9 +++++++++
> >  gdb/testsuite/lib/compiler.cc | 9 +++++++++
> >  gdb/testsuite/lib/fortran.exp | 3 ++-
> >  3 files changed, 20 insertions(+), 1 deletion(-)
> >
> > diff --git a/gdb/testsuite/lib/compiler.c b/gdb/testsuite/lib/compiler.c
> > index 191bced041..4cab1c5052 100644
> > --- a/gdb/testsuite/lib/compiler.c
> > +++ b/gdb/testsuite/lib/compiler.c
> > @@ -67,4 +67,13 @@ set icc_major [string range __ICL 0 1]
> >  set icc_minor [format "%d" [string range __ICL 2 [expr {[string length
> __ICL] -1}]]]
> >  set icc_update __INTEL_COMPILER_UPDATE
> >  set compiler_info [join "icc $icc_major $icc_minor $icc_update" -]
> > +#elif defined(__INTEL_LLVM_COMPILER) &&
> defined(__clang_version__)
> > +/* Intel Next Gen compiler defines preprocessor
> __INTEL_LLVM_COMPILER and
> > +   provides version info in __clang_version__ e.g. value:
> > +   "12.0.0 (icx 2020.10.0.1113)". */
> > +set total_length [string length __clang_version__]
> > +set version_start_index [string last "(" __clang_version__]
> > +set version_string [string range __clang_version__
> $version_start_index+5 $total_length-2]
> > +set version_updated_string [string map {. -} $version_string]
> > +set compiler_info "intel-$version_updated_string"
> >  #endif
> > diff --git a/gdb/testsuite/lib/compiler.cc b/gdb/testsuite/lib/compiler.cc
> > index ab36bea43a..fa9059c68d 100755
> > --- a/gdb/testsuite/lib/compiler.cc
> > +++ b/gdb/testsuite/lib/compiler.cc
> > @@ -55,4 +55,13 @@ set icc_major [string range __ICL 0 1]
> >  set icc_minor [format "%d" [string range __ICL 2 [expr {[string length
> __ICL] -1}]]]
> >  set icc_update __INTEL_COMPILER_UPDATE
> >  set compiler_info [join "icc $icc_major $icc_minor $icc_update" -]
> > +#elif defined(__INTEL_LLVM_COMPILER) &&
> defined(__clang_version__)
> > +/* Intel Next Gen compiler defines preprocessor
> __INTEL_LLVM_COMPILER and
> > +   provides version info in __clang_version__ e.g. value:
> > +   "12.0.0 (icx 2020.10.0.1113)". */
> > +set total_length [string length __clang_version__]
> > +set version_start_index [string last "(" __clang_version__]
> > +set version_string [string range __clang_version__
> $version_start_index+5 $total_length-2]
> > +set version_updated_string [string map {. -} $version_string]
> > +set compiler_info "intel-$version_updated_string"
> >  #endif
> > diff --git a/gdb/testsuite/lib/fortran.exp b/gdb/testsuite/lib/fortran.exp
> > index ee7fe12ad9..a97c6eeb4e 100644
> > --- a/gdb/testsuite/lib/fortran.exp
> > +++ b/gdb/testsuite/lib/fortran.exp
> > @@ -160,7 +160,8 @@ proc fortran_character1 {} {
> >  proc fortran_main {} {
> >      if {[test_compiler_info {gcc-4-[012]-*}]
> >           || [test_compiler_info {gcc-*}]
> > -         || [test_compiler_info {icc-*}]} {
> > +         || [test_compiler_info {icc-*}]
> > +         || [test_compiler_info {intel-*}]} {
> >  	return "MAIN__"
> >      } elseif {[test_compiler_info {clang-*}]} {
> >  	return "MAIN_"
> > --
> > 2.25.1
> >
> > 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
> >

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

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

[Andrew Burgess]

* 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

RE: [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

Re: [RFC][PATCH 1/1] gdb/testsuite: enable __INTEL_LLVM_COMPILER preprocessor in get_compiler_info

[Andrew Burgess]

I've pushed this patch.

Thanks,
Andrew


* Nils-Christian Kempke via Gdb-patches <gdb-patches@sourceware.org> [2022-01-11 18:12:40 +0100]:

> Intel Next Gen compiler defines preprocessor __INTEL_LLVM_COMPILER and provides
> version info in __clang_version__ e.g. value: 12.0.0 (icx 2020.10.0.1113).
> 
> gdb/testsuite/ChangeLog:
> 2020-12-07  Abdul Basit Ijaz  <abdul.b.ijaz@intel.com>
> 
> 	* lib/compiler.c: Add Intel next gen compiler pre-processor check.
> 	* lib/compiler.cc: Ditto.
> 	* lib/fortran.exp (fortran_main): Check Intel next gen compiler in
> 	test_compiler_info.
> ---
>  gdb/testsuite/lib/compiler.c  | 9 +++++++++
>  gdb/testsuite/lib/compiler.cc | 9 +++++++++
>  gdb/testsuite/lib/fortran.exp | 3 ++-
>  3 files changed, 20 insertions(+), 1 deletion(-)
> 
> diff --git a/gdb/testsuite/lib/compiler.c b/gdb/testsuite/lib/compiler.c
> index 191bced041..4cab1c5052 100644
> --- a/gdb/testsuite/lib/compiler.c
> +++ b/gdb/testsuite/lib/compiler.c
> @@ -67,4 +67,13 @@ set icc_major [string range __ICL 0 1]
>  set icc_minor [format "%d" [string range __ICL 2 [expr {[string length __ICL] -1}]]]
>  set icc_update __INTEL_COMPILER_UPDATE
>  set compiler_info [join "icc $icc_major $icc_minor $icc_update" -]
> +#elif defined(__INTEL_LLVM_COMPILER) && defined(__clang_version__)
> +/* Intel Next Gen compiler defines preprocessor __INTEL_LLVM_COMPILER and
> +   provides version info in __clang_version__ e.g. value:
> +   "12.0.0 (icx 2020.10.0.1113)". */
> +set total_length [string length __clang_version__]
> +set version_start_index [string last "(" __clang_version__]
> +set version_string [string range __clang_version__ $version_start_index+5 $total_length-2]
> +set version_updated_string [string map {. -} $version_string]
> +set compiler_info "intel-$version_updated_string"
>  #endif
> diff --git a/gdb/testsuite/lib/compiler.cc b/gdb/testsuite/lib/compiler.cc
> index ab36bea43a..fa9059c68d 100755
> --- a/gdb/testsuite/lib/compiler.cc
> +++ b/gdb/testsuite/lib/compiler.cc
> @@ -55,4 +55,13 @@ set icc_major [string range __ICL 0 1]
>  set icc_minor [format "%d" [string range __ICL 2 [expr {[string length __ICL] -1}]]]
>  set icc_update __INTEL_COMPILER_UPDATE
>  set compiler_info [join "icc $icc_major $icc_minor $icc_update" -]
> +#elif defined(__INTEL_LLVM_COMPILER) && defined(__clang_version__)
> +/* Intel Next Gen compiler defines preprocessor __INTEL_LLVM_COMPILER and
> +   provides version info in __clang_version__ e.g. value:
> +   "12.0.0 (icx 2020.10.0.1113)". */
> +set total_length [string length __clang_version__]
> +set version_start_index [string last "(" __clang_version__]
> +set version_string [string range __clang_version__ $version_start_index+5 $total_length-2]
> +set version_updated_string [string map {. -} $version_string]
> +set compiler_info "intel-$version_updated_string"
>  #endif
> diff --git a/gdb/testsuite/lib/fortran.exp b/gdb/testsuite/lib/fortran.exp
> index ee7fe12ad9..a97c6eeb4e 100644
> --- a/gdb/testsuite/lib/fortran.exp
> +++ b/gdb/testsuite/lib/fortran.exp
> @@ -160,7 +160,8 @@ proc fortran_character1 {} {
>  proc fortran_main {} {
>      if {[test_compiler_info {gcc-4-[012]-*}]
>           || [test_compiler_info {gcc-*}]
> -         || [test_compiler_info {icc-*}]} {
> +         || [test_compiler_info {icc-*}]
> +         || [test_compiler_info {intel-*}]} {
>  	return "MAIN__"
>      } elseif {[test_compiler_info {clang-*}]} {
>  	return "MAIN_"
> -- 
> 2.25.1
> 
> 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
>