https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92976
--- Comment #5 from paul.richard.thomas at gmail dot com ---
Hi Thomas,
Many thanks - you are a scholar and a gentleman, as they say in Ireland.
I will need to discuss with you the messages associated with pushing
patches; how does one push an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320
--- Comment #15 from paul.richard.thomas at gmail dot com ---
Bother - I left the diagnostic line in the patch:
+ gfc_warning_now (0, "s1 %i s2 %i \n", s1->as->type, s2->as->type);
Sorry about that
Paul
On
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325
--- Comment #14 from paul.richard.thomas at gmail dot com ---
Hi Steve,
Your opinion of git and the change over to it is much the same as mine. I
have given it a go but had several "accidents" which put me off for a bit.
As for work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87625
--- Comment #9 from paul.richard.thomas at gmail dot com ---
Bonsoir Dominique,
Je t'en remercie! A petits pas je recommence. Comme Steve Kargl je trouve
le git complètement incompréhensible
mais je retrouve des recettes avec l'aide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325
--- Comment #19 from paul.richard.thomas at gmail dot com ---
Thanks - this has been pointed out to me already by Dominique d'Humieres.
I'll fix tonight or tomorrow.
Paul
On Sun, 2 Aug 2020 at 23:46, ro at gcc dot gnu.org
wrote
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325
--- Comment #20 from paul.richard.thomas at gmail dot com ---
I got caught out by mime content blocking - trying again.
Paul
On Mon, 3 Aug 2020 at 09:26, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Thanks - this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86248
--- Comment #6 from paul.richard.thomas at gmail dot com ---
Hi Bill,
If you look at pr44265, I took over the patch from Ian Sandoe and
fixed one or two of the wrinkles associated with it. I do not seem to
have given it as much thought as I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91863
--- Comment #5 from paul.richard.thomas at gmail dot com ---
Hi Tobias,
It was my intention to commit the patch for PR91926 to 9-branch
tonight. I take it that there was no problem with yours?
Cheers
Paul
On Mon, 28 Oct 2019 at 07:34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92123
--- Comment #8 from paul.richard.thomas at gmail dot com ---
Hi Jakub,
Thanks for spotting that. For whatever reason,
* trans-decl.c (gfc_get_symbol_decl): Assumed shape and assumed
rank dummies of bind C procs require deferred initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92123
--- Comment #21 from paul.richard.thomas at gmail dot com ---
Hi All,
I took one of the other fn_spec's as a template - it might well have
been internal_pack.
Thanks for looking at this.
Cheers
Paul
On Mon, 25 Nov 2019 at 13:04, jak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92785
--- Comment #6 from paul.richard.thomas at gmail dot com ---
Thanks! I'll change to STOP 1.
Paul
On Fri, 28 Feb 2020 at 20:08, drikosev at gmail dot com
wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92785
>
> --- C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55362
--- Comment #7 from paul.richard.thomas at gmail dot com 2013-03-03 18:09:08 UTC ---
Thanks Mikael,
I have been in the middle of one of my "no gfortran periods". I am
back in France next week and will get to this on Tuesday or
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419
--- Comment #64 from paul.richard.thomas at gmail dot com 2012-09-10 10:00:09 UTC ---
Seconded! In return, I promise that, as soon as I have time, I'll
update to 21st century tools :-)
Thanks
Paul
On 9 September 2012 20:17, dominiq at lp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54435
--- Comment #11 from paul.richard.thomas at gmail dot com 2012-09-10 13:10:30 UTC ---
Dear Janus,
Thanks for dealing with that.
Cheers
Paul
On 10 September 2012 14:14, janus at gcc dot gnu.org
wrote:
> http://gcc.gnu.org/bugzi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54690
--- Comment #4 from paul.richard.thomas at gmail dot com 2012-09-24 15:28:52 UTC ---
Looks good to me - why did this pop up now?
On 24 September 2012 16:04, dominiq at lps dot ens.fr
wrote:
>
> http://gcc.gnu.org/bugzilla/show_b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47348
--- Comment #5 from paul.richard.thomas at gmail dot com 2011-01-22 16:50:00 UTC ---
Dear Thomas,
> Paul, this is a case of something (trans-*?) picking up the
> wrong string length and ignoring the substring. Do you have
> any idea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47516
--- Comment #1 from paul.richard.thomas at gmail dot com 2011-01-28 15:14:24 UTC ---
gcc version 4.5.0 20100604??? version is marked as 4.6.0
Paul
On Fri, Jan 28, 2011 at 3:59 PM, burnus at gcc dot gnu.org
wrote:
> http://gcc.gnu.org/bugzi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47519
--- Comment #5 from paul.richard.thomas at gmail dot com 2011-01-31 07:26:23 UTC ---
> This is regtesting as I right but I am sure that it is good.
That does indeed regtest OK.
Paul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47592
--- Comment #1 from paul.richard.thomas at gmail dot com 2011-02-03 07:43:13 UTC ---
Hi Thomas,
I was aware of the potential for functions with side effects to screw
up ALLOCATE with source. I believe that one can persuade the same
thing to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47463
--- Comment #17 from paul.richard.thomas at gmail dot com 2011-02-10 05:24:24 UTC ---
Dear Janus,
> Apparently it's not needed, since removing the line does not introduce any
> regressions in the testsuite. Perhaps it was making up
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46896
--- Comment #15 from paul.richard.thomas at gmail dot com 2011-02-14 13:08:13 UTC ---
Tobias,
You shame me - I undertook to do something with this one and did not.
I do not know that the fix is compatible even with 4.5 - I think not.
I will take
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44945
--- Comment #32 from paul.richard.thomas at gmail dot com 2011-02-19 15:07:03 UTC ---
Dear Tobias,
>
> Aha, you have taken the simple route of modifying trans-decl.c and not the
> whole module reading apparatus :-)
Of course - othe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46244
--- Comment #16 from paul.richard.thomas at gmail dot com 2011-02-21 08:25:51 UTC ---
Dear Mikael,
snip
> Actually none of the gfc_compare_type/gfc_TK_compatible changes are absolutely
> necessary to fix this bug. It is just I fo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47846
--- Comment #1 from paul.richard.thomas at gmail dot com 2011-02-22 10:09:57 UTC ---
Jerry,
You are not the only one :-)
Tobias, I'll take a look-see tonight.
Cheers
Paul
On Tue, Feb 22, 2011 at 10:31 AM, burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44352
--- Comment #14 from paul.richard.thomas at gmail dot com 2011-02-28 06:47:38 UTC ---
Dear Mikael,
It needs the backporting that Thomas suggested. I have been away from
home for a bit and so have not had access to a 4.5 tree. I'll be ba
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
--- Comment #36 from paul.richard.thomas at gmail dot com 2011-10-04 16:04:48 UTC ---
Dear Michael,
I agree - we need the most up to date version to be (re-)submitted. I
will review it.
Cheers
Paul
On Tue, Oct 4, 2011 at 3:17 PM, matz at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
--- Comment #38 from paul.richard.thomas at gmail dot com 2011-10-05 06:40:45 UTC ---
Dear Mikael,
Very good - I'll give it urgent attention as soon as it appears.
Cheers
Paul
On Tue, Oct 4, 2011 at 11:56 PM, mikael at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47844
--- Comment #6 from paul.richard.thomas at gmail dot com 2011-10-05 14:35:14 UTC ---
Dear Tobias and Dominique,
We could fix this in 4.7 by adding a sm field to array descriptors.
If we added the sm field after the dimension array, we would not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
--- Comment #44 from paul.richard.thomas at gmail dot com 2011-10-09 09:48:00 UTC ---
Dear Mikael,
I have duly loaded up your patch - it looks very slick and
professional; it even works as intended!
>>
> This is included in the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50640
--- Comment #19 from paul.richard.thomas at gmail dot com 2011-11-07 11:00:47 UTC ---
Dear Tobias,
I have been keeping out of this for the time being because I want to
get some of the final OOP array issues out of the way. I figured
that, as a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50640
--- Comment #23 from paul.richard.thomas at gmail dot com 2011-11-10 11:09:02 UTC ---
Dear Tobias,
I tried this, in the hope of fixing a problem that I have with the
last big part of the class array patch. To my surprise, it caused
errors like
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52227
--- Comment #3 from paul.richard.thomas at gmail dot com 2012-07-13 15:10:52 UTC ---
Hmmm! OK - I guess that we need
class_pointer/class_target/class_allocatable attributes that are
retained by the symbol, rather than the container.
Cheers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52265
--- Comment #1 from paul.richard.thomas at gmail dot com 2012-02-16 06:58:10 UTC ---
Dear Tobias,
I have encountered this in the work on PR41600. I thought to append a
numeric identifier that increments with each new temporary. In fact,
I had
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58851
--- Comment #3 from paul.richard.thomas at gmail dot com ---
I had changed the testcase to:
! { dg-do run }
!
! PR fortran/58793
!
! Contributed by Vladimir Fuka
!
! Had the wrong value for the storage_size for complex
!
module m
use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58851
--- Comment #5 from paul.richard.thomas at gmail dot com ---
Dear Tobias,
I cannot get to the commit until Sunday night at earliest. Thus, if
you can do it, that would be great. In fact, if you do that, I'll post
the fix for the holl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58851
--- Comment #7 from paul.richard.thomas at gmail dot com ---
Oh damn! Tobias pointed this out to me and I didn't catch on to why
this could happen. I'll fix it tonight.
Sorry about that
Paul
On 30 October 2013 10:23, sch...@linu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58851
--- Comment #10 from paul.richard.thomas at gmail dot com ---
Thanks Tobias,
I was completely perplexed by that - you beat me to the reply by 32 minutes :-)
Cheers
Paul
On 4 November 2013 19:39, burnus at gcc dot gnu.org
wrote:
> h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51529
--- Comment #3 from paul.richard.thomas at gmail dot com 2011-12-14 08:55:08 UTC ---
Dear Tobias,
> However, I do now understand why one needs for SOURCE= to memset the source to
> NULL - at least as long _copy not only copies the data bu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52012
--- Comment #7 from paul.richard.thomas at gmail dot com 2012-01-31 08:23:18 UTC ---
Dear Tobias,
> Thanks for fixing the more pressing issue.
>
> (I think the other issue - second item in comment 4 - is not fixed; at least I
> s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87881
--- Comment #16 from paul.richard.thomas at gmail dot com ---
Hi Jakub,
I don't have access to the source until this evening. You, I think,
must be right. I need to use gfc_replace_expr. I'm trying to do many
things at once - this P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87881
--- Comment #18 from paul.richard.thomas at gmail dot com ---
Exactly
On Wed, 19 Dec 2018 at 09:17, jakub at gcc dot gnu.org
wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87881
>
> --- Comment #17 from Jakub Jeline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56789
--- Comment #20 from paul.richard.thomas at gmail dot com ---
Hi Thomas,
I was mulling this over a few months ago and came to the conclusion
that copy-in/copy-out was the only thing that made sense.
The IBM manual is explicit about this:
https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88810
--- Comment #6 from paul.richard.thomas at gmail dot com ---
Hi Steve and Thomas,
I plead guilty to creating confusing code... It developed step by step
and I didn't go back and consolidate it.
If you can simplify it and still obtain the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91717
--- Comment #4 from paul.richard.thomas at gmail dot com ---
Yes it is - the .false. on entry comes about because the allocatable
component must be deallocated on entry to scope. The reallocation on
assignment takes care of the rest.
Cheers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90297
--- Comment #7 from paul.richard.thomas at gmail dot com ---
At least it is one of the less harmful bits of code that I have introduced :-)
Yes, it can go.
Thanks
Paul
On Sat, 12 Oct 2019 at 01:18, kargl at gcc dot gnu.org
wrote:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83567
--- Comment #5 from paul.richard.thomas at gmail dot com ---
Hi Janne,
I found the problem - thanks for warning me of it.
Cheers
Paul
On 29 December 2017 at 09:25, jb at gcc dot gnu.org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83622
--- Comment #4 from paul.richard.thomas at gmail dot com ---
I can see what is happening: During the allocate, we have
check.dim[0].lbound = 1;
check.dim[0].ubound = 4;
check.dim[0].stride = 1;
check.offset = -1;
but no sign of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83622
--- Comment #6 from paul.richard.thomas at gmail dot com ---
That's what I have been trying to find out :-)
It's jogging my memory but I cannot for the life of me rememeber what
it was about.
Paul
On 4 January 2018 at 22:00, anl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83837
--- Comment #9 from paul.richard.thomas at gmail dot com ---
Hi Jakub,
Thanks truly for fixing this bug. I was planning to revert the change
that I made because I couldn't find any way of correcting the problem
from the fortran fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83999
--- Comment #3 from paul.richard.thomas at gmail dot com ---
Hi Jakub,
I have made the changes to the types of the dtype elements that you
suggested. It led to a cast being needed in
trans-intrinsic.c(gfc_conv_intrinsic_rank) but, apart from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83999
--- Comment #5 from paul.richard.thomas at gmail dot com ---
Hi Jakub,
Thanks for the OK and the help in getting the padding sorted out.
Committed as Committed revision 257065.
Paul
On 24 January 2018 at 20:26, Paul Richard Thomas
wrote
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84088
--- Comment #9 from paul.richard.thomas at gmail dot com ---
Ha! Thanks...
In the main programme:
struct array00_integer(kind=4) desc.3;
desc.3.dtype = {.elem_len=8, .rank=0, .type=11};
desc.3.data = (void * restrict) &z;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141
--- Comment #23 from paul.richard.thomas at gmail dot com ---
Hi Everybody,
I just got in from the lab.. Obviously, I will not be working on this
problem tonight!
I suspect that fact that I have had to pick out allocatable components
for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155
--- Comment #14 from paul.richard.thomas at gmail dot com ---
Hi Dominique,
Thanks for doing that. It was to have been my final step in the process.
I will commit the patch and then will go back to diagnose why an
unchanged tree dump yields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141
--- Comment #37 from paul.richard.thomas at gmail dot com ---
Hi Richi,
> So the fix quite possibly only papers over the problem in general
> - it changes to use a new, non-cached variant in this place but I see
> many more c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87127
--- Comment #6 from paul.richard.thomas at gmail dot com ---
Hi Juergen,
Noted - as it happens, I have an hour or so right now :-)
Cheers
Paul
On Fri, 29 Mar 2019 at 23:08, juergen.reuter at desy dot de
wrote:
>
> https://gcc.g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89841
--- Comment #3 from paul.richard.thomas at gmail dot com ---
It's on its way to being committed this afternoon :-)
Cheers
Paul
On Sat, 30 Mar 2019 at 12:41, dominiq at lps dot ens.fr
wrote:
>
> https://gcc.gnu.org/bugzilla/show
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118
--- Comment #20 from paul.richard.thomas at gmail dot com ---
Hi Rainer,
Thanks a million. Unfortunately, we just missed the 9.1 release.
Cheers
Paul
On Thu, 25 Apr 2019 at 09:59, ro at CeBiTec dot Uni-Bielefeld.DE
wrote:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90297
--- Comment #2 from paul.richard.thomas at gmail dot com ---
dh! Thanks.
Paul
On Wed, 1 May 2019 at 08:27, dcb314 at hotmail dot com
wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90297
>
> David Binder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118
--- Comment #22 from paul.richard.thomas at gmail dot com ---
I'll get lined up to fix this tomorrow night.
Thanks for all the testing.
Regards
Paul
On Sun, 19 May 2019 at 11:58, dominiq at lps dot ens.fr
wrote:
>
> https://
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
--- Comment #5 from paul.richard.thomas at gmail dot com ---
Hi there,
That might well have pinpointed the problem sufficiently.
Thanks
Paul
On Mon, 10 Jun 2019 at 20:18, seurer at gcc dot gnu.org
wrote:
>
> https://gcc.gnu.org/bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
--- Comment #15 from paul.richard.thomas at gmail dot com ---
Hi Thomas,
I had come to the conclusion that the optimizer is screwing up somehow
and was going to suggest testing -fno-inline. Your splitting the files
was definitely the smoking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86408
--- Comment #4 from paul.richard.thomas at gmail dot com ---
Hi Janus,
I see two problems with my patch for PR49630.
(i) It was F2008, not F2003. Bottom of page 535:
C418 (R420 R421 R422) A type-param-value of * shall be used only
• to declare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87359
--- Comment #16 from paul.richard.thomas at gmail dot com ---
Hi Dominique,
Many thanks for coming back so promptly. I will package it up for a
commit this evening.
Best regards
Paul
On 21 September 2018 at 17:12, dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87359
--- Comment #26 from paul.richard.thomas at gmail dot com ---
Jeurgen,
We are extremely pleased that you do follow developments on trunk. It
really helps to catch regressions early, while the changes are fresh
in mind :-)
Sometime, I would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87270
--- Comment #5 from paul.richard.thomas at gmail dot com ---
Hi Janus,
That's wierd. I don't see any final call output with any of the
branches, going back to 6-branch.
I am also puzzled by the lack of calls, given that the fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87359
--- Comment #44 from paul.richard.thomas at gmail dot com ---
Hi Jeurgen,
Thanks for the confirmation. I will take care of a composite fix over
the weeknd. (I get home tomorrow lunchtime.).
Cheers
Paul
On Fri, 28 Sep 2018 at 11:13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56789
--- Comment #10 from paul.richard.thomas at gmail dot com ---
Hi Thomas,
The centre of gravity for this problem is trans-array.c:7905. This is
triggering the packing of the array, which will indeed make the data
contiguous. However, the bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70149
--- Comment #10 from paul.richard.thomas at gmail dot com ---
Thanks Andreas,
I am clearly not casting the initializer correctly. I'll try to figure
out what is correct tomorrow.
Best regards
Paul
On Wed, 3 Oct 2018 at 13:39, sch...@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80945
--- Comment #8 from paul.richard.thomas at gmail dot com ---
Hi Thomas,
It doesn't just ring bells, it lets off sirens and sets the marching
bands to marching!
I can only find rather old sources on the web but I seem to remember
that th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56789
--- Comment #16 from paul.richard.thomas at gmail dot com ---
Hi Thomas,
I think that the copy in/copy out might be rather easy to arrange.
Give me a couple of days.
Paul
On Wed, 3 Oct 2018 at 22:01, tkoenig at gcc dot gnu.org
wrote
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87487
--- Comment #4 from paul.richard.thomas at gmail dot com ---
Dear Rainer,
That's a relief! Thank you for the fast response. I will commit tonight.
Paul
On Thu, 4 Oct 2018 at 12:04, ro at CeBiTec dot Uni-Bielefeld.DE
wrote:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65677
--- Comment #8 from paul.richard.thomas at gmail dot com ---
I am trying to run out. I was stung by some of the comments in the
standards survey about quality of implementation in all brands. This
came out as one of the worst for gfortran so I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84109
--- Comment #7 from paul.richard.thomas at gmail dot com ---
Hi Thomas,
I am going to apply a cumulative deferred character patch to 8-branch
just as soon as the dust has settled on trunk.
Cheers
Paul
On Sat, 6 Oct 2018 at 12:56, tkoenig at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566
--- Comment #4 from paul.richard.thomas at gmail dot com ---
Hi Tobias,
You are grappling with exactly the error that I am grappling with in
backporting my deferred character patches to 8-branch. The problem is
the following and it is specific
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566
--- Comment #5 from paul.richard.thomas at gmail dot com ---
Sorry, forget that last. I got out on the wrong side of the bed I
think. I will take a proper look later.
Cheers
Paul
On Sat, 13 Oct 2018 at 07:45, paul.richard.thomas at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87127
--- Comment #4 from paul.richard.thomas at gmail dot com ---
Hi Tobias,
I have been looking at this one on and off. I think that blocks should
be resolved in the same way as contained procedures; I tried adding
them to the parent contained list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71880
--- Comment #9 from paul.richard.thomas at gmail dot com ---
Not quite fixed. The lhs character length doesn't get set and so it
fails at runtime. I will commit the patch as 'obvious'.
Paul
2018-10-19 Paul Thomas
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69834
--- Comment #2 from paul.richard.thomas at gmail dot com ---
Thanks Thomas! Sorry that I missed your PR.
I wonder what, if anything, we should do about it?
Cheers
Paul
On 16 February 2016 at 11:54, tkoenig at gcc dot gnu.org
wrote:
> ht
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63232
--- Comment #3 from paul.richard.thomas at gmail dot com ---
Hi Dominiq,
It works for me on 5-branch and trunk. Confirmed fixed :-)
Cheers
Paul
On 21 February 2016 at 17:12, dominiq at lps dot ens.fr
wrote:
> https://gcc.gnu.org/bugzi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82064
--- Comment #6 from paul.richard.thomas at gmail dot com ---
Aaaah! I missed the point wrt separate files.
As far as I remember, we make sure that class or derived entities get
their vtable but not unreferenced type declarations.
Cheers
Paul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82184
--- Comment #6 from paul.richard.thomas at gmail dot com ---
Thanks Andrey. I'll get to it as soon as I can.
Paul
On 13 September 2017 at 21:12, andrey.y.guskov at intel dot com
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82184
--- Comment #10 from paul.richard.thomas at gmail dot com ---
Dear Andrey,
Thanks for the confirmation that the fix did the trick.
Cheers
Paul
On 15 September 2017 at 14:55, andrey.y.guskov at intel dot com
wrote:
> https://gcc.gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82184
--- Comment #13 from paul.richard.thomas at gmail dot com ---
Many thanks - it's like currency exchange rate variations; <1% == 0%
Cheers
Paul
On 20 September 2017 at 16:01, andrey.y.guskov at intel dot com
wrote:
> https://
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80477
--- Comment #11 from paul.richard.thomas at gmail dot com ---
Hi Janus,
I'll take a look tonight. I believe, without the source in front of me, that
s/gfc_add_expr_to_block (&post, gfc_call_free
(tmp));/gfc_add_expr_to_block (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80477
--- Comment #16 from paul.richard.thomas at gmail dot com ---
Hi Janus,
The attached does what you want to the testcase. For CLASS objects, it
is the data that has to be copied to a variable, that data freed and
the _data field pointed to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640
--- Comment #31 from paul.richard.thomas at gmail dot com ---
Hi Dominique,
I had suspected that. Thanks for the confirmation!
Cheers
Paul
On 10 June 2017 at 18:46, dominiq at lps dot ens.fr
wrote:
> https://gcc.gnu.org/bugzi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78797
--- Comment #4 from paul.richard.thomas at gmail dot com ---
Hi Janus,
Yes there is one - I had it open but somehow provided the link to the
wrong one...
Paul
On 14 December 2016 at 19:20, janus at gcc dot gnu.org
wrote:
> ht
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78797
--- Comment #5 from paul.richard.thomas at gmail dot com ---
I do apologise, it seems that Mr Reid did not do his usual update. We
will have to work from the draft standard itself.
Paul
On 14 December 2016 at 20:36, paul.richard.thomas at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
--- Comment #13 from paul.richard.thomas at gmail dot com ---
Hi Janus,
Why do you think that both input and output is required?
How is namelist supposed to work with classes? Just with the declared type?
Cheers
Paul
On 17 December 2016 at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
--- Comment #16 from paul.richard.thomas at gmail dot com ---
Dear Janus,
What troubles me is that most times I have used namelist, it has been
primarily for input to codes; especially where there is a default set
of initial conditions
and a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854
--- Comment #5 from paul.richard.thomas at gmail dot com ---
Hi Janus,
Jerry is the expert here.
Cheers
Paul
On 19 December 2016 at 11:59, janus at gcc dot gnu.org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854
>
> --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79382
--- Comment #5 from paul.richard.thomas at gmail dot com ---
Hi Walt,
My reading of the situation is that since, in this version, the
generic procedure is typebound in a public derived type, the PUBLIC
attribute is already accorded it. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71838
--- Comment #14 from paul.richard.thomas at gmail dot com ---
Hi Anton,
Did you take on board that it is the procedure dummy argument that
causes the problem?
A viable workaround is to:
s/procedure( cgca_clvgs_abstract ) :: sub/external :: sub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79434
--- Comment #4 from paul.richard.thomas at gmail dot com ---
Hi Dominiq,
As soon as I have a minute or two, I will back port it. My business is
taking me 7/7 at the moment.
Thanks for the reminder.
Paul
On 26 March 2017 at 17:36, dominiq at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758
--- Comment #17 from paul.richard.thomas at gmail dot com ---
Hi Dmitry,
That's great. I'll let you know how I get on when I return. I knew
that it had to be a complicated pointer assignment or allocation with
source but couldn'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758
--- Comment #20 from paul.richard.thomas at gmail dot com ---
Hi Dmitry,
I will persist with 81758 until I have a satisfactory testcase and
then I promise that I will move to 80850.
Cheers
Paul
On 26 October 2017 at 15:20, liakhdi at ornl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78293
--- Comment #11 from paul.richard.thomas at gmail dot com ---
I rather suspect that was why I had deleted the tree :-)
That's a pity. I am afraid moving from one country to another caused
this PR to get lost.
Cheers
Paul
On 1 November
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77390
--- Comment #2 from paul.richard.thomas at gmail dot com ---
Dear Dominique,
I don't think that the problems are connected. I am having a problem
with a vtable that gets generated in a submodule and so has an address
different from that i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69834
--- Comment #12 from paul.richard.thomas at gmail dot com ---
Hi Dominique,
I was intending to backport to 6-branch but wanted to be sure that no
nasties come out of the woodwork on trunk.
Best regards
Paul
PS Will be back in France late
1 - 100 of 184 matches
Mail list logo
