Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Thomas König]

Hi Martin,

I would change "among" to "between" in the sentence below. OK otherwise
(not that I think an OK is really needed in this case).

+ The purpose of the directive is to provide an API among the GCC 
compiler and
+the GNU C Library which would define vector implementations of math 
routines.


Regards

Thomas

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Martin Liška]

On 2/20/19 10:36 AM, Thomas König wrote:
> Hi Martin,
> 
>> Thank you both useful comments! I installed that as r269035.
> 
> Excellent work, thanks!

;)

> 
> Now a final step: Could you also add a short sentence to gcc-9/changes.html ? 
> In German, we have a saying „Tue Gutes und rede darüber“, do good deeds and 
> talk about it 
> 
> Regards, Thomas
> 

Sure, let's document it with patch attached. Btw. the glibc part patch has been 
just approved
and will be available in glibc release 2.30.

Martin
>From 71a1c50d617c88ea9025385e8139d51e77321c81 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Wed, 20 Feb 2019 15:13:52 +0100
Subject: [PATCH] Document Fortran BUILTIN directive.

---
 htdocs/gcc-9/changes.html | 5 +
 1 file changed, 5 insertions(+)

diff --git a/htdocs/gcc-9/changes.html b/htdocs/gcc-9/changes.html
index 4d9f549..ee7aac1 100644
--- a/htdocs/gcc-9/changes.html
+++ b/htdocs/gcc-9/changes.html
@@ -243,6 +243,11 @@ foo (int how)
 which allows the directive to be written on multiple source lines
 with line continuations.
   
+  
+  A new https://gcc.gnu.org/onlinedocs/gfortran/BUILTIN-directive.html#BUILTIN-directive;>BUILTIN directive, has been added.
+The purpose of the directive is to provide an API among the GCC compiler and
+the GNU C Library which would define vector implementations of math routines.
+  
 
 
 
-- 
2.20.1

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Martin Liška]

On 2/20/19 11:45 AM, Bernhard Reutner-Fischer wrote:
> On 20 February 2019 10:57:29 CET, "Martin Liška"  wrote:
>> On 2/20/19 10:52 AM, Bernhard Reutner-Fischer wrote:
>>> Marin,
>>>
>>> +
>>> +@smallexample
>>> +!GCC$ builtin (sinf) attributes simd (notinbranch) if('x86_64')
>>> +@end smallexample
>>> +
>>> +The purpose of the directive is to provide an API among the GCC
>> compiler and
>>> +the GNU C Library which would define vector implementation of
>> math
>> routines.
>
> s/implementation/implementations/
>
> define? Or provide.
>
> Thanks,
>
>>>
>>>  @node Non-Fortran Main Program
>>>  @section Non-Fortran Main Program
>>> --
>>> 2.20.1
>>>
>

 Hello.

 Thank you both useful comments! I installed that as r269035.
>>>
>>> AFAICS you ignored my comment though ;)
>>> thanks,
>>>
>>
>> Hi.
>>
>> I reworded first sentence into:
>> "You can use this directive to define which middle-end built-ins
>> provide vector implementations"
>>
>> That should align with the comment you sent?
> 
> My comment concerned the sentence below the example as per above.
> You committed the version with singular:
> 
> https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/fortran/gfortran.texi;h=39441bdd57f1369ef7b0fccb204934effc07e21b;hp=02ff32f741f1c6f7c1490b6e35ca7e5111ccd21f;hb=f4ed9e9b1f6c918e6141813491577f6e5d346f96;hpb=25395ee8780231bd50f23c64f9df03b500aad940
> 
> thanks,
> 

Ah, yes, now that sentence should be fixed in r269038.

Martin

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Bernhard Reutner-Fischer]

On 20 February 2019 10:57:29 CET, "Martin Liška"  wrote:
>On 2/20/19 10:52 AM, Bernhard Reutner-Fischer wrote:
>> Marin,
>> 
>> +
>> +@smallexample
>> +!GCC$ builtin (sinf) attributes simd (notinbranch) if('x86_64')
>> +@end smallexample
>> +
>> +The purpose of the directive is to provide an API among the GCC
> compiler and
>> +the GNU C Library which would define vector implementation of
>math
> routines.

 s/implementation/implementations/

 define? Or provide.

 Thanks,

>>
>>  @node Non-Fortran Main Program
>>  @section Non-Fortran Main Program
>> --
>> 2.20.1
>>

>>>
>>> Hello.
>>>
>>> Thank you both useful comments! I installed that as r269035.
>> 
>> AFAICS you ignored my comment though ;)
>> thanks,
>> 
>
>Hi.
>
>I reworded first sentence into:
>"You can use this directive to define which middle-end built-ins
>provide vector implementations"
>
>That should align with the comment you sent?

My comment concerned the sentence below the example as per above.
You committed the version with singular:

https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/fortran/gfortran.texi;h=39441bdd57f1369ef7b0fccb204934effc07e21b;hp=02ff32f741f1c6f7c1490b6e35ca7e5111ccd21f;hb=f4ed9e9b1f6c918e6141813491577f6e5d346f96;hpb=25395ee8780231bd50f23c64f9df03b500aad940

thanks,

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Martin Liška]

On 2/20/19 10:52 AM, Bernhard Reutner-Fischer wrote:
> Marin,
> 
> +
> +@smallexample
> +!GCC$ builtin (sinf) attributes simd (notinbranch) if('x86_64')
> +@end smallexample
> +
> +The purpose of the directive is to provide an API among the GCC
 compiler and
> +the GNU C Library which would define vector implementation of math
 routines.
>>>
>>> s/implementation/implementations/
>>>
>>> define? Or provide.
>>>
>>> Thanks,
>>>
>
>  @node Non-Fortran Main Program
>  @section Non-Fortran Main Program
> --
> 2.20.1
>
>>>
>>
>> Hello.
>>
>> Thank you both useful comments! I installed that as r269035.
> 
> AFAICS you ignored my comment though ;)
> thanks,
> 

Hi.

I reworded first sentence into:
"You can use this directive to define which middle-end built-ins provide vector 
implementations"

That should align with the comment you sent?

Martin

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Bernhard Reutner-Fischer]

Marin,

> >>> +
> >>> +@smallexample
> >>> +!GCC$ builtin (sinf) attributes simd (notinbranch) if('x86_64')
> >>> +@end smallexample
> >>> +
> >>> +The purpose of the directive is to provide an API among the GCC
> >> compiler and
> >>> +the GNU C Library which would define vector implementation of math
> >> routines.
> >
> > s/implementation/implementations/
> >
> > define? Or provide.
> >
> > Thanks,
> >
> >>>
> >>>  @node Non-Fortran Main Program
> >>>  @section Non-Fortran Main Program
> >>> --
> >>> 2.20.1
> >>>
> >
>
> Hello.
>
> Thank you both useful comments! I installed that as r269035.

AFAICS you ignored my comment though ;)
thanks,

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Thomas König]

Hi Martin,

> Thank you both useful comments! I installed that as r269035.

Excellent work, thanks!

Now a final step: Could you also add a short sentence to gcc-9/changes.html ? 
In German, we have a saying „Tue Gutes und rede darüber“, do good deeds and 
talk about it 

Regards, Thomas

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Martin Liška]

