Re: [petsc-dev] GCC8 Fortran length changes from int to size_t

[Smith, Barry F.]

> On May 7, 2018, at 3:56 AM, Lisandro Dalcin  wrote:
> 
> On Mon, 7 May 2018 at 03:11, Jed Brown  wrote:
> 
>> Lisandro Dalcin  writes:
> 
> How do you exactly want to implement that? Totally replace these
> special functions with the BIND(C) interface that calls directly the
> C
> function, or rather generate a native Fortran subroutine that calls
> the C function through a BIND(C) interface?
>>> 
 The latter.  Usage should not change for existing Fortran users.
>>> 
>>> Things may end up being involved anyway, even if using ISO_C_BINDINGS.
>>> 
>>> http://fortranwiki.org/fortran/show/Generating+C+Interfaces#strings
> 
>> I guess I don't understand.  Are you concerned about the string copying?
>> Note that FIXCHAR (used in current interfaces) allocates memory.
> 
> Well, no, my point is that an automatic interface generator based on
> ISO_C_BINDINGS (as Barry wanted) may prove slightly harder to implement
> than expected.

   I see no benefit in using the ISO_C_BINDINGS for the Fortran functions with 
char * arguments either automatically or manually so let's stick to the current 
model.

   Barry

> 
> 
> -- 
> Lisandro Dalcin
> 
> Research Scientist
> Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
> Extreme Computing Research Center (ECRC)
> King Abdullah University of Science and Technology (KAUST)
> http://ecrc.kaust.edu.sa/
> 
> 4700 King Abdullah University of Science and Technology
> al-Khawarizmi Bldg (Bldg 1), Office # 0109
> Thuwal 23955-6900, Kingdom of Saudi Arabia
> http://www.kaust.edu.sa
> 
> Office Phone: +966 12 808-0459

Re: [petsc-dev] GCC8 Fortran length changes from int to size_t

[Lisandro Dalcin]

On Mon, 7 May 2018 at 03:11, Jed Brown  wrote:

> Lisandro Dalcin  writes:

> >> > How do you exactly want to implement that? Totally replace these
> >> > special functions with the BIND(C) interface that calls directly the
C
> >> > function, or rather generate a native Fortran subroutine that calls
> >> > the C function through a BIND(C) interface?
> >
> >> The latter.  Usage should not change for existing Fortran users.
> >
> > Things may end up being involved anyway, even if using ISO_C_BINDINGS.
> >
> > http://fortranwiki.org/fortran/show/Generating+C+Interfaces#strings

> I guess I don't understand.  Are you concerned about the string copying?
> Note that FIXCHAR (used in current interfaces) allocates memory.

Well, no, my point is that an automatic interface generator based on
ISO_C_BINDINGS (as Barry wanted) may prove slightly harder to implement
than expected.


-- 
Lisandro Dalcin

Research Scientist
Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
Extreme Computing Research Center (ECRC)
King Abdullah University of Science and Technology (KAUST)
http://ecrc.kaust.edu.sa/

4700 King Abdullah University of Science and Technology
al-Khawarizmi Bldg (Bldg 1), Office # 0109
Thuwal 23955-6900, Kingdom of Saudi Arabia
http://www.kaust.edu.sa

Office Phone: +966 12 808-0459

Re: [petsc-dev] GCC8 Fortran length changes from int to size_t

[Jed Brown]

Lisandro Dalcin  writes:

>> > How do you exactly want to implement that? Totally replace these
>> > special functions with the BIND(C) interface that calls directly the C
>> > function, or rather generate a native Fortran subroutine that calls
>> > the C function through a BIND(C) interface?
>
>> The latter.  Usage should not change for existing Fortran users.
>
> Things may end up being involved anyway, even if using ISO_C_BINDINGS.
>
> http://fortranwiki.org/fortran/show/Generating+C+Interfaces#strings

I guess I don't understand.  Are you concerned about the string copying?
Note that FIXCHAR (used in current interfaces) allocates memory.

Re: [petsc-dev] GCC8 Fortran length changes from int to size_t

[Lisandro Dalcin]

On Thu, 3 May 2018 at 20:21, Jed Brown  wrote:

> Lisandro Dalcin  writes:

