Re: [Patch, Fortran] Simplify lbound

2015-05-12 Thread Thomas Koenig
Hi Mikael, To be honest, both patches look fragile to me. Yours because it leaves gfc_current_ns to its value, leaving the door open to other problems. Mine, well, because it's playing with a global variable, with the possible side-effects this could have. However, without a better idea,

Re: [Patch, Fortran] Simplify lbound

2015-05-12 Thread Mikael Morin
Le 12/05/2015 08:43, Thomas Koenig a écrit : Hi Mikael, To be honest, both patches look fragile to me. Yours because it leaves gfc_current_ns to its value, leaving the door open to other problems. Mine, well, because it's playing with a global variable, with the possible side-effects this

Re: [Patch, Fortran] Simplify lbound

2015-05-11 Thread Mikael Morin
Le 11/05/2015 00:08, Thomas Koenig a écrit : Am 10.05.2015 um 22:43 schrieb H.J. Lu: Here is what I have committed. It caused: /export/gnu/import/git/sources/gcc/gcc/testsuite/gfortran.dg/inline_matmul_3.f90:38:39: Error: Variable 'c1' cannot appear in the expression at (1)^M I know

Re: [Patch, Fortran] Simplify lbound

2015-05-10 Thread Thomas Koenig
Am 10.05.2015 um 22:43 schrieb H.J. Lu: Here is what I have committed. It caused: /export/gnu/import/git/sources/gcc/gcc/testsuite/gfortran.dg/inline_matmul_3.f90:38:39: Error: Variable 'c1' cannot appear in the expression at (1)^M I know that error message, I got it when developing the

Re: [Patch, Fortran] Simplify lbound

2015-05-10 Thread H.J. Lu
On Sun, May 10, 2015 at 6:58 AM, Mikael Morin mikael.mo...@sfr.fr wrote: Le 03/05/2015 22:38, Thomas Koenig a écrit : Hi Mikael, Looks good. In general, it is better to restrict changes to existing test cases to the necessary minimum that they still pass, and add new code to new test

Re: [Patch, Fortran] Simplify lbound

2015-05-10 Thread Mikael Morin
Le 03/05/2015 22:38, Thomas Koenig a écrit : Hi Mikael, Looks good. In general, it is better to restrict changes to existing test cases to the necessary minimum that they still pass, and add new code to new test cases. This makes regressions easier to track. So, OK with that change.

Re: [Patch, Fortran] Simplify lbound

2015-05-03 Thread Thomas Koenig
Hi Mikael, Looks good. In general, it is better to restrict changes to existing test cases to the necessary minimum that they still pass, and add new code to new test cases. This makes regressions easier to track. So, OK with that change. Thomas

Re: [Patch, Fortran] Simplify lbound

2015-05-02 Thread H.J. Lu
On Mon, Apr 27, 2015 at 11:45 AM, Thomas Koenig tkoe...@netcologne.de wrote: Am 25.04.2015 um 20:12 schrieb Mikael Morin: I've double-checked in the standard, and it seems it is not possible to simplify after all: If ARRAY is a whole array and either ARRAY is an assumed-size

Re: [Patch, fortran] Simplify lbound for array subcomponents

2015-05-01 Thread Thomas Koenig
Am 27.04.2015 um 13:17 schrieb Mikael Morin: Hello, while reviewing Thomas' bound simplification patch, I noticed that the {l,u}bound simplification code wasn't handling array subcomponents. Fixed by the attached patch, regression tested. OK for trunk? Hi Mikael, the patch is OK. Thanks!

Re: [Patch, Fortran] Simplify lbound

2015-05-01 Thread Mikael Morin
Hello, Le 30/04/2015 20:19, Mikael Morin a écrit : As you may want to simplify in the limited scope of the matmul inlining, I'm giving comments about the patch (otherwise you can ignore them): - No need to check for allocatable or pointer, it should be excluded by as-type == AS_ASSUMED_SHAPE

Re: [Patch, Fortran] Simplify lbound

2015-04-30 Thread Mikael Morin
Le 27/04/2015 20:45, Thomas Koenig a écrit : Am 25.04.2015 um 20:12 schrieb Mikael Morin: I've double-checked in the standard, and it seems it is not possible to simplify after all: If ARRAY is a whole array and either ARRAY is an assumed-size array of rank DIM or dimension DIM

[Patch, fortran] Simplify lbound for array subcomponents

2015-04-27 Thread Mikael Morin
Hello, while reviewing Thomas' bound simplification patch, I noticed that the {l,u}bound simplification code wasn't handling array subcomponents. Fixed by the attached patch, regression tested. OK for trunk? Mikael 2015-04-27 Mikael Morin mik...@gcc.gnu.org * simplify.c

Re: [Patch, Fortran] Simplify lbound

2015-04-27 Thread Thomas Koenig
Am 25.04.2015 um 20:12 schrieb Mikael Morin: I've double-checked in the standard, and it seems it is not possible to simplify after all: If ARRAY is a whole array and either ARRAY is an assumed-size array of rank DIM or dimension DIM of ARRAY has nonzero extent, LBOUND

Re: [Patch, Fortran] Simplify lbound

2015-04-27 Thread Thomas Koenig
Hello world, here is a slight correction: This patch includes the change to the test case. Regards Thomas Index: fortran/simplify.c === --- fortran/simplify.c (Revision 222431) +++ fortran/simplify.c (Arbeitskopie) @@

Re: [Patch, Fortran] Simplify lbound

2015-04-25 Thread Mikael Morin
Le 25/04/2015 13:33, Thomas Koenig a écrit : Hello world, this is a simplification for calculating the lboud of assumed-shape arrays - it is usually one, or whatever the user specified as lower bound (if constant). Hello, I've double-checked in the standard, and it seems it is not

[Patch, Fortran] Simplify lbound

2015-04-25 Thread Thomas Koenig
Hello world, this is a simplification for calculating the lboud of assumed-shape arrays - it is usually one, or whatever the user specified as lower bound (if constant). The surprising thing was that the current code generated for the array descriptor for subroutine foo(a, b, n, m)