On 2/20/19 8:06 AM, Bernhard Reutner-Fischer wrote:
> On 19 February 2019 19:18:21 CET, Steve Kargl 
>  wrote:
>> On Mon, Feb 18, 2019 at 02:23:34PM +0100, Martin Liška wrote:
>>>
>>> As I installed all needed patches, I'm sending a documentation entry
>>> for the new functionality.
>>>
>>> Thoughts?
>>
>> See below.  Ok to commit with suggested changes.
>>
>>> Thanks,
>>> Martin
>>
>>> >From 2d304e3b1d734548811f963c5bed1855b5375c43 Mon Sep 17 00:00:00
>> 2001
>>> From: marxin 
>>> Date: Mon, 18 Feb 2019 14:21:56 +0100
>>> Subject: [PATCH] Document Fortran header directive.
>>>
>>> ---
>>>  gcc/fortran/gfortran.texi | 19 +++
>>>  1 file changed, 19 insertions(+)
>>>
>>> diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
>>> index 02ff32f741f..72771a851f7 100644
>>> --- a/gcc/fortran/gfortran.texi
>>> +++ b/gcc/fortran/gfortran.texi
>>> @@ -3596,6 +3596,25 @@ loop that follows.  N is an integer constant
>> specifying the unrolling factor.
>>>  The values of 0 and 1 block any unrolling of the loop.
>>>  
>>>  
>>> +@node BUILTIN directive
>>> +@subsection BUILTIN directive
>>> +
>>> +The syntax of the directive is
>>> +
>>> +@code{!GCC$ BUILTIN (B) attributes simd FLAGS IF('target')}
>>> +
>>> +You can used this directive to define which middle-end built-ins
>> have vector
>>
>> s/used/use
>>
>>> +implementation.  B is name of the middle-end built-in.  FLAGS are
>> optional
>>
>> s/B is/@code{B} is the 
>> S/FLAGS/@code{FLAGS}
>>
>>> +and must have be either "(inbranch)" or "(notinbranch)".  IF
>> statement
>>
>> delete 'have'
>> s/IF/The @code{IF}
>>
>>> +is optional and is used to filter multilib ABIs for that
>>> +the built-in should be vectorized.  Example usage:
>>
>> Change "for that the built-in should be vectorized" to
>> "for the built-in that should be vectorized"
>>
>>
>>> +
>>> +@smallexample
>>> +!GCC$ builtin (sinf) attributes simd (notinbranch) if('x86_64')
>>> +@end smallexample
>>> +
>>> +The purpose of the directive is to provide an API among the GCC
>> compiler and
>>> +the GNU C Library which would define vector implementation of math
>> routines.
> 
> s/implementation/implementations/
> 
> define? Or provide.
> 
> Thanks,
> 
>>>  
>>>  @node Non-Fortran Main Program
>>>  @section Non-Fortran Main Program
>>> -- 
>>> 2.20.1
>>>
> 

Hello.

Thank you both useful comments! I installed that as r269035.

Martin

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Bernhard Reutner-Fischer]

On 19 February 2019 19:18:21 CET, Steve Kargl 
 wrote:
>On Mon, Feb 18, 2019 at 02:23:34PM +0100, Martin Liška wrote:
>> 
>> As I installed all needed patches, I'm sending a documentation entry
>> for the new functionality.
>> 
>> Thoughts?
>
>See below.  Ok to commit with suggested changes.
>
>> Thanks,
>> Martin
>
>> >From 2d304e3b1d734548811f963c5bed1855b5375c43 Mon Sep 17 00:00:00
>2001
>> From: marxin 
>> Date: Mon, 18 Feb 2019 14:21:56 +0100
>> Subject: [PATCH] Document Fortran header directive.
>> 
>> ---
>>  gcc/fortran/gfortran.texi | 19 +++
>>  1 file changed, 19 insertions(+)
>> 
>> diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
>> index 02ff32f741f..72771a851f7 100644
>> --- a/gcc/fortran/gfortran.texi
>> +++ b/gcc/fortran/gfortran.texi
>> @@ -3596,6 +3596,25 @@ loop that follows.  N is an integer constant
>specifying the unrolling factor.
>>  The values of 0 and 1 block any unrolling of the loop.
>>  
>>  
>> +@node BUILTIN directive
>> +@subsection BUILTIN directive
>> +
>> +The syntax of the directive is
>> +
>> +@code{!GCC$ BUILTIN (B) attributes simd FLAGS IF('target')}
>> +
>> +You can used this directive to define which middle-end built-ins
>have vector
>
>s/used/use
>
>> +implementation.  B is name of the middle-end built-in.  FLAGS are
>optional
>
>s/B is/@code{B} is the 
>S/FLAGS/@code{FLAGS}
>
>> +and must have be either "(inbranch)" or "(notinbranch)".  IF
>statement
>
>delete 'have'
>s/IF/The @code{IF}
>
>> +is optional and is used to filter multilib ABIs for that
>> +the built-in should be vectorized.  Example usage:
>
>Change "for that the built-in should be vectorized" to
>"for the built-in that should be vectorized"
>
>
>> +
>> +@smallexample
>> +!GCC$ builtin (sinf) attributes simd (notinbranch) if('x86_64')
>> +@end smallexample
>> +
>> +The purpose of the directive is to provide an API among the GCC
>compiler and
>> +the GNU C Library which would define vector implementation of math
>routines.

s/implementation/implementations/

define? Or provide.

Thanks,

>>  
>>  @node Non-Fortran Main Program
>>  @section Non-Fortran Main Program
>> -- 
>> 2.20.1
>> 

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Steve Kargl]

On Mon, Feb 18, 2019 at 02:23:34PM +0100, Martin Liška wrote:
> 
> As I installed all needed patches, I'm sending a documentation entry
> for the new functionality.
> 
> Thoughts?

See below.  Ok to commit with suggested changes.

> Thanks,
> Martin

> >From 2d304e3b1d734548811f963c5bed1855b5375c43 Mon Sep 17 00:00:00 2001
> From: marxin 
> Date: Mon, 18 Feb 2019 14:21:56 +0100
> Subject: [PATCH] Document Fortran header directive.
> 
> ---
>  gcc/fortran/gfortran.texi | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
> index 02ff32f741f..72771a851f7 100644
> --- a/gcc/fortran/gfortran.texi
> +++ b/gcc/fortran/gfortran.texi
> @@ -3596,6 +3596,25 @@ loop that follows.  N is an integer constant 
> specifying the unrolling factor.
>  The values of 0 and 1 block any unrolling of the loop.
>  
>  
> +@node BUILTIN directive
> +@subsection BUILTIN directive
> +
> +The syntax of the directive is
> +
> +@code{!GCC$ BUILTIN (B) attributes simd FLAGS IF('target')}
> +
> +You can used this directive to define which middle-end built-ins have vector

s/used/use

> +implementation.  B is name of the middle-end built-in.  FLAGS are optional

s/B is/@code{B} is the 
S/FLAGS/@code{FLAGS}

> +and must have be either "(inbranch)" or "(notinbranch)".  IF statement

delete 'have'
s/IF/The @code{IF}

> +is optional and is used to filter multilib ABIs for that
> +the built-in should be vectorized.  Example usage:

Change "for that the built-in should be vectorized" to
"for the built-in that should be vectorized"


> +
> +@smallexample
> +!GCC$ builtin (sinf) attributes simd (notinbranch) if('x86_64')
> +@end smallexample
> +
> +The purpose of the directive is to provide an API among the GCC compiler and
> +the GNU C Library which would define vector implementation of math routines.
>  
>  @node Non-Fortran Main Program
>  @section Non-Fortran Main Program
> -- 
> 2.20.1
> 


-- 
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Martin Liška]

On 11/27/18 10:11 PM, Thomas Koenig wrote:
> Am 27.11.18 um 17:22 schrieb Steve Ellcey:
>> Why wouldn't clang (flang) want to use the same mechanism as
>> GCC/gfortran?  I know there is some interest/work going on here for
>> flang and we would like a consistent way to use pre-includes to define
>> SIMD vector functions in both gfortran and flang.  I think this should
>> be documented so flang and other compilers can use it.  Even if no
>> other compilers did use it I think it should be documented because it
>> crosses project/package boundries, i.e. it is created by glibc and used
>> by gfortran.
> 
> Absolutely.
> 
> As soon as this is committed, we should document all the
> specifics in the gfortran manual.
> 
> Regards
> 
> Thomas

Hi.

As I installed all needed patches, I'm sending a documentation entry
for the new functionality.

