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,
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
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
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
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
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.
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
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
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!
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
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
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
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
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)
@@
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
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)
16 matches
Mail list logo