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
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
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;
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 @@
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 mikael.mo...@sfr.fr wrote:
Le 13/07/2015 21:54, Thomas Schwinge a écrit :
Original situation; _gfortran_runtime_error is not being properly
declared (invoked via
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, 15 Jul 2015 13:44:38 +0200, Mikael Morin mikael.mo...@sfr.fr 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,
Hi!
On Wed, 06 May 2015 22:26:31 +0200, Thomas Koenig tkoe...@netcologne.de 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,
On Mon, May 4, 2015 at 11:25 PM, Thomas Koenig tkoe...@netcologne.de 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
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 tkoe...@gcc.gnu.org
PR fortran/37131
* gfortran.h (gfc_isym_id): Add
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
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 Koenig tkoe...@gcc.gnu.org
PR fortran/37131
*
13 matches
Mail list logo
