https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65045
--- Comment #4 from paul.richard.thomas at gmail dot com ---
Hi Tobias,
Thanks. I found one or two similar testcases that still fail. As soon
as I find some time, I will submit a complete fix.
How was the sailing in Scotland?
Paul
On 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64952
--- Comment #6 from paul.richard.thomas at gmail dot com ---
Dear Mikael,
The pureness is also confused by the C pure, which is whiter than
white pure. I agree with your last remark about the standards
committee needing to reflect on this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58754
--- Comment #9 from paul.richard.thomas at gmail dot com ---
Ah that's a pity. I thought that 5.0 had closed when Tobias was
panicking about his co-array patch. I didn't think to check.
Cheers
Paul
On 17 April 2015 at 18:03, domi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #15 from paul.richard.thomas at gmail dot com ---
I hadn't forgotten - I will be back in France tomorrow night and will deal
with it then.
Cheers
Paul
On Jan 26, 2014 3:31 PM, "mikael at gcc dot gnu.org" <
gcc-bu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60066
--- Comment #7 from paul.richard.thomas at gmail dot com ---
The patch submission (1st February) said:
"That must be one of the fastest reviews on record!
Committed as revision 207389
4.7 and 4.8 to follow next weekend."
Given
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60066
--- Comment #9 from paul.richard.thomas at gmail dot com ---
Dear All,
I propose to add the attached to the testsuite. It is the testcase
from PR60066, which was fixed by the patch for PR59066.
OK for trunk, 4.8 and 4.7?
On 5 February 2014 12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49636
--- Comment #6 from paul.richard.thomas at gmail dot com ---
Dear Dominique,
Thanks for the heads-up about -m32 - I thought that the code would be
immune to word length changes ***sigh***
Cheers
Paul
On 12 February 2014 00:40, dominiq at lps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59198
--- Comment #8 from paul.richard.thomas at gmail dot com ---
Hi Tobias,
I tried giving rng_t a component to avoid that - it didn't work :-(
Cheers
Paul
On 22 February 2014 16:35, burnus at gcc dot gnu.org
wrote:
> http://gcc.gnu.org/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59198
--- Comment #10 from paul.richard.thomas at gmail dot com ---
A further small remark, when the explicit interface for obs1_int is
turned to a subroutine, everything works perfectly. I am homing in on
this as being the source of the trouble; I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59198
--- Comment #12 from paul.richard.thomas at gmail dot com ---
Dear Tobias,
I think that I have see the light! In a particularly uninteresting
part of our Board Meeting, I took a look at the Doxygen documentation
of the compiler. I was trying
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66762
--- Comment #6 from paul.richard.thomas at gmail dot com ---
We need to get an lto expert to take a look.
Cheers
Paul
On 6 September 2015 at 03:13, dominiq at lps dot ens.fr
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66
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
PR fortran/67567
* resolve.c (resolve_fl_procedure): For module procedures, ta
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
wrote:
> https://gcc.gnu.org/bugzi
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=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=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=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=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
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
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
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68243
>
> --- Comment #3 from Paul Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55901
--- Comment #11 from paul.richard.thomas at gmail dot com ---
Hi Harald,
Happy New Year! I have been away in Claifornia these last few weeks and
just got back last night.
I am working with Andre on pr60255 tonight. Once this is done, we should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64578
paul.richard.thomas at gmail dot com
changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64578
--- Comment #10 from paul.richard.thomas at gmail dot com ---
This fixes the other part of the problem:
*** gfc_trans_pointer_assignment (gfc_expr *
*** 6917,6922
--- 7033,7039
rse.expr = gfc_class_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57959
paul.richard.thomas at gmail dot com
changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57959
--- Comment #5 from paul.richard.thomas at gmail dot com ---
The incorrect PR numbers in the Change Logs have been corrected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64578
--- Comment #14 from paul.richard.thomas at gmail dot com ---
Ignore comment 13! I screwed up the Change Logs for PR57959.
Paul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57959
--- Comment #6 from paul.richard.thomas at gmail dot com ---
Committed to trunk as revision 219818. Change logs correct in 219819.
Sorry for the mess.
Paul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64578
--- Comment #15 from paul.richard.thomas at gmail dot com ---
(In reply to Dominique d'Humieres from comment #12)
> AFAICT gfortran.dg/unlimited_polymorphic_21.f90 has not yet been committed.
You are absolutely correct. I just notice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044
paul.richard.thomas at gmail dot com
changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044
--- Comment #10 from paul.richard.thomas at gmail dot com ---
Hi Mikael,
Yes, you will see from my comment on the PR that I had come to the
same conclusion. However, rather than take PR62044 as a place holder,
I will open a new PR. Thanks for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044
--- Comment #11 from paul.richard.thomas at gmail dot com ---
Dear Dominique,
For some reason, the hash values are different in the vtable and the
TYPE IS. I had always worried that that we would have different names
giving the same hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044
--- Comment #12 from paul.richard.thomas at gmail dot com ---
Dear All,
As I just said on #gfortran, the previous explanation is wrong. The
problem is that, for the mold= case with no default initializer, the
code->expr winds up being N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64932
--- Comment #4 from paul.richard.thomas at gmail dot com ---
Dear All,
It would be nice to commit this tonight, if possible. An impetus to do
this is added by Dominique pointing out that it fixes PRs 59765, 60529
and 61766!
Cheers
Paul
On 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63553
--- Comment #7 from paul.richard.thomas at gmail dot com ---
For sure. Please do.
Thanks
Paul
On 11 February 2015 at 18:25, dominiq at lps dot ens.fr
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63553
>
> Dominique d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986
--- Comment #3 from paul.richard.thomas at gmail dot com ---
Dear Uros and Dominique,
I'll try to get to this when I can. I have a horrible feeling that it
is the old problem of array constructors within array constructors all
of whic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63553
paul.richard.thomas at gmail dot com
changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63205
paul.richard.thomas at gmail dot com
changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63205
paul.richard.thomas at gmail dot com
changed:
What|Removed |Added
Attachment #33834|0 |1
is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63205
paul.richard.thomas at gmail dot com
changed:
What|Removed |Added
Attachment #33995|0 |1
is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55901
paul.richard.thomas at gmail dot com
changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55901
--- Comment #9 from paul.richard.thomas at gmail dot com ---
By the way, the patch of comment 8 bootstraps and regtests OK
Paul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59198
--- Comment #17 from paul.richard.thomas at gmail dot com ---
However, it is a patch that doesn't do the job.
Cheers
Paul
On Dec 26, 2014 2:35 PM, "dominiq at lps dot ens.fr" <
gcc-bugzi...@gcc.gnu.org> wrote:
> http
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61780
--- Comment #3 from paul.richard.thomas at gmail dot com ---
Dear Mikael,
I didn't see your posting, which was about an hour before mine. At
least we came to the same conclusion!
Thanks
Paul
On 12 July 2014 13:43, mikael at gcc dot gn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61780
--- Comment #6 from paul.richard.thomas at gmail dot com ---
Dear Richie,
Thanks for doing that. I was going to do 4.8 as soon as I had a
moment and would have changed the summary then. As it happens, I was
distracted by other activities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #32 from paul.richard.thomas at gmail dot com ---
Dear Dominique,
The problem is due to:
atmp.10.offset = 0;
{
integer(kind=8) S.12;
S.12 = 0;
while (1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #34 from paul.richard.thomas at gmail dot com ---
Hi Dominique,
Should one be getting false? It seems to me that the code looks right.
within the do loop:
new_prt_spec ([string_t's]) produces an array of string_t's whose
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
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.
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
On
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
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67
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.
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
wrote:
> https://gcc.gnu.org/bugzi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846
--- Comment #10 from paul.richard.thomas at gmail dot com ---
Hi Salvatore,
If you could reduce the source that produces this error for me, I
would be grateful. By the looks of it, the name mangling is
functioning correctly but is picking up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986
--- Comment #13 from paul.richard.thomas at gmail dot com ---
Dear Mikael,
A good principle in general is to assume cock-up, rather than
conspiracy :-) The reason for this spreading between two functions is
incremental development done at very
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66079
--- Comment #11 from paul.richard.thomas at gmail dot com ---
Hi Mikael,
It looks like my finger slipped on the mouse wheel - I'll put it right tonight.
Thanks
Paul
On 4 August 2015 at 11:27, mikael at gcc dot gnu.org
wrote:
&g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67174
--- Comment #4 from paul.richard.thomas at gmail dot com ---
Dear Rainer,
I am not so sure that it is a kernel bug but, rather, it could be a
gcc bug that is affected by differences in the kernel. It seems to me
that this has crept in since
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48059
--- Comment #9 from paul.richard.thomas at gmail dot com 2011-03-11 15:51:31 UTC ---
Janus,
That looks like the right way to go. Do you understand how this can
be a regression, whilst the correct interface mapping was previously
not present
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48059
--- Comment #12 from paul.richard.thomas at gmail dot com 2011-03-12 16:07:47 UTC ---
Ha! That's what I suspected.
Good. I'll OK the submission.
Thanks
Paul
PS I'll keep quiet about it being a bit of a dubious "regressi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48955
--- Comment #6 from paul.richard.thomas at gmail dot com 2011-05-16 12:48:32 UTC ---
Indeed - I just need to find the time to sort out the logic.
Structurally the patch is OK.
Cheers
Paul
On Mon, May 16, 2011 at 9:56 AM, burnus at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46339
--- Comment #18 from paul.richard.thomas at gmail dot com 2010-11-16 15:04:39 UTC ---
Dear Tobias,
> If my understanding is correct, we can either try to extend the 'span' hack to
> make it work for more cases - or we defer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46678
--- Comment #13 from paul.richard.thomas at gmail dot com 2010-12-02 13:33:38 UTC ---
Semms to me that Jerry should do the honours :-)
Paul
On Thu, Dec 2, 2010 at 1:45 PM, burnus at gcc dot gnu.org
wrote:
> http://gcc.gnu.org/bugzi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48955
--- Comment #11 from paul.richard.thomas at gmail dot com 2011-05-24 09:43:32 UTC ---
Dear Thomas,
> With your patch, what is the difference between GFC_CAN_REVERSE
> and GFC_REVERSE_NOT_SET?
Perhaps GFC_REVERSE_ENABL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47516
--- Comment #7 from paul.richard.thomas at gmail dot com 2011-06-18 08:45:08 UTC ---
Dear All,
It was never there for me :-)
Yes, please close it.
Cheers
Paul
On 6/17/11, burnus at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzi
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=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
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi
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
wrote
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=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, domin
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
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 on with
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=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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116040
--- Comment #2 from paul.richard.thomas at gmail dot com ---
I am away on business right now and cannot deal with this. The plan is to
revert the backport. Please feel free to do this because I am likely to be
seriously jet lagged over the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116261
--- Comment #4 from paul.richard.thomas at gmail dot com ---
Hi Harald,
I logged various regressions before going on vacation. I'll be back
in action next week.
Regards
Paul
On Tue, 13 Aug 2024 at 20:58, anlauf at gcc dot gnu.org
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. The
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 of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83209
--- Comment #12 from paul.richard.thomas at gmail dot com ---
Yes, indeed.
Thanks
Paul
On Thu, 11 Jul 2024 at 12:28, vehre at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83209
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115700
--- Comment #15 from paul.richard.thomas at gmail dot com ---
Hi Harald,
Yes indeed. This has already been flagged up by the folk at Arm. I was
going to remove that test today. The functional test is done in
associate_70.f90 in any case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118640
--- Comment #3 from paul.richard.thomas at gmail dot com ---
Hi Jakub,
I'll take it just as soon as I am in a position to do so - likely Sunday
night or Monday morning.
Thanks for the reduction.
Paul
On Fri, 24 Jan 2025, 13:39 jakub a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100818
--- Comment #5 from paul.richard.thomas at gmail dot com ---
Hi Thomas,
Thanks, that does indeed explain it. The é in José?
I have put Sandra in copy because I just wrote to her about these PRs a few
minutes ago.
Obrigado
Paul
On Sun, 13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119948
--- Comment #13 from paul.richard.thomas at gmail dot com ---
Oh s***t! Don't do that - post in the existing PR.
I must confess that I looked at the second testcase and couldn't see the
difference. I'll put stronger glasses on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103391
--- Comment #9 from paul.richard.thomas at gmail dot com ---
That was a question at the end, not a statement :-) I cannot see anything
wrong with the test case but wondered if one of the more eagle-eyed of us
could see a standardese problem
101 - 184 of 184 matches
Mail list logo