Thoughts?
Thanks,
Martin
>From 2d304e3b1d734548811f963c5bed1855b5375c43 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Mon, 18 Feb 2019 14:21:56 +0100
Subject: [PATCH] Document Fortran header directive.

---
 gcc/fortran/gfortran.texi | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 02ff32f741f..72771a851f7 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -3596,6 +3596,25 @@ loop that follows.  N is an integer constant specifying the unrolling factor.
 The values of 0 and 1 block any unrolling of the loop.
 
 
+@node BUILTIN directive
+@subsection BUILTIN directive
+
+The syntax of the directive is
+
+@code{!GCC$ BUILTIN (B) attributes simd FLAGS IF('target')}
+
+You can used this directive to define which middle-end built-ins have vector
+implementation.  B is name of the middle-end built-in.  FLAGS are optional
+and must have be either "(inbranch)" or "(notinbranch)".  IF statement
+is optional and is used to filter multilib ABIs for that
+the built-in should be vectorized.  Example usage:
+
+@smallexample
+!GCC$ builtin (sinf) attributes simd (notinbranch) if('x86_64')
+@end smallexample
+
+The purpose of the directive is to provide an API among the GCC compiler and
+the GNU C Library which would define vector implementation of math routines.
 
 @node Non-Fortran Main Program
 @section Non-Fortran Main Program
-- 
2.20.1

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Joseph Myers]

On Mon, 14 Jan 2019, Martin Liška wrote:

> Thanks for review, fixed that in updated version of the patch.
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> Ready to be installed?

This patch is OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Martin Liška]

On 1/11/19 7:06 PM, Joseph Myers wrote:
> On Fri, 11 Jan 2019, Martin Liška wrote:
> 
>> +/* Same as add_prefix, but prepending target_sysroot_hdrs_suffix to prefix. 
>>  */
> 
> Actually, it should be prepending target_system_root, but followed by 
> target_sysroot_hdrs_suffix rather than target_sysroot_suffix.  That is, 
> this function should be following add_sysrooted_prefix more closely.
> 
>> +  if (target_sysroot_hdrs_suffix)
> 
> So this should be "if (target_system_root)" - it needs to be sysrooted 
> even if there is no sysroot headers suffix.
> 
>> +{
>> +  char *sysroot_no_trailing_dir_separator
>> += xstrdup (target_sysroot_hdrs_suffix);
>> +  size_t sysroot_len = strlen (target_sysroot_hdrs_suffix);
> 
> And again this would use target_system_root.
> 
>> +  if (sysroot_len > 0
>> +  && target_sysroot_hdrs_suffix[sysroot_len - 1] == DIR_SEPARATOR)
>> +sysroot_no_trailing_dir_separator[sysroot_len - 1] = '\0';
> 
> Likewise.
> 
>> +  if (target_sysroot_suffix)
>> +prefix = concat (sysroot_no_trailing_dir_separator,
>> + target_sysroot_suffix, prefix, NULL);
> 
> While this would use target_sysroot_hdrs_suffix.
> 

Thanks for review, fixed that in updated version of the patch.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin
>From 8f60e280c40d60b1590d0eb41ce130582c7733a9 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Tue, 20 Nov 2018 15:09:16 +0100
Subject: [PATCH] Extend locations where to seach for Fortran pre-include.

gcc/ChangeLog:

2019-01-14  Martin Liska  

	* Makefile.in: Set TOOL_INCLUDE_DIR and NATIVE_SYSTEM_HEADER_DIR
	for GCC driver.
	* config/gnu-user.h (TARGET_F951_OPTIONS): Add 'finclude%s/' as
	a new argument.
	* gcc.c (add_sysrooted_hdrs_prefix): New function.
	(path_prefix_reset): Move up in the source file.
	(find_fortran_preinclude_file): Make complex search for the
	fortran header files.
---
 gcc/Makefile.in   |   4 +-
 gcc/config/gnu-user.h |   2 +-
 gcc/gcc.c | 103 ++
 3 files changed, 87 insertions(+), 22 deletions(-)

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 2fa9083d1b3..095156bd537 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -2172,7 +2172,9 @@ DRIVER_DEFINES = \
   @TARGET_SYSTEM_ROOT_DEFINE@ \
   $(VALGRIND_DRIVER_DEFINES) \
   $(if $(SHLIB),$(if $(filter yes,@enable_shared@),-DENABLE_SHARED_LIBGCC)) \
-  -DCONFIGURE_SPECS="\"@CONFIGURE_SPECS@\""
+  -DCONFIGURE_SPECS="\"@CONFIGURE_SPECS@\"" \
+  -DTOOL_INCLUDE_DIR=\"$(gcc_tooldir)/include\" \
+  -DNATIVE_SYSTEM_HEADER_DIR=\"$(NATIVE_SYSTEM_HEADER_DIR)\"
 
 CFLAGS-gcc.o += $(DRIVER_DEFINES) -DBASEVER=$(BASEVER_s)
 gcc.o: $(BASEVER)
diff --git a/gcc/config/gnu-user.h b/gcc/config/gnu-user.h
index ba146921655..055a4f0afec 100644
--- a/gcc/config/gnu-user.h
+++ b/gcc/config/gnu-user.h
@@ -151,4 +151,4 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 
 #undef TARGET_F951_OPTIONS
 #define TARGET_F951_OPTIONS "%{!nostdinc:\
-  %:fortran-preinclude-file(-fpre-include= math-vector-fortran.h)}"
+  %:fortran-preinclude-file(-fpre-include= math-vector-fortran.h finclude%s/)}"
diff --git a/gcc/gcc.c b/gcc/gcc.c
index bcd04df1691..797ed36616f 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -2976,6 +2976,44 @@ add_sysrooted_prefix (struct path_prefix *pprefix, const char *prefix,
   add_prefix (pprefix, prefix, component, priority,
 	  require_machine_suffix, os_multilib);
 }
+
+/* Same as add_prefix, but prepending target_sysroot_hdrs_suffix to prefix.  */
+
+static void
+add_sysrooted_hdrs_prefix (struct path_prefix *pprefix, const char *prefix,
+			   const char *component,
+			   /* enum prefix_priority */ int priority,
+			   int require_machine_suffix, int os_multilib)
+{
+  if (!IS_ABSOLUTE_PATH (prefix))
+fatal_error (input_location, "system path %qs is not absolute", prefix);
+
+  if (target_system_root)
+{
+  char *sysroot_no_trailing_dir_separator = xstrdup (target_system_root);
+  size_t sysroot_len = strlen (target_system_root);
+
+  if (sysroot_len > 0
+	  && target_system_root[sysroot_len - 1] == DIR_SEPARATOR)
+	sysroot_no_trailing_dir_separator[sysroot_len - 1] = '\0';
+
+  if (target_sysroot_hdrs_suffix)
+	prefix = concat (sysroot_no_trailing_dir_separator,
+			 target_sysroot_hdrs_suffix, prefix, NULL);
+  else
+	prefix = concat (sysroot_no_trailing_dir_separator, prefix, NULL);
+
+  free (sysroot_no_trailing_dir_separator);
+
+  /* We have to override this because GCC's notion of sysroot
+	 moves along with GCC.  */
+  component = "GCC";
+}
+
+  add_prefix (pprefix, prefix, component, priority,
+	  require_machine_suffix, os_multilib);
+}
+
 
 /* Execute the command specified by the arguments on the current line of spec.
When using pipes, this includes several piped-together commands
@@ -9896,20 +9934,61 @@ debug_level_greater_than_spec_func (int 

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Joseph Myers]

On Fri, 11 Jan 2019, Martin Liška wrote:

> +/* Same as add_prefix, but prepending target_sysroot_hdrs_suffix to prefix.  
> */

Actually, it should be prepending target_system_root, but followed by 
target_sysroot_hdrs_suffix rather than target_sysroot_suffix.  That is, 
this function should be following add_sysrooted_prefix more closely.

> +  if (target_sysroot_hdrs_suffix)

