bug)
C = A
C%scalar = onenineeight
class default
call abort
end select
end function
end
On 18 December 2015 at 04:56, Steve Kargl
wrote:
> On Thu, Dec 17, 2015 at 11:12:17PM +0100, Paul Richard Thomas wrote:
>>
>> Some problems have co
Dear All,
Some problems have come up that are not dissimilar to the original
bug, involving infinite recursion with procedure components, with the
same type as the containing type. The fix is verging on the trivial.
However, given that I found two further bugs in fixing the one
reported, I worry t
Committed revision as 231319.
Thanks for testing the patch.
Paul
On 5 December 2015 at 17:41, Steve Kargl
wrote:
> On Sat, Dec 05, 2015 at 04:20:54PM +0100, Paul Richard Thomas wrote:
>>
>> The cause of the segfault, I believe, was an error: 'sym' being used
>> i
Dear Steve,
I'll take a look at this this afternoon. Thanks for bringing it to my attention.
Cheers
Paul
On 3 December 2015 at 07:43, Steve Kargl
wrote:
> On Wed, Dec 02, 2015 at 10:26:30PM -0800, Steve Kargl wrote:
>> On Wed, Dec 02, 2015 at 10:02:33PM -0800, Steve Kargl wrote:
>> > Paul,
>>
Committed as revision 231072.
Thanks for the review
Paul
On 28 November 2015 at 17:19, Steve Kargl
wrote:
> On Sat, Nov 28, 2015 at 11:35:54AM +0100, Paul Richard Thomas wrote:
>> +
>> + /* Abreviated module procedure declaration is not meant to have any
>
> s/A
Dear All,
The check that the number of formal arguments in the submodule
procedure declaration is the same as that in the module interface was
not working when there were none in either of them. This rather
trivial patch remedies the problem.
Bootstrapped and regtested on FC21/x86_64 - OK for tru
Dear Alessandro and Tobias,
I have been through the patch to check for obvious bloopers but can
find none, as expected given the author :-)
I would dearly like to see the testcases at the same time as the patch
but I think that the commit should be made sooner, rather than
later. Given its na
Committed to 5 branch as R230839.
Will deal with 4.9 branch next.
Paul
On 7 November 2015 at 16:57, Steve Kargl
wrote:
> On Wed, Nov 04, 2015 at 04:03:10PM +0100, Paul Richard Thomas wrote:
>>
>> 2015-11-04 Paul Thomas
>>
>> PR fortran/68196
>> *
Hi Steve,
Just a couple of small typos:
"Unexpected expr_type cause an ICE" ; causes?
"! An array of derived types workd too." ; works?
Apart from that it's OK for trunk.
Thanks for the patch
Cheers
Paul
On 20 November 2015 at 21:09, Steve Kargl
wrote:
> On Thu, Nov 19, 2015 at 04:58:36PM
Dear All,
I have committed as 'obvious' revision 230661 to fix 2/3 submodule
problems. In the case of the third, PR68243, I believe gfortran is
behaving correctly and I am awaiting confirmation from the reporter.
Thanks to Dominique for regtesting the part of the patch that fixes PR66762.
I hav
Dear Steve,
OK for trunk.
Some of the code around the patch brings back fond memories;
especially the "scalarization"!
Thanks for the patch.
Paul
On 16 November 2015 at 03:22, Steve Kargl
wrote:
> First, thanks to Dominiq for prodding me into looking at PR 58027.
>
> This was a fun ICE to tra
On 14 November 2015 at 21:10, Steve Kargl
wrote:
> On Sat, Nov 14, 2015 at 07:25:29PM +0100, Paul Richard Thomas wrote:
>>
>> Following an email from Dominique to me, I think not. In the course of
>> fixing PR49954, I put right the setting of the descriptor dtype. Since
>> th
put right gfortran's woes
with deferred characters. As well as concatenation problems that I
think I have fixed, parentheses cause instant death :-(
Cheers
Paul
On 14 November 2015 at 18:49, Steve Kargl
wrote:
> On Sat, Nov 14, 2015 at 06:39:28PM +0100, Paul Richard Thomas wrote:
&g
Dear All,
I am completely unable to reproduce the problems that Dominique is
reporting for deferred_character_4.f90. This might be because the
patch has moved on to fix PR49554 :-)
Concatenation expressions assigned to deferred length character arrays
need careful handling to ensure that the temp
Hi Steve,
I saw the thread on clf. That's a pretty quick turn around!
OK for trunk.
Thanks for the patch
Paul
On 13 November 2015 at 19:38, Steve Kargl
wrote:
> The attached patch implements the checks required by
> constraint C1206 from Fortran 2008 standard. Built
> and regression tested o
Dear Steve,
Thanks for beavering away on these front-end issues.
OK for trunk
Paul
On 8 November 2015 at 23:37, Steve Kargl
wrote:
> On Sun, Nov 08, 2015 at 02:35:58PM -0800, Steve Kargl wrote:
>> The attached patch has been built and regression tested
>> on i386-*-freebsd and x86_64-*-freebsd
Dear Joost,
These cause regressions on my tree:
f951: sorry, unimplemented: Graphite loop optimizations cannot be used
(ISL is not available)(-fgraphite, -fgraphite-identity, -floop-block,
-floop-interchange, -floop-strip-mine, -floop-parallelize-all,
-floop-unroll-and-jam, and -ftree-loop-linear)
Committed as revision 229954.
Thanks for checking it out.
Paul
On 7 November 2015 at 16:57, Steve Kargl
wrote:
> On Wed, Nov 04, 2015 at 04:03:10PM +0100, Paul Richard Thomas wrote:
>>
>> 2015-11-04 Paul Thomas
>>
>> PR fortran/68196
>> * class.c (
Hi Steve,
That's OK for trunk.
Thanks for the patch.
Paul
On 7 November 2015 at 21:20, Steve Kargl
wrote:
> NULL() can only appear in a few situations. It cannot
> be part of an array spec. See testcase for example.
> OK to commit?
>
> 2015-11-07 Steven G. Kargl
>
> PR fortran/682
Dear Andre,
OK for trunk.
I understand that you have investigated the issue(s) reported to you
by Dominique and can find no sign of them.
Thanks
Paul
On 5 November 2015 at 15:29, Andre Vehreschild wrote:
> Hi all,
>
> attached is a rather trivial patch to prevent multiple evaluations of a
> f
***ping***
On 4 November 2015 at 16:03, Paul Richard Thomas
wrote:
> Dear All,
>
> The patch for these PRs is fully explained by the the comments and/or
> changelogs. PR66465 has no connection with PR68196, other than Damian
> asking if it is connected!
>
> Bootstrapped an
Dear Joost,
These two testcases look fine to me. PR53852 is marked as being a
4.9,5,6 regression. If I have understood correctly, it has only been
fixed on trunk. Do you know if there is any intention to fix it on the
other branches?
OK for trunk and, subject to the previous question being answer
Dear All,
The patch for these PRs is fully explained by the the comments and/or
changelogs. PR66465 has no connection with PR68196, other than Damian
asking if it is connected!
Bootstrapped and regtested on x86_64/FC21 - OK for trunk and a few
weeks later 4.9 and 5 branches?
Cheers
Paul
2015-1
Dear Steve,
OK to commit.
Thanks for the fix.
Paul
On 30 October 2015 at 01:03, Steve Kargl
wrote:
> The attached patch restores 3 lines of code removed in my
> fix for PR fortran/65429. The code now checks for a NULL
> character length in the typespec. If it is indeed NULL,
> gfortran will
Oh bother! Thanks, Dominique
Paul
On 27 October 2015 at 19:24, Dominique d'Humières wrote:
> Dear Paul,
>
>> I have added a testcase, which has been committed as revision 229452.
>
> If I compile the test with -fsanitize=address,undefined I get at run time
>
> ==72440==ERROR: AddressSanitizer: g
Dear All,
The recent patches on trunk to gfc_trans_allocate have fixed PR67933.
I have added a testcase, which has been committed as revision 229452.
Since this is a 4.9/5 regression, I will extract the minimum change
necessary and will submit it as soon as I have regtested.
Cheers
Paul
2015-0
;
>> Hi Paul, hi all,
>>
>> thanks for the review. Submitted as r229294.
>>
>> Regards,
>> Andre
>>
>> On Sun, 25 Oct 2015 08:43:24 +0100
>> Paul Richard Thomas wrote:
>>
>> > Dear Andre,
>> >
>> > As fa
for trunk and thanks for the patch.
>
> Regards,
> Andre
>
> On Sat, 24 Oct 2015 15:08:30 +0200
> Paul Richard Thomas wrote:
>
>> Dear All,
>>
>> This patch does four things:
>> (i) On deallocating class components, the vptr is set to point
mplain about. I would love to see more
> comments to help beginners find there way in the code, but that's a
> thing I will never get. :-)
>
> Therefore, from my perspective ok for trunk and thanks for the patch.
>
> Regards,
> Andre
>
> On Sat, 24 Oct 2015
it that tests the functionality though!
You can commit this patch to trunk. As I said elsewhere, I will rename
the testcase for PR67171.
Many thanks for the patch.
Paul
On 23 October 2015 at 09:44, Paul Richard Thomas
wrote:
> Dear Andre,
>
> I will wait until you fix the prob
Shucks! Here it is
On 24 October 2015 at 15:08, Paul Richard Thomas
wrote:
> Dear All,
>
> This patch does four things:
> (i) On deallocating class components, the vptr is set to point to the
> vtable of the declared type;
> (ii) When digging out the last class reference,
Dear All,
This patch does four things:
(i) On deallocating class components, the vptr is set to point to the
vtable of the declared type;
(ii) When digging out the last class reference, a NULL is returned if
the allocatable component is to the right of a part reference with
non-zero rank, so that
Dear Steve,
This is also OK to commit.
Thanks
Paul
On 24 October 2015 at 01:52, Steve Kargl
wrote:
> The attached patch has been built and tested on x86_64-*-freebsd.
> It implements a check for validate kinds in type declarations
> of the form REAL*42.
>
> OK to commit?
>
> 2015-10-23 Steven
Dear Steve,
This is OK to commit.
Thanks for the patch
Paul
On 23 October 2015 at 21:29, Steve Kargl
wrote:
> On Fri, Oct 23, 2015 at 12:28:14PM -0700, Steve Kargl wrote:
>> Built and regression tested on x86_64-*-freebsd.
>> OK to commit?
>>
>
> Now with the patch attached!
>
> --
> Steve
Thanks FX!
Committed to 5 branch as revision 229179 and the testcase to 4_9 as
revision 229180.
Cheers
Paul
On 22 October 2015 at 19:32, FX wrote:
>> 2015-10-22 Paul Thomas
>>
>>PR fortran/58754
>>* trans-stmt.c (gfc_trans_allocate): Do not use the scalar
>>character assignment
Dear All,
Only the testcase will be applied to 4.9. At some time, it seems to
have fixed itself!
Cheers
Paul
On 22 October 2015 at 16:31, Paul Richard Thomas
wrote:
> Dear All,
>
> This patch speaks for itself. It is by no means as comprehensive as
> the work on ALLOCATE that An
Dear All,
This patch speaks for itself. It is by no means as comprehensive as
the work on ALLOCATE that Andre has done on 6 branch but has the
advantage for 5 branch that it is simple and steers the failing code
to the standard assignment, which should be safe.
Bootstraps and regtests on FC21/x86
Hi Steve,
It looks good to me - OK to commit.
Cheers
Paul
PS You, as far as I can tell, are the second most prolific bug fixer
of 2015. The only person that beats you is Mr(or Ms) Unassigned. We
need to sort out who this person is.
On 21 October 2015 at 22:05, Steve Kargl
wrote:
> The att
Hi Steve,
Yes, this is OK for trunk. I suggest that it is so obvious that it
should go into 5 branch as well.
Cheers
Paul
On 19 October 2015 at 21:13, Steve Kargl
wrote:
> The attached patch removes an assert() that prevents gfortran from
> issuing an error message. Built and tested on x86_64
Dear All,
Somewhat belatedly, I have applied the patch to 5 branch and have
committed as revision 228952.
Closing the PR forthwith.
Paul
On 24 May 2015 at 09:51, Paul Richard Thomas
wrote:
> Dear Andre,
>
> I'll put both points right. Thanks for pointing them out.
>
> Ch
Hi Steve,
Thanks - Committed as revision 228940.
I'll commit to 5 branch next Sunday.
Cheers
Paul
On 17 October 2015 at 22:51, Steve Kargl
wrote:
> On Sat, Oct 17, 2015 at 09:49:45PM +0200, Paul Richard Thomas wrote:
>>
>> I was moved by a report on clf of memory le
Dear All,
I was moved by a report on clf of memory leaks in move_alloc to
investigate the cause. This turned out to be trivial but led to the
above PRs, which themselves were trivial. The result is the attached
patch. I am aware that I have not investigated the further
ramifications that I can ima
Me too!
Paul
On 15 October 2015 at 18:31, Dominique d'Humières wrote:
>
>> Le 15 oct. 2015 à 16:59, FX a écrit :
>>
>>> In other words,
>>> consider youself a reviewer for patches in an area
>>> of the compiler that you are comfortable.
>>
>> Seconded.
>>
>> FX
>
> Agreed,
>
> Dominique
>
--
Dear Cesar,
>
> Is there any reason why only certain arrays have array descriptors? The
> arrays with descriptors don't have this problem. It's only the ones
> without descriptors that leak new internal variables that cause errors
> with default(none).
>
This is an obvious question to which there
end the test cases?
>
> Louis
>
> On Mon, 28 Sep 2015 00:55:10 -0700 Paul Richard Thomas wrote
>>Hi Louis,
>>
>>Could you please send the patch as an attachment - in your message,
>>much of the lhs whitespace information has been lost. Fundamentally,
>&
Committed as revision 228222. Thanks for all the help.
I'll update the fortran documentation tomorrow.
Cheers
Paul
On 28 September 2015 at 20:22, Paul Richard Thomas
wrote:
> Dear Mikael,
>
> snip...
>
>>> * io.c (next_char_not_space): Change tab warning
Dear Mikael,
snip...
>> * io.c (next_char_not_space): Change tab warning to warning now
>> to prevent locus being lost.
>
> This has disappeared?
duuh! Thanks
snip
> I think that for better error reporting (avoid unclassifiable statement),
> the gfc_notification_std can
Fixed as 'obvious' in revision: 228169.
Cheers
Paul
2013-09-26 Paul Thomas
PR fortran/67567
* resolve.c (resolve_fl_procedure): For module procedures, take
the parent module name and the submodule name from the name of
the namespace.
Dear Mikael,
Apart from the regtesting, this patch is 'obvious'. This is good for
trunk and, I would suggest, after a decent interval 5 branch.
Thanks for the PR and the patch.
Paul
On 26 September 2015 at 15:10, Mikael Morin wrote:
> Hello,
>
> I've just submitted this PR, and the patch as we
Dear Jim, FX and Jerry,
Frankly, I would accept the patch with the proviso that:
(i) It is hidden behand a gfc_notify_std (GFC_STD_GNU, "...;
(ii) The feature is set in conflict with the new features that FX
mentions, especially coarrays and bind C; and
(iii) As FX says, a good look at the te
* gfortran.dg/ptr_func_assign_4.f08: New test.
On 18 September 2015 at 10:36, Paul Richard Thomas
wrote:
> Dear Mikael,
>
> Thank you very much for the review. I'll give consideration to your
> remarks over the weekend. You will have guessed from the comment that
> I too w
easy to accomplish both the checks and defined assignments.
Thanks again
Paul
On 17 September 2015 at 15:43, Mikael Morin wrote:
> Le 06/09/2015 18:40, Paul Richard Thomas a écrit :
>>
>> It helps to attach the patch :-)
>>
>> Paul
>>
>> On 6 September
Could somebody review this please?
Thanks
Paul
-- Forwarded message --
From: Paul Richard Thomas
Date: 6 September 2015 at 18:40
Subject: Re: [Patch, fortran] PR40054 and PR63921 - Implement pointer
function assignment - redux
To: Dominique Dhumieres , "fort...@gcc.gn
Dear All,
The attached patch fixes a memory leak, prevents writing of smod
files, when there are no submodules and adds a paragraph to the
gfortran documentation on submodules.
After this, PR66762, which is the -flto problem, is the last one to
sort out in order to complete the implementation of
Dear FX,
I am puzzled by this business of the SAVE_EXPR:
First, I agree entirely that it is a mystery as to why the SAVE_EXPR
appears. It does not do so for array elements nor for arrays.
Secondly, as far as I can tell, SAVE_EXPR_RESOLVED_P(…) merely implies
that a pointer to a tree is returned.
Committed as revision 227648.
Thanks for the review and for the PR.
Paul
On 10 September 2015 at 16:22, FX wrote:
>> 2015-08-10 Paul Thomas
>>
>>PR fortran/66993
>>* module.c (read_module): If a symtree exists and the symbol has
>>been associated in a submodule from a parent (s
Dear All,
This is a very straight forward patch of a problem picked up by
Mikael. Since module symbols host associated in the submodule
statement are read using the use association mechanism, the can be
wrongly detected as being ambiguous with use associated symbols. The
latter have precedence, si
Dear FX,
Thanks. I was waiting to resolve this issue before documenting
submodules. I will write something to go with this patch.
There are three PRs out there for submodules:
52846 - submodule support, which I do not want to close until
66993 - host association problem ... is fixed. <= Reall
exit without writing smod file
if it reset.
2015-07-23 Paul Thomas
* gfortran.dg/public_private_module_5.f90: Add module procedure
trigger_smod to ensure that the smod file is written.
On 9 September 2015 at 15:10, Paul Richard Thomas
wrote:
> Dear FX,
>
> In other wor
Dear All,
This is something of a corner case, where gfc_conv_expr comes back
with a SAVE_EXPR, in the case of complex, scalar, coarray lvalues. The
first field of the SAVE_EXPR is a perfectly viable expression to
assign to, so I have taken that. If anybody out there has a better
solution, please s
It helps to attach the patch :-)
Paul
On 6 September 2015 at 13:42, Paul Richard Thomas
wrote:
> Dear All,
>
> The attached patch more or less implements the assignment of
> expressions to the result of a pointer function. To wit:
>
> my_ptr_fcn (arg1, arg2...) = expr
>
&g
Dear All,
The attached patch more or less implements the assignment of
expressions to the result of a pointer function. To wit:
my_ptr_fcn (arg1, arg2...) = expr
arg1 would usually be the target, pointed to by the function. The
patch parses these statements and resolves them into:
temp_ptr => m
Dear FX and Mikael,
Please hold off on reviewing the patch until I say so. Some rather
trivial looking tidying up before submission has introduced a dozen or
so regressions :-(
Cheers
Paul
On 27 August 2015 at 16:54, FX wrote:
> Hi Paul,
>
> I’ll get to reviewing the patch tonight or tomorrow…
Dear All,
The attached patch more or less implements the assignment of
expressions to the result of a pointer function. To wit:
my_ptr_fcn (arg1, arg2...) = expr
arg1 would usually be the target, pointed to by the function. The
patch parses these statements and resolves them into:
temp_ptr => m
ubmodules) was in turn triggered by the example given for
> F08/128, by Daniel Chen from IBM.
> And indeed this seems to have caused some grief to other implementors.
>
> Cheers
> Reinhold
>
>> -Ursprüngliche Nachricht-
>> Von: Paul Richard Thomas [mailto:paul.r
Dear All,
Has this been occasioned by this thread or have other makes
encountered the same difficulty in implementation?
Cheers
Paul
On 10 August 2015 at 20:57, Bader, Reinhold wrote:
> Hello Toon, all else,
>
> a bit unfortunate, in my opinion (I was present at the discussion).
> I've in the
Sorry - I missed the "global"
Paul
On 9 August 2015 at 09:08, Paul Richard Thomas
wrote:
> Dear FX,
>
> I looks OK to me - as you say, it's rather simple. Good for trunk.
>
> Thanks for the patch
>
> Paul
>
> On 9 August 2015 at 08:27, FX wrote:
&g
Dear FX,
I looks OK to me - as you say, it's rather simple. Good for trunk.
Thanks for the patch
Paul
On 9 August 2015 at 08:27, FX wrote:
> ping
>
> In the apparent absence of the libquadmath maintainers, could a global
> reviewer approve this rather simple patch, please?
>
>
>
>> The attach
Hi FX,
This looks fine to me. OK for trunk.
I am not sure how you communicate the IEEE support to the front, since
you need to be able to support cross-compilation. I identification of
the hardware architecture sufficient?
Cheers
Paul
On 6 August 2015 at 18:11, FX wrote:
> The attached patch
Hi Mikael,
This is OK for trunk.
Thanks for resurrecting the patch.
Cheers
Paul
On 6 August 2015 at 12:11, Mikael Morin wrote:
> Le 29/07/2015 20:35, Mikael Morin a écrit :
>>
>> Hello,
>>
>> I'm unburrying the patch from the thread starting at:
>> https://gcc.gnu.org/ml/gcc-patches/2014-03/m
Hi Mikael,
This is fine for backporting.
Thanks for doing this.
Paul
On 6 August 2015 at 12:09, Mikael Morin wrote:
> Le 25/07/2015 20:33, Mikael Morin a écrit :
>>
>> Le 21/07/2015 23:10, Paul Richard Thomas a écrit :
>>>
>>> On 21 July 2015 at 14:53, Mik
Dear Mikael,
Well spotted! This is fine for trunk, since it is 'obvious' once seen.
Cheers
Paul
On 6 August 2015 at 12:07, Mikael Morin wrote:
> Le 19/04/2015 16:54, Mikael Morin a écrit :
>>
>> Hello,
>>
>> while working on pr65792, I noticed that gfc_trans_scalar_assign's
>> l_is_temp and de
ule_5.f08
Sendinggcc/testsuite/gfortran.dg/submodule_9.f08
Sendinggcc/testsuite/lib/fortran-modules.exp
Transmitting file data ...
Committed revision 226622.
The final step is documentation and wiki updates.
Cheers
Paul
On 4 August 2015 at 11:40, Paul Richard Thomas
release of 6 branch.
Once committed, I will get on with the documentation and updating of
gfortran wiki.
Cheers
Paul
On 3 August 2015 at 17:39, Mikael Morin wrote:
> Le 03/08/2015 14:36, Paul Richard Thomas a écrit :
>>
>> Dear Mikael,
>>
>> Thanks for your green light
if this is
not sufficient? Within submodule scope, an advisory could be given for
undefined references to suggest recompiling the module without
optimization or making the entities public.
Cheers
Paul
On 3 August 2015 at 12:44, Mikael Morin wrote:
> Le 29/07/2015 17:08, Paul Richard Thoma
Dear All,
I have committed a patch for this PR as revision 226464, since it is
utterly trivial and obvious.
I will wait a few days before committing it to 5 branch.
Cheers
Paul
2015-08-01 Paul Thomas
PR fortran/67091
* trans-intrinsic.c (gfc_conv_associated): Add the pre and post
Dear All,
My reply is the same as FX's. However, I am perfectly happy to
eliminate the initialization. The correct state is ensured by
gfc_dump_module.
Cheers
Paul
On 29 July 2015 at 17:31, FX wrote:
>> Why do you initialize a static variable to false?
>
> You mean because false is equal to ze
Dear All,
On 24 July 2015 at 10:08, Damian Rouson wrote:
> I love this idea and had similar thoughts as well.
>
> :D
>
> Sent from my iPhone
>
>> On Jul 24, 2015, at 1:06 AM, Paul Richard Thomas
>> wrote:
>>
>> Dear Mikael,
>>
>> It had c
Dear All,
In the words of Jean-Luc Picard, "I will make it so "
Paul
On 24 July 2015 at 10:08, Damian Rouson wrote:
> I love this idea and had similar thoughts as well.
>
> :D
>
> Sent from my iPhone
>
>> On Jul 24, 2015, at 1:06 AM, Paul Richard Th
file
is output.
With best regards
Paul
On 23 July 2015 at 17:42, Mikael Morin wrote:
> Hello Paul,
>
> Le 23/07/2015 09:46, Paul Richard Thomas a écrit :
>>
>> Since all the private entities in a module have to be transmitted to
>> their descendant submodules, whil
amian Rouson wrote:
>
>
>> On Jul 23, 2015, at 12:46 AM, Paul Richard Thomas
>> wrote:
>>
>> Since all the private entities in a module have to be transmitted to
>> their descendant submodules, whilst keeping them hidden from normal
>> use statements, I ha
Dear All,
This is the third and final patch to implement submodules in gfortran.
It is the part that deals with private module entities. Unfortunately,
it is the most invasive and I would either like to have strong support
for it to be committed or a bright idea as to how to do it otherwise.
Sinc
Hi Mikael,
This looks fine to me - OK for trunk.
Thanks for the patch
Paul
On 21 July 2015 at 14:53, Mikael Morin wrote:
> Hello,
>
> The fix for PR61831 committed recently [1] introduced/uncovered a NULLL
> pointer dereference with iso_varying_string, because a generic symbol (which
> has a N
.
>>
>> Regards,
>> Andre
>>
>> On Wed, 15 Jul 2015 13:40:29 +0200
>> Paul Richard Thomas wrote:
>>
>> > Dear Andre,
>> >
>> > I am still in the bizarre situation that the testcase compiles and
>> > run
ubmodule_3.f90: Clean up submodules
* gfortran.dg/submodule_4.f90: Clean up submodules
* gfortran.dg/submodule_5.f90: Clean up submodules
* gfortran.dg/submodule_6.f90: Clean up submodules
* gfortran.dg/submodule_7.f90: Clean up submodules
* gfortran.dg/submodule_8.f90: New test
Dear Andre,
I am still in the bizarre situation that the testcase compiles and
runs correctly on a clean trunk!
That said, the patch applies cleanly and, at very least from my point
of view, does not do any harm :-)
OK for trunk
Thanks for the patch
Paul
On 11 July 2015 at 14:08, Andre Vehres
f a submodule is the pair (ancestor module
> name,
> submodule name) according to 11.2.3, para 2 of the Fortran 2008 standard. So
> I think the error message is spurious.
>
> Cheers
> Reinhold
>
>> -Ursprüngliche Nachricht-
>> Von: Paul Richard Thomas [mailto:pau
PS I forgot to add that I have added a submodule file cleanup
procedure to fortran-modules.exp and cleanup lines to each of the
submodule testcases, such as:
! { dg-final { cleanup-submodules "color_points_a" } }
Paul
On 14 July 2015 at 13:10, Paul Richard Thomas
wrote:
Dear All,
Reinhold Bader has pointed out the naming the submodule files after
the submodule name and using .mod as the extension can potentially
lead to clashes. Therefore, I have written a patch to change gfortran
to follow the naming convention of another leading brand:
submodule filename = mod
a legal expression. Did you mean
> something like rank_remap = ss->dimen < ndim && ndim != 0, or the like?
>
> Regards,
> Andre
>
> Am 6. Juli 2015 21:36:18 MESZ, schrieb Paul Richard Thomas
> :
>>Dear Andre,
>>
>>Whilst it is probably OK in most
Dear Andre,
Whilst it is probably OK in most circumstances, I would change:
s/rank_remap = ss->dimen < ndim/rank_remap = ss->dimen < ndim != 0
Apart from that, it is indeed OK for trunk, in spite of your expectations :-)
Thanks for the patch
Paul
On 6 July 2015 at 14:58, Andre Vehreschild wro
Dear Andre,
I agree with Steve's recommendation that you comment out the line and
open a PR for the problem.
The patch looks fine to me and applied cleanly, apart from trailing
CRs in the testcases.
OK by me too.
Cheers
Paul
PS I felt safe in setting a deadline for the submodule patch because
Dear All,
Committed as revision 225354.
Compared with the submitted version, I have added another test -
submodule_7.f90. This is a slightly tweaked version of the example in
the F2008 standard. In order to get it to compile, the error produced
by the main program's interface block was suppressed
XTERNAL as if they were use associated.
2015-06-30 Paul Thomas
PR fortran/52846
* gfortran.dg/submodule_1.f90: New test
* gfortran.dg/submodule_2.f90: New test
* gfortran.dg/submodule_3.f90: New test
* gfortran.dg/submodule_4.f90: New test
* gfortran.dg/submodule_5.f90: New test
tion. The function result as
> declared
> in the module procedure interface is not propagated to the submodule that
> uses the
> argument/resultless form in the implementation.
>
> Cheers
> Reinhold
>
>> -----Ursprüngliche Nachricht-
>> Von: Paul Richard
fortran.dg/submodule_2.f90: New test
* gfortran.dg/submodule_3.f90: New test
* gfortran.dg/submodule_4.f90: New test
* gfortran.dg/submodule_5.f90: New test
On 22 June 2015 at 14:39, Paul Richard Thomas
wrote:
> Dear All,
>
> This patch enables submodule support in gfortran. Subm
Dear Andre,
It was indeed the associate(pam => im(:, c)) that I had in mind. If
you have that working and in the tescase, that's good enough for me.
Cheers
Paul
On 22 June 2015 at 17:15, Andre Vehreschild wrote:
> Hi Paul,
>
> On Mon, 22 Jun 2015 16:04:09 +0200
> Paul R
Hi Andre,
Some questions: The first and second chunks look a bit awkward in
parse.c. Do they have to be there in order that primary.c does the
right thing? Could the whole lot be transferred to resolve.c or would
that make it horribly messy? I couldn't apply the patch right now -
does it work with
Dear All,
This patch enables submodule support in gfortran. Submodules are a
feature of F2008 but are fully described in ISO/IEC TR 19767:2004(E).
The patch has one significant non-conformance (that I know about,
anyway!); whilst private derived type components are correctly dealt
with, symbols w
ially since the patch was heading towards bit-rot because I have
been so long in getting back to it.
Committed to trunk as revision 224383.
Cheers
Paul
On 25 May 2015 at 19:33, Mikael Morin wrote:
> Le 25/05/2015 09:30, Paul Richard Thomas a écrit :
>> Dear All,
>>
>> Lets see
801 - 900 of 1227 matches
Mail list logo