> > On 3 May 2018 at 18:50, Smith, Barry F.  wrote:
> >>
> >>Jeff, (and others),
> >>
> >>  Do you know of a tool that can take a C prototype and
automatically generate the Fortran C binding interface definition? We
currently generate stubs for C functions that have character arguments
manually and it would be great to remove that manual step.
> >>
> >
> > How do you exactly want to implement that? Totally replace these
> > special functions with the BIND(C) interface that calls directly the C
> > function, or rather generate a native Fortran subroutine that calls
> > the C function through a BIND(C) interface?

> The latter.  Usage should not change for existing Fortran users.

Things may end up being involved anyway, even if using ISO_C_BINDINGS.

http://fortranwiki.org/fortran/show/Generating+C+Interfaces#strings



-- 
Lisandro Dalcin

Research Scientist
Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
Extreme Computing Research Center (ECRC)
King Abdullah University of Science and Technology (KAUST)
http://ecrc.kaust.edu.sa/

4700 King Abdullah University of Science and Technology
al-Khawarizmi Bldg (Bldg 1), Office # 0109
Thuwal 23955-6900, Kingdom of Saudi Arabia
http://www.kaust.edu.sa

Office Phone: +966 12 808-0459

Re: [petsc-dev] GCC8 Fortran length changes from int to size_t

[Jed Brown]

Jed Brown  writes:

> Huh?  Or a test that uses enough arguments to not pass in registers if
> you insist on creating a test failure.  Alternatively, do what the
> documentation says.  If you doubt the documentation, we can check the
> assembly.
>
> $ cat stringarg.f 
> 
>   subroutine stringarg(s) 
>   
>   
>   character(*) s
>   end
>
> With gfortran-7.3.1:
>
>   push   rbp  
>   
>   
> 0001  movrbp,rsp
> 0004  movQWORD PTR [rbp-0x8],rdi
> 0008  movDWORD PTR [rbp-0xc],esi
> 000b  moveax,DWORD PTR [rbp-0xc]
> 000e  cdqe   
> 0010  movrdx,rax
> 0013  movecx,0x0
> 0018  poprbp
> 0019  ret
>
>
> Note the use of esi instead of rsi for the integer argument:
>
> 0008  movDWORD PTR [rbp-0xc],esi
>
> Presumably if you build with gfortran-8.1, the analogous line will use
> rsi.

Confirmed with gfortran-8.1:

  push   rbp
0001  movrbp,rsp
0004  movQWORD PTR [rbp-0x8],rdi
0008  movQWORD PTR [rbp-0x10],rsi
000c  movrax,QWORD PTR [rbp-0x10]
0010  movrdx,rax
0013  movecx,0x0
0018  poprbp
0019  ret

Re: [petsc-dev] GCC8 Fortran length changes from int to size_t

[Jeff Hammond]

Yes.  John Linford (formerly of ParaTools, Inc. aka TAU team, now at ARM)
developed such a thing for OpenSHMEM.

Jeff

-- Forwarded message --
I've written a Fortran bindings generator that uses ISO_C_BINDING to link a
Fortran code to any SHMEM implementation with C linkage:
https://github.com/jlinford/shmem_iso_c_binding. shmem.f90 in that repo
provides the complete OpenSHMEM 1.2 API.

We can use this and the TAU Performance System to automatically generate
Fortran interfaces for just about any OpenSHMEM implementation, and to
update bindings as the API expands, in support of
https://github.com/openshmem-org/specification/pull/48.

There are some quirks of using ISO_C_BINDING, e.g. shmem_malloc needs a
following call to c_f_pointer and C_PTRDIFF_T isn't available in some
compilers so I used C_INTPTR_T as a workaround.   See rotput.f90 in the
repo for details.


On Thu, May 3, 2018 at 8:50 AM, Smith, Barry F.  wrote:

>
>Jeff, (and others),
>
>  Do you know of a tool that can take a C prototype and automatically
> generate the Fortran C binding interface definition? We currently generate
> stubs for C functions that have character arguments manually and it would
> be great to remove that manual step.
>
>Thanks
>
>   Barry
>
>
> > On May 2, 2018, at 11:42 PM, Jeff Hammond 
> wrote:
> >
> > Or you could just use ISO_C_BINDING.  Decent compilers should support it.
> >
> > On Wed, May 2, 2018 at 8:56 AM, Jed Brown  wrote:
> > See Fortran Language Issues.
> >
> >   https://gcc.gnu.org/gcc-8/porting_to.html
> >
> > We'll have to test for this (probably compiler version) and change the
> > PETSC_MIXED_LEN / PETSC_END_LEN to use size_t instead of int.
> >
> >
> >
> > --
> > Jeff Hammond
> > jeff.scie...@gmail.com
> > http://jeffhammond.github.io/
>
>


