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-ef
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 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
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 develo
On Sun, May 10, 2015 at 6:58 AM, Mikael Morin 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 cases. Th
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 c
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 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
>> array of rank
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_A
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. Tha
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 dime
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)
@@ -344
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,
> LBOU
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
* simplify.c (simplify_bound_dim): Tight
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 po
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)
integer
16 matches
Mail list logo