So this should be "if (target_system_root)" - it needs to be sysrooted 
even if there is no sysroot headers suffix.

> +{
> +  char *sysroot_no_trailing_dir_separator
> + = xstrdup (target_sysroot_hdrs_suffix);
> +  size_t sysroot_len = strlen (target_sysroot_hdrs_suffix);

And again this would use target_system_root.

> +  if (sysroot_len > 0
> +   && target_sysroot_hdrs_suffix[sysroot_len - 1] == DIR_SEPARATOR)
> + sysroot_no_trailing_dir_separator[sysroot_len - 1] = '\0';

Likewise.

> +  if (target_sysroot_suffix)
> + prefix = concat (sysroot_no_trailing_dir_separator,
> +  target_sysroot_suffix, prefix, NULL);

While this would use target_sysroot_hdrs_suffix.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Martin Liška]

On 1/9/19 6:15 PM, Joseph Myers wrote:
> On Wed, 9 Jan 2019, Martin Liška wrote:
> 
>> Hi.
>>
>> May I please ping that Joseph. The provided patch should be applicable and
>> I would need help with the proper locations.
> 
> I'm not clear if there is a specific question here, or a patch needing 
> review.  In  I 
> noted a specific issue: TOOL_INCLUDE_DIR should be a non-sysrooted prefix.
> 
> Also, could you clarify what, in the patch 
>  (if that's 
> still the current version),
> 
>> +  add_sysrooted_hdrs_prefix (, argv[2], NULL, 0, 0, false);
> 
> is doing (that is, examples of what sort of prefixes it's adding)?
> 

Hi.

I'm sending updated version of the patch that addresses the 2 notes
mentioned by Joseph.

Martin
>From 531180219809153592100a9eb92ca07b1bf51bda Mon Sep 17 00:00:00 2001
From: marxin 
Date: Tue, 20 Nov 2018 15:09:16 +0100
Subject: [PATCH] Extend locations where to seach for Fortran pre-include.

---
 gcc/Makefile.in   |   4 +-
 gcc/config/gnu-user.h |   2 +-
 gcc/gcc.c | 104 ++
 3 files changed, 88 insertions(+), 22 deletions(-)

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 2fa9083d1b3..095156bd537 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -2172,7 +2172,9 @@ DRIVER_DEFINES = \
   @TARGET_SYSTEM_ROOT_DEFINE@ \
   $(VALGRIND_DRIVER_DEFINES) \
   $(if $(SHLIB),$(if $(filter yes,@enable_shared@),-DENABLE_SHARED_LIBGCC)) \
-  -DCONFIGURE_SPECS="\"@CONFIGURE_SPECS@\""
+  -DCONFIGURE_SPECS="\"@CONFIGURE_SPECS@\"" \
+  -DTOOL_INCLUDE_DIR=\"$(gcc_tooldir)/include\" \
+  -DNATIVE_SYSTEM_HEADER_DIR=\"$(NATIVE_SYSTEM_HEADER_DIR)\"
 
 CFLAGS-gcc.o += $(DRIVER_DEFINES) -DBASEVER=$(BASEVER_s)
 gcc.o: $(BASEVER)
diff --git a/gcc/config/gnu-user.h b/gcc/config/gnu-user.h
index ba146921655..055a4f0afec 100644
--- a/gcc/config/gnu-user.h
+++ b/gcc/config/gnu-user.h
@@ -151,4 +151,4 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 
 #undef TARGET_F951_OPTIONS
 #define TARGET_F951_OPTIONS "%{!nostdinc:\
-  %:fortran-preinclude-file(-fpre-include= math-vector-fortran.h)}"
+  %:fortran-preinclude-file(-fpre-include= math-vector-fortran.h finclude%s/)}"
diff --git a/gcc/gcc.c b/gcc/gcc.c
index bcd04df1691..79e1e7d5f6e 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -2976,6 +2976,45 @@ add_sysrooted_prefix (struct path_prefix *pprefix, const char *prefix,
   add_prefix (pprefix, prefix, component, priority,
 	  require_machine_suffix, os_multilib);
 }
