https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103368
--- Comment #8 from paul.richard.thomas at gmail dot com ---
Hi Harald,
I simply copied all the associated functions in trans-expr.cc from mainline
and plonked them in 13-branch. That's why I said that I hadn't done any
weeding. There is also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106987
--- Comment #8 from paul.richard.thomas at gmail dot com ---
Hi Harald,
After a lot of messing around, I managed to backport the patch; essentially
by hand. However, two of the testcases ICEd in trans-array.cc and so there
were obviously
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106987
--- Comment #7 from paul.richard.thomas at gmail dot com ---
Hi Harald,
I will have a stab at backporting r14-1629 later this afternoon and will
let you know what happens. I am just rebuilding after applying the fix for
pr112407 (yes, I did
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87448
--- Comment #6 from paul.richard.thomas at gmail dot com ---
Hi Harald,
I had forgotten about this PR because the fix became incorporated in the
patch for PR89645. In consequence, pr87448.f90 disappeared from the pr87477
failures :-)
One
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108961
--- Comment #8 from paul.richard.thomas at gmail dot com ---
Hi Harald,
I have just returned from a trip to the General Atomics DIIID facility
in San Diego and feel like death warmed up :-(
I'll try to get to the backport this afternoon once
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109066
--- Comment #4 from paul.richard.thomas at gmail dot com ---
Hi Steve,
Indeed - I found that paragraph shortly after writing. Thanks for posting
it.
Cheers
Paul
On Thu, 9 Mar 2023 at 15:33, kargl at gcc dot gnu.org <
gcc-bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104382
--- Comment #5 from paul.richard.thomas at gmail dot com ---
Hi Thomas,
My stepping out of gfortran activities has been for rather longer than I
expected. I had hoped to have completed the finalization work by now and to
have got
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #17 from paul.richard.thomas at gmail dot com ---
Good morning all,
I have attached the revised patch and an additional testcase. I had totally
forgotten about the class pointer gotcha.
OK for master?
Paul
Fortran: Fix runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96386
--- Comment #3 from paul.richard.thomas at gmail dot com ---
Hi Thomas,
When did it get fixed? I seem to have done so many associate fixes that I
barely know where to start - was it even me?
Lots of the recent PRs are low lying fruit. It's
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=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:
> ht
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 de Thomas
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 f
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=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
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
>
> --- Commen
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, jakub
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=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=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=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=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=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=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=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://gcc.g
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 #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=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_bug.
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=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 same
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=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 J
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 PR has been
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
PR fortran/71880
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=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=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=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
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=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=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=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...@linux
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=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=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 finalization
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=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=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=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 the new
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 mor
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 #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
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)
foo
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
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=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 frontend
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, anlauf at gmx
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
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
<gcc-bugzi...@gcc.gnu.org> wrote:
> https://gc
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 2017
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=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't deduce
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
<gcc-bugzi...@gcc.gnu.org&
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
<gcc-bugzi...@gcc.gnu.org>
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
<gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org
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=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
<gcc-bugzi...@gcc.gnu.org> wrote:
&
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
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 (, gfc_call_free
(tmp));/gfc_add_expr_to_block (>post, gfc_call_f
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
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=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=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
<gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/sho
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
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
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
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
<gcc-bugzi...@gcc.gnu.
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72699
--- Comment #5 from paul.richard.thomas at gmail dot com ---
Hi Dominique,
You are quite right about the revision that fixes this PR, whose
existence I hadn't noticed. Thanks for closing it.
Cheers
Paul
On 5 August 2016 at 14:13, dominiq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147
--- Comment #13 from paul.richard.thomas at gmail dot com ---
Dear Dominique,
With one thing and another, I completely forgot about the backport.
Yes, please do. I am not able to do commits fo the next week.
Thanks
Paul
On 30 July 2016 at 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71883
--- Comment #6 from paul.richard.thomas at gmail dot com ---
Hi Steve,
Thanks, you beat me to it!
Cheers
Paul
PS Since I caused this regression, perhaps I should take it on :-)
On 22 July 2016 at 16:45, kargl at gcc dot gnu.org
<gcc-bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147
--- Comment #11 from paul.richard.thomas at gmail dot com ---
When I have a moment, I intend to fix 5- and 6-branches.
Cheers
Paul
On 22 June 2016 at 16:12, dominiq at lps dot ens.fr
<gcc-bugzi...@gcc.gnu.org> wrote:
> https://gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265
--- Comment #15 from paul.richard.thomas at gmail dot com ---
Dear Ian,
Aaah, OK. I was rather impressed by what you had done with the first bug :-)
For some reason, one of the symbols is not being committed. I will try
and figure out why
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
<gcc-bugzi...@gcc.gnu.org> wrote:
&
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
<gcc-bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69385
--- Comment #14 from paul.richard.thomas at gmail dot com ---
Hi Janus,
Would you be so good as to OK this patch to the list?
Thanks
Paul
On 22 January 2016 at 12:50, janus at gcc dot gnu.org
<gcc-bugzi...@gcc.gnu.org> wrote:
&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69385
--- Comment #6 from paul.richard.thomas at gmail dot com ---
Dear Janus,
It's good to hear from you.
As you will have seen, I have posted a fix for the first problem and
have another fix in the pipeline for the problem in comment #5.
I'll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
--- Comment #18 from paul.richard.thomas at gmail dot com ---
It works for me - a mystery for tomorrow :-)
Paul
On 29 December 2015 at 23:10, dominiq at lps dot ens.fr
<gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070
--- Comment #27 from paul.richard.thomas at gmail dot com ---
...so ragged in fact that it fails at all levels of optimization I
have not had time these last days to come back to it and understand
why. Something for the holidays!
Paul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68676
--- Comment #5 from paul.richard.thomas at gmail dot com ---
As promised, I am working to fix this. Thanks for your contributions.
Paul
On 4 December 2015 at 10:59, ubizjak at gmail dot com
<gcc-bugzi...@gcc.gnu.org> wrote:
&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68243
--- Comment #4 from paul.richard.thomas at gmail dot com ---
Sorry! Wrong PR.
On 8 November 2015 at 11:18, pault at gcc dot gnu.org
<gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68243
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68216
--- Comment #4 from paul.richard.thomas at gmail dot com ---
Dear Dominique,
I think that a meta-bug would be an excellent idea. I am 5
regressions away from a fix for this PR. I'll get the patch to you
over the weekend.
Many thanks for your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57117
--- Comment #11 from paul.richard.thomas at gmail dot com ---
Dear Dominique,
That's odd, it does fine with reshape on my machine sigh
Could you send me the error, please?
pack generates a completely new ICE in the most peculiar place
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57117
--- Comment #7 from paul.richard.thomas at gmail dot com ---
Dear Dominique,
That is entirely possible. I concentrated exclusively on reshape. I
will have a look at the original problem later.
Thanks a lot
Paul
On 28 October 2015 at 18:24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67933
--- Comment #8 from paul.richard.thomas at gmail dot com ---
Thanks for the heads up.
There is something wierd going on here - There is no sign of this
error on my system. Obviously, I will remove the testcase this evening
and will try to fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65045
--- Comment #8 from paul.richard.thomas at gmail dot com ---
I have been working my through my backlog of patches/PRs as you might
have noticed. This one, being a regression is next but two :-)
Cheers
Paul
On 27 October 2015 at 18:30, dominiq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67977
--- Comment #5 from paul.richard.thomas at gmail dot com ---
Hi David,
Yes it does. Thank you for bring this PR to my attention. I'll mark it
appropriately.
Cheers
Paul
On 19 October 2015 at 13:42, davidgkinniburgh at yahoo dot co.uk
<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52010
--- Comment #10 from paul.richard.thomas at gmail dot com ---
Hi Dominique,
I was about to close this one right now :-)
Thanks
Paul
On 18 October 2015 at 22:54, dominiq at lps dot ens.fr
<gcc-bugzi...@gcc.gnu.org> wrote:
&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67567
--- Comment #9 from paul.richard.thomas at gmail dot com ---
Fixed as 'obvious' in revision: 228169.
Cheers
Paul
2013-09-26 Paul Thomas <pa...@gcc.gnu.org>
PR fortran/67567
* resolve.c (resolve_fl_procedure): For module proc
1 - 100 of 176 matches
Mail list logo
