Hi Mikael,
However, it introduces regressions on matmul_bounds_{2,4,5}.
It seems the "incorrect extent" runtime errors are completely optimized
away (even at -O0).
Any ideas?
This is seriously wierd. It seems that the call to gfortran_error is
really optimized away, because the middle-end dec
Le 21/07/2015 21:49, Thomas Koenig a écrit :
Am 21.07.2015 um 19:26 schrieb Mikael Morin:
I would like to avoid the hack in iresolve. So let's reuse the
frontend-passes.c part of my patch (set resolved_isym)
I would much prefer if that was put into gfc_resolve_fe_runtime_error,
next to the as
Am 21.07.2015 um 19:26 schrieb Mikael Morin:
Le 20/07/2015 23:55, Thomas Koenig a écrit :
Hi,
I'm back from holiday, so I can finally reply.
Am 13.07.2015 um 21:54 schrieb Thomas Schwinge:
--- gcc/fortran/iresolve.c
+++ gcc/fortran/iresolve.c
@@ -2207,6 +2207,9 @@ gfc_resolve_fe_runtime_err
Le 20/07/2015 23:55, Thomas Koenig a écrit :
Hi,
I'm back from holiday, so I can finally reply.
Am 13.07.2015 um 21:54 schrieb Thomas Schwinge:
--- gcc/fortran/iresolve.c
+++ gcc/fortran/iresolve.c
@@ -2207,6 +2207,9 @@ gfc_resolve_fe_runtime_error (gfc_code *c)
a->name = "%VAL";
Hi,
I'm back from holiday, so I can finally reply.
Am 13.07.2015 um 21:54 schrieb Thomas Schwinge:
--- gcc/fortran/iresolve.c
+++ gcc/fortran/iresolve.c
@@ -2207,6 +2207,9 @@ gfc_resolve_fe_runtime_error (gfc_code *c)
a->name = "%VAL";
c->resolved_sym = gfc_get_intrinsic_sub_symbol
Le 15/07/2015 16:03, Thomas Schwinge a écrit :
> Hi!
>
> On Wed, 15 Jul 2015 13:44:38 +0200, Mikael Morin wrote:
>> Le 13/07/2015 21:54, Thomas Schwinge a écrit :
>>> Original situation; _gfortran_runtime_error is not being properly
>>> declared (invoked via gcc/fortran/frontend-passes.c:runtime_
Hi!
On Wed, 15 Jul 2015 13:44:38 +0200, Mikael Morin wrote:
> Le 13/07/2015 21:54, Thomas Schwinge a écrit :
> > Original situation; _gfortran_runtime_error is not being properly
> > declared (invoked via gcc/fortran/frontend-passes.c:runtime_error_ne),
> > but, for example, _gfortran_error_runti
Hello,
Le 13/07/2015 21:54, Thomas Schwinge a écrit :
> Original situation; _gfortran_runtime_error is not being properly
> declared (invoked via gcc/fortran/frontend-passes.c:runtime_error_ne),
> but, for example, _gfortran_error_runtime_at is being properly declared
> (invoked from elsewhere):
Hi!
On Wed, 06 May 2015 22:26:31 +0200, Thomas Koenig wrote:
> thanks for the review. I have committed the following [...]
For nvptx-none targets, I'm seeing some odd behavior with this
commit.
Background: the nvptx backend has some special handling for varags
functions, and this only works if
On Mon, May 4, 2015 at 11:25 PM, Thomas Koenig wrote:
> Hello world,
>
> this is an update of the matmul inline patch. The only difference to
> the last version is that it has the ubound simplification taken out.
>
> Any further comments? OK for trunk?
>
> Thomas
>
> 2015-05-05 Thomas K
Hi Mikael,
thanks for the review. I have committed the following, which took
your remarks into account (plus an additional test case, as obvious).
Regards
Thomas
2015-05-06 Thomas Koenig
PR fortran/37131
* gfortran.h (gfc_isym_id): Add GFC_ISYM_FE_RUNTIME_ERROR.
Le 05/05/2015 08:25, Thomas Koenig a écrit :
> Hello world,
>
> this is an update of the matmul inline patch. The only difference to
> the last version is that it has the ubound simplification taken out.
Sorry, I delayed this, but it wasn't (yet) forgotten.
Below a few answers to
https://gcc.gn
12 matches
Mail list logo