+
+/* Same as add_prefix, but prepending target_sysroot_hdrs_suffix to prefix.  */
+
+static void
+add_sysrooted_hdrs_prefix (struct path_prefix *pprefix, const char *prefix,
+			   const char *component,
+			   /* enum prefix_priority */ int priority,
+			   int require_machine_suffix, int os_multilib)
+{
+  if (!IS_ABSOLUTE_PATH (prefix))
+fatal_error (input_location, "system path %qs is not absolute", prefix);
+
+  if (target_sysroot_hdrs_suffix)
+{
+  char *sysroot_no_trailing_dir_separator
+	= xstrdup (target_sysroot_hdrs_suffix);
+  size_t sysroot_len = strlen (target_sysroot_hdrs_suffix);
+
+  if (sysroot_len > 0
+	  && target_sysroot_hdrs_suffix[sysroot_len - 1] == DIR_SEPARATOR)
+	sysroot_no_trailing_dir_separator[sysroot_len - 1] = '\0';
+
+  if (target_sysroot_suffix)
+	prefix = concat (sysroot_no_trailing_dir_separator,
+			 target_sysroot_suffix, prefix, NULL);
+  else
+	prefix = concat (sysroot_no_trailing_dir_separator, prefix, NULL);
+
+  free (sysroot_no_trailing_dir_separator);
+
+  /* We have to override this because GCC's notion of sysroot
+	 moves along with GCC.  */
+  component = "GCC";
+}
+
+  add_prefix (pprefix, prefix, component, priority,
+	  require_machine_suffix, os_multilib);
+}
+
 
 /* Execute the command specified by the arguments on the current line of spec.
When using pipes, this includes several piped-together commands
@@ -9896,20 +9935,61 @@ debug_level_greater_than_spec_func (int argc, const char **argv)
   return NULL;
 }
 
-/* The function takes 2 arguments: OPTION name and file name.
+static void
+path_prefix_reset (path_prefix *prefix)
+{
+  struct prefix_list *iter, *next;
+  iter = prefix->plist;
+  while (iter)
+{
+  next = iter->next;
+  free (const_cast  (iter->prefix));
+  XDELETE (iter);
+  iter = next;
+}
+  prefix->plist = 0;
+  prefix->max_len = 0;
+}
+
+/* The function takes 3 arguments: OPTION name, file name and location
+   where we search for Fortran modules.
When the FILE is found by find_file, return OPTION=path_to_file.  */
 
 static const char *
 find_fortran_preinclude_file (int argc, const char **argv)
 {
-  if (argc != 2)
+  char *result = NULL;
+  if (argc != 3)
 return NULL;
 
+  struct path_prefix prefixes = { 0, 0, "preinclude" };
+
+  /* Search first for 'finclude' folder location for a header file

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Joseph Myers]

On Wed, 9 Jan 2019, Joseph Myers wrote:

> Also, could you clarify what, in the patch 
>  (if that's 
> still the current version),
> 
> > +  add_sysrooted_hdrs_prefix (, argv[2], NULL, 0, 0, false);
> 
> is doing (that is, examples of what sort of prefixes it's adding)?

(I guess this indicates something for the next revision of the patch - if 
each add_sysrooted_hdrs_prefix call has a comment indicating the sort of 
path you expect to be searched, e.g. 
/usr/include/finclude/, that would help both review and 
subsequent readers of the code.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Joseph Myers]

On Wed, 9 Jan 2019, Martin Liška wrote:

> Hi.
> 
> May I please ping that Joseph. The provided patch should be applicable and
> I would need help with the proper locations.

I'm not clear if there is a specific question here, or a patch needing 
review.  In  I 
noted a specific issue: TOOL_INCLUDE_DIR should be a non-sysrooted prefix.

Also, could you clarify what, in the patch 
 (if that's 
still the current version),

> +  add_sysrooted_hdrs_prefix (, argv[2], NULL, 0, 0, false);

is doing (that is, examples of what sort of prefixes it's adding)?

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Martin Liška]

On 11/30/18 2:51 PM, Martin Liška wrote:
> On 11/27/18 2:40 PM, Martin Liška wrote:
>> On 11/26/18 7:44 PM, Joseph Myers wrote:
>>> On Mon, 26 Nov 2018, Martin Liška wrote:
>>>
> I don't see how this version ensures that NATIVE_SYSTEM_HEADER_DIR is 
> properly sysrooted.  Note there's add_sysrooted_prefix separate from 
> add_prefix (but that's *not* the correct thing to use here because it 
> uses 
> target_sysroot_suffix whereas you need target_sysroot_hdrs_suffix).

 I address that in updated version of the patch.
>>>
>>> However, this version seems to make TOOL_INCLUDE_DIR sysrooted as well.  
>>> I don't think that's correct; TOOL_INCLUDE_DIR ($prefix/$target/include, 
>>> roughly) is a non-sysroot location for headers.  Note that it's not 
>>> sysrooted in cppdefault.c, which is a good guide to which directories 
>>> should or should not be sysrooted, and what order they should come in 
>>> (though as discussed, various of the directories there are not relevant 
>>> for the present issue).
>>>
>>> The patch appears to be against some tree other than current trunk.  At 
>>> least, it shows a function find_fortran_preinclude_file in gcc.c as 
>>> already existing in the diff context, but I see no such function in the 
>>> current sources.
>>>
>>
>> I've just installed a prerequisite patch and now you should be able
>> to apply the patch on top of current trunk.
>>
>> Thanks,
>> Martin
>>
> 
> Hi Joseph.
> 
> About this: I'll be away for next 3 weeks and I'm planning to return to
> this once I'm back. If you find a spare cycles and help me with the
> location which should be searched in find_fortran_preinclude_file, I would
> be happy ;)

Hi.

May I please ping that Joseph. The provided patch should be applicable and
I would need help with the proper locations.

Thanks,
Martin

> 
> Thanks,
> Martin
> 

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Martin Liška]

On 11/27/18 2:40 PM, Martin Liška wrote:
> On 11/26/18 7:44 PM, Joseph Myers wrote:
>> On Mon, 26 Nov 2018, Martin Liška wrote:
>>
 I don't see how this version ensures that NATIVE_SYSTEM_HEADER_DIR is 
 properly sysrooted.  Note there's add_sysrooted_prefix separate from 
 add_prefix (but that's *not* the correct thing to use here because it uses 
 target_sysroot_suffix whereas you need target_sysroot_hdrs_suffix).
>>>
>>> I address that in updated version of the patch.
>>
>> However, this version seems to make TOOL_INCLUDE_DIR sysrooted as well.  
>> I don't think that's correct; TOOL_INCLUDE_DIR ($prefix/$target/include, 
>> roughly) is a non-sysroot location for headers.  Note that it's not 
>> sysrooted in cppdefault.c, which is a good guide to which directories 
>> should or should not be sysrooted, and what order they should come in 
>> (though as discussed, various of the directories there are not relevant 
>> for the present issue).
>>
>> The patch appears to be against some tree other than current trunk.  At 
>> least, it shows a function find_fortran_preinclude_file in gcc.c as 
>> already existing in the diff context, but I see no such function in the 
>> current sources.
>>
> 
> I've just installed a prerequisite patch and now you should be able
> to apply the patch on top of current trunk.
> 
> Thanks,
> Martin
> 

Hi Joseph.

About this: I'll be away for next 3 weeks and I'm planning to return to
this once I'm back. If you find a spare cycles and help me with the
location which should be searched in find_fortran_preinclude_file, I would
be happy ;)

Thanks,
Martin

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Thomas Koenig]

Am 27.11.18 um 17:22 schrieb Steve Ellcey:

Why wouldn't clang (flang) want to use the same mechanism as
GCC/gfortran?  I know there is some interest/work going on here for
flang and we would like a consistent way to use pre-includes to define
SIMD vector functions in both gfortran and flang.  I think this should
be documented so flang and other compilers can use it.  Even if no
other compilers did use it I think it should be documented because it
crosses project/package boundries, i.e. it is created by glibc and used
by gfortran.


Absolutely.

As soon as this is committed, we should document all the
specifics in the gfortran manual.

Regards

Thomas

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Steve Ellcey]

On Mon, 2018-11-26 at 17:35 +0100, Martin Liška wrote:
> On 11/26/18 5:19 PM, Matthias Klose wrote:
> > On 26.11.18 13:20, Martin Liška wrote:
> > > On 11/23/18 7:08 PM, Joseph Myers wrote:
> > > > In the multiarch case, do you want 
> > > > /include/finclude/ or 
> > > > /include//finclude?  (This is where I'd
> > > > hope Debian 
> > > > / Ubuntu GCC people would comment.)
> > > 
> > > Mathias can you please reply to this?
> > 
> > this should not matter, as long as you use the multilib name, and the 
> > correct
> > directory is used with the -m32/-m64/-mabi options.  Are other compilers 
> > like a
> > clang based compiler supposed to access this directory as well? 
> 
> I don't think so.
> 
> > In that case
> > the include directories should be documented.

Why wouldn't clang (flang) want to use the same mechanism as
GCC/gfortran?  I know there is some interest/work going on here for
flang and we would like a consistent way to use pre-includes to define
SIMD vector functions in both gfortran and flang.  I think this should
be documented so flang and other compilers can use it.  Even if no
other compilers did use it I think it should be documented because it
crosses project/package boundries, i.e. it is created by glibc and used
by gfortran.

Steve Ellcey
sell...@cavium.com

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Martin Liška]

On 11/26/18 7:44 PM, Joseph Myers wrote:
> On Mon, 26 Nov 2018, Martin Liška wrote:
> 
>>> I don't see how this version ensures that NATIVE_SYSTEM_HEADER_DIR is 
>>> properly sysrooted.  Note there's add_sysrooted_prefix separate from 
>>> add_prefix (but that's *not* the correct thing to use here because it uses 
>>> target_sysroot_suffix whereas you need target_sysroot_hdrs_suffix).
>>
>> I address that in updated version of the patch.
> 
> However, this version seems to make TOOL_INCLUDE_DIR sysrooted as well.  
> I don't think that's correct; TOOL_INCLUDE_DIR ($prefix/$target/include, 
> roughly) is a non-sysroot location for headers.  Note that it's not 
> sysrooted in cppdefault.c, which is a good guide to which directories 
> should or should not be sysrooted, and what order they should come in 
> (though as discussed, various of the directories there are not relevant 
> for the present issue).
> 
> The patch appears to be against some tree other than current trunk.  At 
> least, it shows a function find_fortran_preinclude_file in gcc.c as 
> already existing in the diff context, but I see no such function in the 
> current sources.
> 

I've just installed a prerequisite patch and now you should be able
to apply the patch on top of current trunk.

Thanks,
Martin

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Martin Liška]

On 11/26/18 7:33 PM, Joseph Myers wrote:
> On Mon, 26 Nov 2018, Martin Liška wrote:
> 
>> The header file will be install by glibc (glibc-devel package).
> 
> To confirm: you intend to submit a patch to glibc upstream to install this 
> file (rather than it only being something in distribution packaging)?
> 

Yes, I've already ask glibc people about it:
https://sourceware.org/ml/libc-help/2018-11/msg00015.html

I would appreciate a help with that.

Martin

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Martin Liška]

On 11/27/18 8:57 AM, Thomas Koenig wrote:
> Hi Martin,
> 
>> he header file will be install by glibc (glibc-devel package).
> 
> Why actually glibc-devel?  Needing glibc-devel for fast compilation
> of Fortran seems to be counter-intuitive. Maybe glibc would be better.

Works for me.

Martin

> 
> Regards
> 
> Thomas

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Thomas Koenig]

Hi Martin,


he header file will be install by glibc (glibc-devel package).


Why actually glibc-devel?  Needing glibc-devel for fast compilation
of Fortran seems to be counter-intuitive. Maybe glibc would be better.

Regards

Thomas

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Joseph Myers]

On Mon, 26 Nov 2018, Martin Liška wrote:

> > I don't see how this version ensures that NATIVE_SYSTEM_HEADER_DIR is 
> > properly sysrooted.  Note there's add_sysrooted_prefix separate from 
> > add_prefix (but that's *not* the correct thing to use here because it uses 
> > target_sysroot_suffix whereas you need target_sysroot_hdrs_suffix).
> 
> I address that in updated version of the patch.

However, this version seems to make TOOL_INCLUDE_DIR sysrooted as well.  
I don't think that's correct; TOOL_INCLUDE_DIR ($prefix/$target/include, 
roughly) is a non-sysroot location for headers.  Note that it's not 
sysrooted in cppdefault.c, which is a good guide to which directories 
should or should not be sysrooted, and what order they should come in 
(though as discussed, various of the directories there are not relevant 
for the present issue).

The patch appears to be against some tree other than current trunk.  At 
least, it shows a function find_fortran_preinclude_file in gcc.c as 
already existing in the diff context, but I see no such function in the 
current sources.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Joseph Myers]

On Mon, 26 Nov 2018, Martin Liška wrote:

> The header file will be install by glibc (glibc-devel package).

To confirm: you intend to submit a patch to glibc upstream to install this 
file (rather than it only being something in distribution packaging)?

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Martin Liška]

On 11/23/18 7:08 PM, Joseph Myers wrote:
> On Fri, 23 Nov 2018, Martin Liška wrote:
> 
>> Looks the problematic is quite complex as I can understand. I prepared a 
>> patch
>> that should hopefully follow advises provided.

Hello.

> 
> I don't see how this version ensures that NATIVE_SYSTEM_HEADER_DIR is 
> properly sysrooted.  Note there's add_sysrooted_prefix separate from 
> add_prefix (but that's *not* the correct thing to use here because it uses 
> target_sysroot_suffix whereas you need target_sysroot_hdrs_suffix).

I address that in updated version of the patch.

> 
> The last argument to add_prefix, which you're setting to true, is 
> os_multilib.  But using the OS multilib scheme seems wrong here, because 
> the OS multilib names are names like "../lib64", which only make sense in 
> directories called lib - you don't want to end up searching a directory 
> /include/finclude/../lib64.

Agree, does not make sense.

> 
> In the multiarch case, do you want 
> /include/finclude/ or 
> /include//finclude?  (This is where I'd hope Debian 
> / Ubuntu GCC people would comment.)
> 

As Mathias wrote he's fine with both of these variants. I've just configure a 
compiler
with --enable-multiarch=yes and I see that the file is eventually searched in:

/usr/include/finclude/i386-linux-gnu/math-vector-fortran.h (with -m32)

and

/usr/include/finclude/x86_64-linux-gnu/math-vector-fortran.h (with -m64)

Which looks fine to me?

Thanks,
Martin

>From 84202b443adc00e0847b17c07e3dbf3451e77fb9 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Tue, 20 Nov 2018 15:09:16 +0100
Subject: [PATCH] Extend locations where to seach for Fortran pre-include.

---
 gcc/Makefile.in   |  4 +-
 gcc/config/gnu-user.h |  2 +-
 gcc/gcc.c | 99 ++-
 3 files changed, 83 insertions(+), 22 deletions(-)

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 16c9ed6c5fd..c6ded7baf79 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -2172,7 +2172,9 @@ DRIVER_DEFINES = \
   @TARGET_SYSTEM_ROOT_DEFINE@ \
   $(VALGRIND_DRIVER_DEFINES) \
   $(if $(SHLIB),$(if $(filter yes,@enable_shared@),-DENABLE_SHARED_LIBGCC)) \
-  -DCONFIGURE_SPECS="\"@CONFIGURE_SPECS@\""
+  -DCONFIGURE_SPECS="\"@CONFIGURE_SPECS@\"" \
+  -DTOOL_INCLUDE_DIR=\"$(gcc_tooldir)/include\" \
+  -DNATIVE_SYSTEM_HEADER_DIR=\"$(NATIVE_SYSTEM_HEADER_DIR)\"
 
 CFLAGS-gcc.o += $(DRIVER_DEFINES) -DBASEVER=$(BASEVER_s)
 gcc.o: $(BASEVER)
diff --git a/gcc/config/gnu-user.h b/gcc/config/gnu-user.h
index d0acfed5116..eff6c7d6f83 100644
--- a/gcc/config/gnu-user.h
+++ b/gcc/config/gnu-user.h
@@ -173,4 +173,4 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 
 #undef TARGET_F951_OPTIONS
 #define TARGET_F951_OPTIONS "%{!nostdinc:\
-  %:fortran-preinclude-file(-fpre-include= math-vector-fortran.h)}"
+  %:fortran-preinclude-file(-fpre-include= math-vector-fortran.h finclude%s/)}"
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 4d01e1e2f3b..7c57fe03b41 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -2976,6 +2976,45 @@ add_sysrooted_prefix (struct path_prefix *pprefix, const char *prefix,
   add_prefix (pprefix, prefix, component, priority,
 	  require_machine_suffix, os_multilib);
 }
+
+/* Same as add_prefix, but prepending target_sysroot_hdrs_suffix to prefix.  */
+
+static void
+add_sysrooted_hdrs_prefix (struct path_prefix *pprefix, const char *prefix,
+			   const char *component,
+			   /* enum prefix_priority */ int priority,
+			   int require_machine_suffix, int os_multilib)
+{
+  if (!IS_ABSOLUTE_PATH (prefix))
+fatal_error (input_location, "system path %qs is not absolute", prefix);
+
+  if (target_sysroot_hdrs_suffix)
+{
+  char *sysroot_no_trailing_dir_separator
+	= xstrdup (target_sysroot_hdrs_suffix);
+  size_t sysroot_len = strlen (target_sysroot_hdrs_suffix);
+
+  if (sysroot_len > 0
+	  && target_sysroot_hdrs_suffix [sysroot_len - 1] == DIR_SEPARATOR)
+	sysroot_no_trailing_dir_separator[sysroot_len - 1] = '\0';
+
+  if (target_sysroot_suffix)
+	prefix = concat (sysroot_no_trailing_dir_separator,
+			 target_sysroot_suffix, prefix, NULL);
+  else
+	prefix = concat (sysroot_no_trailing_dir_separator, prefix, NULL);
+
+  free (sysroot_no_trailing_dir_separator);
+
+  /* We have to override this because GCC's notion of sysroot
+	 moves along with GCC.  */
+  component = "GCC";
+}
+
+  add_prefix (pprefix, prefix, component, priority,
+	  require_machine_suffix, os_multilib);
+}
+
 
 /* Execute the command specified by the arguments on the current line of spec.
When using pipes, this includes several piped-together commands
@@ -9891,20 +9930,56 @@ debug_level_greater_than_spec_func (int argc, const char **argv)
   return NULL;
 }
 
-/* The function takes 2 arguments: OPTION name and file name.
+static void
+path_prefix_reset (path_prefix *prefix)
+{
+  struct prefix_list *iter, *next;
+  iter = prefix->plist;
+  while (iter)
+{
+  next = iter->next;
+  

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Martin Liška]

On 11/26/18 5:19 PM, Matthias Klose wrote:
> On 26.11.18 13:20, Martin Liška wrote:
>> On 11/23/18 7:08 PM, Joseph Myers wrote:
>>> In the multiarch case, do you want 
>>> /include/finclude/ or 
>>> /include//finclude?  (This is where I'd hope Debian 
>>> / Ubuntu GCC people would comment.)
>>
>> Mathias can you please reply to this?
> 
> this should not matter, as long as you use the multilib name, and the correct
> directory is used with the -m32/-m64/-mabi options.  Are other compilers like 
> a
> clang based compiler supposed to access this directory as well? 

I don't think so.

> In that case
> the include directories should be documented.
> 
> One more question: Will GCC itself install header files in these directories, 
> or
> will you have different directories depending on the GCC version (or gfortran
> module version)?

The header file will be install by glibc (glibc-devel package).

Martin

> 
> Matthias
> 

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Matthias Klose]

On 26.11.18 13:20, Martin Liška wrote:
> On 11/23/18 7:08 PM, Joseph Myers wrote:
>> In the multiarch case, do you want 
>> /include/finclude/ or 
>> /include//finclude?  (This is where I'd hope Debian 
>> / Ubuntu GCC people would comment.)
> 
> Mathias can you please reply to this?

this should not matter, as long as you use the multilib name, and the correct
directory is used with the -m32/-m64/-mabi options.  Are other compilers like a
clang based compiler supposed to access this directory as well?  In that case
the include directories should be documented.

One more question: Will GCC itself install header files in these directories, or
will you have different directories depending on the GCC version (or gfortran
module version)?

Matthias

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Martin Liška]

On 11/23/18 7:08 PM, Joseph Myers wrote:
> In the multiarch case, do you want 
> /include/finclude/ or 
> /include//finclude?  (This is where I'd hope Debian 
> / Ubuntu GCC people would comment.)

Mathias can you please reply to this?

Thanks,
Martin

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Joseph Myers]

On Fri, 23 Nov 2018, Martin Liška wrote:

> Looks the problematic is quite complex as I can understand. I prepared a patch
> that should hopefully follow advises provided.

I don't see how this version ensures that NATIVE_SYSTEM_HEADER_DIR is 
properly sysrooted.  Note there's add_sysrooted_prefix separate from 
add_prefix (but that's *not* the correct thing to use here because it uses 
target_sysroot_suffix whereas you need target_sysroot_hdrs_suffix).

The last argument to add_prefix, which you're setting to true, is 
os_multilib.  But using the OS multilib scheme seems wrong here, because 
the OS multilib names are names like "../lib64", which only make sense in 
directories called lib - you don't want to end up searching a directory 
/include/finclude/../lib64.

In the multiarch case, do you want 
/include/finclude/ or 
/include//finclude?  (This is where I'd hope Debian 
/ Ubuntu GCC people would comment.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Martin Liška]

On 11/22/18 3:35 PM, Joseph Myers wrote:
> On Thu, 22 Nov 2018, Martin Liška wrote:
> 
>>> (Multilib suffixes on include directories for C are more or less an 
>>> implementation detail of how fixed headers are arranged in the case where 
>>> sysroot headers suffixes are used; they aren't really expected to be a 
>>> stable interface such that third-party software might install anything 
>>> using them, but I'm not sure if this preinclude is meant to come from 
>>> external software or be installed by GCC. 
>>
>> It will come from glibc-devel package, and it's expected to be installed in:
>> usr/include/finclude/ for 64-bit header
>> and /usr/include/finclude/32/ for the 32-bit header.
> 
> So, to be clear, is that
> 
> /finclude/$($CC 
> $CFLAGS $CPPFLAGS -print-multi-directory)
> 
> ?  (Where glibc would be what uses the $CC $CFLAGS $CPPFLAGS 
> -print-multi-directory to determine where to install the file.)
> 
> If so, you need to make sure that all of those pieces are properly used.
> 
> * The sysroot and headers suffix in the case of a sysrooted toolchain.  
> (Sysroot headers suffixes are for e.g. the case of a toolchain with both 
> glibc and uClibc multilibs, so needing multiple sets of headers.  Most 
> toolchains with multiple sysroots using the same libc only need a single 
> set of headers and don't use sysroot headers suffixes, only sysroot 
> suffixes (non-headers), with appropriate arrangements being made for all 
> the per-multilib headers, such as gnu/lib-names-*.h and gnu/stubs-*.h, to 
> be copied into the common include directory.)
> 
> * The native system header directory (which is /include not /usr/include 
> for GNU Hurd, for example; see config.gcc).
> 
> * Then finclude with the multilib (non-OS) suffix.
> 
> And you need to consider what's right for non-sysrooted toolchains.  If 
> native, the above is right, but without the sysroot-related components.  
> But what about a non-sysrooted cross toolchain?  Certainly using the 
> native directory would be wrong there.
> 
> Also, what's right in the multiarch directory arrangements case - should 
> it be 
> //finclude
>  
> instead?  Would one of the Debian / Ubuntu GCC maintainers like to 
> comment?
> 
> Are there corresponding versions with /usr/local/include 
> (LOCAL_INCLUDE_DIR, in general), before those with 
> NATIVE_SYSTEM_HEADER_DIR?  Even in the driver, the list of directories in 
> cppdefault.c should at least serve as a guide to which directories you 
> want to search and which get sysroots added (of course, the C++-specific 
> ones are irrelevant here).
> 

Hi.

Looks the problematic is quite complex as I can understand. I prepared a patch
that should hopefully follow advises provided.

Thoughts?
Thanks,
Martin
>From b59f043ff448f06ac95981d8a61b0dd63bc58bd7 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Tue, 20 Nov 2018 15:09:16 +0100
Subject: [PATCH] Extend locations where to seach for Fortran pre-include.

---
 gcc/Makefile.in   |  4 ++-
 gcc/config/gnu-user.h |  2 +-
 gcc/gcc.c | 58 ---
 3 files changed, 42 insertions(+), 22 deletions(-)

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 16c9ed6c5fd..c6ded7baf79 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -2172,7 +2172,9 @@ DRIVER_DEFINES = \
   @TARGET_SYSTEM_ROOT_DEFINE@ \
   $(VALGRIND_DRIVER_DEFINES) \
   $(if $(SHLIB),$(if $(filter yes,@enable_shared@),-DENABLE_SHARED_LIBGCC)) \
-  -DCONFIGURE_SPECS="\"@CONFIGURE_SPECS@\""
+  -DCONFIGURE_SPECS="\"@CONFIGURE_SPECS@\"" \
+  -DTOOL_INCLUDE_DIR=\"$(gcc_tooldir)/include\" \
+  -DNATIVE_SYSTEM_HEADER_DIR=\"$(NATIVE_SYSTEM_HEADER_DIR)\"
 
 CFLAGS-gcc.o += $(DRIVER_DEFINES) -DBASEVER=$(BASEVER_s)
 gcc.o: $(BASEVER)
diff --git a/gcc/config/gnu-user.h b/gcc/config/gnu-user.h
index d0acfed5116..eff6c7d6f83 100644
--- a/gcc/config/gnu-user.h
+++ b/gcc/config/gnu-user.h
@@ -173,4 +173,4 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 
 #undef TARGET_F951_OPTIONS
 #define TARGET_F951_OPTIONS "%{!nostdinc:\
-  %:fortran-preinclude-file(-fpre-include= math-vector-fortran.h)}"
+  %:fortran-preinclude-file(-fpre-include= math-vector-fortran.h finclude%s/)}"
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 4d01e1e2f3b..3b8b8eaf1bb 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -9891,20 +9891,54 @@ debug_level_greater_than_spec_func (int argc, const char **argv)
   return NULL;
 }
 
-/* The function takes 2 arguments: OPTION name and file name.
+static void
+path_prefix_reset (path_prefix *prefix)
+{
+  struct prefix_list *iter, *next;
+  iter = prefix->plist;
+  while (iter)
+{
+  next = iter->next;
+  free (const_cast  (iter->prefix));
+  XDELETE (iter);
+  iter = next;
+}
+  prefix->plist = 0;
+  prefix->max_len = 0;
+}
+
+/* The function takes 3 arguments: OPTION name, file name and location
+   where we search for Fortran modules.
When the FILE is found by find_file, return OPTION=path_to_file.  */
 
 static const char *

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Joseph Myers]