-- 
Jeff Hammond
jeff.scie...@gmail.com
http://jeffhammond.github.io/

Re: [petsc-dev] GCC8 Fortran length changes from int to size_t

[Jed Brown]

Lisandro Dalcin  writes:

> On 3 May 2018 at 18:50, Smith, Barry F.  wrote:
>>
>>Jeff, (and others),
>>
>>  Do you know of a tool that can take a C prototype and automatically 
>> generate the Fortran C binding interface definition? We currently generate 
>> stubs for C functions that have character arguments manually and it would be 
>> great to remove that manual step.
>>
>
> How do you exactly want to implement that? Totally replace these
> special functions with the BIND(C) interface that calls directly the C
> function, or rather generate a native Fortran subroutine that calls
> the C function through a BIND(C) interface?

The latter.  Usage should not change for existing Fortran users.

Re: [petsc-dev] GCC8 Fortran length changes from int to size_t

[Lisandro Dalcin]

On 3 May 2018 at 18:50, Smith, Barry F.  wrote:
>
>Jeff, (and others),
>
>  Do you know of a tool that can take a C prototype and automatically 
> generate the Fortran C binding interface definition? We currently generate 
> stubs for C functions that have character arguments manually and it would be 
> great to remove that manual step.
>

How do you exactly want to implement that? Totally replace these
special functions with the BIND(C) interface that calls directly the C
function, or rather generate a native Fortran subroutine that calls
the C function through a BIND(C) interface?




-- 
Lisandro Dalcin

Research Scientist
Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
Extreme Computing Research Center (ECRC)
King Abdullah University of Science and Technology (KAUST)
http://ecrc.kaust.edu.sa/

4700 King Abdullah University of Science and Technology
al-Khawarizmi Bldg (Bldg 1), Office # 0109
Thuwal 23955-6900, Kingdom of Saudi Arabia
http://www.kaust.edu.sa

Office Phone: +966 12 808-0459

Re: [petsc-dev] GCC8 Fortran length changes from int to size_t

[Smith, Barry F.]

   Jeff, (and others),

 Do you know of a tool that can take a C prototype and automatically 
generate the Fortran C binding interface definition? We currently generate 
stubs for C functions that have character arguments manually and it would be 
great to remove that manual step.

   Thanks

  Barry


> On May 2, 2018, at 11:42 PM, Jeff Hammond  wrote:
> 
> Or you could just use ISO_C_BINDING.  Decent compilers should support it.
> 
> On Wed, May 2, 2018 at 8:56 AM, Jed Brown  wrote:
> See Fortran Language Issues.
> 
>   https://gcc.gnu.org/gcc-8/porting_to.html
> 
> We'll have to test for this (probably compiler version) and change the
> PETSC_MIXED_LEN / PETSC_END_LEN to use size_t instead of int.
> 
> 
> 
> -- 
> Jeff Hammond
> jeff.scie...@gmail.com
> http://jeffhammond.github.io/

Re: [petsc-dev] GCC8 Fortran length changes from int to size_t

[Jed Brown]

I think we still have to support some laggard compilers, but also,
Fortran compilation is dog slow.  Just compiling the interfaces takes as
long as compiling all the C in PETSc (including Fortran stubs).

Jeff Hammond  writes:

> Or you could just use ISO_C_BINDING.  Decent compilers should support it.
>
> On Wed, May 2, 2018 at 8:56 AM, Jed Brown  wrote:
>
>> See Fortran Language Issues.
>>
>>   https://gcc.gnu.org/gcc-8/porting_to.html
>>
>> We'll have to test for this (probably compiler version) and change the
>> PETSC_MIXED_LEN / PETSC_END_LEN to use size_t instead of int.
>>
>
>
>
> -- 
> Jeff Hammond
> jeff.scie...@gmail.com
> http://jeffhammond.github.io/

Re: [petsc-dev] GCC8 Fortran length changes from int to size_t

[Jeff Hammond]

Or you could just use ISO_C_BINDING.  Decent compilers should support it.

On Wed, May 2, 2018 at 8:56 AM, Jed Brown  wrote:

> See Fortran Language Issues.
>
>   https://gcc.gnu.org/gcc-8/porting_to.html
>
> We'll have to test for this (probably compiler version) and change the
> PETSC_MIXED_LEN / PETSC_END_LEN to use size_t instead of int.
>



