Le 26/12/2021 à 21:09, FX via Fortran a écrit :
OK to commit?
This looks good, yes. Thanks.
Le 06/01/2022 à 20:50, Harald Anlauf a écrit :
Did you find the time to try your version?
Not yet. But I have not (yet) forgotten about this.
lFrom c1c17a43e172ebc28f2cd247f6e83c5fdbc6219f Mon Sep 17 00:00:00 2001
From: Mikael Morin
Date: Fri, 7 Jan 2022 22:34:59 +0100
Subject: [PATCH] Fortran: Ignore KIND argument of a few more intrinsics. [PR103789]
After PR97896 for which some code was added to ignore the KIND argument
of the
Le 09/01/2022 à 15:10, Mikael Morin a écrit :
pulling the latest master brought me a broken bootstrap
It was a user error (of course).
Bootstrap and regression test and commit pending.
Now tested and committed as
r12-6386-gc1c17a43e172ebc28f2cd247f6e83c5fdbc6219f
Le 03/01/2022 à 20:45, Harald Anlauf via Fortran a écrit :
Dear all,
the initial-data-target for a pointer initialization can be either
NULL() or a non-constant target. In the latter case subscripts of
the target specification (or substring starting and ending points)
must be constant expressio
Le 09/01/2022 à 11:52, FX via Fortran a écrit :
ping
Le 2 janv. 2022 à 11:50, FX a écrit :
Hi,
This is the first part of a three-patch series to fix PR 82207
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207), making gfortran handle
signaling NaNs. This part fixes the library code imple
Le 06/01/2022 à 22:44, Mikael Morin a écrit :
Le 06/01/2022 à 20:50, Harald Anlauf a écrit :
Did you find the time to try your version?
Not yet. But I have not (yet) forgotten about this.
I have looked at it, and it enables infinite mutual recursion between
gfc_intrinsic_func_interface and
Le 12/01/2022 à 21:29, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
the attached patch improves error recovery after an invalid
structure constructor has been detected in a DATA statement.
Testcase by Gerhard.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
This should be a rathe
Hello,
Le 10/01/2022 à 18:32, FX via Fortran a écrit :
Hi,
Second part of a three-patch series to fix PR 82207
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207), making gfortran handle
signaling NaNs. This part fixes the library code implementing IEEE_VALUE. To do
so, I switched that part
Hello,
I have just pushed the attached patch after testing the impacted tests
individually.
MikaelFrom 15630e6e9eb019477d1fc5c0966b43979e18ae18 Mon Sep 17 00:00:00 2001
From: Mikael Morin
Date: Sun, 16 Jan 2022 18:33:36 +0100
Subject: [PATCH] testsuite: Enrich tests with variants failing on
I managed to break a working patch by splitting it.
Now fixed.
From d7a44809924297a2ff26b6b1d040c72c22f07346 Mon Sep 17 00:00:00 2001
From: Mikael Morin
Date: Mon, 17 Jan 2022 11:45:46 +0100
Subject: [PATCH] Fortran: Ignore KIND argument of a few more intrinsics.
[PR103789]
After PR97896 for
Le 26/03/2018 à 03:53, Jerry DeLisle a écrit :
On 03/25/2018 02:11 PM, Mikael Morin wrote:
Le 25/03/2018 à 21:27, Jerry DeLisle a écrit :
On 03/25/2018 10:49 AM, Mikael Morin wrote:
Le 25/03/2018 à 00:25, Jerry DeLisle a écrit :
On 03/24/2018 02:56 PM, Steve Kargl wrote:
On Sat, Mar 24
Hello,
Le 06/08/2014 21:23, Andre Vehreschild a écrit :
> Hi,
>
[...]
>
> *** gcc/fortran/Changelog ***
> 2014-08-06 Andre Vehreschild
>
> PR fortran/60414
> * interface.c (compare_parameter): Fixing ICE when argument
> of a generic is a reference into an array.
> ***
Le 07/08/2014 15:40, Andre Vehreschild a écrit :
> Hi,
>
> in the bugtracker for PR60255 janus proposed to fix the bug by removing
> the error and additionally checking if the character array length
> declaration is deferred, which leaves the the charlen to be 0
> (gcc/fortran/class.c (find_intrin
Hello,
Le 10/08/2014 13:55, Andre Vehreschild a écrit :
> Hi,
>
> I am proposing another patch, this time to resolve PR60289. The issue in the
> bug
> reported is, that a code like:
>
> class(*), pointer :: P
> allocate(character(20)::P)
>
> is rejected by trunk's gfortran compiler
Le 16/08/2014 00:10, Tobias Burnus a écrit :
> This patch fixes two minor issues
>
> a) The argument issue mentioned in
> https://gcc.gnu.org/ml/fortran/2014-08/msg7.html
> The main issue is that the decl uses "void" as argument; the FE passes
> IARG() alias gfc_array_index_type while the libr
Le 17/08/2014 14:26, Dominique Dhumieres a écrit :
> As Mikael said in https://gcc.gnu.org/ml/fortran/2014-08/msg00047.html
>
>> the testcase should check that the code generated is actually working,
>> not just that the ICE disappeared. ...
>
Well, this is for another patch where deferred charac
Le 17/08/2014 14:46, Dominique Dhumieres a écrit :
>> My knowledge of unlimited polymorphic types is limited, but I think that
>> this is not correct.
>
> My knowledge of unlimited polymorphic types is even more limited,
> then I cannot comment about the correctness of the patch. However
>
>> The
Le 17/08/2014 14:46, Dominique Dhumieres a écrit :
>> My knowledge of unlimited polymorphic types is limited, but I think that
>> this is not correct.
>
> My knowledge of unlimited polymorphic types is even more limited,
> then I cannot comment about the correctness of the patch. However
>
>> The
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
Hello,
Le 12/05/2015 22:07, Thomas Koenig a écrit :
> Hello world,
>
> this patch fixes a regression from the inline matmul patch by
> not inlining a case that is not yet handled, namely vector
> subscripts.
>
> Regression-tested. OK for trunk?
>
OK with...
>
> Index: frontend-passes.c
>
Hello,
Le 30/04/2015 15:07, Andre Vehreschild a écrit :
> Hi all,
>
> this is just a service release. I encountered that the new testcase in the
> previous release included the testcase of the initial patch, that is
> already on trunk. I therefore replaced the testcase allocate_with_source_5.f90
Le 09/05/2015 15:12, Mikael Morin a écrit :
> Le 01/05/2015 20:25, Paul Richard Thomas a écrit :
>> Dear All,
>>
>> By the time I went to commit, something had changed and the patch
>> caused a regression. I presume that the version that I had of Andre's
>
Le 16/05/2015 12:35, Thomas Koenig a écrit :
> Hello world,
>
> this (rather obvious) patch fixes array declarations in deeply nested
> BLOCKs.
>
> Regression-tested. OK for trunk?
>
OK, thanks.
Mikael
Le 15/05/2015 17:19, Steve Kargl a écrit :
> Regression tested on trunk. OK to commit?
>
Hello,
> Index: gcc/fortran/decl.c
> ===
> --- gcc/fortran/decl.c(revision 223094)
> +++ gcc/fortran/decl.c(working copy)
> @@
Le 14/05/2015 03:58, Jerry DeLisle a écrit :
> The attached patch reverts a change I made for pr65456 which caused this
> regression and adds a check for quotes farther down in the function. This
> avoids treating a '!' in a string as a comment and wiping the rest of the
> line.
>
> I found the
nux. OK for 6/5/4.9 ?
Mikael
2015-05-16 Mikael Morin
PR fortran/61831
* trans-array.c (gfc_conv_array_parameter): Remove allocatable
component deallocation code generation.
* trans-expr.c (gfc_conv_expr_reference): Ditto.
(expr_may_alias_variables): N
Le 19/05/2015 10:50, Andre Vehreschild a écrit :
> Hi all,
>
> find attached latest version to fix 65548.
>
> Bootstraps and regtests ok on x86_64-linux-gnu/f21.
>
OK. Thanks.
Mikael
Le 20/05/2015 10:24, Andre Vehreschild a écrit :
> Hi Mikael,
>
> when I got you right on IRC, then you proposed this change about the pointer
> attribute:
>
> diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c
> index 6d565ae..545f778 100644
> --- a/gcc/fortran/trans-stmt.c
> +++ b
Le 21/05/2015 19:51, Thomas Koenig a écrit :
> Am 18.05.2015 um 00:05 schrieb Thomas Koenig:
>> this patch extends the inline matmul functionality to conjugate
>> complex numbers.
>>
>> Regression-tested. OK for trunk?
>
> OK (with the trivial change in the follow-up e-mail)?
>
> I'd like to star
Le 23/05/2015 01:04, Manuel López-Ibáñez a écrit :
> PING: https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01511.html
>
> This only needs approval from Fortran maintainers.
>
I approved: https://gcc.gnu.org/ml/fortran/2015-05/msg00135.html
But it seems I replied to the fortran list only.
Mikael
-05-23 Mikael Morin
PR fortran/66257
* resolve.c (resolve_actual_arglist): Don't throw an error
if the argument with procedure pointer component is not a variable.
2015-05-23 Mikael Morin
PR fortran/66257
* typebound_call_27.f90: New file.
diff --git a/gcc/fortran/resolve.c
Le 25/05/2015 09:30, Paul Richard Thomas a écrit :
> Dear All,
>
> Lets see if I can get it right this time :-)
>
> Note that I have changed the name of the temporary variable in
> trans_allocate from 'atmp' to 'expr3' so that it is not confused with
> array temporaries.
I agree with Andre willin
hello Andre,
Le 25/05/2015 12:24, Andre Vehreschild a écrit :
> Hi Paul,
>
> I am not quite happy with the naming of the temporary variable. When I
> initially set the prefix to "atmp" this was because the variable would be an
> array most of the time and because of the number appended to it shou
Le 19/05/2015 12:26, Andre Vehreschild a écrit :
> Hi all,
>
> update based on latest 65548 (v5) patch and current trunk. Description and
> issue addressed unchanged (see cite below).
>
> Bootstrapped and regtested on x86_64-linux-gnu/f21.
>
> Any volunteers to review? The initial version dates
Le 27/05/2015 16:07, Andre Vehreschild a écrit :
> Hi Paul, hi Mikael,
>
> about renaming the identifier emitted: I would like to keep it short.
> Remember,
> there is always a number attached to it, which makes it unique. Furthermore
> does "alloc_source_tmp" sound unnecessarily long to me. It t
Le 27/05/2015 23:09, Steve Kargl a écrit :
> On Wed, May 27, 2015 at 06:24:25PM +0200, Mikael Morin wrote:
>> Le 27/05/2015 16:07, Andre Vehreschild a ?crit :
>>> Hi Paul, hi Mikael,
>>>
>>> about renaming the identifier emitted: I would like to keep it short.
Le 28/05/2015 17:29, Andre Vehreschild a écrit :
> *** resolve_allocate_expr (gfc_expr *e, gfc_
> *** 7103,7112
> --- 7103,7123
> if (!ref2 || ref2->type != REF_ARRAY || ref2->u.ar.type == AR_FULL
> || (dimension && ref2->u.ar.dimen == 0))
> {
> + /* F0
Hello Andre,
comments below (out of order, sorry).
Le 29/05/2015 13:46, Andre Vehreschild a écrit :
> Hi Mikael,
>
> comments inline below:
>
> On Thu, 28 May 2015 20:06:57 +0200
> Mikael Morin wrote:
>
>> Le 28/05/2015 17:29
iq reported that the variant of this patch posted on the PR was
also fixing PR49324. I couldn't confirm as what seems to be the
remaining testcase there (comment #6) doesn't fail with trunk here.
2015-04-18 Mikael Morin
PR fortran/65792
* trans-expr.c (gfc_trans_subcomponent_a
Hello,
Le 15/04/2015 20:03, Andre Vehreschild a écrit :
> by accident I patched this pr. For short, when a structure constructor for a
> structure with an allocatable component or a function returning a type with an
> allocatable component is passed as actual argument to a function, then
> gfortr
);
to
gfc_trans_scalar_assign (...blah..., x, !foo && bar);
As foo is most of the time either true or false, this is a simplification.
regression tested on x86-64-unknown-linux-gnu.
OK for post 5.1 trunk?
Mikael
2015-04-19 Mikael Morin
* trans.h (gfc_trans_scalar_assign): Remove fourth argument.
Le 19/04/2015 17:58, Thomas Koenig a écrit :
> Hello world,
>
> here is the first installation of the matmul inlining patch.
>
> This patch calculates c=MATMUL(a,b) using DO loops where there is no
> dependency between a and c/b and c loops, taking care of realloc on
> assignment and bounds check
Dominique reported that the trunk patch breaks class_19.f90 when applied
together with Andre's PR59678 fix.
It appears to me that even without Andre's patch, the code generated is
wrong, and I don't see any easy fix.
Thus I'm withdrawing trunk's patch, and propose the backport patch also
for trunk.
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,
Le 13/03/2015 11:33, Andre Vehreschild a écrit :
> Hi all,
>
> this is another patch preventing a segfault. This time the segfault occurred,
> when -fdump-(fortran|tree)-original was given with the program having an
> implicit class set. The issue is that the _data component is assumed to
Hello,
I'm reviewing the original patch only for now.
The added bits in v2 will have to wait.
Le 23/04/2015 20:00, Andre Vehreschild a écrit :
>>> diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
>>> index 9e6432f..80dfed1 100644
>>> --- a/gcc/fortran/trans-expr.c
>>> +++ b/gcc/fo
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
Hello,
Le 28/04/2015 12:43, Andre Vehreschild a écrit :
> To get the testsuite accepting a dump-fortran-original, I had to insert a
> dg-prune-output. Without the prune output, dejagnu was reporting excess
> errors.
> The prune removes all output after the first Namespace: that starts the
> fortr
Hello,
Le 29/04/2015 02:02, David Malcolm a écrit :
> diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c
> index 2c7c554..30e4eab 100644
> --- a/gcc/fortran/parse.c
> +++ b/gcc/fortran/parse.c
> @@ -4283,7 +4283,7 @@ parse_oacc_structured_block (gfc_statement acc_st)
> unexpected_eof ();
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 assume
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 sh
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
Hello,
Le 05/05/2015 11:00, Andre Vehreschild a écrit :
> diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
> index 4c18920..0b63175 100644
> --- a/gcc/fortran/trans-decl.c
> +++ b/gcc/fortran/trans-decl.c
> @@ -2158,6 +2158,8 @@ build_function_decl (gfc_symbol * sym, bool global)
>
uot; condition is reverted to its previous state.
The testcase is yours.
regression tested on x86_64-unknown-linux-gnu. OK for trunk?
Mikael
2015-05-07 Andre Vehreschild
Mikael Morin
PR fortran/65894
* trans-array.h (gfc_scal
Hello,
I found a (unrelated) bug while playing with Andre's PR65894 patch.
The dummy argument can get out of sync with the actual argument when
there is an (optional) argument missing.
I plan to commit the attached fix as obvious later today (after testing).
Mikael
2015-05-08 Mikael
Le 08/05/2015 12:54, Andre Vehreschild a écrit :
> Hi Mikael,
>
> thanks for the review. I still have some questions/remarks before commiting:
>
>>> @@ -5898,8 +5900,21 @@ gfc_generate_function_code (gfc_namespace * ns)
>>>
>>>if (TREE_TYPE (DECL_RESULT (fndecl)) != void_type_node)
>>>
Le 08/05/2015 13:54, Andre Vehreschild a écrit :
> Hi Mikael,
>
> at first I tried to fix this issue with the scalarizer, too, but I could not
> grasp how the scalarizer was working. Do you have any documentation, how it is
> meant to be? I mean, I have read the comments in the code, but those are
Hello,
Le 09/05/2015 00:11, Thomas Koenig a écrit :
> Index: frontend-passes.c
> ===
> --- frontend-passes.c (Revision 222864)
> +++ frontend-passes.c (Arbeitskopie)
> @@ -2611,14 +2611,40 @@ scalarized_expr (gfc_expr *e_in, gfc_expr
Le 01/05/2015 20:25, Paul Richard Thomas a écrit :
> Dear All,
>
> By the time I went to commit, something had changed and the patch
> caused a regression. I presume that the version that I had of Andre's
> patch was not the same as the one committed. I'll cast an eye over it
> this weekend and se
Le 08/05/2015 15:29, Andre Vehreschild a écrit :
> Hi all,
>
> please find attached a patch for 66035. An ICE occurred when in a structure
> constructor an allocatable component of type class was initialized with an
> existing class object. This was caused by
>
> - the size of the memory to allo
Hello,
Le 10/05/2015 00:31, Thomas Koenig a écrit :
> Am 09.05.2015 um 13:59 schrieb Mikael Morin:
>>> + /* We have to get rid of the shape, if thre is one. Do
>>> +so by freeing it and calling gfc_resolve to rebuild it,
>>> +
; "original" } }
+! { dg-final { cleanup-tree-dump "original" } }
Index: testsuite/ChangeLog
===
--- testsuite/ChangeLog (révision 222978)
+++ testsuite/ChangeLog (révision 222979)
@@ -1,3 +1,7 @@
+2015-05-10 Mikael Mo
.
The condition was assuming full object arrays, and fails with subobject
arrays.
The fix (attached) is obvious enough.
The testcase is Thomas' reduced one, which is independent on matmul
simplification.
I plan to commit this patch tonight.
Mikael
2015-05-11 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
Ping:
https://gcc.gnu.org/ml/fortran/2015-02/msg00045.html
Hello Paul,
have you had time to look at this again?
Mikael
Le 20/03/2015 14:51, Andre Vehreschild a écrit :
> Hi all,
>
> during checking that pr 61275 is really fixed, I found a indentation issue and
> a piece of my former code, that could be done nicer and more readable. This
> patch addresses both these issues.
>
> Bootstraps and regtests ok on x86_64
26/02/2015 18:17, Andre Vehreschild a écrit :
> This first patch is only preparatory and does not change any of the semantics
> of
> gfortran at all.
Sure?
> diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
> index ab6f7a5..d28cf77 100644
> --- a/gcc/fortran/expr.c
> +++ b/gcc/fortran/expr.c
Le 23/03/2015 13:43, Andre Vehreschild a écrit :
> Hi Mikael,
>
> thanks for looking at the patch. Please note, that Paul has sent an addendum
> to
> the patches for 60322, which I deliberately have attached.
>
>> 26/02/2015 18:17, Andre Vehreschild a écrit :
>>> This first patch is only prepar
Le 23/03/2015 16:49, Andre Vehreschild a écrit :
> I see your point. Currently I am bootstraping and regtesting some patches for
> commit. While this is running, my machine is nearly unusable. I will look into
> this as soon, as my machine allows, but probably not before tomorrow.
>
There is no hu
ve finally preferred this safer patch keeping the existing field
completely untouched.
Regression tested on x86_64-unknown-linux-gnu. OK for trunk?
Mikael
2015-03-24 Mikael Morin
PR fortran/64952
PR fortran/65532
* gfortran.h (struct gfc_namespace): New field '
Le 24/03/2015 23:39, Mikael Morin a écrit :
> The patch I propose here adds a flag to remember the function has been
> called, and skip it the second time.
> I considered reusing the existing 'resolved' field, but I had to
> slightly change its semantics to prevent regressin
Le 06/04/2015 01:04, Evangelos Drikos a écrit :
>
> Hi,
>
> The attached patch, type 0, has been discussed a little at:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
>
> Yet, the final version submitted is slightly different from the ones
> discussed and tested in the above link.
>
> Ha
Le 06/04/2015 20:26, Mikael Morin a écrit :
> Regarding the patch, I don't understand why the existing symbol
> restoration code doesn't work here (see
> gfc_restore_last_undo_checkpoint, restore_old_symbol). I have to
> investigate more.
I think the problem is the usage
Le 07/04/2015 14:25, Mikael Morin a écrit :
> Le 06/04/2015 20:26, Mikael Morin a écrit :
>> Regarding the patch, I don't understand why the existing symbol
>> restoration code doesn't work here (see
>> gfc_restore_last_undo_checkpoint, restore_old_symbol). I have
Le 08/04/2015 12:29, Mikael Morin a écrit :
> Except that the following ... ahem ... doesn't work.
>
And it doesn't work because gfc_get_ha_symbol doesn't version
host-associated symbols.
So one has to call symbol.c's save_symbol_data by hand. And then, we
can
Hello, I haven't looked at the patch in detail yet, but...
Le 11/04/2015 14:24, Thomas Koenig a écrit :
> Still to do: Bounds checking (a rather big one),
... as you do a front-end to front-end transformation, you get bounds
checking for free, don't you?
Mikael
Le 08/06/2015 17:31, Jan Hubicka a écrit :
> Hi,
> to furhter add to the topics to discuss, I noticed that Fortran FE seems to
> be quite
> ambivalent about C_CHAR type:
> [jh@gcc2-power8 gcc]$ cat ../b.f90
> ! This testcase will abort if C_CHAR types are not interoperable
> module lto_type_merge_
Le 10/06/2015 16:38, Jan Hubicka a écrit :
>>> [jh@gcc2-power8 gcc]$ cat ../b.f90
>>> ! This testcase will abort if C_CHAR types are not interoperable
>>> module lto_type_merge_test
>>> use, intrinsic :: iso_c_binding
>>> implicit none
>>>
>>> contains
>>> function types_test1(V) bind(c)
>>>
6_64-linux. OK for trunk/5 ?
Mikael
2015-06-18 Mikael Morin
PR fortran/66549
* resolve.c (resolve_global_procedure): Don't save and restore
OpenMP state around the call to gfc_resolve.
(gfc_resolve): Save OpenMP state on entry and restore it on return.
2015
Le 18/06/2015 13:35, Jakub Jelinek a écrit :
> On Thu, Jun 18, 2015 at 01:18:18PM +0200, Mikael Morin wrote:
>> I'm proposing here a fix for an OpenMP ICE regression introduced by me
>> at http://gcc.gnu.org/r221586
>>
>> That revision changed the order in which
Le 16/05/2015 18:43, Mikael Morin a écrit :
> Hello,
>
> this is about PR61831 where in code like:
>
> type :: string_t
> character(LEN=1), dimension(:), allocatable :: chars
> end type string_t
> type(string_t) :: prt_in
> (...)
Le 14/01/2015 19:30, Janus Weil a écrit :
> Hi Mikael,
>
>>> the attached patch fixes an ICE-on-invalid problem with
>>> procedure-pointer components by making sure that we continue resolving
>>> all components of a derived type, even after an error is thrown.
>>>
>> Does the fonction return false
Le 15/01/2015 12:37, Janus Weil a écrit :
>> Your patch at https://gcc.gnu.org/ml/fortran/2015-01/txtThsA1zTNFd.txt
>> looks very similar to the Mikael's one for pr58023 at
>> https://gcc.gnu.org/bugzilla/attachment.cgi?id=30633
>> with retval replaved with success.
>>
>> Was it intended?
>
> Nope
Le 15/01/2015 14:25, Mikael Morin a écrit :
> Le 15/01/2015 12:37, Janus Weil a écrit :
>>> Your patch at https://gcc.gnu.org/ml/fortran/2015-01/txtThsA1zTNFd.txt
>>> looks very similar to the Mikael's one for pr58023 at
>>> https://gcc.gnu.org/bugzilla/atta
don't load list of extensions.
(load_derived_extensions, write_dt_extensions,
write_derived_extensions): Remove.
2015-01-25 Mikael Morin
PR fortran/62044
* gfortran.dg/use_rename_7.f90: New.
Index: decl.c
>
> use m, only: A => X
> use m, only: A => X
>
> should not.
The problem is we check the original (symbol) name instead of the local
(symtree) name.
The fix is close to obvious, and should be safe for the branches (this
is a regression)
Regression tested on x86_64-linux.
Le 07/02/2015 14:40, Dominique Dhumieres a écrit :
> Dear Mikael,
>
> Even if
>
>>> use m, only: A => X
>>> use m, only: A => X
>
> is valid, it does not make sense to use it and it is probably a typo.
> Should not gfortran emit a warning, at least with -Wall?
>
Yeah, why not?
I think we ha
Hello Paul,
comments below
Le 08/02/2015 16:24, Paul Richard Thomas a écrit :
>
> Index: gcc/fortran/gfortran.h
> ===
> *** gcc/fortran/gfortran.h(revision 220482)
> --- gcc/fortran/gfortran.h(working copy)
> ***
eparate struct, and merge them later explicitly into a block.
Alas, the code is not exactly straightforward to my eyes, and my
attempt in that direction to sneak some orthogonality in that madness
failed.
Anyway, regression tested on x86_64-linux, OK for trunk/4.9/4.8 ?
Mikael
201
luated outside the
> scalarization
>loop. Pass back and let the caller deal with it. */
Mikael
! { dg-do run }
!
! Tests the fix for PR64952, in which the assignment to 'array' should
! have generated a temporary because of the references to the lhs in
! the functi
rtran.dg/fmt_en.f90
FAIL: gfortran.dg/nan_7.f90
FAIL: gfortran.dg/quad_2.f90
FAIL: gfortran.dg/quad_3.f90
FAIL: gfortran.dg/round_4.f90
2015-02-15 Mikael Morin
PR fortran/60898
* resolve.c (resolve_symbol): Check that the symbol found from
name lookup really is the current s
Le 15/02/2015 19:00, Jerry DeLisle a écrit :
> On 02/15/2015 09:48 AM, Mikael Morin wrote:
>
>> [*] I have a few failing testcases (also without the patch), namely the
>> following; does this ring a bell ?
>> FAIL: gfortran.dg/erf_3.F90
>> FAIL: gfortran.dg/fmt
Le 16/02/2015 21:18, Bernd Edlinger a écrit :
>
> again, with attachments,
> sorry.
>
>
>>
>> Hi,
>>
>>
>> this patch fixes PR64980 and PR61960 at the same time.
>>
>> The unreduced test case for PR64230 is also included, because a previous
>> version
>> of this patch caused this test to fail b
Le 20/02/2015 22:50, Mikael Morin a écrit :
> Le 16/02/2015 21:18, Bernd Edlinger a écrit :
>>
>> again, with attachments,
>> sorry.
>>
>>
>>>
>>> Hi,
>>>
>>>
>>> this patch fixes PR64980 and PR61960 at the same time.
&g
Hello,
Le 14/08/2016 à 15:05, Thomas Koenig a écrit :
Index: frontend-passes.c
===
--- frontend-passes.c (Revision 239218)
+++ frontend-passes.c (Arbeitskopie)
@@ -177,6 +178,13 @@ realloc_string_callback (gfc_code **c, int *wal
Le 17/08/2016 à 20:56, Jakub Jelinek a écrit :
Hi!
The bug here is that it dereferences expr->ts.u.cl if non-NULL
unconditionally, no matter what expr->ts.type is.
But, ts.u is an union, where ts.u.cl is only valid for BT_CHARACTER,
ts.u.derived for BT_DERIVED etc. ts.u.pad (an int rather than p
Le 18/08/2016 à 21:24, Thomas Koenig a écrit :
Hello Mikael,
This doesn't look correct, what about substrings following component or
array references?
You're right; corrected in the attached patch. I have also added a test
case for this.
PS: What about the original fix, wasn't it a depende
Hello,
Le 26/08/2016 à 20:27, Steve Kargl a écrit :
Here are two possible patches for PR fortran/77391. The first
patch treats the invalid code as a GNU Fortran extension as
gfortran current accepts the invalid code. The second patch
enforces the standard. As I think gfortran should encourage
401 - 500 of 1075 matches
Mail list logo