On Thu, 22 Nov 2018, Martin Liška wrote:

> > (Multilib suffixes on include directories for C are more or less an 
> > implementation detail of how fixed headers are arranged in the case where 
> > sysroot headers suffixes are used; they aren't really expected to be a 
> > stable interface such that third-party software might install anything 
> > using them, but I'm not sure if this preinclude is meant to come from 
> > external software or be installed by GCC. 
> 
> It will come from glibc-devel package, and it's expected to be installed in:
> usr/include/finclude/ for 64-bit header
> and /usr/include/finclude/32/ for the 32-bit header.

So, to be clear, is that

/finclude/$($CC 
$CFLAGS $CPPFLAGS -print-multi-directory)

?  (Where glibc would be what uses the $CC $CFLAGS $CPPFLAGS 
-print-multi-directory to determine where to install the file.)

If so, you need to make sure that all of those pieces are properly used.

* The sysroot and headers suffix in the case of a sysrooted toolchain.  
(Sysroot headers suffixes are for e.g. the case of a toolchain with both 
glibc and uClibc multilibs, so needing multiple sets of headers.  Most 
toolchains with multiple sysroots using the same libc only need a single 
set of headers and don't use sysroot headers suffixes, only sysroot 
suffixes (non-headers), with appropriate arrangements being made for all 
the per-multilib headers, such as gnu/lib-names-*.h and gnu/stubs-*.h, to 
be copied into the common include directory.)

* The native system header directory (which is /include not /usr/include 
for GNU Hurd, for example; see config.gcc).

* Then finclude with the multilib (non-OS) suffix.

And you need to consider what's right for non-sysrooted toolchains.  If 
native, the above is right, but without the sysroot-related components.  
But what about a non-sysrooted cross toolchain?  Certainly using the 
native directory would be wrong there.

Also, what's right in the multiarch directory arrangements case - should 
it be 
//finclude
 
instead?  Would one of the Debian / Ubuntu GCC maintainers like to 
comment?

Are there corresponding versions with /usr/local/include 
(LOCAL_INCLUDE_DIR, in general), before those with 
NATIVE_SYSTEM_HEADER_DIR?  Even in the driver, the list of directories in 
cppdefault.c should at least serve as a guide to which directories you 
want to search and which get sysroots added (of course, the C++-specific 
ones are irrelevant here).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Martin Liška]