-- 
Jeff Hammond
jeff.scie...@gmail.com
http://jeffhammond.github.io/

Re: [petsc-dev] GCC8 Fortran length changes from int to size_t

[Jed Brown]

Huh?  Or a test that uses enough arguments to not pass in registers if
you insist on creating a test failure.  Alternatively, do what the
documentation says.  If you doubt the documentation, we can check the
assembly.

$ cat stringarg.f   
  
  subroutine stringarg(s)   

  
  character(*) s
  end

With gfortran-7.3.1:

  push   rbp

  
0001  movrbp,rsp
0004  movQWORD PTR [rbp-0x8],rdi
0008  movDWORD PTR [rbp-0xc],esi
000b  moveax,DWORD PTR [rbp-0xc]
000e  cdqe   
0010  movrdx,rax
0013  movecx,0x0
0018  poprbp
0019  ret


Note the use of esi instead of rsi for the integer argument:

0008  movDWORD PTR [rbp-0xc],esi

Presumably if you build with gfortran-8.1, the analogous line will use
rsi.

Satish Balay  writes:

> So we need a 64bit arm with gcc8 - for this testcase failure?
>
> Satish
>
> On Wed, 2 May 2018, Jed Brown wrote:
>
>> On x86-64 Linux, the first six integer arguments are passed in registers
>> (rdi, rsi, rdx, rcx, r8, r9).  Multiple smaller integers are not packed
>> into these registers, but they are accessed as 32-bit (edi, ...).
>> 
>> Satish Balay  writes:
>> 
>> > Well it should atleast bite for functions that have 2 char arguments. 
>> > Perhaps
>> > none of the tests are using these routines..
>> >
>> > Satish
>> >
>> > On Wed, 2 May 2018, Jed Brown wrote:
>> >
>> >> Is the length passed in registers and incorrectly using the lower half
>> >> of the register provides the int part?
>> >> 
>> >> Satish Balay  writes:
>> >> 
>> >> > hm - I have gfortran-8 on my laptop - but haven't seen any testsuite 
>> >> > regressions due to this change.
>> >> >
>> >> > Satish
>> >> >
>> >> > On Wed, 2 May 2018, Jed Brown wrote:
>> >> >
>> >> >> See Fortran Language Issues.
>> >> >> 
>> >> >>   https://gcc.gnu.org/gcc-8/porting_to.html
>> >> >> 
>> >> >> We'll have to test for this (probably compiler version) and change the
>> >> >> PETSC_MIXED_LEN / PETSC_END_LEN to use size_t instead of int.
>> >> >> 
>> >> 
>> 

Re: [petsc-dev] GCC8 Fortran length changes from int to size_t

[Jed Brown]

Matthew Knepley  writes:

> On Wed, May 2, 2018 at 1:14 PM, Jed Brown  wrote:
>
>> Matthew Knepley  writes:
>>
>> > On Wed, May 2, 2018 at 12:15 PM, Jed Brown  wrote:
>> >
>> >> Lisandro Dalcin  writes:
>> >>
>> >> > On Wed, 2 May 2018 at 17:29, Satish Balay  wrote:
>> >> >
>> >> >> So we need a 64bit arm with gcc8 - for this testcase failure?
>> >> >
>> >> >
>> >> > Or a big-endian machine/OS ?
>> >>
>> >> Shouldn't be necessary, but why are we so concerned about making a test
>> >> case fail instead of implementing correct behavior?
>> >>
>> >
>> > How would you know your fix was correct?
>>
>> Documentation and/or reading assembly.
>
>
> Its good that tests are superfluous for code you write because it conforms
> to standards and
> you check the assembly. We should take out all the SF tests. That would
> decrease runtime.

Dude, it's nothing alike.  This is about a calling convention (something
not defined by the standard, and where "getting it wrong" gives
undefined behavior rather than a defined error).  The current configure
does not attempt to get a failing test for HAVE_FORTRAN_MIXED_STR_ARG,
which is the closest analogy.  Your insistence on us demonstrating
failing code is like being informed of an obvious security hole (e.g.,
unvalidated sprintf) and insisting on a working exploit before patching.

Re: [petsc-dev] GCC8 Fortran length changes from int to size_t

[Matthew Knepley]

On Wed, May 2, 2018 at 1:14 PM, Jed Brown  wrote:

> Matthew Knepley  writes:
>
> > On Wed, May 2, 2018 at 12:15 PM, Jed Brown  wrote:
> >
> >> Lisandro Dalcin  writes:
> >>
> >> > On Wed, 2 May 2018 at 17:29, Satish Balay  wrote:
> >> >
> >> >> So we need a 64bit arm with gcc8 - for this testcase failure?
> >> >
> >> >
> >> > Or a big-endian machine/OS ?
> >>
> >> Shouldn't be necessary, but why are we so concerned about making a test
> >> case fail instead of implementing correct behavior?
> >>
> >
> > How would you know your fix was correct?
>
> Documentation and/or reading assembly.


Its good that tests are superfluous for code you write because it conforms
to standards and
you check the assembly. We should take out all the SF tests. That would
decrease runtime.

   Matt


>   I don't have gfortran-8
> installed yet, but Satish says he does so I offered a tiny snippet that
> can be used to confirm that the documentation isn't lying.  If you
> really care to make code crash, we can do that too (as I described).
>



-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

https://www.cse.buffalo.edu/~knepley/ 

Re: [petsc-dev] GCC8 Fortran length changes from int to size_t

[Jed Brown]

Matthew Knepley  writes:

> On Wed, May 2, 2018 at 12:15 PM, Jed Brown  wrote:
>
>> Lisandro Dalcin  writes:
>>
>> > On Wed, 2 May 2018 at 17:29, Satish Balay  wrote:
>> >
>> >> So we need a 64bit arm with gcc8 - for this testcase failure?
>> >
>> >
>> > Or a big-endian machine/OS ?
>>
>> Shouldn't be necessary, but why are we so concerned about making a test
>> case fail instead of implementing correct behavior?
>>
>
> How would you know your fix was correct?

Documentation and/or reading assembly.  I don't have gfortran-8
installed yet, but Satish says he does so I offered a tiny snippet that
can be used to confirm that the documentation isn't lying.  If you
really care to make code crash, we can do that too (as I described).

Re: [petsc-dev] GCC8 Fortran length changes from int to size_t

[Matthew Knepley]

On Wed, May 2, 2018 at 12:15 PM, Jed Brown  wrote:

> Lisandro Dalcin  writes:
>
> > On Wed, 2 May 2018 at 17:29, Satish Balay  wrote:
> >
> >> So we need a 64bit arm with gcc8 - for this testcase failure?
> >
> >
> > Or a big-endian machine/OS ?
>
> Shouldn't be necessary, but why are we so concerned about making a test
> case fail instead of implementing correct behavior?
>

How would you know your fix was correct?

   Matt

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

https://www.cse.buffalo.edu/~knepley/ 

Re: [petsc-dev] GCC8 Fortran length changes from int to size_t

[Jed Brown]

Lisandro Dalcin  writes:

> On Wed, 2 May 2018 at 17:29, Satish Balay  wrote:
>
>> So we need a 64bit arm with gcc8 - for this testcase failure?
>
>
> Or a big-endian machine/OS ?

Shouldn't be necessary, but why are we so concerned about making a test
case fail instead of implementing correct behavior?

Re: [petsc-dev] GCC8 Fortran length changes from int to size_t

[Lisandro Dalcin]

On Wed, 2 May 2018 at 17:29, Satish Balay  wrote:

> So we need a 64bit arm with gcc8 - for this testcase failure?


Or a big-endian machine/OS ?


-- 
Lisandro Dalcin

Research Scientist
Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
Extreme Computing Research Center (ECRC)
King Abdullah University of Science and Technology (KAUST)
http://ecrc.kaust.edu.sa/

4700 King Abdullah University of Science and Technology
al-Khawarizmi Bldg (Bldg 1), Office # 0109
Thuwal 23955-6900, Kingdom of Saudi Arabia
http://www.kaust.edu.sa

Office Phone: +966 12 808-0459

Re: [petsc-dev] GCC8 Fortran length changes from int to size_t

[Satish Balay]

So we need a 64bit arm with gcc8 - for this testcase failure?

Satish

On Wed, 2 May 2018, Jed Brown wrote:

> On x86-64 Linux, the first six integer arguments are passed in registers
> (rdi, rsi, rdx, rcx, r8, r9).  Multiple smaller integers are not packed
> into these registers, but they are accessed as 32-bit (edi, ...).
> 
> Satish Balay  writes:
> 
> > Well it should atleast bite for functions that have 2 char arguments. 
> > Perhaps
> > none of the tests are using these routines..
> >
> > Satish
> >
> > On Wed, 2 May 2018, Jed Brown wrote:
> >
> >> Is the length passed in registers and incorrectly using the lower half
> >> of the register provides the int part?
> >> 
> >> Satish Balay  writes:
> >> 
> >> > hm - I have gfortran-8 on my laptop - but haven't seen any testsuite 
> >> > regressions due to this change.
> >> >
> >> > Satish
> >> >
> >> > On Wed, 2 May 2018, Jed Brown wrote:
> >> >
> >> >> See Fortran Language Issues.
> >> >> 
> >> >>   https://gcc.gnu.org/gcc-8/porting_to.html
> >> >> 
> >> >> We'll have to test for this (probably compiler version) and change the
> >> >> PETSC_MIXED_LEN / PETSC_END_LEN to use size_t instead of int.
> >> >> 
> >> 
> 

Re: [petsc-dev] GCC8 Fortran length changes from int to size_t

[Jed Brown]

On x86-64 Linux, the first six integer arguments are passed in registers
(rdi, rsi, rdx, rcx, r8, r9).  Multiple smaller integers are not packed
into these registers, but they are accessed as 32-bit (edi, ...).

Satish Balay  writes:

> Well it should atleast bite for functions that have 2 char arguments. Perhaps
> none of the tests are using these routines..
>
> Satish
>
> On Wed, 2 May 2018, Jed Brown wrote:
>
>> Is the length passed in registers and incorrectly using the lower half
>> of the register provides the int part?
>> 
>> Satish Balay  writes:
>> 
>> > hm - I have gfortran-8 on my laptop - but haven't seen any testsuite 
>> > regressions due to this change.
>> >
>> > Satish
>> >
>> > On Wed, 2 May 2018, Jed Brown wrote:
>> >
>> >> See Fortran Language Issues.
>> >> 
>> >>   https://gcc.gnu.org/gcc-8/porting_to.html
>> >> 
>> >> We'll have to test for this (probably compiler version) and change the
>> >> PETSC_MIXED_LEN / PETSC_END_LEN to use size_t instead of int.
>> >> 
>> 

Re: [petsc-dev] GCC8 Fortran length changes from int to size_t

[Satish Balay]

Well it should atleast bite for functions that have 2 char arguments. Perhaps
none of the tests are using these routines..

Satish

On Wed, 2 May 2018, Jed Brown wrote:

> Is the length passed in registers and incorrectly using the lower half
> of the register provides the int part?
> 
> Satish Balay  writes:
> 
> > hm - I have gfortran-8 on my laptop - but haven't seen any testsuite 
> > regressions due to this change.
> >
> > Satish
> >
> > On Wed, 2 May 2018, Jed Brown wrote:
> >
> >> See Fortran Language Issues.
> >> 
> >>   https://gcc.gnu.org/gcc-8/porting_to.html
> >> 
> >> We'll have to test for this (probably compiler version) and change the
> >> PETSC_MIXED_LEN / PETSC_END_LEN to use size_t instead of int.
> >> 
> 

Re: [petsc-dev] GCC8 Fortran length changes from int to size_t

[Jed Brown]

Is the length passed in registers and incorrectly using the lower half
of the register provides the int part?

Satish Balay  writes:

> hm - I have gfortran-8 on my laptop - but haven't seen any testsuite 
> regressions due to this change.
>
> Satish
>
> On Wed, 2 May 2018, Jed Brown wrote:
>
>> See Fortran Language Issues.
>> 
>>   https://gcc.gnu.org/gcc-8/porting_to.html
>> 
>> We'll have to test for this (probably compiler version) and change the
>> PETSC_MIXED_LEN / PETSC_END_LEN to use size_t instead of int.
>> 

Re: [petsc-dev] GCC8 Fortran length changes from int to size_t

[Satish Balay]

hm - I have gfortran-8 on my laptop - but haven't seen any testsuite 
regressions due to this change.

Satish

On Wed, 2 May 2018, Jed Brown wrote:

> See Fortran Language Issues.
> 
>   https://gcc.gnu.org/gcc-8/porting_to.html
> 
> We'll have to test for this (probably compiler version) and change the
> PETSC_MIXED_LEN / PETSC_END_LEN to use size_t instead of int.
> 

[petsc-dev] GCC8 Fortran length changes from int to size_t

[Jed Brown]

See Fortran Language Issues.

  https://gcc.gnu.org/gcc-8/porting_to.html

We'll have to test for this (probably compiler version) and change the
PETSC_MIXED_LEN / PETSC_END_LEN to use size_t instead of int.