On 11/20/18 7:11 PM, Joseph Myers wrote:
> On Tue, 20 Nov 2018, Jakub Jelinek wrote:
> 
>> hardcoding /usr/include looks just very wrong here.  That should always be
>> dependent on the configured prefix or better be relative from the driver,
>> gcc should be relocatable.  Or at least come from configure.  It should e.g.
>> honor the sysroot stuff etc.
>>
>> That said, I think you need somebody familiar with the driver, perhaps
>> Joseph?

Hi Joseph.

> 
> I'd sort of expect structures like those in cppdefault.[ch] to describe 
> the relevant Fortran directories and their properties (such as being 
> sysrooted or not - and if sysrooted, I suppose you'll want to make sure 
> SYSROOT_HEADERS_SUFFIX_SPEC is properly applied).

We probably forgot to mention that the search mechanism happens in GCC driver.
It's because we want to include the file (via a Fortran -fpre-include) 
conditionally
only when found.

> 
> If this preinclude doesn't pass through the C preprocessor, directories in 
> which it is searched for will need multilib or multiarch suffixes.  

No, it's not C preprocessor.

> (Multilib suffixes on include directories for C are more or less an 
> implementation detail of how fixed headers are arranged in the case where 
> sysroot headers suffixes are used; they aren't really expected to be a 
> stable interface such that third-party software might install anything 
> using them, but I'm not sure if this preinclude is meant to come from 
> external software or be installed by GCC. 

It will come from glibc-devel package, and it's expected to be installed in:
usr/include/finclude/ for 64-bit header
and /usr/include/finclude/32/ for the 32-bit header.

 Multiarch suffixes, for systems 
> using Debian/Ubuntu-style multiarch directory arrangements, *are* intended 
> as a stable interface.  And multilib *OS* suffixes 
> (-print-multi-os-directory) are a stable interface, but only really 
> suitable for libraries, not headers, because they are paths relative to 
> lib/ such as ../lib64.)

If I understand correctly, Jakub wanted to have it working with -m32 being used
for 64-bit GCC compiler. So yes, multi os for header files.

So the question is what can we really do in the GCC driver?

Martin

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Joseph Myers]

On Tue, 20 Nov 2018, Jakub Jelinek wrote:

> hardcoding /usr/include looks just very wrong here.  That should always be
> dependent on the configured prefix or better be relative from the driver,
> gcc should be relocatable.  Or at least come from configure.  It should e.g.
> honor the sysroot stuff etc.
> 
> That said, I think you need somebody familiar with the driver, perhaps
> Joseph?

I'd sort of expect structures like those in cppdefault.[ch] to describe 
the relevant Fortran directories and their properties (such as being 
sysrooted or not - and if sysrooted, I suppose you'll want to make sure 
SYSROOT_HEADERS_SUFFIX_SPEC is properly applied).

If this preinclude doesn't pass through the C preprocessor, directories in 
which it is searched for will need multilib or multiarch suffixes.  
(Multilib suffixes on include directories for C are more or less an 
implementation detail of how fixed headers are arranged in the case where 
sysroot headers suffixes are used; they aren't really expected to be a 
stable interface such that third-party software might install anything 
using them, but I'm not sure if this preinclude is meant to come from 
external software or be installed by GCC.  Multiarch suffixes, for systems 
using Debian/Ubuntu-style multiarch directory arrangements, *are* intended 
as a stable interface.  And multilib *OS* suffixes 
(-print-multi-os-directory) are a stable interface, but only really 
suitable for libraries, not headers, because they are paths relative to 
lib/ such as ../lib64.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Jakub Jelinek]

On Tue, Nov 20, 2018 at 03:14:02PM +0100, Martin Liška wrote:
> Following patch is a follow up of the discussion we had on IRC about
> locations where a Fortran pre-include should be searched.
> 
> With the patch applied I see now:
> $ strace -f -s512 ./xgcc -B. ~/Programming/testcases/usage.F90  -c 2>&1 | 
> grep math-vector
> access("./x86_64-pc-linux-gnu/9.0.0/math-vector-fortran.h", R_OK) = -1 ENOENT 
> (No such file or directory)
> access("./math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or 
> directory)
> access("/home/marxin/bin/gcc2/bin/../include/finclude/x86_64-pc-linux-gnu/9.0.0/math-vector-fortran.h",
>  R_OK) = -1 ENOENT (No such file or directory)
> access("/home/marxin/bin/gcc2/bin/../include/finclude/math-vector-fortran.h", 
> R_OK) = -1 ENOENT (No such file or directory)
> access("/usr/include/finclude/x86_64-pc-linux-gnu/9.0.0/math-vector-fortran.h",
>  R_OK) = -1 ENOENT (No such file or directory)
> access("/usr/include/finclude/math-vector-fortran.h", R_OK) = -1 ENOENT (No 
> such file or directory)
> 
>  static const char *
>  find_fortran_preinclude_file (int argc, const char **argv)
>  {
> +  char *result = NULL;
>if (argc != 2)
>  return NULL;
>  

it doesn't search the same directory as is normally searched for Fortran
modules; that is finclude%s and thus would need to be yet another
argument to this spec internal function and you'd check if
a file exists with that prefix

> +  struct path_prefix prefixes = { 0, 0, "preinclude" };
> +  add_prefix (, STANDARD_BINDIR_PREFIX "../include/finclude/", NULL,
> +   0, 0, 0);
> +  add_prefix (, "/usr/include/finclude/", NULL, 0, 0, 0);

hardcoding /usr/include looks just very wrong here.  That should always be
dependent on the configured prefix or better be relative from the driver,
gcc should be relocatable.  Or at least come from configure.  It should e.g.
honor the sysroot stuff etc.

That said, I think you need somebody familiar with the driver, perhaps
Joseph?

Jakub